Hi,

As from what I understand, Bitcoin nodes transmit transactions twice. First the actual transaction is transmitted; second, the transaction is included in a block and the block is transmitted, effectively transmitting the transaction twice.

The first time a transaction is transmitted, each node verifues the validity of a transaction, before further transmitting it. Again, from what I understand, if the transaction is included in a block, the (all) transaction(s) is (in the block are) verified, before the block is transmitted to the next node.

(Note: these questions are about transaction validity, not the transaction ultimately being accepted in the blockchain)

My questions:
1.a How long does it take to verify the validity of a single transaction (not included in a block)? I guess some assumptions must be made (CPU, memory, number of inouts/outputs in a transaction)
1.b Is there a tool available with which I can test and observe the verification time (of a single and/or multiple transactions)?
2. Is transaction validation of a single transaction (not included in a block) similar to transaction validation of a transaction in a block body?

Thanks.

From reading the wiki (https://en.bitcoin.it/wiki/Block_hashing_algorithm), a block hash is 256 bits.

Out of curiosity, I copied a block hash (block 125551, just a random pick) and turned it into binary, see:
$ echo 00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81 | xxd -b -c 4
0000000: 00110000 00110000 00110000 00110000  0000
0000004: 00110000 00110000 00110000 00110000  0000
0000008: 00110000 00110000 00110000 00110000  0000
000000c: 00110000 00111000 01100001 00110011  08a3
0000010: 01100001 00110100 00110001 01100010  a41b
0000014: 00111000 00110101 01100010 00111000  85b8
0000018: 01100010 00110010 00111001 01100001  b29a
000001c: 01100100 00110100 00110100 00110100  d444
0000020: 01100100 01100101 01100110 00110010  def2
0000024: 00111001 00111001 01100110 01100101  99fe
0000028: 01100101 00110010 00110001 00110111  e217
000002c: 00111001 00110011 01100011 01100100  93cd
0000030: 00111000 01100010 00111001 01100101  8b9e
0000034: 00110101 00110110 00110111 01100101  567e
0000038: 01100001 01100010 00110000 00110010  ab02
000003c: 01100011 01100100 00111000 00110001  cd81

Now I'm counting 4 columns (2nd untill the 5th), 16 lines, and 8 characters per set. 4*16*8=512 bits.

I must be missing something obvious, but haven't found it, yet. Pointing out the obvious is appreciated. Thanks.

TL;DR: Why are transactions (240 bytes) added in the block body, instead of the SHA256 hash (256 bits) of the transaction?

From what I understand, a transaction (approx 240 bytes) is 'broadcasted' to the everyone in the network through inv-messages. A miner collects transactions, and adds 1 or more in a block(body). After finding the hash, a miner 'broadcasts the block (header and body). In essence, transactions are send twice. First the actual transaction, second, a cumulated set of transactions.

If a transactions is broadcasted and everyone receives the transaction, why not add a hash (256 bits) of the transaction in a block body? Propagation time of a block would be similar, the number of transactions send in a block is increased by a factor 8-ish.

One argument could be that not all mempools are synced. However, assuming that a transactions are broadcasted much faster than a block, part of the ruleset could be that a miner only can create a block from  transactions received. In practise, if a miner sends a block to its direct peers (in the P2P network) and the transaction is not known by these nodes, than the block is not valid. Since a block creation time is (on average) 10 minutes, transactions added to the block have plenty of time to propagate.

Hi all,

I was wondering if I could get some feedback on an idea that popped up, mining related.

I'm going to ask to make some assumptions here. The idea is that, by grouping miners, the mining process is distributed, effectively raising the amount of transactions per second. Grouping in this case is not the same as a pool, each miner in each group still would aim for his own profit. Also note that it's not about splitting the network, the P2P network remains intact, it's about distributing mining capacity.

Suppose that it would be possible to group all current Bitcoin miners (say, a protocol groups the current population of miners into two groups, group 1(g1) and group 2 (g2)), like Kademlia but with two buckets (could be more if the number of miners increase, but let's stick to two for now). Each group mines specific transactions (transactions are labelled 1 (t1) or 2 (t2) (t1s go to g1, etc)), and the same protocol also ensures that both groups can submit their found block simultaneously without creating a fork. I'm aware that's not really possible in Bitcoin's current blockchain implementation, but my question is about the grouping of miners, would that be a no-go from a centralization perspective? Thanks.

Hi,

In Bitcoin, the Merkle tree created from all transactions contains nodes that represent a double hash of each transaction: N = SHA256(SHA256(tx0)

What's the point of doing so? Can't we just do a N =  SHA256(tx0)?

Thanks.

Hi all,

In my quest to further understand the mechanics of Bitcoin, I ran into a asymmetric key question.

The Bitcoin wiki simply states that for creating private/public keys, Bitcoin applies the Elliptic Curve Digital Signature Algorithm or ECDSA (https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm). In the Bitcoin developer guide it reads that Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve (https://bitcoin.org/en/developer-guide#transactions).
However, in this scientific article (http://link.springer.com/chapter/10.1007%2F978-3-319-12400-1_35#page-1) it reads that Bitcoin uses the “Elliptic Curve DSA over the NIST P-256 curve”.

This overview of curves http://safecurves.cr.yp.to/  indicates that the two curves above are not considered safe.

When I Google for “bitcoin ecdsa "p-256" site:github.com” and “bitcoin ecdsa "secp256" site:github.com”, both return results. The code itself doesn't provide an answer, to me  (sorry, lousy coder here).

So, my questions are:
1. Which ECDSA curve is used in Bitcoin to generate a private key? Where does it read in the code?
2. Why are both curves mentioned on Bitcoin's Github?
3. If either is used, is that a smart thing to do, considering that both are not considered safe? Wouldn't it be better to use a 'safe' curve?
4. Would it be possible to use both curves amongst multiple users, depending on a user's preferences?
5. Extending that question, if someone found a major flaw in the ECDSA algorithm currently used, would it be possible to switch to another ECDSA algorithm? (no worries, I didn't find a major flaw :-) )

Thanks for reading.

Fevir

Hi all,

While trying to understand how Bitcoin operates under the hood, I was wondering if it's not dead easy to cheat (in Bitcoin).

Suppose we have Alice and Bob, you may know them, and Alice wants to send 10 BTC to Bob. Suppose both have a Bitcoin client (https://en.bitcoin.it/wiki/Clients) running on their device. From what I understand, a client is build upon Bitcoin core. Bitcoin core contains all protocol rules (https://bitcoin.org/en/developer-guide), such as transaction and block rules (https://en.bitcoin.it/wiki/Protocol_rules).
Now, in short, if Alice wants to send Bob 10 BTC, her client verifies the transaction (tx message: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages), the client broadcasts the transaction to peers/miners, who add the transaction into their block they're about to mine. The miner itself also performs a check (block message: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages). If Alice wants to cheat (e.g. tries a double spend), it's either detected by her own client, or by the miner.

Now, suppose the following. Eve wants to get rich. Fast. She decides upon the following. She downloads the source code of Bitcoin Core and makes some adjustments in its protocol, particulalrly, all checks on tx and block messages will pass the check, no matter how the transaction or block looks like. She then compiles the code and has her home-brewn Eve-Bitcoin-client.
Now, Eve creates two addresses (A and B), both contain 0 Bitcoins. Then, she creates a transaction, which sends 1000 BTC from address A to B. She does not broadcast this transaction to the network. Instead, she starts mining a block (based on the latest block in the blockchain) which include her own transaction. Suppose Eve is lucky or very patient and finds the right hash. Her client performs a block checks (which passes all criteria, remember Eve's client) and broadcasts the block to the network. Since the hash is correct, it seems that the network will add Eve's block to the chain. Eve just created 1000 BTC out of thin air.

It sounds too obvious though - what am I missing? Are there additional checks? What are the exact criteria upon which a block is added to the chain, and who decides this?

Fevir.