* [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
@ 2015-12-30 16:35 Tomas
2015-12-30 17:10 ` Luke Dashjr
0 siblings, 1 reply; 5+ messages in thread
From: Tomas @ 2015-12-30 16:35 UTC (permalink / raw)
To: bitcoin-dev
In an attempt to reduce developer centralization, and to reduce the risk
of forks introduced by implementation other than bitcoin-core, I have
drafted a BIP to support changes to the protocol from different
implementations.
The BIP can be found at:
https://github.com/tomasvdw/bips/blob/master/decentralized-improvement-proposals.mediawiki
I believe this BIP could mitigate the risk of forks, and decentralize
the development of the protocol.
If you consider the proposal worthy of discussion, please assign a
BIP-number.
Regards,
Tomas van der Wansem
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
2015-12-30 16:35 [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals Tomas
@ 2015-12-30 17:10 ` Luke Dashjr
2015-12-30 18:22 ` Tomas
0 siblings, 1 reply; 5+ messages in thread
From: Luke Dashjr @ 2015-12-30 17:10 UTC (permalink / raw)
To: bitcoin-dev, Tomas
On Wednesday, December 30, 2015 4:35:17 PM Tomas via bitcoin-dev wrote:
> In an attempt to reduce developer centralization, and to reduce the risk
> of forks introduced by implementation other than bitcoin-core, I have
> drafted a BIP to support changes to the protocol from different
> implementations.
The premises in Motivation are false. BIPs are required to have a reference
implementation, but that implementation need not necessarily be for Bitcoin
Core specifically.
The specification itself looks like an inefficient and bloaty reinvention of
version bits.
Luke
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
2015-12-30 17:10 ` Luke Dashjr
@ 2015-12-30 18:22 ` Tomas
2015-12-30 23:47 ` Luke Dashjr
0 siblings, 1 reply; 5+ messages in thread
From: Tomas @ 2015-12-30 18:22 UTC (permalink / raw)
To: Luke Dashjr, bitcoin-dev
> The specification itself looks like an inefficient and bloaty reinvention
> of
> version bits.
The actual assignment of version bits isn't clear from the
specification. Are you saying that any implementation that wants to
propose a change is encouraged to pick a free version bit and use it?
Furthermore, my proposal addresses the danger of forward-incompatible
changes; a hard-fork can no longer occur as every implementation will
agree on the active the set of rules even if it has not implemented
them. This seems to be lacking in the version bits proposal.
Tomas
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
2015-12-30 18:22 ` Tomas
@ 2015-12-30 23:47 ` Luke Dashjr
2016-01-03 23:31 ` Rusty Russell
0 siblings, 1 reply; 5+ messages in thread
From: Luke Dashjr @ 2015-12-30 23:47 UTC (permalink / raw)
To: Tomas; +Cc: bitcoin-dev
On Wednesday, December 30, 2015 6:22:59 PM Tomas wrote:
> > The specification itself looks like an inefficient and bloaty reinvention
> > of version bits.
>
> The actual assignment of version bits isn't clear from the
> specification. Are you saying that any implementation that wants to
> propose a change is encouraged to pick a free version bit and use it?
That should probably be clarified in the BIP, I agree. Perhaps it ought to be
assigned the same as BIP numbers themselves, by the BIP editor? (Although as a
limited resource, maybe that's not the best solution.)
> Furthermore, my proposal addresses the danger of forward-incompatible
> changes; a hard-fork can no longer occur as every implementation will
> agree on the active the set of rules even if it has not implemented
> them. This seems to be lacking in the version bits proposal.
I don't think that's possible. First of all, a hardfork can always occur,
since this is something done by the economy and not (even possibly opposed to)
miners. Furthermore, consider the change affecting how further rule changes
are made, such as a PoW algorithm change.
Luke
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals
2015-12-30 23:47 ` Luke Dashjr
@ 2016-01-03 23:31 ` Rusty Russell
0 siblings, 0 replies; 5+ messages in thread
From: Rusty Russell @ 2016-01-03 23:31 UTC (permalink / raw)
To: Luke Dashjr, Tomas; +Cc: bitcoin-dev
Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
> On Wednesday, December 30, 2015 6:22:59 PM Tomas wrote:
>> > The specification itself looks like an inefficient and bloaty reinvention
>> > of version bits.
>>
>> The actual assignment of version bits isn't clear from the
>> specification. Are you saying that any implementation that wants to
>> propose a change is encouraged to pick a free version bit and use it?
>
> That should probably be clarified in the BIP, I agree. Perhaps it ought to be
> assigned the same as BIP numbers themselves, by the BIP editor? (Although as a
> limited resource, maybe that's not the best solution.)
I thought about it, but it's subject to change. Frankly, the number of
deployed forks is low enough that they can sort it out themselves. If
we need something more robust, I'm happy to fill that role.
Cheers,
Rusty.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-04 1:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-30 16:35 [bitcoin-dev] [BIP Draft] Decentralized Improvement Proposals Tomas
2015-12-30 17:10 ` Luke Dashjr
2015-12-30 18:22 ` Tomas
2015-12-30 23:47 ` Luke Dashjr
2016-01-03 23:31 ` Rusty Russell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox