Eric Lombrozo [ARCHIVE] on Nostr: đź“… Original date posted:2015-07-22 đź“ť Original message:> On Jul 22, 2015, at 5:34 ...
đź“… Original date posted:2015-07-22
đź“ť Original message:> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists at coryfields.com> wrote:
>
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists at coryfields.com> wrote:
>>>
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>> FWIW, I had worked on something similar a while back:
>>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>>
>>>> I like the idea in principle…but we should require a new genesis block,
>>>> different magic bytes, and a different network port at the very least. :)
>>>>
>>>
>>> Not sure if serious, so I'll assume you are :)
>>
>> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>>
>
> Again, why? If someone wants to create a scamcoin, they can. If
> someone wants to burn money on a scamcoin, equally, they can. I'm not
> sure how this is any different. If someone manages to garner realistic
> support for a hard-fork, I don't see the benefit in forcing them to
> use forked software.. that only leaves Core in the middle because it's
> forced to choose a side (not choosing is unfortunately a side as
> well). It doesn't remove the reality of the split.
In general, new consensus rules are not trivial to implement. Block size limits are exceptional in being so simple to change in the code. So what you’re proposing sounds more like a plugin model supporting dynamic linking than a configuration file.
>>> Why? The idea in this case would be to allow the user to decide
>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>> runtime rather than the likely alternative of "./bitcoind" vs
>>> "./bitcoin-fork”.
>>
>> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>>
>>> Chain params may be identical other than the value of some future
>>> event (miner vote for example), in which case the configs would run
>>> identically until that point.
>>
>> Yes, indeed - this would be a special case.
>>
>>> If your concern is about nodes with different configs communicating
>>> with eachother, I'd like to reiterate: the idea really is no different
>>> than suggesting that someone fork the codebase and implement their own
>>> changes, it just cuts out most of the work required.
>>
>> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
>
> Well of course. It would be a terrible idea. People would try it and
> fail, and lose money. But for those crying foul at Core for being the
> consensus/policy gatekeeper, it seems to me that user-selectable
> params is the only logical solution.
The real problem isn’t so much the difficulty of creating forks of the codebase - but the fact that unless a fork has overwhelming support, blockchains cannot guarantee irreversibility of transactions…which defeats their entire purpose.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/a2ffbaef/attachment-0001.sig>;
đź“ť Original message:> On Jul 22, 2015, at 5:34 PM, Cory Fields <lists at coryfields.com> wrote:
>
> On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists at coryfields.com> wrote:
>>>
>>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>>> FWIW, I had worked on something similar a while back:
>>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>>
>>>> I like the idea in principle…but we should require a new genesis block,
>>>> different magic bytes, and a different network port at the very least. :)
>>>>
>>>
>>> Not sure if serious, so I'll assume you are :)
>>
>> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>>
>
> Again, why? If someone wants to create a scamcoin, they can. If
> someone wants to burn money on a scamcoin, equally, they can. I'm not
> sure how this is any different. If someone manages to garner realistic
> support for a hard-fork, I don't see the benefit in forcing them to
> use forked software.. that only leaves Core in the middle because it's
> forced to choose a side (not choosing is unfortunately a side as
> well). It doesn't remove the reality of the split.
In general, new consensus rules are not trivial to implement. Block size limits are exceptional in being so simple to change in the code. So what you’re proposing sounds more like a plugin model supporting dynamic linking than a configuration file.
>>> Why? The idea in this case would be to allow the user to decide
>>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>>> runtime rather than the likely alternative of "./bitcoind" vs
>>> "./bitcoin-fork”.
>>
>> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>>
>>> Chain params may be identical other than the value of some future
>>> event (miner vote for example), in which case the configs would run
>>> identically until that point.
>>
>> Yes, indeed - this would be a special case.
>>
>>> If your concern is about nodes with different configs communicating
>>> with eachother, I'd like to reiterate: the idea really is no different
>>> than suggesting that someone fork the codebase and implement their own
>>> changes, it just cuts out most of the work required.
>>
>> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
>
> Well of course. It would be a terrible idea. People would try it and
> fail, and lose money. But for those crying foul at Core for being the
> consensus/policy gatekeeper, it seems to me that user-selectable
> params is the only logical solution.
The real problem isn’t so much the difficulty of creating forks of the codebase - but the fact that unless a fork has overwhelming support, blockchains cannot guarantee irreversibility of transactions…which defeats their entire purpose.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/a2ffbaef/attachment-0001.sig>;