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 3 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.
zero-knowledge-proofs in this case.
We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
340. Re: Escrow
Poster: satoshi · Date: 2010-08-11T01:30:02Z · Thread: Escrow
Original: https://bitcointalk.org/index.php?topic=750.msg8649#msg8649
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/340/
Quote from: jgarzik on August 10, 2010, 06:53:57 PM
Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.
When you pay for something up front, you can't get it back either. Consumers seem comfortable with that. It's no worse than that.
Either party always has the option to release it to the other.
Quote from: nelisky on August 10, 2010, 08:20:36 PM
But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
Then you must also be against the common system of payment up front, where the customer loses.
Payment up front: customer loses, and the thief gets the money.
Simple escrow: customer loses, but the thief doesn't get the money either.
Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?
Imagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.
Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.
It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about "money burning" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever.
341. Re: Compile error in SVN r127
Poster: satoshi · Date: 2010-08-11T01:42:30Z · Thread: Compile error in SVN r127
Original: https://bitcointalk.org/index.php?topic=784.msg8651#msg8651
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/341/
Updated SVN. Thanks.
There's little hope of not repeatedly stumbling over that in the future. It doesn't break the compile for me.
342. Re: Not a suggestion
Poster: satoshi · Date: 2010-08-11T21:07:59Z · Thread: Not a suggestion
Original: https://bitcointalk.org/index.php?topic=770.msg8798#msg8798
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/342/
Still thinking this idea through...
The only job the network needs to do is to tell whether a spend of an outpoint is the first or not.
If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:
- the value
- the association of inpoints and outpoints in one transaction
The network would track a bunch of independent outpoints. It doesn't know what transactions or amounts they belong to. A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent. The network keeps the outpoint and the first valid inpoint that proves it spent. The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.
I believe the clients would have to keep the entire history back to the original generated coins. Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend. Maybe the data transfer could be done as an e-mail attachment.
The fact that clients have to keep the entire history reduces the privacy benefit. Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.
343. Re: Lost large number of bitcoins
Poster: satoshi · Date: 2010-08-11T21:46:51Z · Thread: Lost large number of bitcoins
Original: https://bitcointalk.org/index.php?topic=782.msg8803#msg8803
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/343/
Quote from: sirius-m on August 11, 2010, 02:01:53 AM
I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.
You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup. (like 5 seconds)
Quote from: gridecon on August 11, 2010, 08:46:08 PM
Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction.
No, it doesn't usually empty your wallet with each transaction. It uses the smallest set of coins it can find to add up to near the amount. In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change.
344. Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.
Poster: satoshi · Date: 2010-08-11T22:40:25Z · Thread: Where is the separate discussion devoted to possible Bitcoin weaknesses.
Original: https://bitcointalk.org/index.php?topic=788.msg8804#msg8804
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/344/
It doesn't have to be such a breaking change. New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW. Or, they could always accept old transactions, but only a limited number per time period.
I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better. 0.01 is basically a proof of work, but not wasted. But if the problem is validating loads of transactions, then PoW could be checked faster.
A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected. Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack.
Quote from: gavinandresen on August 11, 2010, 04:10:56 PM
Bitcoin's p2p network is subject to various kinds of denial of service attacks.
There, I said it.
+1
Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.
345. Re: Flood attack 0.00000001 BC
Poster: satoshi · Date: 2010-08-11T23:28:50Z · Thread: Flood attack 0.00000001 BC
Original: https://bitcointalk.org/index.php?topic=287.msg8810#msg8810
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/345/
It would be nice to keep the blk*.dat files small as long as we can.
The eventual solution will be to not care how big it gets.
But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore.
There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI.
Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
346. Re: BSD detection
Poster: satoshi · Date: 2010-08-12T00:02:06Z · Thread: BSD detection
Original: https://bitcointalk.org/index.php?topic=790.msg8814#msg8814
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/346/
Quote from: dkaparis on August 11, 2010, 11:00:16 PM
There is this piece of code in headers.h:
#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif
That code was a bad idea anyway, I'm deleting it. Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__.
Quote
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif
Will that definitely cause BSD to be defined on Mac?
347. Re: Not a suggestion
Poster: satoshi · Date: 2010-08-12T02:46:56Z · Thread: Not a suggestion
Original: https://bitcointalk.org/index.php?topic=770.msg8836#msg8836
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/347/
Quote from: Red on August 12, 2010, 01:10:19 AM
Quote from: satoshi on August 11, 2010, 09:07:59 PM
I believe the clients would have to keep the entire history back to the original generated coins. The fact that clients have to keep the entire history reduces the privacy benefit.
I thought this too at first. But then I convinced myself otherwise.
Are you back to talking about the existing Bitcoin system here?
I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back.
If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:
1) Show it the entire history back to the original generated coin.
2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.
But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think.
348. Re: BSD detection
Poster: satoshi · Date: 2010-08-12T21:14:20Z · Thread: BSD detection
Original: https://bitcointalk.org/index.php?topic=790.msg8919#msg8919
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/348/
This is in SVN rev 130. Check that it compiles right.
Code:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h> // to get BSD define
#endif
#ifdef __WXMAC_OSX__
#ifndef BSD
#define BSD 1
#endif
#endif
349. Bugfixes in SVN rev 130
Poster: satoshi · Date: 2010-08-12T21:20:31Z · Thread: Bugfixes in SVN rev 130
Original: https://bitcointalk.org/index.php?topic=795.msg8920#msg8920
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/349/
Misc bugfixes in rev 130:
fix -datadir with relative path
autostart is now off by default except on windows
fix occasional "vector iterator not dereferencable" assertion when compiled with msvc
fix readlink compile warning on linux build
use sys/param.h and BSD define instead of __BSD__
-paytxfee switch, e.g. -paytxfee=0.01
350. Re: Bitcoin Watchdog Service
Poster: satoshi · Date: 2010-08-12T21:34:44Z · Thread: Bitcoin Watchdog Service
Original: https://bitcointalk.org/index.php?topic=691.msg8922#msg8922
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/350/
True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.
ISP network cuts are just your local area. If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less. Block generation in the segment would take several hours per block.
I favour the plan to monitor if the frequency of blocks received drops too slow. That covers a large range of possibilities.
351. Re: Having problems specifing -datadir
Poster: satoshi · Date: 2010-08-12T21:43:29Z · Thread: Having problems specifing -datadir
Original: https://bitcointalk.org/index.php?topic=601.msg8924#msg8924
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/351/
Fixed in SVN rev 130.
352. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-12T22:07:23Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg8929#msg8929
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/352/
That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with. Unless it's a touted feature of the i5 that they made SSE2 six times faster.
A quick summary:
Xeon Quad 41% slower
Core 2 Duo 55% slower
Core 2 Duo same (vess)
Core 2 Quad 50% slower
Core i5 200% faster (nelisky)
Core i5 100% faster (vess)
AMD Opteron 105% faster
aceat64:
My system went from ~7100 to ~4200.
This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.
impossible7:
on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)
nelisky:
My Core2Quad (Q6600) slowed down 50%,
my i5 improved ~200%,
impossible7:
on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)
353. Re: Bugfixes in SVN rev 130
Poster: satoshi · Date: 2010-08-13T03:15:23Z · Thread: Bugfixes in SVN rev 130
Original: https://bitcointalk.org/index.php?topic=795.msg8960#msg8960
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/353/
No, that's not what it is.
-paytxfee allows you to include a transaction fee with your transactions. If transaction confirmations become slow, you can get priority by using "-paytxfee=0.01". Any transactions you send would cost an extra 0.01. There's no reason to use more than 0.01.
It's just there in case we need it. It probably won't be needed, and it can be explained more if we do.
354. Re: Bitcoin Watchdog Service
Poster: satoshi · Date: 2010-08-13T17:09:27Z · Thread: Bitcoin Watchdog Service
Original: https://bitcointalk.org/index.php?topic=691.msg9041#msg9041
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/354/
Quote
But there will be no irc server to bootstrap from.
Which doesn't matter because you can't access sourceforge to download the software either.
If you've ever been connected before, you don't need IRC to bootstrap anymore. Even if you haven't, you can bootstrap from seed nodes. IRC is completely redundant since 0.3.0.
355. Version 0.3.9 rc1, please test
Poster: satoshi · Date: 2010-08-13T17:40:00Z · Thread: Version 0.3.9 rc1, please test
Original: https://bitcointalk.org/index.php?topic=806.msg9046#msg9046
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/355/
Here's a test build if you'd like to help test before 0.3.9 is released.
(or if you'd rather get upgrading out of the way now instead of waiting)
Downloads: (binaries only)
http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip
(http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)
SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip
SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz
Edit:
Linux please test rc2 instead. This adds a -4way switch for tcatm's 4-way SSE2. This will only be for Linux:
http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz
SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz
Please report back your results
http://bitcointalk.org/index.php?topic=820
356. Re: Not a suggestion
Poster: satoshi · Date: 2010-08-13T19:28:47Z · Thread: Not a suggestion
Original: https://bitcointalk.org/index.php?topic=770.msg9074#msg9074
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/356/
I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage?
If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it.
Can public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it.
Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it.
Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related.
There's something here in the general area:
http://www.users.zetnet.co.uk/hopwood/crypto/rh/
What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m.
When paying to a bitcoin address, you would generate a new blinded key for each use.
Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it.
As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.
357. Re: Proposed change to sendtoaddress API call
Poster: satoshi · Date: 2010-08-13T23:39:14Z · Thread: Proposed change to sendtoaddress API call
Original: https://bitcointalk.org/index.php?topic=807.msg9134#msg9134
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/357/
It's too soon to start junking up the API for backward compatibility at all costs.
Just return "<txid>".
358. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-14T00:49:18Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg9145#msg9145
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/358/
MinGW on Windows has trouble compiling it:
g++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I"/boost" -I"/db/build_unix" -I"/openssl/include" -I"/wxwidgets/lib/gcc_lib/mswud" -I"/wxwidgets/include" -msse2 -O3 -o obj/sha256.o sha256.cpp
sha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)':
sha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
make: *** [obj/sha256.o] Error 1
359. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-14T04:22:29Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg9159#msg9159
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/359/
If you haven't already, try aligning thash. It might matter. Couldn't hurt.
Quote from: tcatm on August 14, 2010, 12:53:07 AM
Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?
No help from -O0, same error.
MinGW is GCC 3.4.5. Probably the problem.
I'll see if I can get a newer version of MinGW.
360. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-14T17:55:37Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg9228#msg9228
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/360/
Got the test working on 32-bit with MinGW GCC 4.5. Exactly 50% slower than stock with Core 2.
361. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-14T22:06:13Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg9278#msg9278
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/361/
MinGW GCC 4.5.0:
Crypto++ doesn't work, X86_SHA256_HashBlocks() never returns
I only got 4-way working with test.cpp but not when called by BitcoinMiner
MinGW GCC 4.4.1:
Crypto++ works
4-way SIGSEGV
GCC is definitely not aligning __m128i.
Even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable.
By making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only:
#define Ch(b, c, d) ((b & c) ^ (~b & d))
#define Maj(b, c, d) ((b & c) ^ (b & d) ^ (c & d))
#define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n))
#define SHR(x, n) _mm_srli_epi32(x, n)
But that's with -O0.
362. Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
Poster: satoshi · Date: 2010-08-15T03:40:29Z · Thread: 4 hashes parallel on SSE2 CPUs for 0.3.6
Original: https://bitcointalk.org/index.php?topic=648.msg9359#msg9359
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/362/
On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner. So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.
I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.
I found the problem with Crypto++ on MinGW 4.5.0. Here's the patch for that:
Code:
--- \old\sha.cpp Mon Jul 26 13:31:11 2010
+++
ew\sha.cpp Sat Aug 14 20:21:08 2010
@@ -336,7 +336,7 @@
ROUND(14, 0, eax, ecx, edi, edx)
ROUND(15, 0, ecx, eax, edx, edi)
- ASL(1)
+ ASL(label1) // Bitcoin: fix for MinGW GCC 4.5
AS2(add WORD_REG(si), 4*16)
ROUND(0, 1, eax, ecx, edi, edx)
ROUND(1, 1, ecx, eax, edx, edi)
@@ -355,7 +355,7 @@
ROUND(14, 1, eax, ecx, edi, edx)
ROUND(15, 1, ecx, eax, edx, edi)
AS2( cmp WORD_REG(si), K_END)
- ASJ( jne, 1, b)
+ ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5
AS2( mov WORD_REG(dx), DATA_SAVE)
AS2( add WORD_REG(dx), 64)
363. tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-15T15:52:09Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9452#msg9452
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/363/
0.3.10 has tcatm's 4-way SSE2 as an option switch.
Use the switch "-4way" to turn it on. Without the switch you get Crypto++ ASM SHA-256.
I could only get this working with Linux.
Download:
Get 0.3.10 from http://bitcointalk.org/index.php?topic=827.0
Please report back your CPU and results! I think it's pretty clear that Core 2 and lower are slower, i5 faster. I don't think we've heard any i7 results yet. We need to know about the different models of AMD or other less common CPUs.
364. Re: Potential disaster scenario
Poster: satoshi · Date: 2010-08-15T16:37:16Z · Thread: Potential disaster scenario
Original: https://bitcointalk.org/index.php?topic=813.msg9454#msg9454
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/364/
Some places where generation will gravitate to:
1) places where it's cheapest or free
2) people who want to help for idealogical reasons
3) people who want to get some coins without the inconvenience of doing a transaction to buy them
There are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.
How expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.
There's also kids putting it on their parent's power bill, employees their employer, botnets, etc.
Case 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.
365. Re: Version 0.3.9 rc1, please test
Poster: satoshi · Date: 2010-08-15T18:11:41Z · Thread: Version 0.3.9 rc1, please test
Original: https://bitcointalk.org/index.php?topic=806.msg9475#msg9475
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/365/
Quote from: jgarzik on August 15, 2010, 05:46:27 PM
the extended-help might have been based on my idea, but the code was somewhat different.
The idea was the main part. When you posted your patch, I realized it should have been done that way instead of "-?". I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server.
366. Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
Poster: satoshi · Date: 2010-08-15T18:23:26Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9478#msg9478
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/366/
I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with.
I'm also curious if it performs much worse on 32-bit linux vs 64-bit.
367. Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
Poster: satoshi · Date: 2010-08-15T18:43:27Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9483#msg9483
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/367/
I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff.
368. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T20:59:09Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9530#msg9530
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/368/
Here's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly.
Code:
bool CheckTransaction() const
{
// Basic checks that don't depend on any context
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");
// Check for negative and overflow values
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
if (txout.nValue > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout.nValue too high");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout total too high");
}
if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error("CTransaction::CheckTransaction() : coinbase script size");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error("CTransaction::CheckTransaction() : prevout is null");
}
return true;
}
Don't sticky the topic, nobody looks up there. There'll be enough posts to bump.
369. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T21:06:45Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9531#msg9531
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/369/
It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.
A first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some other misc changes out of the way first, then I'll upload the patch for this.
370. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T21:23:55Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9539#msg9539
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/370/
Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?
371. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T21:40:19Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9548#msg9548
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/371/
Patch is uploaded to SVN rev 132!
For now, recommended steps:
1) Shut down.
2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files)
3) Upgrade.
4) It should start out with less than 74000 blocks. Let it redownload the rest.
If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.
I'll build releases shortly.
372. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T22:58:08Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9573#msg9573
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/372/
Don't update the block chain download. When you take someone's block chain download, you don't want it right up to the end. A somewhat old one is better so it can download and verify the most recent blocks.
tcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago.
I just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux. If you build rev 134 on Linux now you'll get the -4way switch.
If you have problems building because of it, then edit makefile.unix and:
- remove -DFOURWAYSSE2
- remove obj/sha256.o from the end of these lines:
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o
The 0.3.10 linux build will have the -4way option when I build it.
Here are the patch downloads for Windows:
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
Steps:
1) Shut down.
2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files.
http://knightmb.dyndns.org/files/bitcoin/blocks/
http://rapidshare.com/files/413168038/BitcoinBlocks.torrent
3) Upgrade to 0.3.10.
4) It should start out with less than 74000 blocks and redownload the rest.
Or if you don't want to mess with downloading blk files, you can just do this:
1) Shut down.
2) Delete (or move) blk*.dat
3) Upgrade to 0.3.10.
4) It redownloads all blocks, probably take about an hour.
373. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T23:17:24Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9576#msg9576
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/373/
Quote from: knightmb on August 15, 2010, 10:59:04 PM
[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain. [image: Wink; source: /static/img/emoticons/wink.gif]
Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice.
374. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T23:36:10Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9584#msg9584
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/374/
Starting at 67000 is perfect.
Yeah, at the moment you'll stop at 74638. It should start slowly creeping up as more nodes upgrade and generate.
Linux build links below.
The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5 and AMD CPU's. Use the "-4way" switch to enable it and check if it's faster for you.
Download links:
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
375. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-15T23:37:07Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9586#msg9586
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/375/
Quote from: Joozero on August 15, 2010, 11:32:43 PM
I think that you should add something about this: http://bitcointalk.org/index.php?topic=259.0
There must be a label on the client that show a warning message if needed [image: Smiley; source: /static/img/emoticons/smiley.gif]
Now everyone have always to check the website, and I think that this is bad.
Agree, wanted to do that for a long time, haven't had time to do it.
For now, you could also subscribe to the bitcoin-list mailing list. It rarely gets used except for announcements like this and major new versions.
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
376. Version 0.3.10 - block 74638 overflow PATCH!
Poster: satoshi · Date: 2010-08-15T23:48:22Z · Thread: Version 0.3.10 - block 74638 overflow PATCH!
Original: https://bitcointalk.org/index.php?topic=827.msg9590#msg9590
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/376/
Version 0.3.10 patches the block 74638 overflow bug. http://bitcointalk.org/index.php?topic=823
The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's. Try the "-4way" switch to enable it and check if it's faster for you.
Download from sourceforge:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip
It is no longer necessary to delete blk*.dat. The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain.
377. Re: 0.3.10.1 Question on where block should be
Poster: satoshi · Date: 2010-08-16T00:28:28Z · Thread: 0.3.10.1 Question on where block should be
Original: https://bitcointalk.org/index.php?topic=828.msg9608#msg9608
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/377/
I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go away when we make up more than 1/8th of the network.
It'll help if you port forward so you can get lots of connections.
378. Re: 0.3.10.1 Question on where block should be
Poster: satoshi · Date: 2010-08-16T00:37:20Z · Thread: 0.3.10.1 Question on where block should be
Original: https://bitcointalk.org/index.php?topic=828.msg9612#msg9612
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/378/
For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.
379. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T01:00:45Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9623#msg9623
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/379/
Quote from: Ground Loop on August 16, 2010, 12:29:55 AM
Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.
What is the status of that transaction?
From what I can tell, my (updated) sending client wallet shows the deducted amount.
Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?
Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.
It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet.
380. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T01:02:24Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9624#msg9624
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/380/
Quote from: kosovito on August 16, 2010, 12:39:17 AM
I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?
If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes.
For today, try adding these parameters:
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14
See
http://bitcointalk.org/index.php?topic=828
381. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T01:12:05Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9628#msg9628
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/381/
Quote from: trebronics on August 16, 2010, 01:02:35 AM
Most people running clients are not reading this message thread. So... Silly questions:
1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?
2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?
1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.
2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain.
382. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T02:16:10Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9642#msg9642
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/382/
The bad chain is also slowed down as more nodes upgrade.
We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain.
383. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T02:38:21Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9648#msg9648
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/383/
On Windows, findstr /c:"version message" debug.log
It looks like the bad chain was on block 74678 recently. Can't wait to overtake it.
On the stats at http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks per hour in the last 3 hours. We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour.
384. Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
Poster: satoshi · Date: 2010-08-16T02:57:57Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9655#msg9655
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/384/
Quote from: tcatm on August 16, 2010, 12:43:39 AM
I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
GCC 4.3.3 doesn't support -march=amdfamk10. I get:
sha256.cpp:1: error: bad value (amdfamk10) for -march= switch
Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM
With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
Hey, you may be onto something!
hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.
tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.
How much of an improvement do you get with hyperthreading?
Some numbers? What CPU is that?
385. Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
Poster: satoshi · Date: 2010-08-16T03:23:04Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9661#msg9661
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/385/
Quote from: Vasiliev on August 16, 2010, 03:17:07 AM
try -march=amdfam10
That works.
That's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement.
386. Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-16T04:36:59Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9676#msg9676
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/386/
Quote from: jgarzik on August 16, 2010, 03:35:28 AM
Code:
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4cpu family 6 model 26 stepping 4 is an Intel Core i7.
That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
33% faster with hyperthreading than without it.
387. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T12:59:38Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9734#msg9734
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/387/
It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now.
That means it's no longer necessary to delete blk*.dat before upgrading. You can just upgrade and it'll reorg away the bad block chain.
Thanks to everyone for the quick response!
388. Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-16T13:38:01Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg9736#msg9736
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/388/
I wrapped sha256.cpp in
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2
try it now.
389. Re: [PATCH] Automatic block validation
Poster: satoshi · Date: 2010-08-16T15:25:54Z · Thread: [PATCH] Automatic block validation
Original: https://bitcointalk.org/index.php?topic=832.msg9754#msg9754
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/389/
That's a difficult approach.
We need to cause a reorg, which will disconnect the invalid chain.
This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.
Here's what I was thinking of. (I haven't tested this yet) It checks all the blocks in the main chain. If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg. (It can't change pindexBest without actually doing a reorg)
This isn't perfect yet. It still needs to receive one valid block to trigger the reorg.
It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.
Code:
bool CTxDB::LoadBlockIndex()
{
...
// Verify blocks in the main chain
vector<CBlockIndex*> vChain;
for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
vChain.push_back(pindex);
CBlock block;
if (!block.ReadFromDisk(pindex))
return error("LoadBlockIndex() : block.ReadFromDisk failed");
if (!block.CheckBlock())
{
bnBestChainWork = pindex->pprev->bnChainWork;
foreach(CBlockIndex* pindex2, vChain)
pindex2->bnChainWork = 0;
}
}
return true;
}
390. blocks minus 1
Poster: satoshi · Date: 2010-08-16T15:59:25Z · Thread: blocks minus 1
Original: https://bitcointalk.org/index.php?topic=837.msg9757#msg9757
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/390/
I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1:
"0 connections 0 blocks 0 transactions"
It's always been "nBestHeight + 1" because it's counting the genesis block. Technically, yes, the genesis block is a block. It's a hardcoded block that you start out with. You can't not have the genesis block. Maybe think of it as a reference coin that you measure other coins against. The block count people are looking for is the number of blocks they've downloaded.
The main benefit is that blocks will be equal to the block number of the current best block. If blocks is 10, then the highest block number you have is 10. It means you have block 10 and you don't have block 11.
It would reduce the confusion we had here:
Quote from: kencausey on August 15, 2010, 11:45:26 PM
Quote from: davidonpda on August 15, 2010, 11:31:37 PM
... It already is on block 74638. I assume that means that block is now a good one?
I had some confusion on this myself and got clarification in #bitcoin-dev:
The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one.
391. Re: blocks minus 1
Poster: satoshi · Date: 2010-08-16T17:06:27Z · Thread: blocks minus 1
Original: https://bitcointalk.org/index.php?topic=837.msg9774#msg9774
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/391/
Done in SVN rev 137
392. Re: [PATCH] Automatic block validation
Poster: satoshi · Date: 2010-08-16T17:08:02Z · Thread: [PATCH] Automatic block validation
Original: https://bitcointalk.org/index.php?topic=832.msg9775#msg9775
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/392/
Quote from: satoshi on August 16, 2010, 03:25:54 PM
It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.
This is what I ended up doing in SVN rev 139.
Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out.
393. Checking the block chain on load
Poster: satoshi · Date: 2010-08-16T20:07:46Z · Thread: Checking the block chain on load
Original: https://bitcointalk.org/index.php?topic=841.msg9813#msg9813
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/393/
SVN rev 139 does a basic check of the block chain after loading.
With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful implementation of this at the time.
It might take longer than we want, since it has to load all the blocks. If it's too slow, we could have it only go back to a certain block number.
394. Re: checkpointing the block chain
Poster: satoshi · Date: 2010-08-16T20:20:53Z · Thread: checkpointing the block chain
Original: https://bitcointalk.org/index.php?topic=834.msg9816#msg9816
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/394/
There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.
The only exception to that is the manual checkpoints I've added. If it weren't for those, it would be able to reorg all the way back to the first block.
395. Re: overflow bug SERIOUS
Poster: satoshi · Date: 2010-08-16T22:54:55Z · Thread: overflow bug SERIOUS
Original: https://bitcointalk.org/index.php?topic=823.msg9841#msg9841
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/395/
Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again. 0.3.9 and lower nodes still must upgrade.
The SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually. I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option.
396. Re: checkpointing the block chain
Poster: satoshi · Date: 2010-08-16T23:01:48Z · Thread: checkpointing the block chain
Original: https://bitcointalk.org/index.php?topic=834.msg9843#msg9843
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/396/
Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM
How is the strength of the chain calculated?
Total proof-of-work.
397. Re: New screenshots to the front page?
Poster: satoshi · Date: 2010-08-18T16:58:44Z · Thread: New screenshots to the front page?
Original: https://bitcointalk.org/index.php?topic=850.msg10067#msg10067
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/397/
Definitely. The old screenshots of 0.1 are very outdated.
Windows Aero is a good choice. Windows is still the largest user group. Mind what's behind it for the transparent parts.
What to have displayed in the transaction list? Not completely filled up with stuff, just a few things.
398. Re: Difficulty: More nodes active, or faster nodes?
Poster: satoshi · Date: 2010-08-18T18:01:40Z · Thread: Difficulty: More nodes active, or faster nodes?
Original: https://bitcointalk.org/index.php?topic=846.msg10076#msg10076
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/398/
The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical. Only in the 1500 khash/s range. If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast. It still has to do all the steps. It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel. That's not necessarily easy or a given.
399. Re: Checking the block chain on load
Poster: satoshi · Date: 2010-08-18T18:28:28Z · Thread: Checking the block chain on load
Original: https://bitcointalk.org/index.php?topic=841.msg10082#msg10082
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/399/
In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000. If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem. Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked.
Still, the system won't be entirely secure against your blk*.dat files. You are trusting someone if you use a copy of their blk files.
400. Re: Convert Bitcoin to GTK: Yes? No? wx is better?
Poster: satoshi · Date: 2010-08-19T18:44:36Z · Thread: Convert Bitcoin to GTK: Yes? No? wx is better?
Original: https://bitcointalk.org/index.php?topic=867.msg10272#msg10272
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/400/
Quote from: BioMike on August 19, 2010, 08:05:18 AM
WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all platforms including Windows.
The distro packages of 2.8 are UTF-16, so they just trip people up. People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.
This is a problem that will solve itself. With time, 2.9 will become a more mainline release.
401. Re: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)
Poster: satoshi · Date: 2010-08-19T18:55:48Z · Thread: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)
Original: https://bitcointalk.org/index.php?topic=868.msg10275#msg10275
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/401/
That's a really well written walkthough. Someone should confirm if they followed it and didn't run into any snags.
402. Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-19T19:07:43Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg10281#msg10281
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/402/
Quote from: Ground Loop on August 18, 2010, 11:14:26 PM
Any non-Mac i5 love?
Windows i5 64-bit got slower here.
That's the first I've heard anyone say i5 was slower. Everyone else has said 4way was faster on i5. Moreso with hyperthreading enabled.
Quote from: nelisky on August 18, 2010, 11:02:25 PM
And i5, at least on my macbookpro
Good, so I take it that's a confirmation that it's working on Mac as well?
Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version.
403. Re: 28 days without generation, i have 4200khash/s
Poster: satoshi · Date: 2010-08-19T19:40:30Z · Thread: 28 days without generation, i have 4200khash/s
Original: https://bitcointalk.org/index.php?topic=862.msg10290#msg10290
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/403/
Make sure your computer's date and time are correct.
404. Need a post writing up some things users should know
Poster: satoshi · Date: 2010-08-19T20:14:01Z · Thread: Need a post writing up some things users should know
Original: https://bitcointalk.org/index.php?topic=873.msg10297#msg10297
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/404/
I'm not sure what to call it, but we could use a post that lists these things users should know. If someone has time to write it, here's the list:
- Make sure your clock is set correctly.
- Microsoft Security Essentials. This never got written up proper.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
405. Re: Hypothetical question on lost coins / transfers
Poster: satoshi · Date: 2010-08-19T20:28:50Z · Thread: Hypothetical question on lost coins / transfers
Original: https://bitcointalk.org/index.php?topic=870.msg10300#msg10300
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/405/
That's right. You don't need to be re-broadcasting your transactions for it to work.
When any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain. The entire network is making sure to re-integrate your transactions again. All you should see is that your number of confirmations starts over from 0.
In some types of forks, your transaction would have gotten into both forks already, so you're already good either way.
406. Re: Need a post writing up some things users should know
Poster: satoshi · Date: 2010-08-22T22:51:00Z · Thread: Need a post writing up some things users should know
Original: https://bitcointalk.org/index.php?topic=873.msg10715#msg10715
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/406/
The clock part will be covered in the next release (0.3.11 or higher). SVN rev 141 pops up a message box if your clock is too far off.
407. Re: 28 days without generation, i have 4200khash/s
Poster: satoshi · Date: 2010-08-22T23:01:02Z · Thread: 28 days without generation, i have 4200khash/s
Original: https://bitcointalk.org/index.php?topic=862.msg10717#msg10717
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/407/
Search debug.log for "proof-of-work found". If you find any, then check for any errors right after that.
Quote from: davidonpda on August 19, 2010, 07:43:01 PM
How big of a margin on the time is allowed for things to work right.
The margin is 2 hours.
This should be solved in SVN rev 141 and the next release (0.3.11+). It'll pop up a message box alerting you if your clock is off by more than an hour.
408. Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-22T23:21:50Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg10720#msg10720
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/408/
Thanks for clearing that up. I read the link someone posted about AMD making that change around 2007, but I didn't know what the story was for Intel.
There's no hope for Core/Core2 then. They only have half the SSE2 hardware.
Strange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one.
409. Development of alert system
Poster: satoshi · Date: 2010-08-22T23:55:06Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg10722#msg10722
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/409/
I've been working on writing the alert system. Alerts are broadcast through the network and apply to a range of version numbers. Alert messages are signed with a private key that only I have.
Nodes can do two things in response to an alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an error.
In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade. Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.
The json-rpc methods that return errors during an alert are:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
410. Re: integrating digital payments into p2p protocols
Poster: satoshi · Date: 2010-08-22T23:57:32Z · Thread: integrating digital payments into p2p protocols
Original: https://bitcointalk.org/index.php?topic=890.msg10723#msg10723
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/410/
Hey Zooko!
I wanted to thank you for posting about Bitcoin on your blog a year or two ago, back when I announced it on the Cryptography mailing list.
411. Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-24T22:43:56Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg11068#msg11068
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/411/
Quote from: ArtForz on August 21, 2010, 04:56:31 PM
AMD K10: 2 128bit units
intel nehalem: 3 128bit unitsThis probably explains why hyperthreading increases performance with -4way. If three SSE2 units is excessive, then hyperthreading would help keep them all busy.
412. Re: Development of alert system
Poster: satoshi · Date: 2010-08-24T23:51:12Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11074#msg11074
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/412/
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.
I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.
413. Re: Development of alert system
Poster: satoshi · Date: 2010-08-25T00:06:36Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11078#msg11078
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/413/
This is in SVN rev 142 as version 0.3.11.
414. Re: Development of alert system
Poster: satoshi · Date: 2010-08-25T15:17:37Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11150#msg11150
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/414/
It can't do arbitrary actions remotely. Maybe some of you are responding to other posters who suggested the alert system should do more?
If there is an alert, the following json-rpc methods return an error:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
The remaining 14 methods function as normal.
I believe the safer option should be enabled by default. If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.
Worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.
Getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.
Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back. I'm not arguing that this is the permanent way of things forever. It's still beta software.
415. Re: Development of alert system
Poster: satoshi · Date: 2010-08-25T16:40:20Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11151#msg11151
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/415/
I changed the switch name to -disablesafemode.
416. Re: Development of alert system
Poster: satoshi · Date: 2010-08-25T16:56:15Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11155#msg11155
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/416/
Quote from: jimbobway on August 25, 2010, 04:45:22 PM
Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia, I think the quote button is easier to find then the reply one.
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
A few rhetorical questions for satoshi:
Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance? Seriously.
WRT the alert system, who cares? The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade. All nodes keep running and generating, the network stays up. If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system. It would be a temporary inconvenience only.
Quote from: BioMike on August 23, 2010, 05:15:43 AM
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network".
417. Re: Development of alert system
Poster: satoshi · Date: 2010-08-25T17:59:30Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11158#msg11158
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/417/
Quote from: nelisky on August 25, 2010, 01:28:32 AM
So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.
The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert.
I added the switch "-testsafemode" for you. SVN rev 145.
This stuff is very new and may still be subject to change.
Quote from: mizerydearia on August 25, 2010, 12:11:50 AM
I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode. Perhaps it should be added! Also others liek -4way should be added as well.
Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.
-4way should eventually be replaced by an auto-detect.
418. Re: Development of alert system
Poster: satoshi · Date: 2010-08-26T00:08:12Z · Thread: Development of alert system
Original: https://bitcointalk.org/index.php?topic=898.msg11219#msg11219
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/418/
Quote from: BioMike on August 25, 2010, 06:23:45 PM
Quote from: satoshi on August 25, 2010, 04:56:15 PM
Quote from: BioMike on August 23, 2010, 05:15:43 AM
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network".
I've never objected this change/idea, just asking if this was possible and to what extent.
What's wrong with getting informed? [image: Wink; source: /static/img/emoticons/wink.gif]
My apologies, your post was indeed a question not a statement.
419. Re: RFC: remove DB_PRIVATE flag
Poster: satoshi · Date: 2010-08-26T00:33:28Z · Thread: RFC: remove DB_PRIVATE flag
Original: https://bitcointalk.org/index.php?topic=920.msg11224#msg11224
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/419/
Can you provide more details about what removing DB_PRIVATE does?
I can't remember if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some example code. Does removing DB_PRIVATE make it safe for other processes to open the database simultaneously? That may be an improvement, depending what the side effects are. Does it substantially reduce performance by making it have to write out every change immediately or do other coordination? Are there additional locking or coordination files then? What else changes? You could test by timing an initial block download with and without DB_PRIVATE, preferably -connect-ing to a local machine so network isn't a factor.
Apparently, DB_PRIVATE doesn't do what you would hope it would do, which is prevent other processes from being able to open the database. It still lets them, it just screws up if they do. Another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes.
420. Re: Need a post writing up some things users should know
Poster: satoshi · Date: 2010-08-26T00:44:05Z · Thread: Need a post writing up some things users should know
Original: https://bitcointalk.org/index.php?topic=873.msg11227#msg11227
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/420/
Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software. We can try to use words to help the situation until code gets there.
The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.
421. Re: auto backing up of wallet.dat
Poster: satoshi · Date: 2010-08-26T00:57:40Z · Thread: auto backing up of wallet.dat
Original: https://bitcointalk.org/index.php?topic=921.msg11228#msg11228
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/421/
I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.
The main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.
I was starting to post the same idea you said nelisky.
How about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it? That would be a smaller project than the pooled keys, so maybe it could be done first.
What's the simplest portable way to copy a file? Is there something in Boost?
What should it be named? maybe:
backupwallet <destination>
422. Re: Gentoo Linux Ebuild
Poster: satoshi · Date: 2010-08-27T00:49:43Z · Thread: Gentoo Linux Ebuild
Original: https://bitcointalk.org/index.php?topic=930.msg11342#msg11342
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/422/
Try -datadir=
Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it. There wasn't time to investigate at the time.
One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there. -lwx_gtk2ud-2.9 only matches the right configuration. It fails if wxWidgets was built with the wrong configuration.
Quote
Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.
Did they say why they were baffled?
Quote
This is because on my system the path is /usr/include/wx-2.9/wx/wx.h
Why is it there? Was it included by the OS, or did you have to build it? If you built it, I wonder why it would put itself in a different place.
Has wxWidgets 2.9 finally started to become available as a debian package?
Maybe we should do this:
INCLUDEPATHS= \
-I"/usr/local/include/wx-2.9" \
-I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
-I"/usr/include/wx-2.9" \
-I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9"
Again, those paths help make sure it's only 2.9 and will fail with 2.8.
wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.
423. Re: auto backing up of wallet.dat
Poster: satoshi · Date: 2010-08-27T01:13:42Z · Thread: auto backing up of wallet.dat
Original: https://bitcointalk.org/index.php?topic=921.msg11345#msg11345
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/423/
If you read it into memory and write it out, it could fail in tight memory situations.
I'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it. If you find it for me, it's more likely I'll get to implementing it.
Quote from: nelisky on August 26, 2010, 01:21:57 AM
As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps.
We require Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is good, portable stuff, we should not shy away from it.
424. Re: auto backing up of wallet.dat
Poster: satoshi · Date: 2010-08-27T02:54:07Z · Thread: auto backing up of wallet.dat
Original: https://bitcointalk.org/index.php?topic=921.msg11350#msg11350
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/424/
I doubt there's an mmap(2) on Windows. I'd rather call an existing file copy function than make and test my own.
Quote from: nelisky on August 27, 2010, 01:21:09 AM
But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill.
Thanks. I thought it would be in there somewhere.
We already use boost::filesystem in a dozen places. It's not a new added dependency. It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere.
425. Re: auto backing up of wallet.dat
Poster: satoshi · Date: 2010-08-27T15:47:57Z · Thread: auto backing up of wallet.dat
Original: https://bitcointalk.org/index.php?topic=921.msg11399#msg11399
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/425/
Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.
We want to avoid Windows API calls whenever possible. They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.
I usually shy away from iostreams. Seems like I too often hit limitations. They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right. Using it in rpc.cpp may still turn out to be a mistake.
Bottom line is I'd rather call an existing file copy function than make and test my own.
426. Re: New web service: obtain dump of bitcoin block NNNN
Poster: satoshi · Date: 2010-08-27T16:13:16Z · Thread: New web service: obtain dump of bitcoin block NNNN
Original: https://bitcointalk.org/index.php?topic=928.msg11400#msg11400
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/426/
That's kind of interesting as an upside-down bar chart of how many blocks were produced each day. The target is 144 blocks per day.
427. Re: Bitcoins are most like shares of common stock
Poster: satoshi · Date: 2010-08-27T16:39:26Z · Thread: Bitcoins are most like shares of common stock
Original: https://bitcointalk.org/index.php?topic=845.msg11403#msg11403
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/427/
Bitcoins have no dividend or potential future dividend, therefore not like a stock.
More like a collectible or commodity.
428. Re: Bitcoin does NOT violate Mises' Regression Theorem
Poster: satoshi · Date: 2010-08-27T17:32:07Z · Thread: Bitcoin does NOT violate Mises' Regression Theorem
Original: https://bitcointalk.org/index.php?topic=583.msg11405#msg11405
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/428/
As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable either
- not useful for any practical or ornamental purpose
and one special, magical property:
- can be transported over a communications channel
If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.
Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.
I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.
(I'm using the word scarce here to only mean limited potential supply)
429. Version 0.3.11 with upgrade alerts
Poster: satoshi · Date: 2010-08-27T21:54:12Z · Thread: Version 0.3.11 with upgrade alerts
Original: https://bitcointalk.org/index.php?topic=941.msg11439#msg11439
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/429/
Version 0.3.11 is now available.
Changes:
- Some blk*.dat checking on load
- Built the -4way code with -march=amdfam10, which makes it a little faster
- Warning if your clock is too far off
- Warnings/errors/alerts can also be seen in the getinfo command
- Alert system
The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.
In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.
This is an important safety improvement. For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.
Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/
430. Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Poster: satoshi · Date: 2010-08-28T14:27:15Z · Thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Original: https://bitcointalk.org/index.php?topic=820.msg11503#msg11503
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/430/
The simplification is intentional. There will only be more than one thash[7]=0 in one out of 134,217,728 cases. It only makes it 0.0000007% slower.
431. Re: Version 0.3.11 with upgrade alerts
Poster: satoshi · Date: 2010-08-28T14:54:04Z · Thread: Version 0.3.11 with upgrade alerts
Original: https://bitcointalk.org/index.php?topic=941.msg11505#msg11505
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/431/
Quote from: torservers on August 28, 2010, 01:00:37 PM
The "About" dialog still shows 0.3.10.1 beta.
What OS? I ran the Windows and 64-bit Linux version and checked the about dialog.
The Mac version is still 0.3.10.1.
Quote from: pavelo on August 28, 2010, 07:36:07 AM
iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.
I updated the first post to be more specific. Only the -4way code is compiled this way.
432. Re: Big endian code problems
Poster: satoshi · Date: 2010-08-29T22:14:36Z · Thread: Big endinan code problems
Original: https://bitcointalk.org/index.php?topic=816.msg11610#msg11610
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/432/
The code assumes little-endian throughout and was written with the intention of never being ported to big-endian. Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code. It would not be worth the extra sourcecode bloat.
Big-endian is on its way out anyway.
433. Re: CryptoPP Assertion Error
Poster: satoshi · Date: 2010-09-05T23:25:32Z · Thread: CryptoPP Assertion Error
Original: https://bitcointalk.org/index.php?topic=967.msg12062#msg12062
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/433/
You can probably just comment out the line
cryptopp/secblock.h:187
//assert(false);
Let me know if it works, and watch if it memory leaks.
It looks like a template class to make sure the derived class defines its own version of allocate and deallocate. It would be weird if that was the actual problem and it made it all the way to release. Probably a false alarm.
434. Re: Warning : Check your system ( Help me )
Poster: satoshi · Date: 2010-09-05T23:36:20Z · Thread: Warning : Check your system clock (help me)
Original: https://bitcointalk.org/index.php?topic=960.msg12063#msg12063
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/434/
Any suggestions for better text to put for this error message so the next person will be less likely to be confused?
It's trying to tell them their clock is wrong and they need to correct it.
It's relying on 3 time sources:
1) the system clock
2) the other nodes, if within an hour of the system clock
if those disagree, then
3) the user (asking the user to fix the system clock)
I've thought about NTP, but this is more secure.
435. Re: HTTP status codes from the JSON-RPC api
Poster: satoshi · Date: 2010-09-06T21:21:21Z · Thread: HTTP status codes from the JSON-RPC api
Original: https://bitcointalk.org/index.php?topic=969.msg12130#msg12130
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/435/
This is in SVN rev 147.
This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct. The code/message members have become standard in later json-rpc specs.
If you have code that checks the error and expects a string, you'll need to change it. When there is an error, the error member is now an object not a string.
Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code. Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The "backupwallet <destination>" command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy.
436. Re: Warning : Check your system ( Help me )
Poster: satoshi · Date: 2010-09-06T21:41:06Z · Thread: Warning : Check your system clock (help me)
Original: https://bitcointalk.org/index.php?topic=960.msg12132#msg12132
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/436/
Quote from: Insti on September 06, 2010, 12:51:37 PM
Quote from: satoshi on September 05, 2010, 11:36:20 PM
Any suggestions for better text to put for this error message so the next person will be less likely to be confused?
"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly."
Thanks.
437. Re: auto backing up of wallet.dat
Poster: satoshi · Date: 2010-09-06T21:45:10Z · Thread: auto backing up of wallet.dat
Original: https://bitcointalk.org/index.php?topic=921.msg12134#msg12134
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/437/
rpc backupwallet <destination> is in SVN rev 147.
438. Re: bitcoind as daemon in OSX
Poster: satoshi · Date: 2010-09-06T21:52:45Z · Thread: bitcoind as daemon in OSX
Original: https://bitcointalk.org/index.php?topic=992.msg12135#msg12135
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/438/
Can you build?
Try changing line 78 of init.cpp from:
#ifdef __WXGTK__
to:
#ifndef __WXMSW__
If that works, I'll change the source. It should work.
439. Re: Always pay transaction fee?
Poster: satoshi · Date: 2010-09-07T16:32:21Z · Thread: Always pay transaction fee?
Original: https://bitcointalk.org/index.php?topic=994.msg12168#msg12168
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/439/
Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.
The threshold should probably be lower than it currently is.
I don't think the threshold should ever be 0. We should always allow at least some free transactions.
440. Version 0.3.12
Poster: satoshi · Date: 2010-09-07T19:17:55Z · Thread: Version 0.3.12
Original: https://bitcointalk.org/index.php?topic=999.msg12181#msg12181
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/440/
Version 0.3.12 is now available.
Features:
- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
- json-rpc command line returns exit codes.
- json-rpc "backupwallet" command.
- Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.
If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://bitcointalk.org/index.php?topic=969.0
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/
441. Re: Always pay transaction fee?
Poster: satoshi · Date: 2010-09-08T17:30:14Z · Thread: Always pay transaction fee?
Original: https://bitcointalk.org/index.php?topic=994.msg12237#msg12237
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/441/
Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.
It's not a big deal if we reach the threshold. Free transactions would just take longer to get into a block.
I did a rough tally of 4000 blocks from around 74000-78000. This is excluding the block reward transactions:
There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.
Average transaction bytes per block was 428 bytes, or 214 bytes per transaction.
The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.
The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.
442. Re: Version 0.3.12
Poster: satoshi · Date: 2010-09-08T18:06:04Z · Thread: Version 0.3.12
Original: https://bitcointalk.org/index.php?topic=999.msg12240#msg12240
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/442/
Bitcoin clients currently only create and recognize transactions that match two possible templates.
Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit. Nodes will only work on adding those transactions to their block.
In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.
443. Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?
Poster: satoshi · Date: 2010-09-08T20:27:39Z · Thread: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?
Original: https://bitcointalk.org/index.php?topic=955.msg12248#msg12248
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/443/
Quote from: BitLex on September 07, 2010, 08:10:54 PM
AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt
Did you try -4way?
Quote
How many hashes can I expect with a 24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second.
AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that)
There's been so much else to do that I haven't had time to make -4way automatic. For now you still have to do it manually.
http://bitcointalk.org/index.php?topic=820.0
444. Auto-detect for 128-bit 4-way SSE2
Poster: satoshi · Date: 2010-09-09T01:04:05Z · Thread: Auto-detect for 128-bit 4-way SSE2
Original: https://bitcointalk.org/index.php?topic=1007.msg12262#msg12262
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/444/
SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2.
It uses the CPUID instruction to get the CPU brand, family, model number and stepping. That's the easy part. Knowing what to do with the model number is the hard part. I was not able to find any table of family, model and stepping numbers for CPUs. I had to go by various random reports I saw.
Here's what I ended up with:
Code:
// We need Intel Nehalem or AMD K10 or better for 128bit SSE2
// Nehalem = i3/i5/i7 and some Xeon
// K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
// Intel Core i5 family 6, model 26 or 30
// Intel Core i7 family 6, model 26 or 30
// Intel Core i3 family 6, model 37
// AMD Phenom family 16, model 10
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs.
If it's wrong, you can still override it with -4way or -4way=0.
It prints what it finds in debug.log. Search on CPUID.
This is only enabled if built with GCC.
445. Re: Won't let me send coins because it requires a transaction fee?
Poster: satoshi · Date: 2010-09-10T00:23:24Z · Thread: Won't let me send coins because it requires a transaction fee?
Original: https://bitcointalk.org/index.php?topic=1013.msg12341#msg12341
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/445/
What version is the one where this happened? Release build, or built it yourself? Which operating system?
Were you sending by IP or by Bitcoin Address?
When you sent 49.99, did it prompt you to pay a 0.01 fee?
There was a change in GetMinFee, but I can't see how it would cause this. It only starts to apply when a block gets huge.
The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.
446. Re: Won't let me send coins because it requires a transaction fee?
Poster: satoshi · Date: 2010-09-10T00:46:37Z · Thread: Won't let me send coins because it requires a transaction fee?
Original: https://bitcointalk.org/index.php?topic=1013.msg12342#msg12342
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/446/
I think I know what happened. Doubleclick on the generated transaction. It probably has a sub-0.01 transaction fee in it.
Someone has been paying a 0.00000010 transaction fee. I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it. Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.
It would normally be harmless except in this corner case. I should add a special case to CreateTransaction to handle this.
447. Re: Won't let me send coins because it requires a transaction fee?
Poster: satoshi · Date: 2010-09-10T17:12:33Z · Thread: Won't let me send coins because it requires a transaction fee?
Original: https://bitcointalk.org/index.php?topic=1013.msg12368#msg12368
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/447/
The fix is in SVN rev 151.
You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.
448. Re: Auto-detect for 128-bit 4-way SSE2
Poster: satoshi · Date: 2010-09-10T18:11:06Z · Thread: Auto-detect for 128-bit 4-way SSE2
Original: https://bitcointalk.org/index.php?topic=1007.msg12372#msg12372
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/448/
Quote from: teknohog on September 09, 2010, 07:32:05 PM
Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to
#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)
to make it compile again, at least on ARM.
Added in SVN rev 152
449. Re: Running on a port other than 8333
Poster: satoshi · Date: 2010-09-12T17:40:20Z · Thread: Running on a port other than 8333
Original: https://bitcointalk.org/index.php?topic=589.msg12483#msg12483
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/449/
Quote from: lachesis on August 10, 2010, 03:24:55 PM
Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.
Is there a way to open BerkeleyDB exclusive?
DB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.
I've dropped the DB_PRIVATE flag in rev 153.
450. Re: RFC: remove DB_PRIVATE flag
Poster: satoshi · Date: 2010-09-12T18:00:39Z · Thread: RFC: remove DB_PRIVATE flag
Original: https://bitcointalk.org/index.php?topic=920.msg12484#msg12484
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/450/
Trying it without the DB_PRIVATE flag in rev 153. We need to keep an eye on what's different.
On Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB. It doesn't delete them on exit, it just leaves them behind.
The docs say it uses memory mapped files. I assume they have the same file permissions as the database files, so the same user access restrictions apply.
Tests on Windows private LAN download of 78500 blocks:
with DB_PRIVATE 20 minutes 51 seconds
without DB_PRIVATE 20 minutes 51 seconds
I wasn't expecting them to come out exactly the same.
451. Re: Switch to GPL
Poster: satoshi · Date: 2010-09-12T19:24:53Z · Thread: Switch to GPL
Original: https://bitcointalk.org/index.php?topic=989.msg12494#msg12494
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/451/
If the only library is closed source, then there's a project to make an open source one.
If the only library is GPL, then there's a project to make a non-GPL one.
If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.
I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS. For smaller projects, I think the fear of a closed-source takeover is overdone.
452. Re: Memory leak
Poster: satoshi · Date: 2010-09-19T17:22:03Z · Thread: Memory leak
Original: https://bitcointalk.org/index.php?topic=1023.msg13201#msg13201
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/452/
Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the "-connect" switch?
Did you compile it or is this a release build, and what version?
I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?
The wait function on linux is:
inline void Sleep(int64 n)
{
boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}
If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.
453. Re: Issues building bitcoin on Windows 7
Poster: satoshi · Date: 2010-09-19T18:46:46Z · Thread: Issues building bitcoin on Windows 7
Original: https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/453/
The lines it's tripping on:
Code:
ERROR extern map<string, string> mapAddressBook;
ERROR extern CCriticalSection cs_mapAddressBook;
ERROR extern vector<unsigned char> vchDefaultKey;
OK extern bool fClient;
OK extern int nBestHeight;
OK extern unsigned int nWalletDBUpdated;
ERROR extern DbEnv dbenv;
So it's acting like nothing is defined, not even map and vector.
Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.
Is VC trying to use precompiled headers and screwing it up? Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?
There's an installer package now that makes it really easy to install MinGW. Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program completely installs everything, it's not hard like it used to be. I think the only thing I had to do was rename make*.exe something to make.exe.
http://tdm-gcc.tdragon.net/
Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault. With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason.
454. Re: Bug? /usr/bin/bitcoind ""
Poster: satoshi · Date: 2010-09-19T19:58:11Z · Thread: Bug? /usr/bin/bitcoind ""
Original: https://bitcointalk.org/index.php?topic=1063.msg13211#msg13211
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/454/
I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice.
We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.
I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.
455. Re: The case for removing IP transactions
Poster: satoshi · Date: 2010-09-19T21:49:30Z · Thread: The case for removing IP transactions
Original: https://bitcointalk.org/index.php?topic=1048.msg13219#msg13219
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/455/
Probably best to disable receiving by IP unless you specifically intend to use it. This is a lot of surface area that nobody uses that doesn't need to be open by default.
In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts. Random unidentified payments volunteered to the server's IP address would be unhelpful.
In general, sending by IP has limited useful cases. If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-the-middle risk is unacceptably high. If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.
I uploaded this change to SVN rev 156. The switch to enable is "-allowreceivebyip".
Senders with this version will get the error "Recipient is not accepting transactions sent by IP address". Older version senders will get "Transfer was not accepted".
I used a different name for the switch because "-allowiptransactions" sounds like it includes sending. If there's a better name for the switch, we can change it again.
456. Re: Message Encryption as a built-in feature?
Poster: satoshi · Date: 2010-09-19T22:47:00Z · Thread: Message Encryption as a built-in feature?
Original: https://bitcointalk.org/index.php?topic=1032.msg13221#msg13221
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/456/
Theymos already said this... ECDSA does not support encrypting messages. Only digital signatures.
457. Re: Always pay transaction fee?
Poster: satoshi · Date: 2010-09-23T16:08:35Z · Thread: Always pay transaction fee?
Original: https://bitcointalk.org/index.php?topic=994.msg13829#msg13829
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/457/
Quote from: satoshi on September 08, 2010, 05:30:14 PM
The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.
I implemented this change in SVN rev 157.
The reason I previously made it so high was to allow very large transactions without hitting the transaction fee. The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins. Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level. The new threshold puts it at around 11,000 BTC for sending generated coins. It would mostly only be reached with generated bitcoins. If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions. Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.
458. Internal version number
Poster: satoshi · Date: 2010-09-23T16:19:08Z · Thread: Internal version number
Original: https://bitcointalk.org/index.php?topic=1269.msg13831#msg13831
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/458/
In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.
459. Re: Warning : Check your system ( Help me )
Poster: satoshi · Date: 2010-09-23T16:28:25Z · Thread: Warning : Check your system clock (help me)
Original: https://bitcointalk.org/index.php?topic=960.msg13833#msg13833
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/459/
I don't understand, are you under the impression that the program sets the system clock? It doesn't.
Quote from: Cdecker on September 19, 2010, 08:14:08 PM
We already have ways to synchronize (approximately) the clients, so why not make use of that?
We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour. If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.
460. Re: Porn
Poster: satoshi · Date: 2010-09-23T17:56:55Z · Thread: Porn
Original: https://bitcointalk.org/index.php?topic=671.msg13844#msg13844
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/460/
Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to "porn guys", or afraid of recurring billing.
461. Re: How divisible are bitcoins - the technical side
Poster: satoshi · Date: 2010-09-23T18:39:56Z · Thread: How divisible are bitcoins - the technical side
Original: https://bitcointalk.org/index.php?topic=1271.msg13848#msg13848
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/461/
I would not encourage using the extra decimal places. They're only intended for future use.
You are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it. The UI will show it rounded down.
462. Re: Internal version number
Poster: satoshi · Date: 2010-09-23T18:46:20Z · Thread: Internal version number
Original: https://bitcointalk.org/index.php?topic=1269.msg13849#msg13849
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/462/
I don't think it should cause any problems for version comparisons. 31300 > 312.
463. Re: How To Make a Distributed BitCoin Escrow Service
Poster: satoshi · Date: 2010-09-26T17:34:26Z · Thread: How To Make a Distributed BitCoin Escrow Service
Original: https://bitcointalk.org/index.php?topic=1283.msg14136#msg14136
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/463/
It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:
http://bitcointalk.org/index.php?topic=750.0
It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.
464. Re: I broke my wallet, sends never confirm now.
Poster: satoshi · Date: 2010-09-30T16:38:53Z · Thread: I broke my wallet, sends never confirm now.
Original: https://bitcointalk.org/index.php?topic=1306.msg14714#msg14714
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/464/
As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.
I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.
I didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant.
The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.
I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly.
If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.
If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.
change:
if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)
continue;
to:
if (pcoin->GetDepthInMainChain() < 1)
continue;
465. Re: I broke my wallet, sends never confirm now.
Poster: satoshi · Date: 2010-09-30T16:59:00Z · Thread: I broke my wallet, sends never confirm now.
Original: https://bitcointalk.org/index.php?topic=1306.msg14720#msg14720
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/465/
0.3.13 release candidate, please test:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe
466. 0.3.13 RC1 for Windows, please test
Poster: satoshi · Date: 2010-09-30T17:04:15Z · Thread: 0.3.13 RC1 for Windows, please test
Original: https://bitcointalk.org/index.php?topic=1322.msg14722#msg14722
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/466/
0.3.13 release candidate, to be released soon so please test:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe
- don't count or spend payments until they have 1 confirmation
http://bitcointalk.org/index.php?topic=1306.0
- internal version number from 312 to 31300
- only accept transactions sent by IP address if -allowreceivebyip is specified
- dropped DB_PRIVATE Berkeley DB flag
- fix problem sending the last cent with sub-cent fractional change
- auto-detect whether to use 128-bit 4-way SSE2 on Linux
Gavin Andresen:
- option -rpcallowip= to accept json-rpc connections from another machine
- clean shutdown on SIGTERM on Linux
467. Re: BitCoin Wikipedia page DELETED!!!
Poster: satoshi · Date: 2010-09-30T17:50:32Z · Thread: BitCoin Wikipedia page DELETED!!!
Original: https://bitcointalk.org/index.php?topic=652.msg14729#msg14729
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/467/
If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is.
I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of.
The article could be as simple as something like:
"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/."
The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.
468. Re: Prioritized transactions, and tx fees
Poster: satoshi · Date: 2010-09-30T18:11:56Z · Thread: Prioritized transactions, and tx fees
Original: https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/468/
It ramps up the fee requirement as the block fills up:
<50KB free
50KB 0.01
250KB 0.02
333KB 0.03
375KB 0.04
etc.
It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers.
Just including the minimum 0.01 goes a long way.
469. Re: Prioritized transactions, and tx fees
Poster: satoshi · Date: 2010-09-30T18:22:22Z · Thread: Prioritized transactions, and tx fees
Original: https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/469/
True, the switch should be something more dynamic that pays per KB. It's harder to think of how to explain it.
470. Re: Remote RPC access
Poster: satoshi · Date: 2010-09-30T18:27:41Z · Thread: Remote RPC access
Original: https://bitcointalk.org/index.php?topic=1291.msg14736#msg14736
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/470/
It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other.
0.3.13 RC1 is available for Windows:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe
471. Re: 0.3.13 RC1 for Windows, please test
Poster: satoshi · Date: 2010-10-01T00:32:46Z · Thread: 0.3.13 RC1 for Windows, please test
Original: https://bitcointalk.org/index.php?topic=1322.msg14787#msg14787
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/471/
Too late for 0.3.13, but I'll try to find time to add it to the next version.
472. Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-01T00:34:35Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg14788#msg14788
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/472/
Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.
Changes:
- Don't count or spend payments until they have 1 confirmation.
- Internal version number from 312 to 31300.
- Only accept transactions sent by IP address if -allowreceivebyip is specified.
- Dropped DB_PRIVATE Berkeley DB flag.
- Fix problem sending the last cent with sub-cent fractional change.
- Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
- Option -rpcallowip= to accept json-rpc connections from another machine.
- Clean shutdown on SIGTERM on Linux.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/
(Thanks Laszlo for the Mac OSX build!)
Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
You can still control the SSE2 use manually with -4way and -4way=0.
Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
473. Re: Version 0.3.13
Poster: satoshi · Date: 2010-10-03T18:17:06Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15102#msg15102
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/473/
Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM
That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.
I still have to add the "-4way" switch.
Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.
Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?
Do all AMDs that support 64-bit have the better SSE2 hardware also?
474. Re: Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-03T19:39:06Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15110#msg15110
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/474/
Could a few people please run this special build? It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now. We really just need one block letting them through to clear up the previous transactions. Post if you generate a block with this.
These are binaries only. The linux version is 64-bit only.
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
SHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip
SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better.
475. Re: Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-03T19:49:32Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15112#msg15112
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/475/
Quote from: tcatm on October 03, 2010, 07:45:45 PM
983 Mhash/s box.
Seriously? What hardware is that?
476. Re: Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-03T20:02:24Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15116#msg15116
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/476/
Code:
diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sun Oct 03 20:57:20 2010
+++ new\main.cpp Sun Oct 03 20:57:54 2010
@@ -2831,6 +2831,10 @@
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
+ // AMD reports a lower model number in 64-bit mode
+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)
+ fUseSSE2 = true;
+
static bool fPrinted;
if (!fPrinted)
{
@@ -2989,6 +2993,17 @@
// Transaction fee based on block size
int64 nMinFee = tx.GetMinFee(nBlockSize);
+ //////// temporary code
+ if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "")
+ {
+ if (nBestHeight < 91000)
+ nMinFee = 0;
+ if (nBestHeight < 100000 && nTxSize < 2000)
+ nMinFee = 0;
+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)
+ nMinFee = 0;
+ }
+ //////// temporary code
map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
diff -u old\serialize.h new\serialize.h
--- old\serialize.h Sun Oct 03 20:57:45 2010
+++ new\serialize.h Sun Oct 03 20:57:54 2010
@@ -22,8 +22,8 @@
class CAutoFile;
static const unsigned int MAX_SIZE = 0x02000000;
-static const int VERSION = 31300;
-static const char* pszSubVer = "";
+static const int VERSION = 31301;
+static const char* pszSubVer = " test1";
477. Re: Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-03T20:54:07Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/477/
Quote from: theymos on October 03, 2010, 08:09:51 PM
ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.
Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.
Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.
If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them.
Quote from: theymos on October 03, 2010, 08:09:51 PM
The person who originally sent the broken transactions deleted his wallet
Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet.
Quote from: tcatm on October 03, 2010, 08:10:47 PM
It's running. Should find a block within 3 hours.
It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least.
478. Re: [PATCH] increase block size limit
Poster: satoshi · Date: 2010-10-03T21:07:28Z · Thread: [PATCH] increase block size limit
Original: https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/478/
Quote from: theymos on October 03, 2010, 08:28:39 PM
Applying this patch will make you incompatible with other Bitcoin clients.
+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.
We can phase in a change later if we get closer to needing it.
479. Re: How to overthrow the GPU Oligarchs
Poster: satoshi · Date: 2010-10-03T21:30:04Z · Thread: How to overthrow the GPU Oligarchs
Original: https://bitcointalk.org/index.php?topic=1332.msg15142#msg15142
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/479/
Quote from: theymos on October 02, 2010, 06:11:11 AM
Quote from: lzsaver on October 02, 2010, 05:49:47 AM
Can you tell more about it:
"they have to do weird things with extraNonce, which increases the size of the block header".
When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception.This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header.
We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't.
extraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.
Separate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too.
480. Re: Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-03T21:43:20Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15147#msg15147
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/480/
ShadowOfHarbringer, is yours faster with -4way?
If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.
The specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit.
481. Re: Memory leak
Poster: satoshi · Date: 2010-10-03T22:07:00Z · Thread: Memory leak
Original: https://bitcointalk.org/index.php?topic=1023.msg15150#msg15150
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/481/
You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.
IRC seems to be working. It ought to have other nodes to try.
There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside. Maybe there's something wrong in it.
Are you using -addnode?
482. Re: Version 0.3.13, please upgrade
Poster: satoshi · Date: 2010-10-03T23:46:19Z · Thread: Version 0.3.13, please upgrade
Original: https://bitcointalk.org/index.php?topic=1327.msg15167#msg15167
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/482/
Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41.
483. Re: Website and software translations
Poster: satoshi · Date: 2010-10-04T01:44:41Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg15176#msg15176
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/483/
Thanks eurekafag, Russian translation added to SVN rev 160.
484. Re: Website and software translations
Poster: satoshi · Date: 2010-10-04T19:21:01Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg15360#msg15360
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/484/
Quote from: eurekafag on October 04, 2010, 10:55:56 AM
Where can I find the latest English .po file to keep the translation up-to-date?
poedit does it. Either get the src directory from a release, or download it with SVN. Place your .po file 3 directories deep under the src directory. Open it with poedit and do Catalog->Update from sources.
So for example, you have:
src
src\base58.h
src\bignum.h
...
src\util.cpp
src\util.h
src\xpm
src\locale
u\LC_MESSAGES\bitcoin.po
Open bitcoin.po with poedit, do Catalog->Update from sources. It looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is.
This updates your existing .po file you already worked on and adds any news strings. It may try to match close strings, so check things over and make sure it didn't make any bad guesses.
Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things. I'm attaching your Russian one to this message.
485. Re: [PATCH] increase block size limit
Poster: satoshi · Date: 2010-10-04T19:48:40Z · Thread: [PATCH] increase block size limit
Original: https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/485/
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
486. Re: Website and software translations
Poster: satoshi · Date: 2010-10-06T15:42:39Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg15660#msg15660
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/486/
poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it's fine now. Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?
Strings aren't added or changed very often. It's months before enough changes build up.
I uploaded the changes.
This Windows build has the Russian translation in it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
487. Re: I broke my wallet, sends never confirm now.
Poster: satoshi · Date: 2010-10-06T16:54:23Z · Thread: I broke my wallet, sends never confirm now.
Original: https://bitcointalk.org/index.php?topic=1306.msg15672#msg15672
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/487/
That's going to be more of a SelectCoins thing.
SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent. This is needed because you should be able to spend your own change right away.
The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.
Here's a Windows build:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it. If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.
488. Re: Tor connections not working reliably, many seednodes offline
Poster: satoshi · Date: 2010-10-06T17:36:41Z · Thread: Tor connections not working reliably, many seednodes offline
Original: https://bitcointalk.org/index.php?topic=1375.msg15682#msg15682
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/488/
Maybe you were just unlucky to have an exit node without reverse lookup.
The IRC server's response doesn't look like it was disconnecting you for that. It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.
I see the problem. The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase. I'll fix it.
I don't know if it's really required to wait for the server to finish looking up hostname before sending nick.
How long did it take to get connected with TOR the first time, having to use the seed nodes?
489. Re: The Niche List
Poster: satoshi · Date: 2010-10-06T23:10:31Z · Thread: The Niche List
Original: https://bitcointalk.org/index.php?topic=1268.msg15741#msg15741
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/489/
Quote from: kiba on September 23, 2010, 04:00:16 PM
1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process.
Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism. One good one I found was Mihalism Multi Host. It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.
490. Key pool feature for safer wallet backup
Poster: satoshi · Date: 2010-10-09T20:19:33Z · Thread: Key pool feature for safer wallet backup
Original: https://bitcointalk.org/index.php?topic=1414.msg16316#msg16316
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/490/
SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.
For now I made the default pool size 100. It can be configured with -keypool=. Be aware, it takes a little time to increase the pool size, so don't go crazy with it. Disk space is about 1K per key.
I have not addressed the recovery side of this yet. If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.
I've only tested this moderately. You might not want to use this for a website server until it's had some more testing.
491. Version 0.3.14
Poster: satoshi · Date: 2010-10-21T16:39:27Z · Thread: Version 0.3.14
Original: https://bitcointalk.org/index.php?topic=1528.msg17924#msg17924
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/491/
Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/
Changes:
- Key pool feature for safer wallet backup
Gavin Andresen:
- TEST network mode with switch -testnet
- Option to use SSL for JSON-RPC connections on unix/osx
- validateaddress RPC command
eurekafag:
- Russian translation
492. Re: Website and software translations
Poster: satoshi · Date: 2010-10-21T22:50:47Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg17965#msg17965
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/492/
The order matters not to the program, but it matters to me maintaining it. If it jumbles the order of the .po file then I can't diff for changes. I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order.
I can still put it back into normal order by making poedit rescan it.
It is normal that untranslated strings are shown on top.
Quote from: eurekafag on October 06, 2010, 07:39:36 PM
By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.
I know, but not easily without complicating the sourcecode.
493. Re: ERROR - PLEASE HELP ME!
Poster: satoshi · Date: 2010-10-23T18:22:49Z · Thread: ERROR - PLEASE HELP ME!
Original: https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/493/
Quote from: theymos on October 21, 2010, 10:00:26 PM
his block count remains "stuck" at 1698.
He was generating invalid blocks at difficulty 1.0. He must have a corrupted entry in his blk0001.dat or blkindex.dat file. He just needs to delete blk*.dat and let it redownload.
The safety lockdown detected the problem and was displaying "WARNING: Displayed transactions may not be correct!" because it saw a longer chain existed that it was unable to accept. The safety lockdown cannot stop generation or it would create an attack possibility.
Quote from: gavinandresen on October 22, 2010, 02:25:14 PM
The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.
Good idea, I made a change to make sure it won't generate before checkpoint block 74000.
494. Re: ERROR - PLEASE HELP ME!
Poster: satoshi · Date: 2010-10-23T18:38:04Z · Thread: ERROR - PLEASE HELP ME!
Original: https://bitcointalk.org/index.php?topic=1530.msg18245#msg18245
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/494/
OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.
Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.
It would be instructive to get knightmb's blk*.dat and see if that gets him past that point.
495. Re: Win7 64bit since last patch Tues now crashes
Poster: satoshi · Date: 2010-10-23T18:52:02Z · Thread: Win7 64bit since last patch Tues now crashes
Original: https://bitcointalk.org/index.php?topic=1540.msg18246#msg18246
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/495/
Quote from: Odin on October 22, 2010, 09:24:38 PM
Fault Module Name: mingwm10.dll
This is the important clue. I believe it's saying it crashed in that. Maybe there are other versions of it to try. mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.
Is anyone else running OK on Windows 64-bit?
496. Re: Suggestion: Allow short messages to be sent together with bitcoins ?
Poster: satoshi · Date: 2010-10-23T19:02:57Z · Thread: Suggestion: Allow short messages to be sent together with bitcoins ?
Original: https://bitcointalk.org/index.php?topic=1545.msg18250#msg18250
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/496/
ECDSA can't encrypt messages, only sign signatures.
It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.
If there's going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they're from.
497. Re: Multiple Wallets, one computer
Poster: satoshi · Date: 2010-10-24T19:17:51Z · Thread: Multiple Wallets, one computer (multiple accounts)
Original: https://bitcointalk.org/index.php?topic=665.msg18349#msg18349
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/497/
I have the beginning of something like this. It's mostly like what Gavin described.
Some more rpc interface:
move <fromaccount> <toaccount> <amount>
Move from one internal account to another. I think blank account name ("") will be your default account. If you sell something to a user, you could do move "theiraccount" "" 123.45.
Is "move" the best name for this? I shied away from "transfer" because that sounds too close to sending a transaction.
I'm thinking a new function getaccountaddress instead of overloading getnewaddress:
getaccountaddress <account>
Gives you an address allocated from getnewaddress <account>. It'll keep giving the same address until something is received on the address, then it allocates a new address. (It automatically does what the sample code I posted some time ago did)
Would these commands make it possible in simple cases to implement your website without needing a database of your own?
498. Re: Multiple Wallets, one computer
Poster: satoshi · Date: 2010-10-25T16:53:53Z · Thread: Multiple Wallets, one computer (multiple accounts)
Original: https://bitcointalk.org/index.php?topic=665.msg18508#msg18508
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/498/
Here's some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier.
print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)
// if you make a sale, move the money out of their account
move(username, "", amount, 6)
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6)
499. Re: Win7 64bit since last patch Tues now crashes
Poster: satoshi · Date: 2010-10-25T17:27:47Z · Thread: Win7 64bit since last patch Tues now crashes
Original: https://bitcointalk.org/index.php?topic=1540.msg18511#msg18511
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/499/
The only thing I can think of is to see if there are other versions of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread. I don't know exactly what it does, but it probably just says something like "yes Windows, see I'm in a DLL like you insisted."
The end of your debug.log file might show the last thing it was doing before it crashed.
500. Re: New icon/logo
Poster: satoshi · Date: 2010-11-13T00:55:51Z · Thread: New icon/logo
Original: https://bitcointalk.org/index.php?topic=64.msg21766#msg21766
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/500/
I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.
It'll be a lot simpler if authors could make their graphics public domain.
501. Re: Some testing that I did on the testnetwork, my findings.
Poster: satoshi · Date: 2010-11-13T23:25:26Z · Thread: Some testing that I did on the testnetwork, my findings.
Original: https://bitcointalk.org/index.php?topic=1668.msg21896#msg21896
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/501/
Thank you for limiting flood tests to the testnet.
Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin's idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.
In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.
502. Version 0.3.15
Poster: satoshi · Date: 2010-11-13T23:26:40Z · Thread: Version 0.3.15
Original: https://bitcointalk.org/index.php?topic=1780.msg21897#msg21897
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/502/
Version 0.3.15 is now available.
Changes:
- paytxfee switch is now per KB, so it adds the correct fee for large transactions
- sending avoids using coins with less than 6 confirmations if it can
- BitcoinMiner processes transactions in priority order based on age of dependencies
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo
503. Re: Some testing that I did on the testnetwork, my findings.
Poster: satoshi · Date: 2010-11-14T16:53:19Z · Thread: Some testing that I did on the testnetwork, my findings.
Original: https://bitcointalk.org/index.php?topic=1668.msg21959#msg21959
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/503/
Quote from: ByteCoin on November 13, 2010, 11:55:11 PM
Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can "save" the higher priority coins for when the network is being flooded.
You should use at least some priority in case a flood comes along before the next block.
As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.
Quote
Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don't think we'll need to get into that much detail though. There's a wide enough difference between normal users and flooders.
Priority doesn't have to do everything. Once you know there's a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck.
504. Re: Need OP_BLOCKNUMBER to allow "time" limited transactions
Poster: satoshi · Date: 2010-11-15T18:37:44Z · Thread: Need OP_BLOCKNUMBER to allow "time" limited transactions
Original: https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/504/
We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.
nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later.
505. Re: Transaction / spam flood attack currently under way
Poster: satoshi · Date: 2010-11-19T23:50:24Z · Thread: Transaction / spam flood attack currently under way
Original: https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/505/
Quote from: creighto on November 19, 2010, 08:29:12 PM
Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.
I'm doing something like that. Priority is a more formalised version of the concept you're describing.
Quote from: FreeMoney on November 19, 2010, 05:39:44 PM
As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?
Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.
Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block.
I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. 0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.
Version 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.
I think this is a good compromise short of making the default fee 0.01. It's not so much to ask that free transactions can only be used to turn coins over so often. If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.
We've always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01.
506. Re: OpenCL miner for the masses
Poster: satoshi · Date: 2010-11-20T17:24:20Z · Thread: python OpenCL bitcoin miner
Original: https://bitcointalk.org/index.php?topic=1334.msg23097#msg23097
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/506/
Quote from: m0mchil on November 20, 2010, 10:16:19 AM
updated to SVN 186
Thanks m0mchil for keeping up on the updates!
GPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam.
Quote from: m0mchil on November 16, 2010, 10:30:41 AM
Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.
Before SVN 184, compiling transactions into a block used an n^2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)
507. New getwork
Poster: satoshi · Date: 2010-11-23T19:50:12Z · Thread: New getwork
Original: https://bitcointalk.org/index.php?topic=1901.msg23876#msg23876
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/507/
I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601)
m0mchil's external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn't want to add additional dependencies to the build. getwork allows these problems to be solved separately, with different programs for different hardware and OSes. It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.
The interface has a few changes:
getwork [data]
If [data] is not specified, returns formatted hash data to work on:
"midstate" : precomputed hash state after hashing the first half of the data
"data" : block data
"hash1" : formatted hash buffer for second hash
"target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful. [data] is the same 128 byte block data that was returned in the "data" field, but with the nonce changed.
Notes:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been separated into data and hash1.
- data is 128 bytes, which includes the first half that's already hashed by midstate.
- hash1 is always the same, but included for convenience.
- Logging of "ThreadRPCServer method=getwork" is disabled, it would be too much junk in the log.
508. Re: New getwork
Poster: satoshi · Date: 2010-11-23T20:55:27Z · Thread: New getwork
Original: https://bitcointalk.org/index.php?topic=1901.msg23891#msg23891
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/508/
It's not an exact drop-in replacement. I wanted to clean up the interface a little. It only requires a few changes.
ScanHash_ functions aren't going away. BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).
509. Re: New getwork
Poster: satoshi · Date: 2010-11-24T17:21:01Z · Thread: New getwork
Original: https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/509/
Quote from: jgarzik on November 24, 2010, 04:47:42 AM
I suspect something weird going on with ByteReverse (or lack thereof). It's quite unclear whether or not 'data' and 'nonce' must be byte-reversed, and in what way.
getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing. They're the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork.
I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent.
target is little endian, it's supposed to be the same as how m0mchil's did it. (if it's not, then it should be fixed) That's the only case where you would use byte reverse. I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].
Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM
Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification
This is the new spec. It shouldn't be hard to update your miner to use it.
The changes are:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been split into data and hash1.
- state renamed to midstate for consistency.
- extranonce not needed.
510. Re: OpenCL miner for the masses
Poster: satoshi · Date: 2010-11-24T17:53:09Z · Thread: python OpenCL bitcoin miner
Original: https://bitcointalk.org/index.php?topic=1334.msg24101#msg24101
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/510/
A revised version of getwork is now in the official client, but the miners need to be updated a little to use it.
511. Re: RFC: ship block chain 1-74000 with release tarballs?
Poster: satoshi · Date: 2010-11-25T17:51:39Z · Thread: RFC: ship block chain 1-74000 with release tarballs?
Original: https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/511/
It's not the downloading that takes the time, it's verifying and indexing it.
Bandwidthwise, it's more efficient than if you downloaded an archive. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.
During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing.
Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
512. Version 0.3.17
Poster: satoshi · Date: 2010-11-25T20:07:36Z · Thread: Version 0.3.17
Original: https://bitcointalk.org/index.php?topic=1946.msg24460#msg24460
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/512/
Version 0.3.17 is now available.
Changes:
- new getwork, thanks m0mchil
- added transaction fee setting in UI options menu
- free transaction limits
- sendtoaddress returns transaction id instead of "sent"
- getaccountaddress <account>
The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.
The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.
Downloads:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/
513. Re: RFC: ship block chain 1-74000 with release tarballs?
Poster: satoshi · Date: 2010-11-26T17:32:01Z · Thread: RFC: ship block chain 1-74000 with release tarballs?
Original: https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/513/
I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes.
If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens.
Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that's how it should work.
Quote from: jgarzik on November 26, 2010, 02:07:43 AM
Quote from: satoshi on November 25, 2010, 05:51:39 PM
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the ACID properties do you need, while downloading?
It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can't assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent.
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
Quote
Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.We checkpoint every 500 blocks.
514. Re: Version 0.3.17
Poster: satoshi · Date: 2010-11-26T18:23:30Z · Thread: Version 0.3.17
Original: https://bitcointalk.org/index.php?topic=1946.msg24673#msg24673
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/514/
Laszlo does them, but I haven't asked him to do one for a while because there wasn't anything major. I'll ask him to do this version.
515. Re: New getwork
Poster: satoshi · Date: 2010-11-26T21:31:13Z · Thread: New getwork
Original: https://bitcointalk.org/index.php?topic=1901.msg24708#msg24708
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/515/
That's what it does, it returns true/false.
516. Re: New demonstration CPU miner available
Poster: satoshi · Date: 2010-11-26T22:02:41Z · Thread: New demonstration CPU miner available
Original: https://bitcointalk.org/index.php?topic=1925.msg24719#msg24719
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/516/
You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++.
Currently it's only enabled in the Linux build, so if you get it to work you could make it available to Windows users. It's about 100% speedup on AMD CPUs.
517. Re: Cooperative mining
Poster: satoshi · Date: 2010-11-28T16:03:30Z · Thread: [2.5+ EH] Slush Pool (slushpool.com); World's First Mining Pool
Original: https://bitcointalk.org/index.php?topic=1976.msg25119#msg25119
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/517/
ribuck's description is spot on.
Pool operators can modify their getwork to take one additional parameter, the address to send your share to.
The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone
That would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people.
The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.
Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.
New users wouldn't really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server. When the miner says it found something, a while later a few coins show up in their account.
Miner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.
518. Re: RFC: ship block chain 1-74000 with release tarballs?
Poster: satoshi · Date: 2010-11-28T17:13:01Z · Thread: RFC: ship block chain 1-74000 with release tarballs?
Original: https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/518/
Despite everything else said, the current next step is:
Quote
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
In particular, I suspect that more read caching might help a lot.
Quote from: jgarzik on November 28, 2010, 02:33:29 AM
Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.
Then something more specific was wrong. That's not due to normal initial download time. Without more details, it can't be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point?
Quote
We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.
The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile.
If there was a "verify it" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.
Quote from: jgarzik on November 28, 2010, 07:33:55 AM
Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those...
80 bytes per header and no indexing work. Might take 1 minute.
Quote
uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.
The data is mostly hashes and keys and signatures that are uncompressible.
The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads.
519. Re: Is safe running bitcoins with the same wallet on more computers simultaneously?
Poster: satoshi · Date: 2010-11-28T18:06:39Z · Thread: Is safe running bitcoins with the same wallet on more computers simultaneously?
Original: https://bitcointalk.org/index.php?topic=1986.msg25154#msg25154
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/519/
Quote
Will it be synchronized automatically?
Very much not. Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that. Both copies will get screwed up.
If you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems. jgarzik has a CPU miner, and it supports tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7).
New demonstration CPU miner available:
http://bitcointalk.org/index.php?topic=1925.0
520. Re: RFC: ship block chain 1-74000 with release tarballs?
Poster: satoshi · Date: 2010-11-29T20:19:12Z · Thread: RFC: ship block chain 1-74000 with release tarballs?
Original: https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/520/
It seems like you're inclined to assume everything is wrong more than is actually so.
Writing the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what's slow. Read caching would help that. It's best if the DB does that. Maybe it has a setting for how much cache memory to use.
Quote
1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.
Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown.
Quote
And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.
If it was doing that it would be much slower. It's supposed to be only once a minute or 500 blocks:
if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
nMinutes = 1;
dbenv.txn_checkpoint(0, nMinutes, 0);
Probably should add this:
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);
Quote
2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.
Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can't imagine they're required to batch all their stuff up themselves.
In the following cases, would case 1 flush once and case 2 flush twice?
case 1:
write
write
write
write
checkpoint
case 2:
begin transaction
write
write
commit transaction
begin transaction
write
write
commit transaction
checkpoint
Contorting our database usage will not be the right approach. It's going to be BDB settings and caching.
521. Re: Incompatible wallet format with latest bitcoin-git ?
Poster: satoshi · Date: 2010-11-30T19:02:31Z · Thread: Incompatible wallet format with latest bitcoin-git ?
Original: https://bitcointalk.org/index.php?topic=2007.msg25799#msg25799
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/521/
What was this wallet used with? An early accounts patch or git build?
It's while loading the wallet. I assume it must be in this:
else if (strType == "acentry")
{
string strAccount;
ssKey >> strAccount;
uint64 nNumber;
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}
You could check that with this:
else if (strType == "acentry")
{
string strAccount;
assert(!ssKey.empty());
ssKey >> strAccount;
uint64 nNumber;
if (ssKey.size() != 8 )
printf("***** %s %d
", strAccount.c_str(), ssKey.size());
assert(ssKey.empty() == false);
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}
Was there an interim version of accounts on git at some point that had just ("acentry", "account") for the key?
If you have gdb, you could run it in gdb and do a backtrace.
gdb --args bitcoin ...
run
(wait for exception)
bt
522. Re: RFC: ship block chain 1-74000 with release tarballs?
Poster: satoshi · Date: 2010-12-01T21:25:39Z · Thread: RFC: ship block chain 1-74000 with release tarballs?
Original: https://bitcointalk.org/index.php?topic=1931.msg26016#msg26016
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/522/
That's a good optimisation. I'll add that next time I update SVN.
More generally, we could also consider this:
dbenv.set_lk_max_objects(10000);
dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug
dbenv.set_flags(DB_AUTO_COMMIT, 1);
+ dbenv.set_flags(DB_TXN_NOSYNC, 1);
ret = dbenv.open(strDataDir.c_str(),
DB_CREATE |
DB_INIT_LOCK |
DB_INIT_LOG |
We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes.
523. Re: Wikileaks contact info?
Poster: satoshi · Date: 2010-12-05T09:08:08Z · Thread: Wikileaks contact info?
Original: https://bitcointalk.org/index.php?topic=1735.msg26999#msg26999
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/523/
Quote from: RHorning on December 04, 2010, 10:17:44 PM
Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
No, don't "bring it on".
The project needs to grow gradually so the software can be strengthened along the way.
I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy. You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.
524. Re: JSON-RPC method idea: list transactions newer than a given txid
Poster: satoshi · Date: 2010-12-08T20:21:49Z · Thread: JSON-RPC method idea: list transactions newer than a given txid
Original: https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/524/
It's not safe to use listtransactions this way.
I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
The model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.
Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.
525. Re: JSON-RPC method idea: list transactions newer than a given txid
Poster: satoshi · Date: 2010-12-08T22:36:45Z · Thread: JSON-RPC method idea: list transactions newer than a given txid
Original: https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/525/
Then how do you cope with the issues I listed in the message you quoted?
526. Version 0.3.18
Poster: satoshi · Date: 2010-12-08T23:19:24Z · Thread: Version 0.3.18
Original: https://bitcointalk.org/index.php?topic=2162.msg28302#msg28302
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/526/
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little
The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://bitcointalk.org/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/
527. Re: JSON-RPC method idea: list transactions newer than a given txid
Poster: satoshi · Date: 2010-12-09T00:12:17Z · Thread: JSON-RPC method idea: list transactions newer than a given txid
Original: https://bitcointalk.org/index.php?topic=2151.msg28313#msg28313
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/527/
I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way.
Quote from: satoshi on December 08, 2010, 10:36:45 PM
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.
It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.
Quote from: jgarzik on December 08, 2010, 11:07:22 PM
Quote from: satoshi on December 08, 2010, 10:36:45 PM
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.
Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.
528. Re: Version 0.3.18
Poster: satoshi · Date: 2010-12-09T14:37:05Z · Thread: Version 0.3.18
Original: https://bitcointalk.org/index.php?topic=2162.msg28533#msg28533
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/528/
New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction.
Timestamp hashes are still already possible:
txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01
If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.
I like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it:
Quote from: Hal on December 05, 2010, 11:43:56 PM
I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.
The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence.
I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.
529. Re: Version 0.3.18
Poster: satoshi · Date: 2010-12-09T15:17:53Z · Thread: Version 0.3.18
Original: https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/529/
I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.
Quote from: nanotube on December 09, 2010, 06:19:05 AM
why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?
That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.
I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it.
530. Re: JSON-RPC method idea: list transactions newer than a given txid
Poster: satoshi · Date: 2010-12-09T18:08:08Z · Thread: JSON-RPC method idea: list transactions newer than a given txid
Original: https://bitcointalk.org/index.php?topic=2151.msg28640#msg28640
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/530/
Quote from: jgarzik on December 09, 2010, 12:58:05 AM
I agree with you and satoshi about "txs after <txid>". My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.
As long as the interface is designed for things like showing the user the last N transactions history, it's fine, now that we have the Accounts feature making it easier to do payment detection the right way.
Gavin, could listtransactions have an option to list transactions for all accounts?
I'm not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]
It would be hard to do that from the command line though.
I can't think of a good solution for the interface, that's the problem. Maybe "*" special case like "" is. Everyone would have to make sure no user can create account name "*".
Quote from: jgarzik on December 09, 2010, 04:13:50 PM
Sure, and that's easy enough to track with transactions.
I don't get how that's "easy" to track with transactions.
531. Re: Automated nightly builds
Poster: satoshi · Date: 2010-12-09T18:28:45Z · Thread: Automated nightly builds
Original: https://bitcointalk.org/index.php?topic=644.msg28643#msg28643
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/531/
Thanks for setting this up Cdecker.
Is there any chance of getting it to build the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly. Is this an environment where you can build wxWidgets once and leave it there and just keep using it?
532. Re: BitDNS and Generalizing Bitcoin
Poster: satoshi · Date: 2010-12-09T21:02:42Z · Thread: BitDNS and Generalizing Bitcoin
Original: https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/532/
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
533. Re: BitDNS and Generalizing Bitcoin
Poster: satoshi · Date: 2010-12-09T22:46:50Z · Thread: BitDNS and Generalizing Bitcoin
Original: https://bitcointalk.org/index.php?topic=1790.msg28715#msg28715
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/533/
Quote from: nanotube on December 09, 2010, 09:20:40 PM
seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also for the same work.
While you are generating bitcoins, why not also get free domain names for the same work?
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.
In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.
Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.
534. Re: Fees in BitDNS confusion
Poster: satoshi · Date: 2010-12-09T23:58:54Z · Thread: Fees in BitDNS confusion
Original: https://bitcointalk.org/index.php?topic=2181.msg28729#msg28729
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/534/
Not locktime.
There's a possible design for far in the future:
You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.
It's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.
There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.
535. Re: BitDNS and Generalizing Bitcoin
Poster: satoshi · Date: 2010-12-10T17:29:28Z · Thread: BitDNS and Generalizing Bitcoin
Original: https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/535/
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.
The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
Fears about securely buying domains with Bitcoins are a red herring. It's easy to trade Bitcoins for other non-repudiable commodities.
If you're still worried about it, it's cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both. The second signer can't release one without releasing the other.
536. Accounts example code
Poster: satoshi · Date: 2010-12-10T19:21:03Z · Thread: Accounts example code
Original: https://bitcointalk.org/index.php?topic=2202.msg28947#msg28947
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/536/
Some sample pseudocode using the new Accounts based commands in 0.3.18.
print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)
// if you make a sale, move the money from their account to your "" account
if (move(username, "", amount, 6, "purchased item"))
SendTheGoods()
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")
You can use listtransactions(username) to show them a list of their recent transactions.
537. Re: BitDNS and Generalizing Bitcoin
Poster: satoshi · Date: 2010-12-10T19:55:12Z · Thread: BitDNS and Generalizing Bitcoin
Original: https://bitcointalk.org/index.php?topic=1790.msg28959#msg28959
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/537/
Quote from: Hal on December 10, 2010, 07:14:04 PM
additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
Right, the exchange rate between domains and bitcoins would float.
A longer interval than 10 minutes would be appropriate for BitDNS.
So far