📅 Original date posted:2012-07-06
📝 Original message:It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me.
________________________________
From: Mark Friedenbach <mark at monetize.io>
To: Jeff Garzik <jgarzik at exmulti.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Sent: Friday, July 6, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter at coinlab.com> wrote:
>> The proposal is simple, and it's a small change for miners, I imagine.
>>
>> My question is: why?
>>
>> I worry about stuffing too many requirements on the coinbase. I suppose
>> the coinbase is easily extendible if we run out of bytes, but I think I'd
>> like to see some more discussion / good / bad type cases for making this
>> change. What do we get over just the prev_hash by doing this?
>
>With the existing setup (sans height in coinbase), you might not have
>unique transactions, with all that entails.
>
But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a <transaction hash, output index> refers to the first such pair that is not already spent. No?
Mark
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Amir Taaki [ARCHIVE] /
npub1ep…m3rel
2023-06-07 10:20:00
in reply to nevent1q…qs28
Author Public Key
npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3relSeen on
wss://relay.noswhere.comPublished at
2023-06-07 10:20:00Event JSON
{
"id": "1883b65b616824569d9972e670615404d6fbc3d9b5b4dc4edbccee4b4dabbcee",
"pubkey": "c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051",
"created_at": 1686133200,
"kind": 1,
"tags": [
[
"e",
"91d48645ee2fc11d41b139a1cb2582257810fa8d5c6e7516cf9fda8a47515a1c",
"",
"root"
],
[
"e",
"cdd907b698442281e41b20765faf1ab0243365e381a7f70422f2565ef5058420",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2012-07-06\n📝 Original message:It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me.\n\n\n\n\n________________________________\nFrom: Mark Friedenbach \u003cmark at monetize.io\u003e\nTo: Jeff Garzik \u003cjgarzik at exmulti.com\u003e \nCc: Bitcoin Development \u003cbitcoin-development at lists.sourceforge.net\u003e \nSent: Friday, July 6, 2012 6:56 PM\nSubject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase\n\n\nOn Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\nOn Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes \u003cpeter at coinlab.com\u003e wrote:\n\u003e\u003e The proposal is simple, and it's a small change for miners, I imagine.\n\u003e\u003e\n\u003e\u003e My question is: why?\n\u003e\u003e\n\u003e\u003e I worry about stuffing too many requirements on the coinbase. I suppose\n\u003e\u003e the coinbase is easily extendible if we run out of bytes, but I think I'd\n\u003e\u003e like to see some more discussion / good / bad type cases for making this\n\u003e\u003e change. What do we get over just the prev_hash by doing this?\n\u003e\n\u003eWith the existing setup (sans height in coinbase), you might not have\n\u003eunique transactions, with all that entails.\n\u003e\n\nBut those issues are solvable through other, non-backwards incompatible means. For example, mandate that a \u003ctransaction hash, output index\u003e refers to the first such pair that is not already spent. No?\n\nMark\n------------------------------------------------------------------------------\nLive Security Virtual Conference\nExclusive live event will cover all the ways today's security and \nthreat landscape has changed and how IT managers can respond. Discussions \nwill include endpoint security, mobile security and the latest in malware \nthreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n_______________________________________________\nBitcoin-development mailing list\nBitcoin-development at lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "0f564f5dcd7fa223e9cd8dda25c7b43503633dd6954d0340bcb2ac98345e8d6c0490f62e3fad269e75b031a58d2845fd53bc1639cb411ab5fa49d63a633744eb"
}