From: Amir Taaki <zgenjix@yahoo•com>
To: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
Date: Fri, 6 Jul 2012 13:02:40 -0700 (PDT) [thread overview]
Message-ID: <1341604960.84829.YahooMailNeo@web121006.mail.ne1.yahoo.com> (raw)
In-Reply-To: <CACh7GpFb8Xxn9KmR34UNw6N=P96TJSgqec+eLdr5KneZAOj9Tw@mail.gmail.com>
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@monetize•io>
To: Jeff Garzik <jgarzik@exmulti•com>
Cc: Bitcoin Development <bitcoin-development@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@exmulti•com> wrote:
On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes <peter@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@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2012-07-06 20:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 15:10 Jeff Garzik
2012-07-06 16:45 ` Peter Vessenes
2012-07-06 16:49 ` Jeff Garzik
2012-07-06 16:56 ` Mark Friedenbach
2012-07-06 20:02 ` Gavin Andresen
2012-07-06 20:10 ` Gregory Maxwell
2012-07-06 20:02 ` Amir Taaki [this message]
2012-07-06 17:02 ` Peter Vessenes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1341604960.84829.YahooMailNeo@web121006.mail.ne1.yahoo.com \
--to=zgenjix@yahoo$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox