Chris Stewart [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-13 📝 Original message:I'm interested in hearing ...
📅 Original date posted:2017-07-13
📝 Original message:I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
about lightning bribes. I hadn't given much thought about those while
writing my original BIP, but it does seem like my original BIP (minus the
fixed indexes in the coinbase output) fits this pretty well. If I
understand Paul correctly the OP_BV output will never hit the blockchain
then -- only the commitment in the coinbase transaction. This means no
extra data (if use lightning) has to be added to the blockchain *except*
the drivechain commitment (34 bytes in the coinbase tx vout). If this is
used for the vast majority bribes it may make the op code worth it.
In general though, I'm still unclear of what purpose the 'Ratchet' serves.
Can you either link to documentation about it or write something up quick?
-Chris
On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> I still think it may be more inefficient, in equilibrium. (In other words,
> in the future steady state of Bitcoin that includes LN or something
> LN-like).
>
> Assume there are N sidechains.
>
> In the coinbase version:
> 1. There is some single event, per N, that causes nodes to notice that a
> new sidechain has been created.
> 2. Per block, there are N hash commitments (32 bytes) and N instances of
> the ratchet's block counter (2 bytes).
> 3. Per block, some node operator _may_ have BMMed the block, and a miner
> therefore might want redeem an OP Bribe that pays BTC from a sidechain node
> operator to the miner. But they are likely to negotiate the payment through
> the Lightning Network (when this is possible).
> 4. Sidechains running in SPV mode know exactly where to find the
> information they need in order to discover the "longest" chain.
>
> In the OP RETURN version:
> 1. [same] There is some single event, per N, that causes nodes to notice
> that a new sidechain has been created.
> 2. [+30 bytes (+more?)] Per block, there are N hash commitments (32 bytes)
> and also N prevBlockHashes (32 bytes). Also, to make this transaction,
> someone needs to spend something in the UTXO set (or select no inputs in a
> kind of 'hollow transaction'), whereas one coinbase will always exist per
> block.
> 3. [same] No need for a new transaction.
> 4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain per
> block, sidechains need just a merkle tree path, but they don't necessarily
> know where it is. They must store extra [?] data to help them find the
> data's location?
>
>
> On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
>
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
>
> I think that that is the purpose of Rusty's soft fork rule about only
> including one per sidechain -- miners would have one "slot" per sidechain,
> and they would therefore have an incentive to make the slot count, and
> would be only selecting the highest fee txn to fill each slot.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/7914e30b/attachment.html>;
📝 Original message:I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think
about lightning bribes. I hadn't given much thought about those while
writing my original BIP, but it does seem like my original BIP (minus the
fixed indexes in the coinbase output) fits this pretty well. If I
understand Paul correctly the OP_BV output will never hit the blockchain
then -- only the commitment in the coinbase transaction. This means no
extra data (if use lightning) has to be added to the blockchain *except*
the drivechain commitment (34 bytes in the coinbase tx vout). If this is
used for the vast majority bribes it may make the op code worth it.
In general though, I'm still unclear of what purpose the 'Ratchet' serves.
Can you either link to documentation about it or write something up quick?
-Chris
On Wed, Jul 12, 2017 at 7:00 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> I still think it may be more inefficient, in equilibrium. (In other words,
> in the future steady state of Bitcoin that includes LN or something
> LN-like).
>
> Assume there are N sidechains.
>
> In the coinbase version:
> 1. There is some single event, per N, that causes nodes to notice that a
> new sidechain has been created.
> 2. Per block, there are N hash commitments (32 bytes) and N instances of
> the ratchet's block counter (2 bytes).
> 3. Per block, some node operator _may_ have BMMed the block, and a miner
> therefore might want redeem an OP Bribe that pays BTC from a sidechain node
> operator to the miner. But they are likely to negotiate the payment through
> the Lightning Network (when this is possible).
> 4. Sidechains running in SPV mode know exactly where to find the
> information they need in order to discover the "longest" chain.
>
> In the OP RETURN version:
> 1. [same] There is some single event, per N, that causes nodes to notice
> that a new sidechain has been created.
> 2. [+30 bytes (+more?)] Per block, there are N hash commitments (32 bytes)
> and also N prevBlockHashes (32 bytes). Also, to make this transaction,
> someone needs to spend something in the UTXO set (or select no inputs in a
> kind of 'hollow transaction'), whereas one coinbase will always exist per
> block.
> 3. [same] No need for a new transaction.
> 4. [same?] Due to Rusty's soft fork rule of only one h* per sidechain per
> block, sidechains need just a merkle tree path, but they don't necessarily
> know where it is. They must store extra [?] data to help them find the
> data's location?
>
>
> On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:
>
> Hi Russell/ZmnSCPxj,
>
> I think you guys are right. The only problem I can see with it is
> replaceability of the bribe transaction. If the 'Bribe' is the fee on the
> transaction it isn't clear to me what the best way to replace/remove it is.
>
>
> I think that that is the purpose of Rusty's soft fork rule about only
> including one per sidechain -- miners would have one "slot" per sidechain,
> and they would therefore have an incentive to make the slot count, and
> would be only selecting the highest fee txn to fill each slot.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/7914e30b/attachment.html>;