[Bitcoin-ml] Can we decide on a roadmap now?

Gal Buki jkl at torus.ch
Mon Sep 4 11:40:29 UTC 2017


Hi

> I think major drawbacks from having a single roadmap is creating tension
> within the community and stiffle innovation, and it will be Bitcoin Core
> all over again.

I think the opposite is true.
If everyone does his own thing and invests months/years, the investment
(financially and personal) might be too big to just back off and it will
lead to tension between the teams.

I would argue that for consensus relevant features a community wide agreed
upon roadmap is necessary.
Features that do not change the consensus rules do not need to be agreed
upon in advance and here I indeed see more innovation.

The problem with Bitcoin Core was that they had their own roadmap
(including consensus rules) and did not listened to other teams. This
should be avoided.

> If the users/miners/businesses want something that
> not a single implementation has, there will be a software fork to get
> that, or implementations will adapt.

If e.g. 3 out of 4 implementations have the same feature this might work.
But once we have 2 or 3 different approaches it could again lead to a long
fight where the only winner are other coins.

--
Gal

On Mon, September 4, 2017 8:03 am, Erik Hedman via bitcoin-ml wrote:
> Do we really need a community wide roadmap for software features? As I
> see it, to not have a roadmap for all, not need to find consensus for
> all software features and not having a reference implementation is a
> major feature.
>
> I think major drawbacks from having a single roadmap is creating tension
> within the community and stiffle innovation, and it will be Bitcoin Core
> all over again.
>
> Let the different software implementations implement what they see fit.
> The implementation with the features the users/miners/businesses want
> will gain majority. If the users/miners/businesses want something that
> not a single implementation has, there will be a software fork to get
> that, or implementations will adapt.
>
> As I see it, the thing we need to agree on, is that if you have a
> feature that you want implemented, you do proper documentation for
> others to use and be able to implement from.
>
>
>
>
>
>
> Den Sön 3 sep 2017 kl 22:30 skrev Mirco Romanato via bitcoin-ml:
>> Il 02/09/2017 23:42, Tom Zander via bitcoin-ml ha scritto:
>>
>> > The reason I object to a SMF is simply because this is a problem that
>> has
>> > been known for over 6 years. Everyone in Bitcoin works around it. Yes,
>> it
>> > should be fixed eventually.
>> > At this point nobody gains by pushing out a quick fix.
>> > Especially since it doesn't actually fix things for all transactions,
>> just
>> > new transactions.
>>
>> Small question and suggestion:
>>
>> 1) How far away is Child Pay For Parents (CPFP) in Unlimited / Classic /
>> ABC?
>>
>> 2) If we have CPFP how much work is needed to have the wallet to create
>> an unmalleable "zero-fee tx spent by a fee paying tx"?
>>
>> This is the only "Quick fix" to malleability we should have right now.
>> It doesn't change formats, no new transaction type, can be done without
>> changing any consensus rule I know about.
>>
>> After this "fix" is out, we will see what real demand for unmalleable
>> transactions is there.
>>
>> If LN can someway work without a malleability fix, I suppose it can work
>> with this fix also. Then, if this fix is not enough, more reasons to
>> push for a comprehensive fix of malleability.
>>
>> --
>> Mirco Romanato
>>
>> --
>> Mirco Romanato
>>
>> ---
>> Questa email è stata esaminata alla ricerca di virus da AVG.
>> http://www.avg.com
>>
>> _______________________________________________
>> bitcoin-ml mailing list
>> bitcoin-ml at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
> _______________________________________________
> bitcoin-ml mailing list
> bitcoin-ml at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml
>




More information about the bitcoin-ml mailing list