Congratulations Grau!

Please note that all DoS protections that the Shatoshi client has still haven't been implemented in bitsofproof supernode.
They are needed before putting nodes live on the p2p net.
I will review its security regarding DoS soon.

Check the thread: P2PTradeX: P2P Trading between cryptocurrencies (https://bitcointalk.org/index.php?topic=91843.0)

For a method of trading between block-chains that works fine in practice and has no known drawback.

Best regards,
  Sergio.

Not the whole field, just take a couple of bytes from it. 2 bytes is more than enough for version information...

I can't  follow you line of reasoning.

If you force the Block.nVersion>=2 or higher, old clients will see "garbage", and will do nothing (or do the same as when a 0.6.x version sees a version 2 block, just process it).

Then you can keep the 2 less significant bytes for version, and use the 2 most significant bytes for nonce. Any miner have the power to do it, and nobody can stop them from doing it.

When Bitcoin version 7.1 is out, then the dev team will need to change the code to reflect this change, splitting the nVersion field in two.
If they try to force the 2 MSbytes of nVersion to zero, then they will force a hard fork, because there will be already a block in the chain with nVersion>65536 and because old clients will accept new blocks with nVersion>65536, so they must follow the community and accept the new semantics.

In this regard, any miner has the power to change the protocol semantics.

Obviously, having consent from all parties involved is better.

best regards,
 Sergio.

Well, it's not a change in the protocol implementation. It's a change in the protocol semantics.

Right now you can use part of the version field as nonce and nothing bad will happen AFAIK.

There is a possible FIX to add more nonce space while maintaining backwards compatibility:


We can take 16 bits from the block version field to be used as more nonce space:

4    version    uint32_t    Block version information, based upon the software version creating this block

split it as:

2    version    uint16_t    Block version information, based upon the software version creating this block
2    extra_nonce uint16_t    More nonce space


I think it will not break compatibility. Old nodes will only tell the users to upgrade.

What yo you think?

I don't know exactly what algorithm currently use merchants that are accepting 0 confirmations.

They may be using this algorithm:

After you receive the transaction tx1 sending X coins to my address:

"If a second transaction tx2 is detected (coming from another peer or a "watch" node)  that spends any of the tx1 inputs and has different hash, then it's a double spend attempt"

This algorithm can fail to some attacks, because of possible signature malleability. A possible correct algorithm would be:

"If a second transaction tx2 is detected (coming from another peer or a "watch" node) that spends any of the tx1 inputs and does not have an output sending X coins to my address , then it's a double spend attempt"

Don't check the remaining outputs nor the transaction hash.

Best regards,
 Sergio.

For the record, there is another possibility of signature malleability.

For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.

As the vulnerability CVE-2012-3789 that I found was fixed in recent versions, you can try to upgrade and check if the problem is still present.

Also you can reconnect to a different set of peers (without accepting incoming connections). The possibility that you're still under attack after reconnection is very low.

But if you still think you're under some kind (known or unknown) of attack, maybe you can send your debug.log file to one or the core developers for examination.

Best regards,
 Sergio.

And was packaged with OpenSSL 0.9.8h 28 May 2008

BitCoin v0.1.5 ALPHA

https://github.com/bitcoin/bitcoin/tree/4405b78d6059e536c36974088a8ed4d9f0f29898

August 29, 2009

Interesting, isn't it?

The point is that we really don't know if CryptAcquireContext() in RAND_Screen fails. OpenSSL tells nothing to the user about it.

I don't even known in which situations it can fail. Maybe "Windows HOME BASIC For Childen under 13" does not support it. Or Maybe "Windows for Cuba"  does not either because crypto export controls...

Interesting. What would cover all spent outputs...
Also I can use that information to validate the naive method I suggested, and see the false positives/negatives ratio.

These are my opinions (which are more based on intuition and experience than on theoretical grounds that I can cite).
They are based on how the system would respond to a failure of one of the components, as damage control.

1. Don't add private ECC keys as random source.

A failure in OpenSSL random pool would imply the leakage of private keys as a new vector of attack.

2. Use a simple pool state file, with RAND_load_file(). The first time bitcoin is run, gather entropy from keys pressed and save that entropy to the state file. Mix the entropy state file with the current pool state each time the application starts.

3. Don't XOR private ECC keys.

The properties of XOR over the EC field were not analyzed. Hashing them together would be better. Nevertheless if a state file is used, this is not necessary.

4. If half of the private ECC key is disclosed, is possible that the full key is compromised. That happens in many number theoretic ciphers and signature algorithms. Half a private key is NOT half of the security.

5. Call RAND_event() each time we process a Windows message.

6. Leave RAND_Screen where it is (It cannot do any harm).

As the first call to RAND_bytes calls RAND_Poll, RAND_Screen is not strictly necessary. (see http://security.stackexchange.com/questions/7718/openssl-rand-poll-good-enough )

I like Diapolo code but the application should tell the user or halt if CryptAcquireContext fails. 250000 bytes is probably not needed. Just 64 bytes (as in OpenSSL) would be ok.

But you still have to know which addresses belongs to you, so there is the chicken and egg problem.

Yes, if anyone wants it


But no client would automatically generate a transaction where the change is greater than a transaction input? What for?

Do you mean something like (A):

Inputs: 10 , 20, 30
Outputs: 15 (change), 45 (payment)

Why not create the tx (B):

Input: 20 , 30
Output: 5 (change) ,45 (payment)

Is the client so dumb to generate a transaction like A which wastes space instead of B ?

You could run Diehard tests (http://en.wikipedia.org/wiki/Diehard_tests) but they won't detect low entropy unless you generate terabytes of data to test. I don't think it would work.

I said before, since RAND_Screen calls CryptGenRandom() which is supposed to be strong, entropy should be enough.
But again! OpenSSL will not tell the function caller if CryptAcquireContext() fails and so CryptGenRandom()  is never called.

I not sure how CryptAcquireContext() can fail, but there are so many failure error codes that I suppose it will fail sometimes! (I would prefer fail-safe semantics that informs the user of the actual entropy acquired for RAND_Screen)
(check http://msdn.microsoft.com/en-us/library/windows/desktop/aa379886%28v=vs.85%29.aspx)

The best solution I can think of is to notify the user if the entropy generation code is not working.

Note that Bitcoind running in Windows 2000 or earlier would probably suffer from lack of entropy, but I think Win2K is not supported.

Yes, as I said: RAND_Screen seems strong enough. (check OpenSSL code at openssl-1.0.1c\crypto\rand\rand_win.c)

OpenSSL does not add additional entropy by itself: the user must call RAND_poll() periodically. Only the first time RAND_Bytes is called OpenSSL calls RAND_poll().

Yes! I forgot the change position randomization!

But still it's generally possible to guess which output is the change, since :

1. The payment amount is always greater than the sum of inputs amounts, with the exception of the input amount of lesser value.
3. The change amount is always smaller than any of the inputs.

The only case where this guessing fails is when there is a single input amount. In this case, generally the payment amount is an integer value, and the change is not, so you still can guess with some accuracy.

Best regards Pieter!

I'm making this (non-)vulnerability public since I'm quite sure that there is no immediate danger, but the source code should be modified by the core dev-team for the next version.

In the Bitcoin Windows client, entropy is provided by:

1. RAND_Screen at initialization (in util.cpp)
2. Periodic calls to RandAddSeedPerfmon()

But the second method may present two problems:

A. RandAddSeedPerfmon() calls RandAddSeed() that calls QueryPerformanceCounter() which gets a timestamp with about 25 bits of real entropy (since service applications tend to be run when the computer starts). But QueryPerformanceCounter() requires the argument to be QWORD aligned, and I'm not sure if gcc aligns to 8-byte boundaries (I think it aligns to 4-byte). So maybe the call sometimes fails quietly, and these entropy bits are never returned.

B. RandAddSeedPerfmon() calls RegQueryValueExA(HKEY_PERFORMANCE_DATA, "Global" with a fixed buffer size of 250000. If the returned data is bigger than this buffer, it fails. But in my XP (and probably in many other systems) the returned data is around 280 Kb, so this functions fails quietly.

At the end, the ONLY source of random may be RAND_Screen with no entropy reseeding taking place.


Note that the first keypair is created with just two calls to RandAddSeedPerfmon(), so it would be possible to guess keys if RAND_Screen would not be strong enough. (Luckily it is in XP and above).

The problem I see is that there is nothing logged in the debug.log file or message telling the user that he may be generating weak keys.  Both failures of QueryPerformanceCounter() and RegQueryValueExA should be logged and the user should be alarmed.

To the dev-team: please don't remove RAND_Screen (interesting talk at http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/06/04)

Best regards,
 Sergio.

PS: Congratulations Gavin for the Bitcoin Foundation!