📅 Original date posted:2012-07-06
📝 Original message: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.
>
> Yes, I've experienced that myself, actually.
> > Anyway, some background would be great; if I missed it, I'm happy to go
> > read up, but I didn't see any links on the wiki.
>
> Gavin wrote some notes on upgrades and BIP16 lessons-learned at
> https://gist.github.com/2355445
>
> This is a super coherent and excellent writeup. I may come back with more
thoughts, I want to let it percolate. Thanks!
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120706/a1b1e1dc/attachment.html>;
Peter Vessenes [ARCHIVE] /
npub1ez…6r8pt
2023-06-07 10:20:03
in reply to nevent1q…ajep
Author Public Key
npub1ezg54d03a7unwu0fckmlugxulukrg06x7jzx4engngxfg79sfcqsn6r8ptPublished at
2023-06-07 10:20:03Event JSON
{
"id": "3bd8cdcdde7ef23a5bd4351adc50d8ec0bbd29cb30725e754c9f7f3117aacbae",
"pubkey": "c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01",
"created_at": 1686133203,
"kind": 1,
"tags": [
[
"e",
"91d48645ee2fc11d41b139a1cb2582257810fa8d5c6e7516cf9fda8a47515a1c",
"",
"root"
],
[
"e",
"1883b65b616824569d9972e670615404d6fbc3d9b5b4dc4edbccee4b4dabbcee",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 Original date posted:2012-07-06\n📝 Original message:On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\n\u003e On 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\u003e With the existing setup (sans height in coinbase), you might not have\n\u003e unique transactions, with all that entails.\n\u003e\n\u003e Yes, I've experienced that myself, actually.\n\n\n\u003e \u003e Anyway, some background would be great; if I missed it, I'm happy to go\n\u003e \u003e read up, but I didn't see any links on the wiki.\n\u003e\n\u003e Gavin wrote some notes on upgrades and BIP16 lessons-learned at\n\u003e https://gist.github.com/2355445\n\u003e\n\u003e This is a super coherent and excellent writeup. I may come back with more\nthoughts, I want to let it percolate. Thanks!\n\n\u003e --\n\u003e Jeff Garzik\n\u003e exMULTI, Inc.\n\u003e jgarzik at exmulti.com\n\u003e\n\n\n\n-- \n------------------------------\n\n[image: CoinLab Logo]PETER VESSENES\nCEO\n\n*peter at coinlab.com * / 206.486.6856 / SKYPE: vessenes\n811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120706/a1b1e1dc/attachment.html\u003e",
"sig": "4360d643a0c564b1ccc5b0996759c2948b82e476c59c2e2d4c3389292bfa41fc506379cbbe9f0950a669c0624371593006d269212725e63d546cbf830192c334"
}