Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-21 📝 Original message:On Tue, Jul 21, 2015 at ...
📅 Original date posted:2015-07-21
📝 Original message:On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev wrote:
> I still disagree. Using height instead of time may make the
> implementation more complex by requiring some additional preparations
> but using height is in fact a simpler design. Why relay on clocks that
> we know will differ in different computers and places when we have a
> universal tick with every block?
The Bitcoin protocol fundementally uses time in a consensus-critical
manner anyway; miners vote on what time it is via the median time
mechanism.
Triggering events based on median time is compatable with consensus and
gives more human scale predictability as to when events may happen. In
addition the median time is guaranteed to be monotonic by the consensus
rules.
See the version bits proposal for an example of its use:
https://gist.github.com/sipa/bf69659f43e763540550#Specification
Having said that, in general triggering events without verifying a
supermajority of miner support can be very dangerous. Without miner
support the chain is insecure, and can be attacked. For instance a
blocksize limit increase that a majority of miners choose not to
implement raises huge risks of reorg for any miners who attempt to
create large blocks, and huge risks of payment reversal for any
merchants accepting transactions in such blocks. Note how with BIP102,
extending the original Bitcoin chain is inherently an attack on the
Garzik chain.
For that reason I think BIP102 is extremely poorly designed. I can only
conclude that Jeff Garzik is either deliberately trolling us and/or
manipulating discussion with a badly designed proposal that he doesn't
actually expect to be adopted verbatim, or is incompetent.
--
'peter'[:-1]@petertodd.org
0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/46dd463a/attachment.sig>;
📝 Original message:On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev wrote:
> I still disagree. Using height instead of time may make the
> implementation more complex by requiring some additional preparations
> but using height is in fact a simpler design. Why relay on clocks that
> we know will differ in different computers and places when we have a
> universal tick with every block?
The Bitcoin protocol fundementally uses time in a consensus-critical
manner anyway; miners vote on what time it is via the median time
mechanism.
Triggering events based on median time is compatable with consensus and
gives more human scale predictability as to when events may happen. In
addition the median time is guaranteed to be monotonic by the consensus
rules.
See the version bits proposal for an example of its use:
https://gist.github.com/sipa/bf69659f43e763540550#Specification
Having said that, in general triggering events without verifying a
supermajority of miner support can be very dangerous. Without miner
support the chain is insecure, and can be attacked. For instance a
blocksize limit increase that a majority of miners choose not to
implement raises huge risks of reorg for any miners who attempt to
create large blocks, and huge risks of payment reversal for any
merchants accepting transactions in such blocks. Note how with BIP102,
extending the original Bitcoin chain is inherently an attack on the
Garzik chain.
For that reason I think BIP102 is extremely poorly designed. I can only
conclude that Jeff Garzik is either deliberately trolling us and/or
manipulating discussion with a badly designed proposal that he doesn't
actually expect to be adopted verbatim, or is incompetent.
--
'peter'[:-1]@petertodd.org
0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/46dd463a/attachment.sig>;