Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wallet encryption could cause duplicate coinbase txes #482

Closed
TheBlueMatt opened this issue Aug 31, 2011 · 3 comments
Closed

Wallet encryption could cause duplicate coinbase txes #482

TheBlueMatt opened this issue Aug 31, 2011 · 3 comments

Comments

@TheBlueMatt
Copy link
Contributor

Quote from 59ed5cb#commitcomment-562434

This edit states that the "default key" will be used as the target for payouts for mining. If this is correct, then it might be problematic and could result in a loss of funds to miners. When miners mine more than one block using the same payout address, the coinbase transactions in each block are identical, which results in them having an identical sha256 hash, which results in all but the first one being unidentifiable and hence unspendable. I suppose you might be aware of that, but wanted to point this out just to prevent the possibility of it being an expensive consequence for somebody else.

@gavinandresen
Copy link
Contributor

Can somebody double-check to see if I'm reading the code correctly?

Looks like both BitcoinMiner and getwork() call IncrementExtraNonce() to create unique coinbase transactions, so I don't think this is an issue.

@sipa
Copy link
Member

sipa commented Sep 6, 2011

They both call IncrementExtraNonce... which resets the extra nonce every second after overflowing. This guarantees unique block candidates, but not unique coinbase transactions. When an infinite supply of pubkeys are available, this isn't a problem, because after creating a block, the previous default pubkey will be in use, and a new one will be used.

My suggestion: add the current timestamp to the coinbase when no fresh pubkeys are available.

@makomk
Copy link

makomk commented Sep 6, 2011

Also, the extra nonce used in IncrementExtraNonce isn't stored across restarts. This isn't normally an issue due to the timestamps in block headers - it's very unlikely a bitcoin restart will take less than a second - but it means that not resetting the extranonce isn't a solution.

coblee referenced this issue in litecoin-project/litecoin Jul 17, 2012
ptschip pushed a commit to ptschip/bitcoin that referenced this issue May 4, 2017
Re-request a full thinblock on merkleroot check failure
dexX7 added a commit to dexX7/bitcoin that referenced this issue Jul 7, 2017
…stic

4b42303 Remove git created macros to make builds deterministic (dexX7)
IntegralTeam pushed a commit to IntegralTeam/bitcoin that referenced this issue May 15, 2019
* Litecon: Modify thread names

Since this string is displayed externally within lists of processes and should be consistent with branding, and not cause confusion for admins, when running "top", "ps aux", "pgrep" or similar commands.

* Litecoin: Remove invalid doxygen link

* Litecoin: Add additional optional build steps for osx builds

Fixes: litecoin-project#463

* Litecoin: Show scrypt sse2 status in configure and fix scrypt syntax issue
kallewoof pushed a commit to kallewoof/bitcoin that referenced this issue Oct 4, 2019
…91fd7043533cf7

2d465aa Squashed 'src/secp256k1/' changes from 0b70241..53ad841 (Gregory Sanders)
rajarshimaitra pushed a commit to rajarshimaitra/bitcoin that referenced this issue Aug 5, 2021
Related to the new definition of Bitcoin Mining bitcoin#482
rajarshimaitra pushed a commit to rajarshimaitra/bitcoin that referenced this issue Aug 5, 2021
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants