Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-22 📝 Original message:On Mon, May 22, 2017 at ...
📅 Original date posted:2017-05-22
📝 Original message:On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
Thanks for the credit, although I think the security properties of what you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.
As you state in [2] "if miners never validate sidechains at all, whoever bids
the most for the chain (on a continuous basis), can spam a 3-month long stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of telling
who “should” really get the funds."
Finally, you suggest that in this event, miners *do* have to upgrade to a full
node, an expensive and time-consuming operation (and one that may be impossible
for some miners if necessary data isn't available).
It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/c4d63e2f/attachment.sig>;
📝 Original message:On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
Thanks for the credit, although I think the security properties of what you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.
As you state in [2] "if miners never validate sidechains at all, whoever bids
the most for the chain (on a continuous basis), can spam a 3-month long stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of telling
who “should” really get the funds."
Finally, you suggest that in this event, miners *do* have to upgrade to a full
node, an expensive and time-consuming operation (and one that may be impossible
for some miners if necessary data isn't available).
It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/c4d63e2f/attachment.sig>;