satosthi started bitcoin talk nov 2009
|521|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 14, 2009, 05:15:56 PM|
Can anyone shed some light here?
g++ -c -O0 -Wno-invalid-offsetof -Wformat
-g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8"
-I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include"
-I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h
ui.h:430: error: no
matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>,
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void
It looks like the implicit conversion from
std::string to wxString isn't working. That's used everywhere, the conversion needs to work.
complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. You can get that problem on Windows if the
"unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char.
some wxWidgets compile defines or build configuration. What "configure" options did you use?
not sure __WXMAC__ is the right define. It may be the Mac Classic support that's complicating wxString, and we only
want OSX. Try __WXOSX__ (or see below)http://docs.wxwidgets.org/stable/wx_cppconst.html
"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic
version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format,
like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which
can only be used under OS X. To summarize:
* If you want to test for all Mac platforms, classic
and OS X, you should test both __WXMAC__ and __WXCOCOA__.
* If you want to test for any GUI Mac port
under OS X, use __WXOSX__.
* If you want to test for any port under Mac OS X, including, for example,
wxGTK and also wxBase, use __DARWIN__"
|522|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 13, 2009, 04:51:25 PM|
There would be a command line switch at runtime to tell it to run
without UI. All it needs to do is not create the main window. A simplistic way would be to disable "pframeMain->Show"
and "ptaskbaricon->Show" in ui.cpp. The network threads don't care that the UI isn't there. The only
other UI is a message box in CheckDiskSpace if it runs out of disk space.
Then a separate command line utility
to communicate with it to do things. Not sure what it should be named.
"natural deflation"... I
like that name for it. Yes, there will be natural deflation due to payment mistakes and lost data. Coin creation
will eventually get slow enough that it is exceeded by natural deflation and we'll have net deflation.
|523|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 12, 2009, 06:17:10 PM|
I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine
here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST!
I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?)
and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.
support would be nice. wxWidgets really pays off for cross platform.
Please don't try PPC. PPC is big-endian
and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a
potentially byte-swapping node out there. PPC is on its way out anyway.
Considered autoconf. Autoconf
is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without
it. I'd rather keep the makefile simple as long as possible.
I think that
breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to
a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should
be fairly simple. Of course an API would have to be developed.
My head hurts just thinking about that. Funnelling
all the UI backend through a TCP connection would make everything twice as hard. There's too much bandwidth between
the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control
I'd rather have command line control, that would get us remote admin and batch automation.
|524|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 12, 2009, 05:52:44 PM|
The average total coins generated across the network per day stays
the same. Faster machines just get a larger share than slower machines. If everyone bought faster machines, they
wouldn't get more coins than before.
We should have a gentleman's agreement to postpone the GPU arms race as long
as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about
GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.
|525|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 11, 2009, 07:27:55 PM|
Right, the SVN has the almost-release-candidate 0.2 source, which
can also be built and run on Linux. It hasn't been tested on FreeBSD.
If we can get to the point where we have a working backend process that will run on FreeBSD
I can run always-on seeds.
That would be a big help. TOR users wouldn't have to worry about how to get seeded,
and we wouldn't depend on IRC.
It can be run in a few simple modes without access to the UI if you don't mind a
minimized window on the desktop. (0.1.5 doesn't have -min so it would be an open window)
To only run a seed:
bitcoin -min -gen=0
You could sort of monitor it by looking at debug.log. To stop it, kill the process,
the database won't mind.
bitcoin -min -gen
To get the generated bitcoins, you'd have
to copy wallet.dat (with version 0.2) to a machine with a UI, swap in the wallet.dat, run bitcoin and transfer the coins to
your main account. (With version 0.1.5 you'd have to copy the whole "%appdata%/Bitcoin" directory.) There
is one caveat about copying wallet.dat: if you happened to kill the program at the exact moment that it generated a coin or
received a payment, wallet.dat might not work by itself and you'd have to copy the whole directory.
I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have
seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the
debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application.
(Just an example).
I see, that would happen with multiple nodes using the same NAT or VPN or some ISP that funnels
everyone through a few proxy servers. I just committed a fix to SVN for this. If it gets "433" name
already in use (it was error 433, right?), it'll retry with a non-address random username.
In any event, I would like to help. I have a lot of time and a project like this one is very exciting.
great, any help is really appreciated!
|526|| Bitcoin / Bitcoin Discussion / Re: Questions about Bitcoin||on: December 11, 2009, 05:58:57 PM|
That's true, with the send-to-IP option, you are sending to whoever
answers that IP. Sending to a bitcoin address doesn't have that problem.
The plan is to implement an IP +
bitcoin address option that would have the benefits of both. It would still use a different address for each transaction,
but the receiver would sign the one-time-use address with the given bitcoin address to prove it belongs to the intended receiver.
|527|| Bitcoin / Bitcoin Discussion / Re: Questions about Bitcoin||on: December 10, 2009, 08:49:02 PM|
For that level of anonymity you need to connect through
TOR, which will be possible with version 0.2, which is only a few weeks away. I'll post TOR instructions at that time.
Version 0.1.5: backup the whole %appdata%\Bitcoin directory.
Version 0.2: you can backup just wallet.dat.
Nope. The whole design is all about preventing that from working.
Those coins can
never be recovered, and the total circulation is less. Since the effective circulation is reduced, all the remaining
coins are worth slightly more. It's the opposite of when a government prints money and the value of existing money goes
It's currently 29,296 blocks. The circulation is the number of blocks times 50, so the current
circulation is 1,464,800 bc.
If you only have 24k blocks, it must not have finished the initial block download.
Exit bitcoin and start it again. Version 0.2 is better/faster at the initial block download.
Typically a few hundred right now. It's easy now but it'll get harder as the network grows.
question, it's TCP. The website needs to be updated to say TCP port 8333.
The port forwarding is so other
nodes can connect to you, so it helps you stay connected because you are able to be connected with more nodes. You also
need it to receive payments by IP address.
No, the other nodes won't accept that.
source means anyone can independently review the code. If it was closed source, nobody could verify the security. I
think it's essential for a program of this nature to be open source.
Slower machines produce fewer coins.
It's proportional to CPU speed.
There are more coming.
It uses a transactional
database called Berkeley DB. It will not lose data in a system crash. Transactions are written to the database
immediately when they're received.
For now, you can just multiply the total blocks by 50. The Bitcoin
network has been running for almost a year now. The design and coding started in 2007.
|528|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 10, 2009, 07:31:49 PM|
Front ends can also be ran on clients with very low cpu power such as mobile phones.
That's a good approach for mobile. Programmatic API used by PHP (any language) to present a web UI covers remote
admin, mobile and any other client that can't be online all the time with a static IP. It would be like webmail.
It would be easier for new users to get started if they only need to create an account on a website, not install software.
The app could be pre-seeded before downloading. Pre-seeding would also cure
the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.
Yeah, we can phase out IRC when
there are enough static nodes to preprogram a seed list. Once you get seeded, you don't need IRC.
Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks
on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).
There were some issues in 0.1.5 where the initial block download could get bogged down. 0.2 has code to make
sure it goes smoothly. It ought to take less than an hour, I think. I need to hurry up and get 0.2 out the door.
The blocks increase linearly, it'll be decades before it's millions. In theory, the block download time should
top out 8 months from now when Moore's Law will be growing faster than the block chain.
Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.
SVN on sourceforge. PM or e-mail me your sourceforge account and I'll give you access.
I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.
That's great because that's
where I have less expertise. For instance, I haven't researched the best way to do the "Start Bitcoin on system
startup" feature on Linux. On Windows, the option adds/removes an icon in the Startup folder.
|529|| Bitcoin / Development & Technical Discussion / Re: A few suggestions||on: December 09, 2009, 06:45:10 PM|
Helpful suggestions, thanks.
- When the bitcoin software establishes a connection with a peer (client TCP socket)
have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons
for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.
That's a good idea. The side accepting the connection just needs to withhold from sending anything until it
receives a valid handshake. Any portscan would only get a dead connection that doesn't volunteer to identify itself.
- Use some sort of encryption during the handshake (sort of goes with the
statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about
people in non-free (as in freedom) countries such as China/Iran.
I have thought about eventually SSLing all the
connections. I assume anything short of SSL would be pointless against DPI. Maybe a better more immediate solution
is to connect through TOR, which will be possible with 0.2.
- Some sort
of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt
mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information
and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments)
outbound. Status could be returned via the https receipt interface.
That's one of the main things on the agenda
- Static port/Random port. Have a setting to randomly assign
the port that it runs on. (also be able to set it statically for very restrictive firewalls).
Yeah, the other stealth
stuff would be kinda pointless if it's always the same port number.
- UPnP support.
Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options
I'm looking forward to trying UPnP. Do most P2P clients typically have UPnP enabled by default?
- Ability to compile a headless (console only) install for *NIX systems.
Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket
would be ok).
I'm still thinking about how best to structure the management interface. Maybe command line
commands to communicate with the background daemon to query transactions received and initiate sending transfers. That
would be more automation friendly. Or what about an http interface on some port other than 80 to manage it with a browser?
|530|| Bitcoin / Bitcoin Discussion / [OLD THREAD] Bitcoin version 0.2 development status||on: November 27, 2009, 10:48:39 PM|
We've been working hard on improvements for the next version release.
Martti (sirius-m) added some nice features to make it more user friendly and easier to run in the background:
Minimize to system tray option
- Autostart on boot option so you can keep it running in the background automatically
- New options dialog layout
- Setup EXE for Windows, in addition to the archive download
been working on a number of refinements to the networking code and laying the groundwork for future functionality. Also
coming in version 0.2:
- Multi-processor support for coin generation
- Proxy support
|531|| Bitcoin / Bitcoin Discussion / Re: Repost: Linux/UNIX compile||on: November 27, 2009, 05:27:09 PM|
The Linux version is on its way. Martti's Linux port was merged
into the main code branch and New Liberty Standard has been testing it. It'll be in the next release, version 0.2.
Command line is on the to-do list after 0.2.
|532|| Bitcoin / Bitcoin Discussion / Repost: Linux/UNIX compile||on: November 27, 2009, 05:17:22 PM|
08 of Oct, 2009 (05:49 UTC)
Can we get instructions or modifications to compile and install BitCoin on Linux? A
command line version would be great.
|533|| Bitcoin / Bitcoin Discussion / Re: Repost: How anonymous are bitcoins?||on: November 25, 2009, 06:17:23 PM|
> Can nodes on the network tell from which and or to which bitcoin
> address coins are being sent? Do blocks contain a history of where
> bitcoins have been transfered to
Bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying
When you send to an IP address, the transaction is still written to a bitcoin address. The IP
address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly
to the recipient and get a confirmation.
Blocks contain a history of the bitcoin addresses that a coin has
been transferred to. If the identities of the people using the bitcoin addresses are not known and each address is used
only once, then this information only reveals that some unknown person transferred some amount to someone else.
possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection
with the bitcoin addresses you use. If you post your bitcoin address on the web, then you're associating that address
and any transactions with it with the name you posted under. If you posted under a handle that you haven't associated
with your real identity, then you're still pseudonymous.
For greater privacy, it's best to use bitcoin addresses
only once. You can change addresses as often as you want using Options->Change Your Address. Transfers by IP
address automatically use a new bitcoin address each time.
> Can nodes tell which bitcoin addresses belong to
which IP addresses?
> Is there a command line option to enable the sock proxy the first
time that bitcoin starts?
In the next release (version 0.2), the command line to run it through a proxy from the
first time is:
The problem for TOR is that the IRC server which Bitcoin uses
to initially discover other nodes bans the TOR exit nodes, as all IRC servers do. If you've already connected once before
then you're already seeded, but for the first time, you'd need to provide the address of a node as such:
If someone running a node with a static IP address that can accept incoming connections
could post their IP to use for -addnode, that would be great.
> What happens if you send bitcoins to an IP address
that has multiple
> clients connected through network address translation (NAT)?
Whichever one you've set
your NAT to forward port 8333 to will receive it. If your router can change the port number when it forwards, you could
allow more than one client to receive. For instance, if port 8334 forwards to a computer's port 8333, then senders could
send to "x.x.x.x:8334"
If your NAT can't translate port numbers, there currently isn't a command
line option to change the incoming port that bitcoin binds to, but I'll look into it.
|534|| Bitcoin / Bitcoin Discussion / Repost: How anonymous are bitcoins?||on: November 25, 2009, 06:15:57 PM|
How anonymous are
Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks
contain a history of where bitcoins have been transfered to and from? Can nodes tell which bitcoin addresses belong to which
IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if
you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?
|536|| Bitcoin / Bitcoin Discussion / Re: Repost: Bitcoin Maturation||on: November 22, 2009, 06:34:21 PM|
It's important to have network connectivity while you're trying to
generate a coin (block) and at the moment it is successfully generated.
1) During generation (when the status bar
says "Generating" and you're using CPU to find a proof-of-work), you must constantly keep in contact with the network
to receive the latest block. If your block does not link to the latest block, it may not be accepted.
2) When you
successfully generate a block, it is immediately broadcast to the network. Other nodes must receive it and link to it
for it to be accepted as the new latest block.
Think of it as a cooperative effort to make a chain. When
you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for
an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several
links since then and they're not going to want to use your link that now branches off the middle.
After a block
is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can
be spent. Your node isn't doing anything with the block during that time, just waiting for other blocks to be added
after yours. You don't have to be online during that time.
|538|| Bitcoin / Bitcoin Discussion / Repost: Bitcoin Maturation||on: November 22, 2009, 06:31:44 PM|
Posted:Thu 01 of Oct, 2009 (14:12 UTC)
From the user's perspective the bitcoin maturation process can be broken
down into 8 stages.
1. The initial network transaction that occurs when you first click Generate Coins.
The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction field to inside it.
4. The time between when the
bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more
5. The change of the Description to Generated (50.00 matures in x more blocks).
6. The time between when
the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.
7 The change
of the Description to Generated.
8. The time after the Description has changed to Generated.
require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)
As far as I know, there's no network transaction when you click Generate Coins - your computer just starts calculating
the next proof-of-work. The CPU usage is 100% when you're generating coins.
In this example, the network
connection is used when you broadcast the information about the proof-of-work block you've created (that which entitles you
to the new coin). Generating coins successfully requires constant connectivity, so that you can start working on the next
block when someone gets the current block before you.