Chris Stewart [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-30 📝 Original message:>I don't understand this ...
📅 Original date posted:2017-06-30
📝 Original message:>I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
Maybe I am misunderstanding you, but isn't this a flaw not a feature? What
if a attacker pays a large fee to have his *invalid* block hash included in
the bitcoin mainchain? Would this block *have* to be included in the
sidechain's blockchain forever since *it was* included in bitcoin
blockchain?
>Do you not provide a single sidechain's h* twice in the block? Once in
the coinbase and once in the briber's separate transaction?
Yes, my BIP proposal does this.
>In my scheme at least there is no indicator byte -- the "previous block"
hash is the indicator of which sidechain it is extending. From your other
emails on this list, it seems the ratchet is for withdrawals from sidechain
to mainchain? If so, should it not only appear in only some of the
sidechains (the ones which are currently doing some withdrawal?)?
Maybe I am missing something here, but why we do *explicitly* commit to the
previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
If a drivechain node tries to sync the drivechain from bitcoin's commitment
headers, it will invalidate that block since
the block hash does not correctly reference the previous block hash. AFAICT
there is no need to explicitly specify the previous block hash in the OP_BV
output. In general, I don't think we should assume these commitment headers
dictate the strict ordering of blocks on the sidechain -- only potential
blocks that
*might* be valid. To guarantee full validity drivechain nodes will have to
download the full block and figure out if they follow all of the consensus
rules.
This is sort of like headers first sync in bitcoin core:
https://bitcoin.org/en/developer-guide#headers-first
-Chris
On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good Morning Paul,
>
> >It seems that, in your version, the "bribers" would react to the scheme
> >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
> >fee per Kb) is low.
> >
> >In short, there would be many bribe-attempts (each of which would take
> >up space in mainchain blocks), almost all of which would be unsuccessful.
> >
> >In turn, miners would likely react to this, and try to improve the state
> >of affairs by offering users the privilege of occupying transaction slot
> >#2 (ie, the one right after the coinbase). Users would need to trust
> >miners for this, which introduces a cost friction which is pure
> >deadweight loss. And, it might be easier for larger/older miners to be
> >trustworthy than smaller/newer ones.
>
> I understand.
>
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part. In my scheme, a sidechain cannot reorganize
> unless the mainchain reorganizes, since the consensus loop only cares about
> matching the current block; it ignores splits and does not consider them
> valid.
>
> But I suppose you are considering something like the Ethereum mutability
> feature, which I do not think is something you would want in a sidechain.
>
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block? Once in
> the coinbase and once in the briber's separate transaction?
>
> In my scheme at least there is no indicator byte -- the "previous block"
> hash is the indicator of which sidechain it is extending. From your other
> emails on this list, it seems the ratchet is for withdrawals from sidechain
> to mainchain? If so, should it not only appear in only some of the
> sidechains (the ones which are currently doing some withdrawal?)?
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170630/fdacfffe/attachment-0001.html>;
📝 Original message:>I don't understand this part. In my scheme, a sidechain cannot reorganize
unless the mainchain reorganizes, since the consensus loop only cares about
matching the current block; it ignores splits and does not consider them
valid.
Maybe I am misunderstanding you, but isn't this a flaw not a feature? What
if a attacker pays a large fee to have his *invalid* block hash included in
the bitcoin mainchain? Would this block *have* to be included in the
sidechain's blockchain forever since *it was* included in bitcoin
blockchain?
>Do you not provide a single sidechain's h* twice in the block? Once in
the coinbase and once in the briber's separate transaction?
Yes, my BIP proposal does this.
>In my scheme at least there is no indicator byte -- the "previous block"
hash is the indicator of which sidechain it is extending. From your other
emails on this list, it seems the ratchet is for withdrawals from sidechain
to mainchain? If so, should it not only appear in only some of the
sidechains (the ones which are currently doing some withdrawal?)?
Maybe I am missing something here, but why we do *explicitly* commit to the
previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
If a drivechain node tries to sync the drivechain from bitcoin's commitment
headers, it will invalidate that block since
the block hash does not correctly reference the previous block hash. AFAICT
there is no need to explicitly specify the previous block hash in the OP_BV
output. In general, I don't think we should assume these commitment headers
dictate the strict ordering of blocks on the sidechain -- only potential
blocks that
*might* be valid. To guarantee full validity drivechain nodes will have to
download the full block and figure out if they follow all of the consensus
rules.
This is sort of like headers first sync in bitcoin core:
https://bitcoin.org/en/developer-guide#headers-first
-Chris
On Thu, Jun 29, 2017 at 11:00 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good Morning Paul,
>
> >It seems that, in your version, the "bribers" would react to the scheme
> >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
> >fee per Kb) is low.
> >
> >In short, there would be many bribe-attempts (each of which would take
> >up space in mainchain blocks), almost all of which would be unsuccessful.
> >
> >In turn, miners would likely react to this, and try to improve the state
> >of affairs by offering users the privilege of occupying transaction slot
> >#2 (ie, the one right after the coinbase). Users would need to trust
> >miners for this, which introduces a cost friction which is pure
> >deadweight loss. And, it might be easier for larger/older miners to be
> >trustworthy than smaller/newer ones.
>
> I understand.
>
> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
> >do anything to refund the briber, if the sidechain (but not the
> >mainchain) reorganizes (as it can easily do, if an older sidechain
> >parent is extended while the mainchain proceeds normally). This creates
> >additional risk.
>
> I don't understand this part. In my scheme, a sidechain cannot reorganize
> unless the mainchain reorganizes, since the consensus loop only cares about
> matching the current block; it ignores splits and does not consider them
> valid.
>
> But I suppose you are considering something like the Ethereum mutability
> feature, which I do not think is something you would want in a sidechain.
>
> >I think mine is also much more space-efficient. Even if ours each had
> >exactly one h* per sidechain per block, it seems that I only require one
> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
> >for the ratchet), whereas you require two. Since its overhead per
> >sidechain per block, it actually might really add up.
>
> Do you not provide a single sidechain's h* twice in the block? Once in
> the coinbase and once in the briber's separate transaction?
>
> In my scheme at least there is no indicator byte -- the "previous block"
> hash is the indicator of which sidechain it is extending. From your other
> emails on this list, it seems the ratchet is for withdrawals from sidechain
> to mainchain? If so, should it not only appear in only some of the
> sidechains (the ones which are currently doing some withdrawal?)?
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170630/fdacfffe/attachment-0001.html>;