Ah, well, I meant the time it takes for a single node to verify the vallidity of a transaction. Not the time it takes for the entire network to accept the transaction as valid and incorporate it into the blockchain. In other words, checking the signature, checking the structure of the transaction, checking the content of the transaction fields, all that, how long does that take for a node (assumptions can be made on processor power, etc)? This should be independent of the tx fee.

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.

argh... thanks!

00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81 = 0000000000000000000000000000000000000000000000000000100010100011101001000001101 1100001011011100010110010100110101101010001000100110111101111001010011001111111 1011100010000101111001001111001101100010111001111001010110011111101010101100000 0101100110110000001 --> 256 bits

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.

Thanks! That's helpful, appreciate the explanation.

Thanks, an interesting read.

I see. So if I get it right, this could lead to a double spend, by creating two similar (inputs, outputs # of coins) transactions with separate txids?

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.

I'll go with "uncles are cool" :-) I know it's not possible now (2 blocks simulteanously being accepted), forking and such, but I'm trying to wiggle my way around that. Will get back later once I do a proper write up. Thanks!

Thanks for your response.

Apologies for the bad explanation, the word 'grouping' may be confusing here. I'm not refering to a pool, but a set of miners that is mining a particularly set of transactions (t1), each inidividual miner in that set aims to find a hash for its own block (no shared rewards, like in pools). The tricky part is when two sets of miners (different sets, that is) find a block; the protocol I'm trying to work on should be able to handle two blocks from two different sets of miners (but not two blocks from the same miners in a specific set). The assumption for now is that two blocks can be valid at the same time within the same cryptocurrency network, as long as they come from different sets (not pools) of miners.

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.

I was wondering the same as valrama, though the answer given raises two more questions:

-Can a pool 'hide' behind for example Tor, as in, change it's IP-address each time a valid block is broadcasted, and obtain a new Bitcoin address, too?

-So we have a pretty good idea of the hashing power of registered pools, but there's no insight in private (e.g. government backed) pools, or just a miner with a very large amount of hashing power (and money for mining hardware), both being able to change their Bitcoin address for each new coinbase transaction?

The 'concern' I'm having is that there's no way to find out if a miner obtains near 50% of the total hashing power. Though it's not likely to happen considering the costs, I'm curious if we'd be able to detect such a case, where a mining pool puts effort in remaining anonymous.

Thanks for your answer. I was thinking along the same lines, that it's somewhat of a security measure.

But if there would be a flaw in SHA256, wouldn't that impact both SHA256d hashed transactions, pretty much the same as SHA256 hashed transactions? It would of course depend on the flaw found, but reasoning that Satoshi choose this as a security measure, we're talking delay here.

Just wondering if the choice for SHA256d is a functional decision, like speed improvement.

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.

Great answers, that really is helpful. 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

Thanks. Wasn't aware that every single node receiving a new block also checks the transactions in the new block. I assume each node also performs a "block message" (https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages) check upon receiving new blocks.

Another thought occured: what if Eve changes her input to 1000 (of account A) and then send that 1000 to B. But this (https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages) reads it becomes an orphan transaction, because there is no corresponding 'out' for Eve's 'input'.

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.