jl2012 at xbt.hk [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-07 📝 Original message:This looks very ...
📅 Original date posted:2016-02-07
📝 Original message:This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.
Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation threshold of consensus rule changes.
For the witness commitment, it will also be treated as a merge mined
commitment?
It is also good to emphasize that it is the responsibility of miners, not
devs, to ensure that the hardfork is accepted by the supermajority of the
economy.
-----Original Message-----
From: bitcoin-dev-bounces at lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Luke
Dashjr via bitcoin-dev
Sent: Sunday, 7 February, 2016 17:53
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] Pre-BIP Growth Soft-hardfork
Here's a draft BIP I wrote almost a year ago. I'm going to look into
revising and completing it soon, and would welcome any suggestions for doing
so.
This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
vulnerable to attack.
https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki
Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.
Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation threshold of consensus rule changes.
For the witness commitment, it will also be treated as a merge mined
commitment?
It is also good to emphasize that it is the responsibility of miners, not
devs, to ensure that the hardfork is accepted by the supermajority of the
economy.
-----Original Message-----
From: bitcoin-dev-bounces at lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Luke
Dashjr via bitcoin-dev
Sent: Sunday, 7 February, 2016 17:53
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] Pre-BIP Growth Soft-hardfork
Here's a draft BIP I wrote almost a year ago. I'm going to look into
revising and completing it soon, and would welcome any suggestions for doing
so.
This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
vulnerable to attack.
https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki
Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev