Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2014-12-29 📝 Original message:On Monday, December 29, ...
📅 Original date posted:2014-12-29
📝 Original message:On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
This is something I've wanted since 2011, but hasn't been a priority.
> Because sometime in the future (maybe 5-10 years) we may have to deal
> with problems of securing the blockchain, as the subsidy is lowered. We
> don't want the number of confirmation blocks to be increased in
> compensation because Bitcoin won't be able to compete with other payment
> networks.
> Then by having this hardfork now, we will be able to soft-fork later to
> any rule we may came come up with involving deposit bonds,
> proof-of-stake, and the penalization of double-mining (mining two blocks
> at the same height) to prevent short-range attacks.
I'm not sure this increases the priority of it.
If someone feels it's worth the time, I'd suggest coding up a branch that
hardforks it in at some far-off block height. Even if it doesn't get merged
right away, at least the code will be available for testing and ready to go
when/if that time comes.
Luke
📝 Original message:On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
This is something I've wanted since 2011, but hasn't been a priority.
> Because sometime in the future (maybe 5-10 years) we may have to deal
> with problems of securing the blockchain, as the subsidy is lowered. We
> don't want the number of confirmation blocks to be increased in
> compensation because Bitcoin won't be able to compete with other payment
> networks.
> Then by having this hardfork now, we will be able to soft-fork later to
> any rule we may came come up with involving deposit bonds,
> proof-of-stake, and the penalization of double-mining (mining two blocks
> at the same height) to prevent short-range attacks.
I'm not sure this increases the priority of it.
If someone feels it's worth the time, I'd suggest coding up a branch that
hardforks it in at some far-off block height. Even if it doesn't get merged
right away, at least the code will be available for testing and ready to go
when/if that time comes.
Luke