All BitcoinTalk forum posts (539, SNI numbers 5–543), from "Welcome to the new Bitcoin forum!" to "Added some DoS limits, removed safe mode (0.3.19)" (Part 2 of 4)
Document text
Research, not advice. Part of the Bitcoin research archive (October 2026). Claims labelled unverified, contested or fringe are reported, not endorsed; statuses of bills and rules are as of the date checked. Government, court and patent records are public domain; the research notes are CC BY 4.0.
disadvantage that it's a single point of failure. The "addr" system has no single point of failure, but can only tell you what nodes have recently been seen, so it takes a little longer to get connected since some of the nodes you try have gone offline. The combination of the two gets us the best of both worlds and more total robustness.
Is there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us?
118. Re: Hostnames instead of IP Addresses
Poster: satoshi · Date: 2010-06-14T19:53:44Z · Thread: Hostnames instead of IP Addresses
Original: https://bitcointalk.org/index.php?topic=158.msg1582#msg1582
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/118/
SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to. This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert.
Instead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.
The user would send to domain.com (or www.domain.com is ok too). That would be very natural and users could see and verify that what they entered is who they intend to pay.
The SSL also makes it safe for TOR users.
Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for. You simply cannot count on users to enter the right thing in the comment fields to identify the transaction. It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.
Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability. Regular users aren't used to the idea of having to identify the payment. Merchants would get too many blank payments followed by "I paid you, where's my stuff?!" a week later.
The payment sequence does have a step where the receiver verifies the order before accepting it. It can reject the payment and return an error message if it doesn't contain a valid order number. That would require a difficult level of integration of custom code with the bitcoin server though.
119. Re: Dealing with SHA-256 Collisions
Poster: satoshi · Date: 2010-06-14T20:39:50Z · Thread: Dealing with SHA-256 Collisions
Original: https://bitcointalk.org/index.php?topic=191.msg1585#msg1585
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/119/
SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.
If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
120. Re: Technical clarifications
Poster: satoshi · Date: 2010-06-14T22:21:55Z · Thread: Technical clarifications
Original: https://bitcointalk.org/index.php?topic=179.msg1588#msg1588
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/120/
3) Nothing, if sending by bitcoin address
5) It is decentralised. After you have connected to the network the first time, you no longer need IRC.
121. Re: Can't Build r80 from SVN
Poster: satoshi · Date: 2010-06-14T22:40:14Z · Thread: Can't Build r80 from SVN
Original: https://bitcointalk.org/index.php?topic=163.msg1590#msg1590
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/121/
Sorry, I didn't test compile on linux the last few revisions.
Reverted makefile.unix.
122. Re: What is the incentive to collect transactions?
Poster: satoshi · Date: 2010-06-15T23:41:29Z · Thread: What is the incentive to collect transactions?
Original: https://bitcointalk.org/index.php?topic=165.msg1595#msg1595
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/122/
Quote from: theymos on June 05, 2010, 04:26:09 PM
Adding transactions to the block you're working on will slow down your generation rate
The premise is false. Adding more transactions to the block you're working on does NOT slow down your generation rate. When generate is scanning hashes, it only hashes the header of the block, which is constant size. The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.
If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.
123. Re: URI-scheme for bitcoin
Poster: satoshi · Date: 2010-06-16T00:15:47Z · Thread: URI-scheme for bitcoin
Original: https://bitcointalk.org/index.php?topic=55.msg1596#msg1596
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/123/
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00
But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can't send an unidentified payment. They can't send payment until they've been given a correct bitcoin address to send to.
What would be nice about sending by domain is you could visually verify who it's going to.
A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589
and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
124. Re: Website translations
Poster: satoshi · Date: 2010-06-16T16:53:34Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg1600#msg1600
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/124/
Thanks DataWraith! The German translation is uploaded to SVN.
This is great, we've already got 3 major languages.
125. Re: new binary release?
Poster: satoshi · Date: 2010-06-17T17:07:56Z · Thread: new binary release?
Original: https://bitcointalk.org/index.php?topic=184.msg1609#msg1609
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/125/
I'm working on getting version 0.3 released as soon as I can. Just a last few things left to do. It's been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and JSON-RPC available. This time we'll have both 32-bit and 64-bit linux binaries, and Laszlo is going to build a Mac OSX release. Plus, we'll include the German, Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks you guys!).
126. Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Poster: satoshi · Date: 2010-06-17T18:46:08Z · Thread: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Original: https://bitcointalk.org/index.php?topic=195.msg1611#msg1611
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
127. Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Poster: satoshi · Date: 2010-06-18T16:17:14Z · Thread: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Original: https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/127/
A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.
I know, most developers don't like their software forked, but I have real technical reasons in this case.
Quote from: gavinandresen on June 17, 2010, 07:58:14 PM
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
That's one of the reasons for transaction fees. There are other things we can do if necessary.
Quote from: laszlo on June 17, 2010, 06:50:31 PM
How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well [image: Smiley; source: /static/img/emoticons/smiley.gif]
Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.
Fortunately, so far all the issues raised have been things I previously considered and planned for.
128. Re: On IRC bootstrapping
Poster: satoshi · Date: 2010-06-18T17:28:18Z · Thread: On IRC bootstrapping
Original: https://bitcointalk.org/index.php?topic=84.msg1619#msg1619
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/128/
The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes. There are enough seed nodes now that many of them should still be up by the time of the next release. It only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while. At that point, be patient. It's only slow to get connected the first time.
This means TOR users won't need to -addnode anymore, it'll get connected automatically.
129. Re: Get 5 free bitcoins from freebitcoins.appspot.com
Poster: satoshi · Date: 2010-06-18T23:08:34Z · Thread: Get 5 free bitcoins from freebitcoins.appspot.com
Original: https://bitcointalk.org/index.php?topic=183.msg1620#msg1620
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/129/
Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up.
You should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.
130. Re: Bitcoin in Ubuntu 10.04
Poster: satoshi · Date: 2010-06-21T17:20:21Z · Thread: Bitcoin in Ubuntu 10.04
Original: https://bitcointalk.org/index.php?topic=149.msg1646#msg1646
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/130/
Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM
Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release.
This is now fixed in the SVN version.
1) Menu bar default color.
2) Balance bar not a different color.
3) Background behind bitcoin address and balance now the same color as toolbar.
I checked all the standard themes and it seems reasonable with all of them.
Ubuntu minimize,maximize,close buttons to the right:
gconf-editor
apps->metacity->general
button_layout=menu:minimize,maximize,close
They've got it awfully buried considering 9 out of 10 users are used to having it on the right.
131. Re: Dying bitcoins
Poster: satoshi · Date: 2010-06-21T17:48:26Z · Thread: Dying bitcoins
Original: https://bitcointalk.org/index.php?topic=198.msg1647#msg1647
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/131/
Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone.
Quote from: laszlo on June 21, 2010, 01:54:29 PM
I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this..
Computers have to get about 2^200 times faster before that starts to be a problem. Someone with lots of compute power could make more money by generating than by trying to steal.
132. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-06-21T18:09:17Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg1648#msg1648
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/132/
I integrated the hashmeter idea into the SVN version. It displays khash/s in the left section of the status bar.
Two new log messages:
21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s
21/06/2010 01:23 generated 50.00
grep your debug.log for "generated" to see what you've generated, and grep for "hashmeter" to see the performance. On windows, use:
findstr "hashmeter generated" "%appdata%\bitcoin\debug.log"
I have the hashmeter messages once an hour. How often do you think it should be?
133. Re: Bitcoin in Ubuntu 10.04
Poster: satoshi · Date: 2010-06-22T03:45:56Z · Thread: Bitcoin in Ubuntu 10.04
Original: https://bitcointalk.org/index.php?topic=149.msg1653#msg1653
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/133/
On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there.
But now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it.
Updated SVN.
Thanks for testing.
134. 0.3 almost ready -- please test the Mac version!
Poster: satoshi · Date: 2010-06-22T04:01:53Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1654#msg1654
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/134/
I finished everything on my list to do for version 0.3. The code on SVN is about ready to release.
Testing at this point is much appreciated.
135. Re: How fast do the fastest computers generate bitcoins?
Poster: satoshi · Date: 2010-06-22T04:35:26Z · Thread: How fast do the fastest computers generate bitcoins?
Original: https://bitcointalk.org/index.php?topic=197.msg1656#msg1656
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/135/
I've noticed that hashing performance doesn't vary as much between CPUs as you'd expect. Compared to an old CPU, a newer CPU doesn't show as much of a speedup at hashing as it does on general benchmarks.
I guess recent CPU optimizations must have concentrated on things like I/O and branch prediction. Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long.
The latest SVN version has a khash/s display. Around 400 khash/s per processor is typical.
136. Re: Bitcoin in Ubuntu 10.04
Poster: satoshi · Date: 2010-06-22T16:39:43Z · Thread: Bitcoin in Ubuntu 10.04
Original: https://bitcointalk.org/index.php?topic=149.msg1668#msg1668
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/136/
It's too late now for feature changes to 0.3, but I'll add that to the post-0.3 to do list. I never would have noticed that if you hadn't pointed it out.
137. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-06-22T16:51:14Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg1669#msg1669
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/137/
Agree. Certainly too trivial to clutter the user's attention with.
I changed it to every 30 minutes.
If I increased it to every 10 minutes, it would still be a small enough presence in the log file. Question is whether that would be more output than the user wants when they grep.
138. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-22T17:02:07Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1670#msg1670
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/138/
Quote from: lachesis on June 22, 2010, 06:20:02 AM
It would be nice if the listtransactions RPC method were finished before the next release, though.
My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably.
We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do.
139. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-22T17:37:08Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1671#msg1671
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/139/
Here's RC1 for windows for testing:
(removed, see RC2 below)
Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in "c:\program files\bitcoin"
140. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-22T19:11:41Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1675#msg1675
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/140/
Quote from: davidonpda on June 22, 2010, 06:23:26 PM
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()
What operating system?
Normally when it does that it's because the directory where the data directory should go doesn't exist. See if the "%appdata%" directory exists.
Do you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.
141. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-22T19:25:13Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1677#msg1677
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/141/
davidonpda, were you also running laszlo's build previously?
Check if the "%appdata%" directory exists, and "%appdata%\bitcoin"
Try:
rename "%appdata%\bitcoin" bitcoin2
does it work then?
142. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-22T19:46:23Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1679#msg1679
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/142/
You figured it out faster than I could post a reply. [image: Smiley; source: /static/img/emoticons/smiley.gif]
It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.
When you copied the directory except log.0000000002, that's the best solution. You should be good now.
The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don't go back to v0.2.10.
Anyone else who hits this problem, move the database\log.000000000* files somewhere else. (if it works fine after that, you can delete them later)
I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do.
143. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-22T22:23:39Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1686#msg1686
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/143/
Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.
30khash increase to what total rate? (to figure the % increase)
144. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-24T17:40:05Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1748#msg1748
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/144/
Here's RC1 for linux for testing:
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the "-mt" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt.
145. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-25T02:17:41Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1760#msg1760
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/145/
I don't know. Maybe someone with more Linux experience knows how to install the library it needs.
I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?
The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.
We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.
I'm also curious if it's a little faster on linux than windows.
Do you think I should make the directories:
/bin32/
/bin64/
instead of
/bin/32/
/bin/64/
146. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-25T14:10:06Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1769#msg1769
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/146/
Thanks virtualcoin, that's a perfect comparison.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
147. Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel
Poster: satoshi · Date: 2010-06-25T21:15:15Z · Thread: Bitcoin clients getting k-lined from the IRC bootstrapping channel
Original: https://bitcointalk.org/index.php?topic=215.msg1779#msg1779
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/147/
We need more details about what happened MadHatter.
Both 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected.
0.2 can find other nodes without IRC if it's ever been connected before, but a new install can't discover the network for the first time without IRC.
0.3 can also seed without IRC. It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy.
148. Re: On IRC bootstrapping
Poster: satoshi · Date: 2010-06-25T22:40:47Z · Thread: On IRC bootstrapping
Original: https://bitcointalk.org/index.php?topic=84.msg1781#msg1781
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/148/
Quote from: laszlo on June 14, 2010, 06:30:58 PM
I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything. It is only two servers right now but we don't mess with it or anything, it just runs.
My box is a dedicated irc server:
2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08
You can use irc.lfnet.org to connect.
This seems like a good idea.
What does everyone think, should we make the switch for 0.3?
149. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-26T00:32:09Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1787#msg1787
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/149/
Lets try using Laszlo's irc.lfnet.org instead of freenode. Here's RC2, that's the only change in it:
(see below for download links)
150. Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel
Poster: satoshi · Date: 2010-06-26T14:28:06Z · Thread: Bitcoin clients getting k-lined from the IRC bootstrapping channel
Original: https://bitcointalk.org/index.php?topic=215.msg1797#msg1797
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/150/
Freenode is too visible, right in the middle of where all those users and moderators are hanging out. Laszlo's option is a much better fit for us.
I made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start switching over:
http://bitcointalk.org/index.php?topic=199.msg1787#msg1787
151. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-06-26T15:10:10Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1800#msg1800
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/151/
The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.
152. Beta?
Poster: satoshi · Date: 2010-06-26T17:02:43Z · Thread: Beta?
Original: https://bitcointalk.org/index.php?topic=217.msg1803#msg1803
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/152/
Is it about time we lose the Beta? I would make this release version 1.3.
153. Re: 1.3 almost ready
Poster: satoshi · Date: 2010-06-26T19:21:05Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1806#msg1806
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/153/
Changed the version number to 1.3 and removed "Beta".
(links removed, see below)
Uses irc.lfnet.org.
154. Re: Bitcoin mobile.
Poster: satoshi · Date: 2010-06-26T20:58:26Z · Thread: Bitcoin mobile.
Original: https://bitcointalk.org/index.php?topic=177.msg1814#msg1814
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/154/
Quote from: sirius-m on June 10, 2010, 01:51:16 PM
You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them.
I think that's the best option right now. Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses.
They could make a smaller version of the site optimized for mobile. If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from.
If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis? It could always be an Android app instead. An app is not really necessary though, just a mobile sized website.
A web interface to your own Bitcoin server at home wouldn't be a solution for everyone. Most users don't have a static IP, and it's too much trouble to set up port forwarding.
155. Re: Building BitCoin Client completely Headless
Poster: satoshi · Date: 2010-06-26T21:06:06Z · Thread: Building BitCoin Client completely Headless
Original: https://bitcointalk.org/index.php?topic=171.msg1815#msg1815
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/155/
The linux release candidate in the "1.3 almost ready" thread contains prebuilt bitcoind.
156. Re: Bitcoin Faucet changes
Poster: satoshi · Date: 2010-06-26T21:39:52Z · Thread: Bitcoin Faucet changes
Original: https://bitcointalk.org/index.php?topic=206.msg1816#msg1816
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/156/
Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?). Maybe you should have a minimum time between payments per class-B.
If you can't solve the problem, you can always keep lowering the amount of bitcoins given until it's manageable, and always require captcha.
157. Re: Beta?
Poster: satoshi · Date: 2010-06-27T12:43:50Z · Thread: Beta?
Original: https://bitcointalk.org/index.php?topic=217.msg1827#msg1827
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/157/
But 1.0 sounds like the first release. For some things newness is a virtue but for this type of software, maturity and stability are important. I don't want to put my money in something that's 1.0. 1.0 might be more interesting for a moment, but after that we're still 1.0 and everyone who comes along thinks we just started. This is the third major release and 1.3 reflects that development history. (0.1, 0.2, 1.3)
158. Re: IPv6, headless client, and more
Poster: satoshi · Date: 2010-06-27T13:02:38Z · Thread: IPv6, headless client, and more
Original: https://bitcointalk.org/index.php?topic=218.msg1828#msg1828
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/158/
Welcome, Harry.
I hadn't thought about starting out using bitcoind without using bitcoin first. I guess for now, this thread serves as the tutorial.
The focus for bitcoind so far has been more on backend support for websites. There's demand for things that would be nice for adminning headless generators like listgenerated. For the moment, you can grep the debug.log file for "generated" and "hashmeter" for some feedback. Generated blocks take about 24 hours before they're credited to your balance.
159. Re: 1.3 almost ready
Poster: satoshi · Date: 2010-06-27T15:30:13Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1834#msg1834
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/159/
MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
160. Re: Major Meltdown
Poster: satoshi · Date: 2010-06-27T19:06:09Z · Thread: Major Meltdown
Original: https://bitcointalk.org/index.php?topic=202.msg1838#msg1838
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/160/
Here's an answer to a similar question about how to recover from a major meltdown.
https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585
Quote from: satoshi on June 14, 2010, 08:39:50 PM
If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
161. Re: Feature Request: Limiting Connections
Poster: satoshi · Date: 2010-07-02T19:21:36Z · Thread: Feature Request: Limiting Connections
Original: https://bitcointalk.org/index.php?topic=223.msg1924#msg1924
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/161/
Thanks for the feedback on this.
One thing we could do is lower the outbound connections from 15 to 10 or maybe even 5. The choice of 15 was arbitrary. It just needs to be enough for redundancy and fast exponential propagation of messages. 10 would still be plenty. 5 should be fine. 10 is good as a nice round number so users can see that it stopped intentionally.
It would help to implement UPnP so there would be more inbound accepting nodes. Your number of connections is the ratio of inbound accepting nodes to out-only times 15. We need to encourage more people to accept inbound connections.
I will implement a feature to stop accepting inbound connections once you hit a certain number.
Which version are you running?
Anyone know how many connections typical P2P software like BitTorrent can get up to?
162. Re: 1.3 almost ready
Poster: satoshi · Date: 2010-07-02T20:37:17Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1926#msg1926
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/162/
Quote from: dkaparis on June 27, 2010, 10:02:25 PM
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
It is, but generating is more than twice as slow.
163. Re: 0.3 almost ready
Poster: satoshi · Date: 2010-07-02T21:57:45Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1927#msg1927
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/163/
(reverted to rc2)
Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it.
164. Re: Beta?
Poster: satoshi · Date: 2010-07-02T22:03:41Z · Thread: Beta?
Original: https://bitcointalk.org/index.php?topic=217.msg1928#msg1928
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/164/
OK, back to 0.3 then.
Please download RC4 and check it over as soon as possible. I'd like to release it soon.
http://bitcointalk.org/index.php?topic=199.msg1927#msg1927
Other than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections. 15 was a lot more than needed. 8 is still plenty for redundancy.
165. Re: Feature Request: Limiting Connections
Poster: satoshi · Date: 2010-07-02T22:20:20Z · Thread: Feature Request: Limiting Connections
Original: https://bitcointalk.org/index.php?topic=223.msg1929#msg1929
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/165/
I reduced max outbound connections from 15 to 8 in RC4.
15 was way more than we needed for redundancy. 8 is still plenty of redundancy.
As the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get.
If anyone wants more than 8 connections, they can open port 8333 on their firewall.
166. Re: 0.3 almost ready -- please test the Mac version!
Poster: satoshi · Date: 2010-07-04T21:52:28Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg1947#msg1947
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/166/
Laszlo's build is going to be our first Mac release so please test it!
167. Re: Slashdot Submission for 1.0
Poster: satoshi · Date: 2010-07-05T21:31:14Z · Thread: Slashdot Submission for 1.0
Original: https://bitcointalk.org/index.php?topic=234.msg1976#msg1976
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/167/
BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0.
I really appreciate the effort, but there are a lot of problems.
We don't want to lead with "anonymous". (I've been meaning to edit the homepage)
"The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government." -- I am definitely not making an such taunt or assertion.
It's not stable-with-respect-to-energy. There was a discussion on this. It's not tied to the cost of energy. NLS's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate.
Sorry to be a wet blanket. Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to.
168. Bitcoin 0.3 released!
Poster: satoshi · Date: 2010-07-06T18:32:35Z · Thread: Bitcoin 0.3 released!
Original: https://bitcointalk.org/index.php?topic=238.msg2004#msg2004
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/168/
Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.
What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero)
Get it at http://www.bitcoin.org or read the forum to find out more.
169. Re: 0.3 almost ready -- please test the Mac version!
Poster: satoshi · Date: 2010-07-06T19:43:18Z · Thread: 0.3 almost ready -- please test the Mac version!
Original: https://bitcointalk.org/index.php?topic=199.msg2006#msg2006
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/169/
0.3 released
http://bitcointalk.org/index.php?topic=238.msg2004#msg2004
170. Re: On IRC bootstrapping
Poster: satoshi · Date: 2010-07-07T01:31:07Z · Thread: On IRC bootstrapping
Original: https://bitcointalk.org/index.php?topic=84.msg2010#msg2010
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/170/
Everybody needs to connect to the same IRC server and channel so they can find each other.
Quote from: Vasiliev on June 25, 2010, 11:50:15 PM
You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.
It might not be good if we suddenly rushed freenode with a ton of users all at once.
The fallback is our own seed system.
irc.lfnet.org is pretty old and has impressive uptime. I think it's going to be fine.
We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems.
171. Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Poster: satoshi · Date: 2010-07-08T18:24:19Z · Thread: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Original: https://bitcointalk.org/index.php?topic=246.msg2068#msg2068
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/171/
Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that.
Just to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not?
172. Re: Anonymity
Poster: satoshi · Date: 2010-07-08T19:12:00Z · Thread: Anonymity
Original: https://bitcointalk.org/index.php?topic=241.msg2071#msg2071
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/172/
It's hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world.
Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated.
If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over.
If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.
It wouldn't be easy to take advantage of the segmentation to double-spend. If it's impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over.
You would usually know whether you're in the smaller segment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you're in the smaller segment, you should assume nothing is confirmed.
173. Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Poster: satoshi · Date: 2010-07-09T03:01:35Z · Thread: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Original: https://bitcointalk.org/index.php?topic=246.msg2077#msg2077
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/173/
I think I see where the problem is. Coincidentally, I recently coded a replacement for the function in question which should fix it. It's not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison.
174. Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)
Poster: satoshi · Date: 2010-07-09T03:28:46Z · Thread: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)
Original: https://bitcointalk.org/index.php?topic=242.msg2078#msg2078
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/174/
What the OP described is called "cornering the market". When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.
The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979:
"Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.[1] During Hunt's accumulation of the precious metal silver prices rose from $11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]"
http://en.wikipedia.org/wiki/Cornering_the_market
175. Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Poster: satoshi · Date: 2010-07-09T15:37:05Z · Thread: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Original: https://bitcointalk.org/index.php?topic=246.msg2092#msg2092
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/175/
I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it. This change is revision 102 of the SVN.
176. Re: Security
Poster: satoshi · Date: 2010-07-10T12:58:02Z · Thread: Security
Original: https://bitcointalk.org/index.php?topic=240.msg2132#msg2132
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/176/
I'll start thinking about how to do this.
At the moment, you can kind of use -connect. You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100. If you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty. If you've port-forwarded though, then outside nodes might still connect inward to you.
With -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect? The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two. In that case, you wouldn't want the -connect computers on IRC.
void ThreadIRCSeed(void* parg)
{
if (mapArgs.count("-connect"))
return;
177. Re: Major Meltdown
Poster: satoshi · Date: 2010-07-10T13:36:17Z · Thread: Major Meltdown
Original: https://bitcointalk.org/index.php?topic=202.msg2133#msg2133
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/177/
Quote from: llama on July 01, 2010, 10:21:47 PM
However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.
True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)
178. Re: No blocks downloaded... why?
Poster: satoshi · Date: 2010-07-14T16:22:03Z · Thread: No blocks downloaded - MS Security Essentials users please read
Original: https://bitcointalk.org/index.php?topic=323.msg2867#msg2867
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/178/
So that was responsible for keeping blocks from downloading?
The link: "Win32 CPU Cycles vs 'Live Protection' Engines"
For BitcoinFX, Live Protection was keeping it from getting CPU for generating coins. You said your friend was getting 1400-1600 khash/s, so it was getting CPU. I guess Live Protection must have been blocking some other part of the program then?
179. Re: resource hog
Poster: satoshi · Date: 2010-07-14T16:29:39Z · Thread: resource hog
Original: https://bitcointalk.org/index.php?topic=327.msg2871#msg2871
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/179/
In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn't make a difference though.
If you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it's taking is generate, which is idle priority already.
It could be it's slow just because you have too many things running at once and you're out of memory. When you switch from one thing to another, it has to page it in from disk.
180. Re: stopped prodicing coins
Poster: satoshi · Date: 2010-07-14T17:04:02Z · Thread: stopped prodicing coins
Original: https://bitcointalk.org/index.php?topic=343.msg2880#msg2880
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/180/
Thanks for making that calculator.
The difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells.
181. Re: Building Bitcoin 0.3
Poster: satoshi · Date: 2010-07-14T17:34:50Z · Thread: Building Bitcoin 0.3
Original: https://bitcointalk.org/index.php?topic=298.msg2885#msg2885
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/181/
It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately, there isn't a Debian package of wxWidgets 2.9 yet.
182. Re: bitcoin auto-renice-ing
Poster: satoshi · Date: 2010-07-14T17:38:31Z · Thread: bitcoin auto-renice-ing
Original: https://bitcointalk.org/index.php?topic=72.msg2886#msg2886
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/182/
Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.
183. Re: Stuck on 513 blocks
Poster: satoshi · Date: 2010-07-14T18:02:28Z · Thread: Stuck on 513 blocks
Original: https://bitcointalk.org/index.php?topic=305.msg2895#msg2895
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/183/
This is the second time I've seen this "Live Protection" problem reported.
It must be blocking the program's network communication. It sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.
We need to understand this problem better.
Can someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is.
184. Re: Error on Ubuntu 10.04
Poster: satoshi · Date: 2010-07-14T18:25:41Z · Thread: Error on Ubuntu 10.04
Original: https://bitcointalk.org/index.php?topic=318.msg2903#msg2903
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/184/
What language is your computer set to? Is it set to German, Dutch or Italian? Is it one of those sub-languages like "nl-??"?
It's trying to load a translation and failing. You could delete the locale directory that came with bitcoin so it doesn't try to use it.
Can someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three?
185. Re: Runaway CPU usage for 64bit BitCoin (Linux Client)
Poster: satoshi · Date: 2010-07-14T18:45:53Z · Thread: Runaway CPU usage for 64bit BitCoin (Linux Client)
Original: https://bitcointalk.org/index.php?topic=299.msg2908#msg2908
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/185/
After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.
There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.
Quote from: knightmb on July 12, 2010, 10:39:13 PM
On a side note, I've tracked down the other GUI issue.
The "minimize to tray instead of taskbar" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.
This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.
I did notice on the 64 bit Client, what happens is, it spawns multiple "tray" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere? [image: Huh; source: /static/img/emoticons/huh.gif]
That's interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn't know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I'm thinking we should disable it again on Linux.
186. Re: Warning this block was not received by any other nodes
Poster: satoshi · Date: 2010-07-14T18:56:29Z · Thread: Warning this block was not received by any other nodes
Original: https://bitcointalk.org/index.php?topic=291.msg2913#msg2913
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/186/
Microsoft Security Essentials Live Protection is blocking your communication with the network. You have connections, which tricks Bitcoin into thinking it's connected, but they are silent because the data is being blocked.
You need to make bitcoin.exe an excluded process in Live Protection.
This is becoming a common problem. Someone should write this up in a pegged thread.
The message "Warning: This block was not received by any other nodes" occurs when Bitcoin broadcasts a block, but nobody confirms they received it. The warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you. Your block will never become valid because nobody received it.
187. Re: Hash/sec Throttling for Democracy
Poster: satoshi · Date: 2010-07-14T20:25:06Z · Thread: Hash/sec Throttling for Democracy
Original: https://bitcointalk.org/index.php?topic=325.msg2935#msg2935
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/187/
Quote from: knightmb on July 14, 2010, 07:17:43 PM
So if your computer was only 1% towards solving block 68000 This is a common point of confusion. There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.
It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.
The RNG is the OpenSSL secure random number generator. On Windows it's seeded with the complete set of all hardware performance counters since your computer started, on Linux it's dev/random.
188. Re: Scalability
Poster: satoshi · Date: 2010-07-14T21:10:52Z · Thread: Scalability
Original: https://bitcointalk.org/index.php?topic=286.msg2947#msg2947
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/188/
The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself.
The lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.
I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.
At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.
189. Re: Runaway CPU usage for 64bit BitCoin (Linux Client)
Poster: satoshi · Date: 2010-07-15T00:18:23Z · Thread: Runaway CPU usage for 64bit BitCoin (Linux Client)
Original: https://bitcointalk.org/index.php?topic=299.msg3008#msg3008
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/189/
OK, the undocumented switch "-minimizetotray" which re-enables the option.
I uploaded the change to SVN.
190. Re: [Bitcoin 0.3.0] Runtime error
Poster: satoshi · Date: 2010-07-15T14:05:20Z · Thread: [Bitcoin 0.3.0] Runtime error
Original: https://bitcointalk.org/index.php?topic=373.msg3150#msg3150
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/190/
More directly, this:
http://bitcointalk.org/index.php?topic=246.0
I will be posting release candidate of 0.3.1 with this fix shortly. Please try that and let me know if it fixes the problem.
191. Re: Static Linux x86_64 bins for those having libcrypto troubles
Poster: satoshi · Date: 2010-07-15T14:33:04Z · Thread: UPDATED - Linux x64 bins for those having libcrypto and GLIBCXX_3.4.11 troubles
Original: https://bitcointalk.org/index.php?topic=326.msg3157#msg3157
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/191/
We don't even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes. There's probably a compiler switch that would tell it to static link it. I'm not sure what the licensing issues would be. Typically, compiler stuff is fully redistributable.
192. Re: resource hog
Poster: satoshi · Date: 2010-07-15T14:59:00Z · Thread: resource hog
Original: https://bitcointalk.org/index.php?topic=327.msg3162#msg3162
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/192/
Then all the CPU time is the generate thread, which definitely runs at the lowest possible priority, idle priority. It's normal that your CPU meter is 100%. Since it's idle priority, it won't actually slow anything else down, even though the CPU meter is 100%.
193. Bitcoin 0.3.1 released
Poster: satoshi · Date: 2010-07-15T17:05:54Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3198#msg3198
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/193/
This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.
The download links are on bitcoin.org
Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
Linux
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of "start on windowing system startup" option
194. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-15T17:23:48Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3205#msg3205
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/194/
Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
195. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-15T17:56:43Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3221#msg3221
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/195/
I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.
196. Re: Website and software translations
Poster: satoshi · Date: 2010-07-15T18:30:22Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg3238#msg3238
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/196/
Quote from: aidos on July 15, 2010, 12:49:11 AM
Ok here is the .po file for French. While I'm at it, I noted a couple of issues:
1. The "About" box didn't take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the "About" box message. Same problem with the "Apply" button in the Settings window.
I need to give an updated .po file.
Quote from: aidos on July 15, 2010, 12:49:11 AM
2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as "éàèç"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere.
OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can.
Quote from: aidos on July 15, 2010, 12:49:11 AM
4. About the .po file :
- There are a few strings in the .po file that don't needs translation (ie: "Bitcoin"). Maybe those shouldn't be inside _("...") ?
- Others shouldn't be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.
- Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit.
Many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things. I have a program I use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before I upload them to SVN.
197. Re: Website and software translations
Poster: satoshi · Date: 2010-07-15T18:37:13Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg3242#msg3242
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/197/
I uploaded an updated bitcoin.po for 0.3.1 attached to this message:
http://bitcointalk.org/index.php?topic=151.msg1259#msg1259
please use it if you're starting a new translation.
If you already have a po file, poedit can update it.
- Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do:
http://bitcointalk.org/index.php?topic=383.0
- Make a subdirectory under src: locale/??/LC_MESSAGES
(?? could be anything really, "en" or your language 2-letter code)
- Put your .po file there
- Open it with poedit
- In poedit, Catalog->Update from sources
The key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file.
198. Re: Website and software translations
Poster: satoshi · Date: 2010-07-15T18:43:54Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg3247#msg3247
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/198/
Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PM
I recommend to remove the download links at the bottom of the main page.
As you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.
There's a download box with the current releases on the right anyway, so why not remove the links from the translated pages.
I updated them to 0.3.0.
I am tempted to remove the download links from the other languages and only keep it on English.
They will need to be updated for 0.3.1 soon. Perhaps there's a way for someone to manage the updating of the translated drupal pages.
199. Re: Website and software translations
Poster: satoshi · Date: 2010-07-15T19:12:14Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg3257#msg3257
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/199/
Thanks for the Spanish and French translations! The edited and updated .po files are attached.
I uploaded these to the SVN.
200. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-15T21:40:34Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3295#msg3295
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/200/
Quote from: knightmb on July 15, 2010, 07:37:10 PM
On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.
Do you have dual-proc? Are you sure you weren't running a single processor hog?
201. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-15T22:07:35Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3305#msg3305
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/201/
Quote from: knightmb on July 15, 2010, 08:15:46 PM
On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
202. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-15T22:10:19Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3306#msg3306
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/202/
Quote from: db on July 15, 2010, 08:39:08 PM
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
Yes a bug. It'll have to be fixed in the next version.
203. Re: "SetIcons(): icon bundle doesn't contain any suitable icon"
Poster: satoshi · Date: 2010-07-15T22:18:26Z · Thread: "SetIcons(): icon bundle doesn't contain any suitable icon"
Original: https://bitcointalk.org/index.php?topic=391.msg3308#msg3308
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/203/
That's surprising that we've never heard of that before now.
Maybe you're the first person to ever run it on Vista [image: Smiley; source: /static/img/emoticons/smiley.gif]
I have to guess it has something to do with your display color depth selection. e.g. 8-bit, 16-bit, 24-bit, 32-bit, what is it? Do you have a weird video card, display setup or running it on a tablet or mobile or something?
204. Re: Runaway CPU usage for 64bit BitCoin (Linux Client)
Poster: satoshi · Date: 2010-07-15T22:22:30Z · Thread: Runaway CPU usage for 64bit BitCoin (Linux Client)
Original: https://bitcointalk.org/index.php?topic=299.msg3309#msg3309
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/204/
The fix for the thread priority level on linux is available in the 0.3.1 release candidate here:
http://bitcointalk.org/index.php?topic=383.msg3198#msg3198
205. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-15T23:23:04Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3319#msg3319
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/205/
Quote from: RHorning on July 15, 2010, 10:29:28 PM
I don't see either happening, although it did get put into the "Startup" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.
It could go either way. The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller. Bitcoin will not relentlessly keep re-adding it if you delete it manually.
OpenOffice is another example of something that puts its link in the Startup folder.
206. Re: "SetIcons(): icon bundle doesn't contain any suitable icon"
Poster: satoshi · Date: 2010-07-15T23:41:23Z · Thread: "SetIcons(): icon bundle doesn't contain any suitable icon"
Original: https://bitcointalk.org/index.php?topic=391.msg3323#msg3323
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/206/
Quote from: bdonlan on July 15, 2010, 11:27:14 PM
in 120DPI mode.
What is "120DPI mode"? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided.
207. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-16T00:44:32Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3339#msg3339
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/207/
Run it with the undocumented switch -minimizetotray and the option is available in the options menu.
I don't know how to fix it. It's something wrong deep inside wxWidgets or GTK or Gnome.
208. Re: Donations to freebitcoins.appspot.com needed!
Poster: satoshi · Date: 2010-07-16T02:02:07Z · Thread: Donations to freebitcoins.appspot.com needed!
Original: https://bitcointalk.org/index.php?topic=295.msg3350#msg3350
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/208/
5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2 BTC.
This is an important service so new users can at least get something if generating is too hard.
209. Re: "SetIcons(): icon bundle doesn't contain any suitable icon"
Poster: satoshi · Date: 2010-07-16T02:43:29Z · Thread: "SetIcons(): icon bundle doesn't contain any suitable icon"
Original: https://bitcointalk.org/index.php?topic=391.msg3362#msg3362
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/209/
That must be it then.
It must be looking for a larger icon like 20x20 but we don't have one.
210. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-07-16T14:46:12Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg3488#msg3488
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/210/
The proof-of-work difficulty is currently 45.38. (see http://www.alloscomp.com/bitcoin/calculator.php)
It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.
The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.
211. Re: Assertion Failure - Ubuntu Lucid
Poster: satoshi · Date: 2010-07-16T14:52:04Z · Thread: Assertion Failure - Ubuntu Lucid
Original: https://bitcointalk.org/index.php?topic=400.msg3492#msg3492
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/211/
That's the first time I've seen this error.
How many blocks do you have? (in the status bar)
You should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again. If you don't mind, could you keep the old blk*.dat files for a little while in case I need to look at them?
212. Re: Fedora 13 libcrypto
Poster: satoshi · Date: 2010-07-16T14:55:23Z · Thread: Fedora 13 libcrypto
Original: https://bitcointalk.org/index.php?topic=296.msg3495#msg3495
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/212/
Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:
http://bitcointalk.org/index.php?topic=383.0
Let me know if that works.
213. Re: Resending transaction
Poster: satoshi · Date: 2010-07-16T15:01:33Z · Thread: Resending transaction
Original: https://bitcointalk.org/index.php?topic=303.msg3499#msg3499
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/213/
Bitcoin automatically rebroadcasts your transactions if it receives new blocks that don't contain them. It may take about an hour to get rebroadcasted. It is relentless though. It will keep nagging the network forever until your transaction gets into a block.
214. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-16T15:09:59Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3505#msg3505
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/214/
Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.
215. Re: Source code documentation
Poster: satoshi · Date: 2010-07-16T15:37:00Z · Thread: Source code documentation
Original: https://bitcointalk.org/index.php?topic=393.msg3510#msg3510
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/215/
I like that in libraries for the external API's, but you can probably tell from the code that I'm not a fan of it for interior functions. Big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function. They're some trouble for maintenance, as changes to the function then require duplicate changes in the comment header. I like to keep code compact so you can see more code on the screen at once.
To add them now at this point, what would be written would just be what's obvious from looking at the function.
The external API we have, in rpc.cpp, the usage documentation is in the help string.
Sorry to be a wet blanket.
216. Re: Hash() function not secure
Poster: satoshi · Date: 2010-07-16T16:13:53Z · Thread: Hash() function not secure
Original: https://bitcointalk.org/index.php?topic=360.msg3520#msg3520
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/216/
SHA256 is not like the step from 128 bit to 160 bit.
To use an analogy, it's more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn't mean we're going to run out again with 64-bit anytime soon.
SHA256 is not going to be broken by Moore's law computational improvements in our lifetimes. If it's going to get broken, it'll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.
If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash.
217. Re: Request: expected bitcoins per day display
Poster: satoshi · Date: 2010-07-16T16:47:14Z · Thread: Request: expected bitcoins per day display
Original: https://bitcointalk.org/index.php?topic=397.msg3524#msg3524
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/217/
Many businesses are like that. For a car salesman, when will the next customer walk in the door?
On the OP's question, it's a good feature, but the question is, how would we word it so people don't expect to get something after that specific amount of time? "it said 7 days and I waited more than a week and didn't get anything!" Approx, average, but still they're going to think that way. It can't be a whole sentence, unless we think of somewhere else to put it, but where would that be? Suggestions?
The difficulty quadrupled a few minutes ago to 181.54. It's going to take typically about a week to generate now.
218. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-07-16T16:56:54Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg3526#msg3526
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/218/
It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.
The difficulty can adjust down as well as up.
The network should be generating close to 6 blocks per hour now.
219. Re: Source code documentation
Poster: satoshi · Date: 2010-07-16T17:15:47Z · Thread: Source code documentation
Original: https://bitcointalk.org/index.php?topic=393.msg3534#msg3534
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/219/
It's in init.cpp.
It's a wxWidgets app, so it doesn't have a main() function. It may in a little while, since I'm pretty close to making bitcoind build w/o wxBase. (it'll be in init.cpp)
Sorry about my choice of the filename "main.cpp", another possible name would have been "core.cpp". It's much too late to change. I still prefer main.cpp.
We're still in great need of sample code showing the recommended way to use the JSON-RPC functions, like for a basic account system on a typical storefront website. Using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used. I posted a sample code fragment on the forum somewhere. (search on getreceivedbylabel or getnewaddress) The sample code could be a plain vanilla bank site where you can deposit and send payments.
220. Re: 0.3.1 release candidate, please test
Poster: satoshi · Date: 2010-07-16T17:26:17Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3536#msg3536
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/220/
Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
221. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-07-16T17:29:28Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg3537#msg3537
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/221/
Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You know long before that that you won one.
222. Re: bitcoin trademark?
Poster: satoshi · Date: 2010-07-16T17:47:05Z · Thread: bitcoin trademark?
Original: https://bitcointalk.org/index.php?topic=378.msg3540#msg3540
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/222/
No, not related at all.
223. Re: The dollar cost of bitmining energy
Poster: satoshi · Date: 2010-07-16T17:58:44Z · Thread: The dollar cost of bitmining energy
Original: https://bitcointalk.org/index.php?topic=403.msg3545#msg3545
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/223/
Neat chart.
Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.
224. Re: Website integration for bitcoin
Poster: satoshi · Date: 2010-07-16T18:23:04Z · Thread: Website integration for bitcoin
Original: https://bitcointalk.org/index.php?topic=364.msg3559#msg3559
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/224/
I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail. It would be nice if you didn't have to re-invent the wheel like you're doing here. Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.
225. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-07-16T18:43:51Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg3565#msg3565
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/225/
Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.
The recent adjustment put us back to close to 6 blocks per hour again.
There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:
http://nullvoid.org/bitcoin/statistix.php
226. Sample account system using JSON-RPC needed
Poster: satoshi · Date: 2010-07-16T19:45:10Z · Thread: Sample account system using JSON-RPC needed
Original: https://bitcointalk.org/index.php?topic=417.msg3579#msg3579
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/226/
We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system. Most sites that sell things will need something like this. Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.
When a user is logged in to their account, you show the bitcoin address they can send to to add funds. Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>). You only need to keep the latest bitcoin address for the account in your database. (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)
You use getreceivedbylabel <username> with the username as the label to get the "credit" amount of the account. You need to keep a "debit" amount in your database. The current balance of the account is (credit - debit). When the user spends money, you increase debit.
If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged. Not all sites need to wait for confirmations, so the dual current & available should be optional. Most sites selling digital goods are fine to accept 0 confirmations.
A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address. The sample code should be the simplest possible with the minimum extra stuff to make it a working site.
vekja.net is an example of a site like this.
227. Re: Bitcoin 0.3.1 released
Poster: satoshi · Date: 2010-07-16T21:06:57Z · Thread: Bitcoin 0.3.1 released
Original: https://bitcointalk.org/index.php?topic=383.msg3590#msg3590
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/227/
I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.
You don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0.
228. Re: A New Currency System for the World
Poster: satoshi · Date: 2010-07-16T22:20:09Z · Thread: A New Currency System for the World
Original: https://bitcointalk.org/index.php?topic=128.msg3605#msg3605
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/228/
Quote from: hugolp on May 08, 2010, 10:38:51 AM
When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.
0.3.1 fixes that, sets the generate threads to the lowest priority. Download links are on the homepage now.
229. Re: BUG Report: Rounding glitch
Poster: satoshi · Date: 2010-07-17T16:06:12Z · Thread: BUG Report: Rounding glitch
Original: https://bitcointalk.org/index.php?topic=432.msg3769#msg3769
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/229/
It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result. The only place where it uses floating point to represent money is returning a value in JSON-RPC.
1.139999999999 is longer than bitcoin can internally represent.
internally, it could only be:
1.13999999 or
1.14000000
1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.
The code is this:
(double)GetBalance() / (double)COIN.
(I can't think of an easy way to fix it at the moment)
230. Re: Privacy versus Safety: handling change
Poster: satoshi · Date: 2010-07-17T16:27:39Z · Thread: Privacy versus Safety: handling change
Original: https://bitcointalk.org/index.php?topic=434.msg3770#msg3770
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/230/
We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed. They aren't very big, so it wouldn't hurt to have a lot of them. This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it. Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.
The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses. When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.
There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat. I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
231. Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.
Poster: satoshi · Date: 2010-07-17T16:56:06Z · Thread: Nenolod, the guy that wants to prove Bitcoin doesn't work.
Original: https://bitcointalk.org/index.php?topic=431.msg3773#msg3773
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/231/
0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.
But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document.
232. Bitcoin 0.3.2 released
Poster: satoshi · Date: 2010-07-17T21:35:51Z · Thread: Bitcoin 0.3.2 released
Original: https://bitcointalk.org/index.php?topic=437.msg3807#msg3807
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/232/
Download links available now on bitcoin.org. Everyone should upgrade to this version.
- Added a simple security safeguard that locks-in the block chain up to this point.
- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.
The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday. (if you have this update)
I'll probably put a checkpoint in each version from now on. Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.
233. Re: Bitcoin snack machine (fast transaction problem)
Poster: satoshi · Date: 2010-07-17T22:29:13Z · Thread: Bitcoin snack machine (fast transaction problem)
Original: https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/233/
I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.
The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.
A rough back-of-the-envelope example:
1 0
4 1
16 4
64 16
80% 20%
So if a double-spend has to wait even a second, it has a huge disadvantage.
The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
234. Re: Assertion Failure - Ubuntu Lucid
Poster: satoshi · Date: 2010-07-17T22:37:06Z · Thread: Assertion Failure - Ubuntu Lucid
Original: https://bitcointalk.org/index.php?topic=400.msg3823#msg3823
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/234/
Quote from: singpolyma on July 17, 2010, 10:19:48 PM
My coins disappeared, but I assume they'll come back when it's up to current?
Right, they'll re-appear when it's finished downloading all the blocks.
235. Re: Bitcoin 0.3.2 released
Poster: satoshi · Date: 2010-07-17T22:54:24Z · Thread: Bitcoin 0.3.2 released
Original: https://bitcointalk.org/index.php?topic=437.msg3825#msg3825
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/235/
Quote from: llama on July 17, 2010, 09:56:25 PM
However, it's important that you don't lock all the way up the very latest block. Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock.
I went about 200 blocks back. The block chain was a clean straight line without branches, and there was only one known version of the locked block.
Quote from: llama on July 17, 2010, 09:56:25 PM
Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client. Is this so?
Sorry, not yet, but I do want to make the initial block download faster.
236. Re: Source code documentation
Poster: satoshi · Date: 2010-07-17T23:18:30Z · Thread: Source code documentation
Original: https://bitcointalk.org/index.php?topic=393.msg3828#msg3828
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/236/
I didn't realize you were going to document all the intentionally undocumented commands. They're unsupported and not intended to be used by users.
All the user-facing commands are listed in the -? help.
237. Re: Network Size
Poster: satoshi · Date: 2010-07-17T23:25:16Z · Thread: Network Size
Original: https://bitcointalk.org/index.php?topic=419.msg3830#msg3830
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/237/
Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PM
Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong.
In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.
Please upgrade to 0.3.2, it's available now.
238. Re: Bitcoin snack machine (fast transaction problem)
Poster: satoshi · Date: 2010-07-18T01:59:15Z · Thread: Bitcoin snack machine (fast transaction problem)
Original: https://bitcointalk.org/index.php?topic=423.msg3867#msg3867
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/238/
Quote from: llama on July 18, 2010, 12:03:29 AM
This is a good start, but still not impermeable.
I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards.
Quote
(for example, by refusing to propogate word of the transaction at the vending machine)
No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes.
239. Re: Source code documentation
Poster: satoshi · Date: 2010-07-18T15:12:54Z · Thread: Source code documentation
Original: https://bitcointalk.org/index.php?topic=393.msg3999#msg3999
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/239/
They're only intended for intrepid programmers who read the sourcecode.
240. Re: URI-scheme for bitcoin
Poster: satoshi · Date: 2010-07-18T16:06:16Z · Thread: URI-scheme for bitcoin
Original: https://bitcointalk.org/index.php?topic=55.msg4008#msg4008
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/240/
Quote from: lachesis on June 16, 2010, 06:14:05 AM
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
That's what I thought too.
Quote from: sirius-m on June 16, 2010, 08:26:14 AM
Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1. Not other domains, but just specifically to that one. Great...
If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.
I'll get started on adding the password field.
241. Re: Bitcoin 0.3.2 released
Poster: satoshi · Date: 2010-07-18T18:58:21Z · Thread: Bitcoin 0.3.2 released
Original: https://bitcointalk.org/index.php?topic=437.msg4037#msg4037
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/241/
The change list is basically encompassed by what's listed in the first message. Everyone should upgrade to get the important security improvements.
Minimizing to tray had at least 3 different glitches and bugs on Linux, including a crash one, so I disabled it again. You can still re-enable the option with "-minimizetotray" if you want to use it anyway. The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and I don't know how to fix them. Sorry, I just don't know what else to do, it's just too glitchy and buggy to have as a mainline feature.
242. JSON-RPC password
Poster: satoshi · Date: 2010-07-18T20:49:22Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4059#msg4059
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/242/
I uploaded to SVN my changes to add a password to JSON-RPC. If you're set up to build, please test it.
The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
bitcoin -rpcpw=<password> -- runs with JSON-RPC port open
bitcoind -rpcpw=<password> -- daemon with password
If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too. I'm not sure but I think they may want to use different passwords for the two.
It gives a warning if you don't set a password.
All commands now require the password as the first parameter. It'll tell you that if you run "bitcoind help".
The central code:
// Check password
if (params.size() < 1 || params[0].type() != str_type)
throw runtime_error("First parameter must be the password.");
if (params[0].get_str() != strRPCPassword)
{
if (strRPCPassword.size() < 15)
Sleep(50);
begin = strRequest.end();
printf("ThreadRPCServer incorrect password attempt
");
throw runtime_error("Incorrect password.");
}
Any comments on these decisions?
1) if (strRPCPassword.size() < 15) Sleep(50); -- this means if it's a short password, it'll wait 50ms after each attempt. This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan. This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15. If you want to close the DoS possibility, just use a password 15 characters or longer.
2) begin = strRequest.end(); -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password. This is so you can't stuff it with millions of password attempts in one packet. What do you think, is this the right thing to do? (multiple invocation is probably almost never used anyway)
I also fixed the two duplicated commands listed in the help:
getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>
243. Re: MSVC build & SHA-256
Poster: satoshi · Date: 2010-07-18T21:24:09Z · Thread: Faster SHA-256, MSVC build
Original: https://bitcointalk.org/index.php?topic=453.msg4068#msg4068
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/243/
OpenSSL doesn't have any interface for doing just the low level raw block hash part of SHA256. SHA256 begins by wrapping your data in a specially formatted buffer. Setting up the buffer takes an order of magnitude longer than the actual hashing if you're only hashing one or two blocks like we do. It's intended that the time is amortised if you were hashing many KB or MB of data. In BitcoinMiner, we format the buffer once and keep reusing it.
If you can find SHA256 code that's faster (with MinGW/GCC) than what we've got, that would be really great! (although, keep licensing in mind) The one we have is the only one I tried, so there's significant chance for improvement.
When I wrote it more than 2 years ago, there were screaming hot SHA1 implementations but minimal attention to SHA256. That's a lot of time for them to come up with better stuff. SHA256 was a lot slower than the fastest SHA1 at the time than I thought it should be. Obviously SHA256 should be slower than SHA1 by a certain amount, but not by as much as I saw.
(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)
244. Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.
Poster: satoshi · Date: 2010-07-18T21:56:18Z · Thread: Nenolod, the guy that wants to prove Bitcoin doesn't work.
Original: https://bitcointalk.org/index.php?topic=431.msg4073#msg4073
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/244/
Typically, over 25,000 BTC.
245. Re: Did block generation crawl to a halt?
Poster: satoshi · Date: 2010-07-18T23:35:27Z · Thread: Did block generation crawl to a halt?
Original: https://bitcointalk.org/index.php?topic=441.msg4095#msg4095
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/245/
Nice graph! A moving average to smooth it out would be nice.
http://nullvoid.org/bitcoin/statistix.php says 212 blocks in the last 24 hours, or 8.8 per hour.
246. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-19T04:43:13Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4169#msg4169
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/246/
Right, that is quite a bit better.
Can you give me any examples of other stuff that does it that way? (and what the command line looks like)
The main change you're talking about here is instead of -rpcpw= when you start bitcoind, you'd use a switch that specifies a text file to go and read it from, right? (any ideas what I should name the switch?)
247. Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)
Poster: satoshi · Date: 2010-07-19T16:01:38Z · Thread: Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)
Original: https://bitcointalk.org/index.php?topic=479.msg4263#msg4263
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/247/
Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser. It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.
We're working on a release soon that puts a password on the JSON-RPC interface, but until then, avoid using the -server switch, and don't web browse on the same machine where bitcoind is running.
Update:
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
248. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-19T16:20:50Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4268#msg4268
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/248/
So you drop a settings file in the ~/.bitcoin directory, that sounds better. In the "no password is set" warning, it could tell you where the file is and what to do.
What is the most popular and common settings file format?
HTTP basic authentication should be considered. In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list. What do you think? Does HTTP basic authentication get us any additional benefits? Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win.
Quote from: gavinandresen on July 19, 2010, 12:02:39 PM
I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list. I agree that reading the command-line password from a file would be more convenient and more secure.
You're also confusing me, what do you mean? Did I do something unintended?
249. Re: They want to delete the Wikipedia article
Poster: satoshi · Date: 2010-07-20T18:38:28Z · Thread: They want to delete the Wikipedia article
Original: https://bitcointalk.org/index.php?topic=342.msg4508#msg4508
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/249/
Bitcoin is an implementation of Wei Dai's b-money proposal http://weidai.com/bmoney.txt on Cypherpunks http://en.wikipedia.org/wiki/Cypherpunks in 1998 and Nick Szabo's Bitgold proposal http://unenumerated.blogspot.com/2005/12/bit-gold.html
The timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment?
It would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.
If you post in http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Bitcoin please don't say "yeah, but bitcoin is really important and special so the rules shouldn't apply" or argue that the rule is dumb or unfair. That only makes it worse. Try to address how the rule is satisfied.
Search "bitcoin" on google and see if you can find more big references in addition to the infoworld and slashdot ones. There may be very recent stuff being written by reporters who heard about it from the slashdot article.
I hope it doesn't get deleted. If it does, it'll be hard to overcome the presumption. Institutional momentum is to stick with the last decision. (edit: or at least I assume so, that's how the world usually works, but maybe Wiki is different)
250. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-21T00:05:20Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4577#msg4577
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/250/
Still need to know what's the most typical settings file format on Linux. Is there a standard file extension? I've never seen a settings file using JSON, and it doesn't look very human friendly with everything required to be in quotes. I think what I usually see is like:
# comment
setting=value
Is there a settings file thing in Boost?
When you're using bitcoind to issue commands from the command line as a client, can we have it get the password from the settings file then too?
Gavin pointed out I forgot to increment the column of numbers in CommandLineRPC, so the current -rpcpw= implementation doesn't work right from the command line with non-string parameters. (JSON-RPC is fine) Still under construction.
251. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-21T05:51:34Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4646#msg4646
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/251/
I was researching config file formats, here's a comparison.
YAML is massive. I'm not sure there's a lightweight easy to build library we can integrate into our project. Seems overkill.
JSON is tempting and I'm inclined to like it, but two main sticking points:
1) No comments! How can you have a config file where you can't comment out a line to disable it?
2) Not very user friendly to have to "quote" all the strings, including the keys, and also have to remember the comma at the end of lines.
{
"key" : "value",
}
I suppose we could easily preprocess JSON reading the config file one line at a time, truncate the lines at any # character (and/or "//"?), concatenate them into a string and pass it to JSON, so you could go:
# comment
"key" : "value", # still have to remember the comma
"key2" : "value", // comment like this or both
Boost has boost::program_options.
We could read lines ourselves and feed them into a map<string, string> mapConfig.
while (!eof)
read line
if '#' found, truncate line
split line at first ':' -> key, value
mapConfig.insert(key, value)
If we use the syntax:
# comment
key : value
...and don't allow whitespace indenting before the keys, I guess we would be a subset of YAML and could switch to YAML someday if we need more complexity.
If we go with self parsed, that doesn't mean we can't use JSON on particular parameter values as needed. If an option needs a list or more structured data, it could always parse its value as json:
key : ["item1", "item2", "item3"]
Although it has to be all on one line then.
I guess I'm leaning towards self parsed mapConfig:
# comment
key : value
252. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-21T16:07:57Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4758#msg4758
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/252/
Quote from: gavinandresen on July 21, 2010, 12:11:10 PM
I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
1 file used "key value"
5 used "key=value"
Thanks for that survey!
I find "key value" a little unnatural. There ought to be a more definite separator between key and value that suggests assignment. The space people may just be getting lazy using their language's split function.
key=some full sentence with spaces in it. # seems more clear
key some full sentence with spaces in it. # than this
Allright then, lets go with self-parsed mapConfig, syntax:
# comment
key=value
file extension .conf. What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?
I think we better strip whitespace at the beginning and end of the key and the value.
# user who likes column formatted
k = value
key = value
longerkey = this sentence would be this # "this sentence would be this"
key = value # guess this is ok too
nextkey = value
right = justified
The normal syntax should be "key=value", but you can't blame people for the occasional "key = value".
253. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-21T17:31:09Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4775#msg4775
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/253/
boost::program_options has the same "key=value" format. Gavin pointed out we can use it in a simple way as a parser without getting into all the esoteric c++ syntax like typed value extraction. We can use more features if we want later.
Lets go ahead with HTTP basic authentication instead of password as a parameter.
254. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-22T02:34:23Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg4928#msg4928
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/254/
Quote from: gavinandresen on July 22, 2010, 01:11:26 AM
TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.
In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:
#if defined(__WXMSW__) && wxUSE_GUI
MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password>
", "Bitcoin", wxOK | wxICON_EXCLAMATION);
#else
fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password>
");
#endif
255. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-23T17:07:40Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg5337#msg5337
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/255/
Quote from: gavinandresen on July 23, 2010, 03:11:45 PM
Question for everybody: should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication? PHP and Python make is really easy-- just use the http://user:pass@host:port/ URL syntax.
Yes, I think that would be really good so each dev doesn't have to figure it out themselves. We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.
256. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-23T17:14:31Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg5338#msg5338
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/256/
Gavin's changes look good. I think everything is complete. Here's a test build, please test it!
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz
257. Re: bitcoind not responding to RPC
Poster: satoshi · Date: 2010-07-23T17:23:47Z · Thread: bitcoind not responding to RPC
Original: https://bitcointalk.org/index.php?topic=548.msg5339#msg5339
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/257/
If I recall correctly, 500 is the prescribed status code for JSON-RPC error responses. There is still a JSON response in the body of the reply telling the explanation of the error, which could be something like {"result":"","error":"bitcoin address not found","id":"1"}.
258. Faster initial block download (5x faster)
Poster: satoshi · Date: 2010-07-23T18:24:56Z · Thread: Faster initial block download (5x faster)
Original: https://bitcointalk.org/index.php?topic=550.msg5349#msg5349
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/258/
By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes.
The database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.
I only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.
I built a test build if you'd like to start using it:
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz
These binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.
I've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.
There are no changes to the way it handles wallet.dat. This change is only for blk*.dat and the non-critical addr.dat. You can always delete blk*.dat if it gets screwed up and let it re-download.
259. Re: Faster initial block download
Poster: satoshi · Date: 2010-07-23T20:13:27Z · Thread: Faster initial block download (5x faster)
Original: https://bitcointalk.org/index.php?topic=550.msg5378#msg5378
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/259/
Quote from: knightmb on July 23, 2010, 07:32:58 PM
Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?
Not really. I'll change it to 1000 next time.
260. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-23T20:39:03Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg5383#msg5383
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/260/
I don't think authentication should be disabled by default if there's no conf file or the config file doesn't contain "rpcpassword", but what if it contains "rpcpassword="?
I can see both points.
What if the programmer can't figure out how to do HTTP authentication in their language (Fortran or whatever) or it's not even supported by their JSON-RPC library? Should they be able to explicitly disable the password requirement?
OTOH, what if there's a template conf file, with
rpcpassword= # fill in a password here
There are many systems that don't allow you to log in without a password. This forum, for instance. Gavin's point seems stronger.
BTW, I haven't tested it, but I hope having rpcpassword= in the conf file is valid. It's only if you use -server or -daemon or bitcoind that it should fail with a warning. If it doesn't need the password, it should be fine. Is that right?
261. Re: JSON-RPC Multiple Invocations
Poster: satoshi · Date: 2010-07-24T00:59:08Z · Thread: JSON-RPC Multiple Invocations
Original: https://bitcointalk.org/index.php?topic=528.msg5416#msg5416
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/261/
Obviously it's a bug that it repeats the header.
I was trying to follow the 1.0 spec: http://json-rpc.org/wiki/specification It called for multiple invocation.
I think they mean it's like this, but I'm not sure:
Post:
{"method": "postMessage", "params": ["Hello all!"], "id": 99}
{"method": "postMessage", "params": ["I have a question:"], "id": 101}
Reply:
{"result": 1, "error": null, "id": 99}
{"result": 1, "error": null, "id": 101}
I can't remember where I think I saw that it's supposed to send back HTTP status 500 for an error reply. If it contains multiple responses and one is an error, I wonder if that makes the status 500 for the whole thing, I guess so. Maybe it should always return 200. I think someone sounded like the 500 might be causing a problem.
This probably gets fixed after 0.3.3. Until then, just use single invocation. I wonder if any JSON-RPC package even supports multiple invocation, probably not.
It would be nice if we could pin down better how multiple-invocation is supposed to work, if at all, before trying to fix it, and whether returning HTTP status 500 for error response is right.
262. Re: bitcoind not responding to RPC
Poster: satoshi · Date: 2010-07-24T01:15:58Z · Thread: bitcoind not responding to RPC
Original: https://bitcointalk.org/index.php?topic=548.msg5419#msg5419
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/262/
Can anyone confirm if JSON-RPC over HTTP is supposed to use status 500 if the reply is an error reply? I can't remember where I picked that up, maybe it's wrong. It seems like 200 would make more sense unless there's something wrong with the mechanics of the HTTP request itself. (and maybe that's what it said and I forgot and spread 500 to all error responses)
263. Re: Warning: don't use -server or bitcoind on a machine where you web browse
Poster: satoshi · Date: 2010-07-24T02:29:09Z · Thread: Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)
Original: https://bitcointalk.org/index.php?topic=479.msg5432#msg5432
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/263/
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
264. Version 0.3.2.5 -- please test!
Poster: satoshi · Date: 2010-07-24T03:32:52Z · Thread: Version 0.3.2.5 -- please test!
Original: https://bitcointalk.org/index.php?topic=556.msg5443#msg5443
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/264/
Please test 0.3.2.5 in preparation for the 0.3.3 release! This build is looking good and should be the one that goes into 0.3.3. I encourage you to go ahead and upgrade now if you're on Windows or Linux.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
Download here:
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz
Thanks!
265. Re: Reading/Writing Blocks and FLATDATA
Poster: satoshi · Date: 2010-07-24T04:04:20Z · Thread: Reading/Writing Blocks and FLATDATA
Original: https://bitcointalk.org/index.php?topic=555.msg5450#msg5450
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/265/
FLATDATA was a workaround to serialize a fixed field length array. There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time. We don't support MSVC6 anymore because we use something in Boost that doesn't. We lost support for it after 0.2.0. Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.
266. Re: a simple traffic load test run
Poster: satoshi · Date: 2010-07-25T14:46:33Z · Thread: a simple traffic load test run
Original: https://bitcointalk.org/index.php?topic=567.msg5694#msg5694
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/266/
Was that on the test network?
http://bitcointalk.org/index.php?topic=363.0
267. Re: a simple traffic load test run
Poster: satoshi · Date: 2010-07-25T15:29:52Z · Thread: a simple traffic load test run
Original: https://bitcointalk.org/index.php?topic=567.msg5698#msg5698
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/267/
Please do these tests on the test network. That's what it's for. Thanks.
268. Bitcoin 0.3.3 released -- PLEASE UPGRADE
Poster: satoshi · Date: 2010-07-25T16:55:09Z · Thread: Bitcoin 0.3.3 released -- PLEASE UPGRADE
Original: https://bitcointalk.org/index.php?topic=570.msg5707#msg5707
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/268/
Please upgrade to 0.3.3! Important security improvements were made in 0.3.2 and 0.3.3.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
269. Re: Stealing Coins
Poster: satoshi · Date: 2010-07-25T17:45:22Z · Thread: Stealing Coins
Original: https://bitcointalk.org/index.php?topic=571.msg5712#msg5712
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/269/
It's best if you tell it to me privately so it can be fixed first.
I just e-mailed you my e-mail address. (or you could PM me here)
270. Re: Stealing Coins
Poster: satoshi · Date: 2010-07-25T19:06:23Z · Thread: Stealing Coins
Original: https://bitcointalk.org/index.php?topic=571.msg5724#msg5724
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/270/
Red, thanks for telling me privately first! Please go ahead and post it (and relieve the suspense for everyone!)
His point is that transactions paid to a Bitcoin Address are only as secure as the hash function. To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself. An attacker would only have to break the hash function, not ECDSA.
271. Re: Stealing Coins
Poster: satoshi · Date: 2010-07-25T20:01:40Z · Thread: Stealing Coins
Original: https://bitcointalk.org/index.php?topic=571.msg5740#msg5740
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/271/
Quote from: knightmb on July 25, 2010, 07:44:02 PM
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.
But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.
You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key.
When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.
Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.
He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt.
272. Re: Stealing Coins
Poster: satoshi · Date: 2010-07-25T20:48:01Z · Thread: Stealing Coins
Original: https://bitcointalk.org/index.php?topic=571.msg5754#msg5754
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/272/
Quote
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.
2^80 is if you can use a birthday attack. You can't use a birthday attack for this, so the difficulty is the full 2^160 bits. Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.
Bitcoin Addresses are the only place where 160-bit hash is used. Everything else is SHA-256. They're calculated as:
bitcoinaddress = RIPEMD-160(SHA-256(publickey))
Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case. An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision. Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256. If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it? You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.
For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone. But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256. If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.
273. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-25T21:34:29Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg5767#msg5767
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/273/
Quote from: lachesis on July 25, 2010, 07:52:35 PM
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
Code:
...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like "bitcoin getinfo" fail. The server still works fine with properly behaving clients.
This can be solved by removing the newlines (and maybe '
's) from result at the end of the Base64Encode function:
Code:
result.erase(std::remove(result.begin(), result.end(), '
'), result.end());
result.erase(std::remove(result.begin(), result.end(), '
'), result.end());
+1 to you for having such a long password that you found this bug.
Uploaded to SVN as rev 110.
274. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-25T21:44:16Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg5769#msg5769
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/274/
Quote from: BitLex on July 25, 2010, 08:45:38 PM
i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.
That's strange, didn't someone just say that was supposed to work? (what library was he using?) Post if you figure out what wrong.
I hope it's not going to put up this much of a fight for all PHP users.
Looks like we've got the Fortran scenario already.
275. Re: JSON-RPC password
Poster: satoshi · Date: 2010-07-25T21:51:31Z · Thread: JSON-RPC password
Original: https://bitcointalk.org/index.php?topic=461.msg5771#msg5771
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/275/
Quote from: gavinandresen on July 25, 2010, 09:38:19 PM
Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function
SVN rev 111
276. Re: md5?
Poster: satoshi · Date: 2010-07-25T22:06:57Z · Thread: md5?
Original: https://bitcointalk.org/index.php?topic=458.msg5772#msg5772
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/276/
For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later.
http://www.bitcoin.org/Satoshi_Nakamoto.asc
277. Re: Stealing Coins
Poster: satoshi · Date: 2010-07-25T22:27:36Z · Thread: Stealing Coins
Original: https://bitcointalk.org/index.php?topic=571.msg5778#msg5778
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/277/
Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA. I shouldn't have said "prime numbers". ECDSA doesn't take much time to generate a keypair.
278. bitcoind without wxWidgets
Poster: satoshi · Date: 2010-07-26T17:23:33Z · Thread: bitcoind without wxWidgets
Original: https://bitcointalk.org/index.php?topic=576.msg5904#msg5904
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/278/
I replaced the last of the few wxBase dependencies in bitcoind.
bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.
main(int argc, char* argv[]) is added to init.cpp. CMyApp and the Startup folder stuff are moved to ui.cpp. ui.cpp and uibase.cpp aren't linked by bitcoind.
The makefiles have -DGUI to control whether the GUI is used.
I test compiled MinGW, VC and Ubuntu. I don't know if I broke the Mac OSX build, someone will need to check that.
279. Re: Bitcoin x64 for Windows
Poster: satoshi · Date: 2010-07-26T18:41:31Z · Thread: Bitcoin x64 for Windows
Original: https://bitcointalk.org/index.php?topic=501.msg5920#msg5920
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/279/
Quote from: Olipro on July 26, 2010, 06:39:17 AM
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Is that still starting from Crypto++? Lets get this into the main sourcecode.
280. Re: Bitcoin x86 for Windows
Poster: satoshi · Date: 2010-07-27T01:29:42Z · Thread: Bitcoin x86 for Windows
Original: https://bitcointalk.org/index.php?topic=572.msg5978#msg5978
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/280/
Quote from: Olipro on July 26, 2010, 01:04:41 PM
Crypto++ 5.6.0: http://www.cryptopp.com/
Cached SHA256: http://pastebin.com/rJAYZJ32 (although I'm pretty sure this is publically submitted elsewhere, I was linked to it on IRC)
I added the cached SHA256 state idea to the SVN, rev 113. The speedup is about 70%. I credited it to tcatm based on your post in the x64 thread.
I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers?
281. Re: Proof-of-work difficulty increasing
Poster: satoshi · Date: 2010-07-27T03:04:58Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg5990#msg5990
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/281/
New difficulty factor 244.213223092
+35%
I updated the first post.
date, difficulty factor, % change
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
282. Re: Bitcoin x86 for Windows
Poster: satoshi · Date: 2010-07-27T18:27:30Z · Thread: Bitcoin x86 for Windows
Original: https://bitcointalk.org/index.php?topic=572.msg6069#msg6069
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/282/
Quote from: BlackEye on July 25, 2010, 10:12:23 PM
I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly code. Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.
I think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.
I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped it down to just SHA and 11 general dependency files. There shouldn't be any other crypto in there other than SHA.
I aligned the data fields and it worked. The ASM SHA-256 is about 48% faster. The combined speedup is about 2.5x faster than version 0.3.3.
I guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment.
It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.
This is SVN rev 114.
283. Re: Bitcoin x86 for Windows
Poster: satoshi · Date: 2010-07-27T19:47:42Z · Thread: Bitcoin x86 for Windows
Original: https://bitcointalk.org/index.php?topic=572.msg6083#msg6083
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/283/
OK, thanks. I'd also like to know if it runs fine as long as you don't turn on Generate. You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load. At least Pentium 3's could run it without generating.
284. Re: Having problems specifing -datadir
Poster: satoshi · Date: 2010-07-28T20:58:26Z · Thread: Having problems specifing -datadir
Original: https://bitcointalk.org/index.php?topic=601.msg6268#msg6268
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/284/
It was able to reproduce this. The database doesn't like the relative path.
"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.
I guess we should resolve the full path before passing it to the database.
It looks like you were the first one to ever use -datadir with a relative path.
285. Re: Build error SVN r115 on my Mac: workaround
Poster: satoshi · Date: 2010-07-28T21:23:23Z · Thread: Build error SVN r115 on my Mac: workaround
Original: https://bitcointalk.org/index.php?topic=604.msg6273#msg6273
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/285/
Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?
I had to do that for makefile.vc also. It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.
We'll disable it now, and if anyone figures out how to fix it, we can re-enable it then. It's still 1.7x faster from the midstate optimisation.
The Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).
I uploaded this makefile.osx change to SVN. (let me know if that compiles now)
286. Re: Difficulty
Poster: satoshi · Date: 2010-07-29T01:16:23Z · Thread: Difficulty
Original: https://bitcointalk.org/index.php?topic=587.msg6301#msg6301
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/286/
You were looking at the wrong code. Here's the code that applies:
Code:
bool CBlock::CheckBlock() const
{
...
// Check timestamp
if (nTime > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
...
bool CBlock::AcceptBlock()
{
...
// Check timestamp against prev
if (nTime <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");
The timestamp is limited to up to 2 hours in the future. It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks. The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened.
287. Re: Scalability and transaction rate
Poster: satoshi · Date: 2010-07-29T02:00:38Z · Thread: Scalability and transaction rate
Original: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/287/
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
Quote from: bytemaster on July 28, 2010, 08:59:42 PM
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819
288. Re: wiki registration email?
Poster: satoshi · Date: 2010-07-29T02:10:46Z · Thread: wiki registration email?
Original: https://bitcointalk.org/index.php?topic=338.msg6307#msg6307
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/288/
WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that.
289. *** ALERT *** Upgrade to 0.3.6
Poster: satoshi · Date: 2010-07-29T19:13:06Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6451#msg6451
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/289/
Please upgrade to 0.3.6 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6!
If you can't upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do.
Also in 0.3.6, faster hashing:
- midstate cache optimisation thanks to tcatm
- Crypto++ ASM SHA-256 thanks to BlackEye
Total generating speedup 2.4x faster.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/
Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
290. Re: *** ALERT *** version 0.3.6
Poster: satoshi · Date: 2010-07-29T19:55:51Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6469#msg6469
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/290/
Haven't had time to update the SVN yet. Wait for 0.3.6, I'm building it now. You can shut down your node in the meantime.
291. Re: *** ALERT *** version 0.3.6
Poster: satoshi · Date: 2010-07-29T20:30:15Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6480#msg6480
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/291/
SVN is updated with version 0.3.6.
Uploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux.
292. Re: *** ALERT *** Upgrade to 0.3.6 ASAP!
Poster: satoshi · Date: 2010-07-29T21:20:38Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6490#msg6490
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/292/
0.3.6 Linux build is back to the old makefile.unix. It static links libjpeg so that shouldn't be a problem.
Is that working better?
If you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*
Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
293. Re: *** ALERT *** Upgrade to 0.3.6 ASAP!
Poster: satoshi · Date: 2010-07-29T21:43:15Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6502#msg6502
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/293/
"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.
294. Re: Implementation bug prior to 0.3.6
Poster: satoshi · Date: 2010-07-29T22:04:15Z · Thread: Implementation bug prior to 0.3.6
Original: https://bitcointalk.org/index.php?topic=628.msg6508#msg6508
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/294/
Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.
295. Re: Transaction disappeared in the void...
Poster: satoshi · Date: 2010-07-29T22:08:31Z · Thread: Transaction disappeared in the void...
Original: https://bitcointalk.org/index.php?topic=615.msg6512#msg6512
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/295/
If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it. Long term, it does keep relentlessly sending it.
I'll shorten that length of time in a future version.
You do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms. Same with the recipient.
296. Re: Linux distribution download
Poster: satoshi · Date: 2010-07-29T22:17:24Z · Thread: Linux distribution download
Original: https://bitcointalk.org/index.php?topic=612.msg6516#msg6516
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/296/
Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that.
297. Re: *** ALERT *** Upgrade to 0.3.6 ASAP!
Poster: satoshi · Date: 2010-07-29T23:12:12Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6542#msg6542
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/297/
Quote from: lachesis on July 29, 2010, 10:14:36 PM
On Debian testing 32-bit, I get a few build errors, all resembling:
Code:
script.cpp:114: error: OP_NOP1 was not declared in this scopeI got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.
If anyone else gets this error, the simplest solution is to "make clean" and retry the build.
We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.
Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates.
298. Re: Bug: "Immature" coins lost in wallet.dat during transaction
Poster: satoshi · Date: 2010-07-30T19:19:05Z · Thread: Bug: "Immature" coins lost in wallet.dat during transaction
Original: https://bitcointalk.org/index.php?topic=642.msg6701#msg6701
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/298/
I don't get how it let you send if it was not matured. Your balance would have been lower than the amount. It would have said balance 0.01, right? If I try that it says "you don't have enough money" or "Insufficient funds" from the command line.
How many blocks did it say it had left to mature when you sent?
There's a chance it might still go through.
Have you copied or moved your wallet.dat in any way?
299. Re: [PATCH] implement 'listtransactions'
Poster: satoshi · Date: 2010-07-30T19:40:54Z · Thread: [PATCH] implement 'xlisttransactions'
Original: https://bitcointalk.org/index.php?topic=611.msg6706#msg6706
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/299/
What are you needing to use listtransactions for?
The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.
When we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like "0/unconfirmed 0:0:0 date comment debit 4 credit 0" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.
300. Re: *** ALERT *** Upgrade to 0.3.6 ASAP!
Poster: satoshi · Date: 2010-07-30T19:53:06Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6711#msg6711
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/300/
Quote from: knightmb on July 30, 2010, 07:24:07 PM
I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.
I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:
Dependencies
------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev (or libboost1.37-dev)
wxWidgets
---------
cd /usr/local
tar -xzvf wxWidgets-2.9.0.tar.gz
cd /usr/local/wxWidgets-2.9.0
mkdir buildgtk
cd buildgtk
../configure --with-gtk --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install
ldconfig
added a comment in makefile.unix:
# for boost 1.37, add -mt to the boost libraries
LIBS= \
-Wl,-Bstatic \
-l boost_system \
-l boost_filesystem \
-l boost_program_options \
-l boost_thread \
-l db_cxx \
-l crypto \
-Wl,-Bdynamic \
-l gthread-2.0
301. Re: *** ALERT *** Upgrade to 0.3.6 ASAP!
Poster: satoshi · Date: 2010-07-30T21:44:04Z · Thread: *** ALERT *** Upgrade to 0.3.6
Original: https://bitcointalk.org/index.php?topic=626.msg6728#msg6728
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/301/
Quote from: knightmb on July 30, 2010, 08:04:19 PM
So that last command should simply be
sudo apt-get install libboost1.37-dev
Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.
Seems they changed everything around in Boost recently, "-mt" and all that, makes it hard.
BTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.
Mac OSX version is available now. See bitcoin.org or the SourceForge link.
302. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-07-31T00:29:20Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg6751#msg6751
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/302/
That's amazing...
So are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.
303. Webpage idea: Next predicted difficulty change
Poster: satoshi · Date: 2010-07-31T01:32:08Z · Thread: Webpage idea: Next predicted difficulty change
Original: https://bitcointalk.org/index.php?topic=651.msg6760#msg6760
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/303/
It would be neat if someone had a page (like that handy calculator at http://www.alloscomp.com/bitcoin/calculator.php) that projects what the next difficulty adjustment will be.
projected difficulty adjustment multiplier =
blocks_since_last_adjustment / 2016
------------------------------------
time_since_last_adjustment / 14_days
For instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double:
(1008/2016) / (3.5/14) = 0.5/0.25 = 2.0
Also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed.
304. Re: Linux distribution download
Poster: satoshi · Date: 2010-07-31T14:38:52Z · Thread: Linux distribution download
Original: https://bitcointalk.org/index.php?topic=612.msg6822#msg6822
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/304/
It can be built with Boost 1.37 or later.
305. Re: Linux version => No GUI after upgrade. WTF?
Poster: satoshi · Date: 2010-08-02T17:39:27Z · Thread: Linux version => No GUI after upgrade. WTF?
Original: https://bitcointalk.org/index.php?topic=655.msg7057#msg7057
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/305/
Did it print anything to the console? Are you sure you didn't run "bitcoind"?
Try version 0.3.7.
306. Re: Mac Client Problems Outlined...
Poster: satoshi · Date: 2010-08-02T18:02:20Z · Thread: Mac Client Problems Outlined...
Original: https://bitcointalk.org/index.php?topic=660.msg7068#msg7068
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/306/
"Minimize to the tray instead of the taskbar" & "Minimize to the tray on close" must not be implemented yet on the Mac. We should grey them out in the next version.
307. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-02T19:02:46Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg7084#msg7084
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/307/
Is it 2x fast on AMD and 1/2 fast on Intel?
Quote from: tcatm on July 31, 2010, 10:12:38 AM
Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?
Tried that, but it doesn't work for things on the stack. I ran some tests.
It doesn't even cause an error, it just doesn't align it.
308. Re: Protocol Buffers for Bitcoin
Poster: satoshi · Date: 2010-08-02T20:22:08Z · Thread: Protocol Buffers for Bitcoin
Original: https://bitcointalk.org/index.php?topic=632.msg7090#msg7090
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/308/
The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.
I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. The serialization format we have is as dead simple and flat as possible. There is no extra freedom in the way the input stream is formed. At each point, the next field in the data structure is expected. The only choices given are those that the receiver is expecting. There is versioning so upgrades are possible.
CAddress is about the only object with significant reserved space in it. (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)
The larger things we have like blocks and transactions can't be optimized much more for size. The bulk of their data is hashes and keys and signatures, which are uncompressible. The serialization overhead is very small, usually 1 byte for size fields.
On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. There are few P2P systems that only need broadcast. There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. Those libraries are also much harder to install than ourselves.
309. Re: Builds for Ubuntu?
Poster: satoshi · Date: 2010-08-03T20:56:11Z · Thread: Builds for Ubuntu?
Original: https://bitcointalk.org/index.php?topic=454.msg7328#msg7328
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/309/
Quote from: nimnul on August 03, 2010, 05:51:15 PM
Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk
Yes, 0.3.7 has it. It was in rev 112.
310. Re: Bitcoind x86 binary for CentOS
Poster: satoshi · Date: 2010-08-03T21:05:08Z · Thread: Bitcoind x86 binary for CentOS
Original: https://bitcointalk.org/index.php?topic=685.msg7331#msg7331
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/310/
Quote from: sgtstein on August 03, 2010, 05:30:37 PM
I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk. [image: Undecided; source: /static/img/emoticons/undecided.gif]
I urge you not to use BDB 4.8. The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.
311. Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)
Poster: satoshi · Date: 2010-08-03T21:26:26Z · Thread: Authentication, JSON RPC and Python
Original: https://bitcointalk.org/index.php?topic=689.msg7335#msg7335
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/311/
Quote from: gavinandresen on August 03, 2010, 06:56:44 PM
Quote from: jgarzik on August 03, 2010, 06:09:08 PM
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.
I guess we should try to support the case where there's no Content-Length parameter. I don't want to rip and replace streams though, even if it has to read one character at a time.
Edit: That is, assuming there actually are any libraries that don't support Content-Length.
312. Re: What happens when network is split for prolonged time and reconnected?
Poster: satoshi · Date: 2010-08-03T22:45:07Z · Thread: What happens when network is split for prolonged time and reconnected?
Original: https://bitcointalk.org/index.php?topic=661.msg7356#msg7356
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/312/
creighto: I agree with that idea. After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance. It could tell if it's not hearing the hum of the world anymore.
Quote from: knightmb on August 03, 2010, 07:02:13 PM
Quote from: gavinandresen on August 03, 2010, 06:38:44 PM
Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),
In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days. Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.
Quote from: knightmb on August 03, 2010, 07:02:13 PM
If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?
There's no time limit. Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.
313. Please upgrade to 0.3.8!
Poster: satoshi · Date: 2010-08-03T23:40:18Z · Thread: Please upgrade to 0.3.8!
Original: https://bitcointalk.org/index.php?topic=696.msg7364#msg7364
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/313/
Version 0.3.8 adds an important security improvement. Everyone should upgrade to get this change.
The new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.
If it sees a longer chain, but it can't process it, then it knows something is wrong. It displays "WARNING: Displayed transactions may not be correct! You may need to upgrade." and makes most RPC commands return an error. It still keeps generating as normal, which is necessary for the stability of the network.
There were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!
Also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/
314. Re: Bitcoind x86 binary for CentOS
Poster: satoshi · Date: 2010-08-04T00:09:32Z · Thread: Bitcoind x86 binary for CentOS
Original: https://bitcointalk.org/index.php?topic=685.msg7372#msg7372
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/314/
Quote from: knightmb on August 03, 2010, 11:46:46 PM
There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
I'd rather you didn't make a build of the 1000 node connecting version available. It won't take very many people running that before we have to make another release just to limit the incoming connections.
315. Re: Please upgrade to 0.3.8!
Poster: satoshi · Date: 2010-08-04T00:29:37Z · Thread: Please upgrade to 0.3.8!
Original: https://bitcointalk.org/index.php?topic=696.msg7381#msg7381
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/315/
I guess SourceForge hasn't updated its mirrors yet. The files are there on the admin side, but not on the user side. I have no idea how long that will take. It's always been immediate in the past.
Edit: SourceForge is updated now.
316. Re: Building initial transaction trust through "coin ripping"
Poster: satoshi · Date: 2010-08-04T00:40:40Z · Thread: Building initial transaction trust through "coin ripping"
Original: https://bitcointalk.org/index.php?topic=635.msg7385#msg7385
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/316/
The software is designed to support things like this. I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time.
317. Re: Flood attack 0.00000001 BC
Poster: satoshi · Date: 2010-08-04T16:25:36Z · Thread: Flood attack 0.00000001 BC
Original: https://bitcointalk.org/index.php?topic=287.msg7524#msg7524
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/317/
Quote from: Insti on August 04, 2010, 02:58:31 PM
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.
318. Re: Flood attack 0.00000001 BC
Poster: satoshi · Date: 2010-08-05T16:03:21Z · Thread: Flood attack 0.00000001 BC
Original: https://bitcointalk.org/index.php?topic=287.msg7687#msg7687
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/318/
Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
I am not claiming that the network is impervious to DoS attack. I think most P2P networks can be DoS attacked in numerous ways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)
If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don't abuse them.
That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left. I think it should just add it automatically. It's trivial compared to the fees many other types of services add automatically.
Quote from: FreeMoney on August 04, 2010, 07:30:32 PM
Does including more slow down your hashing rate?
No, not at all.
319. Re: Flood attack 0.00000001 BC
Poster: satoshi · Date: 2010-08-05T16:30:20Z · Thread: Flood attack 0.00000001 BC
Original: https://bitcointalk.org/index.php?topic=287.msg7694#msg7694
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/319/
Quote from: bytemaster
Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned. This rule makes it impossible to pay for a simple "search query" with no further transactions.
One alternative is to use a round-up system. You pay for, say, 1000 pages or images or downloads or searches or whatever at a time. When you've used up your 1000 pages, you pay for another 1000 pages. If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.
Or you could pay per day. The first time you access the site on a given day, you pay for 24 hours of access.
Per 1000 or per day may be easier for consumers to get their heads around too. They worry about per item because it's harder to figure if it might add up too fast. Unlimited for 24 hours they know what the cost will be. Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.
320. Re: Flood attack 0.00000001 BC
Poster: satoshi · Date: 2010-08-05T16:39:58Z · Thread: Flood attack 0.00000001 BC
Original: https://bitcointalk.org/index.php?topic=287.msg7696#msg7696
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/320/
Quote from: bytemaster on August 05, 2010, 03:39:19 PM
The only solution to this problem is to make broadcasting of a transaction "non free". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.
I don't know a way to implement that. The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size. If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
321. Re: Who's the Spanish jerk draining the Faucet?
Poster: satoshi · Date: 2010-08-05T17:06:03Z · Thread: Who's the Spanish jerk draining the Faucet?
Original: https://bitcointalk.org/index.php?topic=704.msg7703#msg7703
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/321/
Silently failing would look bad.
Quote from: gavinandresen on August 04, 2010, 08:40:55 PM
1. Rate limit based on the first byte of the IP address (79. or 81. in this case).
Definitely needed. What rate are you thinking of? Ultimately, it's better to rate limit it than to let it all drain out.
Quote from: gavinandresen on August 04, 2010, 08:40:55 PM
3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).
That might work surprisingly well. If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.
Quote from: gavinandresen on August 04, 2010, 08:40:55 PM
4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).
Definitely time to lower it.
322. Re: bitcoind transaction to ip address
Poster: satoshi · Date: 2010-08-05T17:28:40Z · Thread: bitcoind transaction to ip address
Original: https://bitcointalk.org/index.php?topic=711.msg7705#msg7705
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/322/
It's not implemented.
It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.
323. Re: Transaction Overload Solution
Poster: satoshi · Date: 2010-08-05T17:38:21Z · Thread: Transaction Overload Solution
Original: https://bitcointalk.org/index.php?topic=713.msg7706#msg7706
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/323/
I can't think of a way to implement that. All the transaction fees would be additional transactions. What about the transaction fees for the transaction fee's transaction?
324. Re: Flood attack 0.00000001 BC
Poster: satoshi · Date: 2010-08-05T17:49:43Z · Thread: Flood attack 0.00000001 BC
Original: https://bitcointalk.org/index.php?topic=287.msg7710#msg7710
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/324/
Quote from: bytemaster on August 05, 2010, 04:46:52 PM
Right now the transaction fee address is left "blank" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.
If you're only going to have one person work on building the block, that could take days. Oh, do you mean send a different variation to each node with the tx fee written to them?
The way it is now, it's whoever builds this gets it.
If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast. Relay paying transactions to me, or I won't relay them to you. It probably won't be an actual problem though. It only takes one node relaying like it should to cancel out 7 others greedily not relaying.
325. Re: A proposal for a semi-automated Escrow mechanism
Poster: satoshi · Date: 2010-08-05T18:08:30Z · Thread: A proposal for a semi-automated Escrow mechanism
Original: https://bitcointalk.org/index.php?topic=645.msg7712#msg7712
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/325/
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
326. Re: latency and locality
Poster: satoshi · Date: 2010-08-07T16:28:17Z · Thread: latency and locality
Original: https://bitcointalk.org/index.php?topic=723.msg8103#msg8103
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/326/
Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?
327. Re: Bitcoin minting is thermodynamically perverse
Poster: satoshi · Date: 2010-08-07T17:46:09Z · Thread: Bitcoin minting is thermodynamically perverse
Original: https://bitcointalk.org/index.php?topic=721.msg8114#msg8114
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/327/
It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.
I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste.
Quote from: gridecon on August 06, 2010, 04:48:00 PM
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to "roll as many dice as posible" within that given time period? The "chain of proof" for coin ownership and transactions doesn't depend on the method for spawning coins.
Each node's influence on the network is proportional to its CPU power. The only way to show the network how much CPU power you have is to actually use it.
If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs.
I suppose it might be possible to measure CPU power at certain times. For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes. You could still prove your total power at given times without running it all the time. I'm not sure how that could be implemented though. There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.
Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.
328. Re: A proposal for a semi-automated Escrow mechanism
Poster: satoshi · Date: 2010-08-07T20:04:59Z · Thread: A proposal for a semi-automated Escrow mechanism
Original: https://bitcointalk.org/index.php?topic=645.msg8137#msg8137
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/328/
Quote from: jgarzik on August 05, 2010, 07:00:30 PM
Due to that recourse, it is unlikely to be used as an escrow mechanism [image: Smiley; source: /static/img/emoticons/smiley.gif]
Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)
329. Escrow
Poster: satoshi · Date: 2010-08-07T20:13:52Z · Thread: Escrow
Original: https://bitcointalk.org/index.php?topic=750.msg8140#msg8140
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/329/
Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.
The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.
While this system does not guarantee the parties against loss, it takes the profit out of cheating.
If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.
Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.
330. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-07T21:16:01Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg8145#msg8145
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/330/
Quote from: impossible7 on August 06, 2010, 11:37:20 AM
CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.
Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs.
331. Re: bitcoin generation broken in 0.3.8?
Poster: satoshi · Date: 2010-08-09T18:50:41Z · Thread: bitcoin generation broken in 0.3.8? (64-bit)
Original: https://bitcointalk.org/index.php?topic=753.msg8388#msg8388
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/331/
I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility. I was trying to take the safer option.
It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime. Maybe I'm not looking in the right place.
Should we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit.
I will recompile the 64-bit part of the Linux 0.3.8 release.
332. Version 0.3.8.1 update for Linux 64-bit
Poster: satoshi · Date: 2010-08-09T19:46:58Z · Thread: Version 0.3.8.1 update for Linux 64-bit
Original: https://bitcointalk.org/index.php?topic=765.msg8402#msg8402
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/332/
When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build. Version 0.3.8.1 is on SourceForge with the 64-bit binary updated.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download
Future versions after 0.3.8 will probably require SSE2. Anyone have Pentium 3 or older where this would be a problem?
333. Re: What could be the transition plan to Y2038 compliant Bitcoin?
Poster: satoshi · Date: 2010-08-09T20:13:26Z · Thread: What could be the transition plan to Y2038 compliant Bitcoin? (it already is)
Original: https://bitcointalk.org/index.php?topic=760.msg8413#msg8413
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/333/
unsigned int is good until 2106. Surely the network will have to be totally revamped at least once by then.
There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int.
334. Re: bitcoin generation broken in 0.3.8? (64-bit)
Poster: satoshi · Date: 2010-08-09T20:34:06Z · Thread: bitcoin generation broken in 0.3.8? (64-bit)
Original: https://bitcointalk.org/index.php?topic=753.msg8417#msg8417
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/334/
I uploaded 0.3.8.1 for Linux with re-built 64-bit. I ran a difficulty 1 test with it and it has generated blocks.
http://bitcointalk.org/index.php?topic=765.0
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download
335. Re: Version 0.3.8.1 update for Linux 64-bit
Poster: satoshi · Date: 2010-08-09T20:55:06Z · Thread: Version 0.3.8.1 update for Linux 64-bit
Original: https://bitcointalk.org/index.php?topic=765.msg8422#msg8422
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/335/
That's a good point, I believe you could run with generation off if you don't have SSE2.
How about add to the top of cryptopp/config.h:
#if !defined(_M_X64) && !defined(__x86_64__)
#define CRYPTOPP_DISABLE_SSE2 1
#endif
that would disable SSE2 for 32-bit builds. (at least with GCC or MSVC)
336. Connection limits
Poster: satoshi · Date: 2010-08-09T20:58:45Z · Thread: Connection limits
Original: https://bitcointalk.org/index.php?topic=766.msg8424#msg8424
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/336/
SVN rev 125:
- Always make 8 outbound connections even if have 8 inbound
- Limit outbound connections to one per a.b.?.? range
- Switch -maxconnections=#
I added the (currently undocumented) switch -maxconnections=#. You shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.
I haven't really tested -maxconnections much, could someone test it?
337. Re: Bitcoin minting is thermodynamically perverse
Poster: satoshi · Date: 2010-08-09T21:28:39Z · Thread: Bitcoin minting is thermodynamically perverse
Original: https://bitcointalk.org/index.php?topic=721.msg8431#msg8431
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/337/
The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer.
If you have other cheaper heating than electric, then the waste is only the difference in cost.
If it's summer and you're using A/C, then it's twice.
Bitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free.
338. Re: Version 0.3.8.1 update for Linux 64-bit
Poster: satoshi · Date: 2010-08-10T23:46:00Z · Thread: Version 0.3.8.1 update for Linux 64-bit
Original: https://bitcointalk.org/index.php?topic=765.msg8628#msg8628
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/338/
SVN rev 128: disable SSE2 on 32-bit. This may only disable it for MSVC and GCC. Other compilers might have different 64-bit defines.
339. Re: Not a suggestion
Poster: satoshi · Date: 2010-08-11T00:14:22Z · Thread: Not a suggestion
Original: https://bitcointalk.org/index.php?topic=770.msg8637#msg8637
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/339/
This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.
Originally, a coin can be just a chain of signatures. With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double-spends that requires global knowledge of all transactions.
The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?
It's hard to think of how to apply