Bitcoin Forum
December 04, 2016, 12:05:18 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why include any transactions?  (Read 1037 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 22, 2011, 12:01:47 PM
 #1

Could a miner not just create "blank" blocks which just pay themselves the 50BTC fee and don't contain any other transactions?

This would eliminate the need to verify any transactions (which is apparently a big issue for solo miners vs pooled miners).

This wouldn't actually be useless, since they are verifying the previous block and adding to the proof of work.

Also, they could still include some high value transactions, which would actually act to increase the average transaction fee.  If 25% of miners were solo "blank" miners, then free transactions would be less likely to be included.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1480809918
Hero Member
*
Offline Offline

Posts: 1480809918

View Profile Personal Message (Offline)

Ignore
1480809918
Reply with quote  #2

1480809918
Report to moderator
1480809918
Hero Member
*
Offline Offline

Posts: 1480809918

View Profile Personal Message (Offline)

Ignore
1480809918
Reply with quote  #2

1480809918
Report to moderator
1480809918
Hero Member
*
Offline Offline

Posts: 1480809918

View Profile Personal Message (Offline)

Ignore
1480809918
Reply with quote  #2

1480809918
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin-Qt, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480809918
Hero Member
*
Offline Offline

Posts: 1480809918

View Profile Personal Message (Offline)

Ignore
1480809918
Reply with quote  #2

1480809918
Report to moderator
1480809918
Hero Member
*
Offline Offline

Posts: 1480809918

View Profile Personal Message (Offline)

Ignore
1480809918
Reply with quote  #2

1480809918
Report to moderator
1480809918
Hero Member
*
Offline Offline

Posts: 1480809918

View Profile Personal Message (Offline)

Ignore
1480809918
Reply with quote  #2

1480809918
Report to moderator
ihadanny
Newbie
*
Offline Offline

Activity: 9


View Profile
July 18, 2011, 06:07:12 PM
 #2

Can anyone answer? Why indeed???
Also, can you expand on how does the miner decide on when to seal the new block and start working on it = not accept any new transactions? does he wait until the entire block gets filled?
Also, what happens to other transactions that did not enter winning block but to a losing block? How do they enter the next winning block?
bcforum
Full Member
***
Offline Offline

Activity: 140


View Profile
July 19, 2011, 01:10:42 PM
 #3


Yes, a miner could sign blocks containing only the generation transaction. This would be anti-social, and when the problem got large enough the other miners would update their client to ignore these blocks. You would get nothing for your efforts.

Verifying transactions was only an issue with CPU miners since the CPU was shared between assembling the block and searching for the golden nonce. With GPU mining, the CPU assembles the block (and verifies transactions) and the GPU searches for the nonce.

The block is constantly changing (new transactions being added) until a golden nonce is found. The block is then pushed to the network and a new block is started. There isn't any concept of a 'filled' block though, a block contains all the transactions up to the point the nonce is found.

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
ihadanny
Newbie
*
Offline Offline

Activity: 9


View Profile
July 19, 2011, 01:44:44 PM
 #4

thanks!
are you sure about the nonce not being the hash for the entire string of the entire block?!
I thought that the whole point was that the golden nonce is a proof-of-work, AND a seal of approval on the entire block - say a hash of its CRC.
I thought that this is the mechanism to prevent retro-active changes in the block chain history.

let me rephrase what you are saying, tell me if I got it right: the golden nonce is the hash of simply the previous block nonce, and that the block transactions are just a payload.
so what is the protection against someone changing history, and re-writing one of those transactions, if the nonce doesn't seal them off?
realnowhereman
Hero Member
*****
Offline Offline

Activity: 504



View Profile
July 19, 2011, 02:02:27 PM
 #5

thanks!
are you sure about the nonce not being the hash for the entire string of the entire block?!
I thought that the whole point was that the golden nonce is a proof-of-work, AND a seal of approval on the entire block - say a hash of its CRC.
I thought that this is the mechanism to prevent retro-active changes in the block chain history.

let me rephrase what you are saying, tell me if I got it right: the golden nonce is the hash of simply the previous block nonce, and that the block transactions are just a payload.
so what is the protection against someone changing history, and re-writing one of those transactions, if the nonce doesn't seal them off?

I think you're mixing up the nonce with the block hash.  It is the block hash that seals the entire block, or rather the block header.  The block header also contains a hash (or rather the Merkle root hash) of all the transactions in the block.   So... if any transactions in the block change, the hash in the block header changes, if the block header changes the hash changes.

If that was all there was to it, then the block header would have a fixed hash.  The nonce supplies another way of changing the block header.  The nonce serves no other purpose so may be completely arbitrarily chosen.  Miners try many nonces until the block hash meets the proof-of-work condition.

Given that there is no way of knowing if any particular nonce will be "the one", it doesn't matter if any other fields in the block header change at the same time.  In particular the transaction hash.  Therefore it costs the miner close to zero to allow an additional transaction into the block, since it's effect is exactly the same as changing the nonce.

As to the extra work for additional transactions, bear in mind that we're talking about megahashes per second machines.  The additional work to add a transaction is the recalculation of the Merkle tree, is in the order of say thousands of hashes rather than millions of hashes, then the extra cost is tiny.  Further: if we had a GPU doing the nonce search, the little bit of work that the CPU would have to do to add a transaction comes close to being free.

So while there is no reason for miners to add transactions, there's also no reason not to add them either.

If it really became a problem then sociable miners could add a test that said "if there are a thousand pending transactions and new block X contains none of them, then reject the block".  It'd be dangerous to do though because it would make block acceptance conditional on out-of-block state.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
ihadanny
Newbie
*
Offline Offline

Activity: 9


View Profile
July 19, 2011, 08:18:11 PM
 #6

ok, I re-read your answer carefully, and the article I missed about: https://en.bitcoin.it/wiki/Block_hashing_algorithm, and now I'm educated about the block header and no longer confused (10x!).
However, 1 last try: by constantly changing the current block merkle root, you can't possibly work methodically and cover methodically all the nonces between 0-2^32, increment extra-nonce and then continue to the next 0-2^32 nonces. isn't this a bad thing? you end up shooting in the dark instead of sequentially passing over all the options. or is it irrelevant when what you're looking for hides at a 2^256 space?
realnowhereman
Hero Member
*****
Offline Offline

Activity: 504



View Profile
July 19, 2011, 11:37:22 PM
 #7

There is no need to cover any particular subset fully. The chances of any nonce being "the one" are always the same since there is no way to predict hash from nonce.

It might be easiest for miners to search the nonce-space monotonically, but it doesn't reallymayter.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 19, 2011, 11:46:37 PM
 #8

However, 1 last try: by constantly changing the current block merkle root, you can't possibly work methodically and cover methodically all the nonces between 0-2^32, increment extra-nonce and then continue to the next 0-2^32 nonces. isn't this a bad thing? you end up shooting in the dark instead of sequentially passing over all the options. or is it irrelevant when what you're looking for hides at a 2^256 space?
It makes no difference. Every hash you try, assuming you haven't already tried it, has precisely the same chance of yielding a block.

As a practical matter, a miner will generally try all 2^32 possible nonces for a given work unit until they either mine a block or generate a share. When they request a new work unit, that new work unit will include all valid transactions (or as many fit or meet their criteria) known at that time.

A miner will only abort a nonce scan in progress if a new block is found somewhere on the network. In that case, it's worth disrupting the mining in progress to start working on a longer chain. New transactions have to wait for new work units.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
bcforum
Full Member
***
Offline Offline

Activity: 140


View Profile
July 20, 2011, 12:32:54 AM
 #9


And as a point of fact 400MH/s only takes 10 seconds to search the whole 2^32 nonce space, so when the miner requests new work the timestamp is updated.

At this stage the only use I see for the extra-nonce field is to give the same mekel root to multiple miners while still providing different data to hash.

If you found this post useful, feel free to share the wealth: 1E35gTBmJzPNJ3v72DX4wu4YtvHTWqNRbM
ihadanny
Newbie
*
Offline Offline

Activity: 9


View Profile
July 20, 2011, 08:39:32 AM
 #10

Quote
the extra-nonce field is to give the same mekel root to multiple miners while still providing different data to hash

not needed, because the first transaction in each block is the one generating 50 coins to the miner, and each miner has a different address.
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 20, 2011, 08:40:53 AM
 #11

Quote
the extra-nonce field is to give the same mekel root to multiple miners while still providing different data to hash

not needed, because the first transaction in each block is the one generating 50 coins to the miner, and each miner has a different address.
Not if they're members of the same pool.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!