Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D35B371 for ; Tue, 25 Oct 2016 16:39:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68982149 for ; Tue, 25 Oct 2016 16:39:41 +0000 (UTC) Received: by mail-qk0-f175.google.com with SMTP id z190so263433904qkc.2 for ; Tue, 25 Oct 2016 09:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gwZvBz1xHqSKPg9f596yZR4YycOVkg7KaWu42wFGGRY=; b=rY08Nj2I/XD4uplNz5jRR9h7Sp2TOfylOp24OQWhFkaRpleYvykQI5IA2M8c4FvWY1 xO9yVpdLzPKzX+qNG0/KSNGJJJPXcwRI5qlB4/z9tUdV8nAPQLf48eSpIcIxC10W3L03 7PMdOEOL9gbjBCmNE0IGV4yl3kY5yv8BLoM+1VIxGQB6zKM4funiFgnZpiJxyKuCINNQ EkG4eLdwJ87DgPkS/E+55S49tTX5nCELx65DVa9N+rHincaXHrlaXNiZjVPU2StfrYiR AWJkF4gDqm91IkJsdGiGdvcr5GpfWB5WYGl9Y1rQ30/vTfBwF33Sgxlsxxa66HYK7Q49 S6eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gwZvBz1xHqSKPg9f596yZR4YycOVkg7KaWu42wFGGRY=; b=bWAOTQNNq5CJe/XfMgqtJ+9abF0OcakWWnPUD6ixHbFhuYTERNhwgwXQ1m8JjLzxFQ Q2mQH2lPesxHZYC9OXkQCiCUi3X8UCS2jHXvlg2qg5dzVOlOWu5AAcFg291v6DQ8q4vN 3XwkwjBa8KwWaIRwjLH0/joGHcdGJrd2MGCqLrlgb97Xys4VfLA1IpfInFLvIXQKHyF6 FPWtS82+vYwCWFA45qAwwtle77++ykqjzsl1BX2uKPDEQBj8EwbWBef/bgDpkT7KTMtb oM8c4O9yq4TigXGDFTCUX8pDvh8g7/O+a3B64+6cLKns769gPcZ62VYl19cpnPfX444i VaXg== X-Gm-Message-State: ABUngvc/G8lBaIYpMzgQiLi8I3AXqdZnHwyl+T3us8FR+5lxwtabjxeY/Y03gPxMI8yco5uOavgRqOWM140g0w== X-Received: by 10.55.135.1 with SMTP id j1mr19586680qkd.46.1477413580435; Tue, 25 Oct 2016 09:39:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.35.7 with HTTP; Tue, 25 Oct 2016 09:38:59 -0700 (PDT) In-Reply-To: <157f7c47e65.afdd12df33806.8370403107286597157@xbt.hk> References: <157f7c47e65.afdd12df33806.8370403107286597157@xbt.hk> From: Sergio Demian Lerner Date: Tue, 25 Oct 2016 13:38:59 -0300 Message-ID: To: Johnson Lau Content-Type: multipart/alternative; boundary=94eb2c073c10a5fae3053fb32717 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev Subject: Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 16:39:43 -0000 --94eb2c073c10a5fae3053fb32717 Content-Type: text/plain; charset=UTF-8 Responding between lines... On Mon, Oct 24, 2016 at 2:37 PM, Johnson Lau wrote: > Some comments and questions > > 1. In the BIP you mentioned scriptSig 3 times, but I don't think you are > really talking about scriptSig. Especially, segwit has aborted the use of > scriptSig to fix malleability. From the context I guess you mean > redeemScript (see BIP141) > You're right.I will change the naming asap. > > 2. It seems that 51% of miners may steal all money from the peg, right? > But I think this is unavoidable for all 2-way-peg proposals. To make it > safer you still need notaries. > Correct, that's inherently a technical limitation. However, there can be many deterrents from miners stealing money (legal contracts, mutual-assured-destruction states). Aslo as you mention, you can combine OP_COUNT_ACK with notary sigantures as AND/OR or a more complex acknowledge weight distribution. > > 3. Instead of using a OP_NOPx, I suggest you using an unused code such as > 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that > does not write to the stack. > Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit versioning allows to create new opcode multiplexing opcodes, so I was thinking about adding an "opcode index" to a more generic OP_OPERATE. But that prevents using all NOP space, but prevents easily counting OP_ACK_COUNT for checksig block limit. > 4. I don't think you should simply replace "(witversion == 0)" with > "((witversion == 0) || (witversion == 1))". There are only 16 available > versions. It'd be exhausted very soon if we use a version for every new > opcode. As a testing prototype this is fine, but the actual softfork should > not waste a witversion this way. We need a better way to coordinate the use > of new witness version. BIP114 suggests an additional field in the witness > to indicate the script version (https://github.com/bitcoin/ > bips/blob/master/bip-0114.mediawiki) > > Good. But currently that version is not enforced, so this BIP cannot make use of it. I can use (witversion == 1) but add the BIP114 version field so that the next BIP can make use of it. > 5. It seems this is the first BIP in markdown format, not mediawiki (but > this is allowed by BIP1) > > 6. The coinbase space is limited to 100 bytes and is already overloaded by > many different purposes. I think any additional consensus critical message > should go to a dummy scriptPubKey like the witness commitment. You may > consider to have a new OP_RETURN output like BIP141, with different magic > bytes. However, please don't make this output mandatory (cf. witness > commitment output is optional if the block does not have witness tx) > > 6a. "..........due to lack of space to include the proper ack tag in a > block": this shouldn't happen if you use a OP_RETURN output > > I'm not sure about this. The fact that the space for acknowledge and proposal is short has been seen by other developers a benefit and not a drawback. It prevent hundreds of sidechains to be offered, which might hurt solo miners. 70 bytes allows for approximately 10 active polls. > 7. "It can be the case that two different secondary blockchains specify > the same transaction candidate, but **at least** one of them will clearly > be unauthentic." > > thnks. 8. Question: is an ack-poll valid only for 1 transaction? When the > transaction is confirmed, could full nodes prune the corresponding ack-poll > data? (I think it has to be prunable after spending because ack-poll data > is effectively UTXO data) > > Yes, there is no ack-poll data stored except for the coinbase field cache, which periodically cleans itself by using a FIFO approach. > 9. No matter how you design a softfork, "Zero risk of invalidating a > block" couldn't be true for any softfork. For example, even if a miner does > not include any txs with OP_COUNT_ACKS, he may still build on top of blocks > with invalid OP_COUNT_ACKS operations. > > I'm not sure. I assumed that transactions redeeming a script using OP_COUNT_ACKS would be non-standard, so the the problem you point out would only happen if the block including the transaction would be mined specifically for the purpose to defeat subsequent miners. A honest pre-fork miner would never include a redeemScript that that verifies an OP_COUNT_ACKS, since that transaction would never be received by the p2p protocol (it could if the miner accepts non-standard txs by a different channnel). But I must check this in the BIP source code if OP_COUNT_ACKS is really non-standard as I designed it to be. (Thanks Jonhson Lau for taking the time to analyze the BIP.) Sergio. > ---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via > bitcoin-dev wrote ---- > > Since ScalingBitcoin is close, I think this is a good moment to publish > our proposal on drivechains. This BIP proposed the drivechain we'd like to > use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it > implemented in Bitcoin. Until that happens, we're using a federated > approach. > > I'm sure that adding risk-less Bitcoin extensibility through > sidechains/drivechains is what we all want, but it's of maximum importance > to decide which technology will leads us there. > > We hope this work can also be the base of all other new 2-way-pegged > blockchains that can take Bitcoin the currency to new niches and test new > use cases, but cannot yet be realized because of current > limitations/protections. > > > > The full BIP plus a reference implementation can be found here: > > > > BIP (draft): > > https://github.com/rootstock/bips/blob/master/BIP-R10.md > > > > Code & Test cases: > > https://github.com/rootstock/bitcoin/tree/op-count-acks_devel > > (Note: Code is still unaudited) > > > > As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forked > opcode that counts acks and nacks tags in coinbase fields, and push the > resulting totals in the script stack. > > > > The system was designed with the following properties in mind: > > > > 1. Interoperability with scripting system > > 2. Zero risk of invalidating a block > > 3. No additional computation during blockchain management and > re-organization > > 4. No change in Bitcoin security model > > 5. Bounded computation of poll results > > 6. Strong protection from DoS attacks > > 7. Minimum block space consumption > > 8. Zero risk of cross-secondary chain invalidation > > > > Please see the BIP draft for a more-detailed explanation on how we > achieve these goals. > > > > I'll be in ScalingBitcoin in less than a week and I'll be available to > discuss the design rationale, improvements, changes and ideas any of you > may have. > > > > Truly yours, > > Sergio Demian Lerner > > Bitcoiner and RSK co-founder > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > --94eb2c073c10a5fae3053fb32717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Responding between lines...

On Mon, Oct 24, 2016 at 2:37 PM, Johnso= n Lau <jl2012@xbt.hk> wrote:
Some comments and questions

1. In the BIP you mentioned scriptSig 3 times, but I don't think you ar= e really talking about scriptSig. Especially, segwit has aborted the use of= scriptSig to fix malleability. From the context I guess you mean redeemScr= ipt (see BIP141)

You're right.I wil= l change the naming asap.
=C2=A0

2. It seems that 51% of miners may steal all money from the peg, right? But= I think this is unavoidable for all 2-way-peg proposals. To make it safer = you still need notaries.

Correct, that&= #39;s inherently a technical limitation. However, there can be many deterre= nts from miners stealing money (legal contracts, mutual-assured-destruction= states). Aslo as you mention, you can combine OP_COUNT_ACK with notary sig= antures as AND/OR or a more complex acknowledge weight distribution.
=C2= =A0

3. Instead of using a OP_NOPx, I suggest you using an unused code such as 0= xba. OP_NOPx should be reserved for some simple "VERIFY"-type cod= es that does not write to the stack.

Ok= . I'm not sure, but if everyone agrees to it, I will. Also Segwit versi= oning allows to create new opcode multiplexing opcodes, so I was thinking a= bout adding an "opcode index" to a more generic OP_OPERATE. But t= hat prevents using all NOP space, but prevents easily counting OP_ACK_COUNT= for checksig block limit.


4. I don't think you should simply replace "(witversion =3D=3D 0)&= quot; with "((witversion =3D=3D 0) || (witversion =3D=3D 1))". Th= ere are only 16 available versions. It'd be exhausted very soon if we u= se a version for every new opcode. As a testing prototype this is fine, but= the actual softfork should not waste a witversion this way. We need a bett= er way to coordinate the use of new witness version. BIP114 suggests an add= itional field in the witness to indicate the script version (https://github.com/bitcoin/bips/blob/master/bip= -0114.mediawiki)

Good. But currently that version is not enforced, so = this BIP cannot make use of it. I can use (witversion =3D=3D 1) but add the= BIP114 version field so that the next BIP can make use of it.

=C2= =A0
5. It seems this is the first BIP in markdown format, not mediawiki (but th= is is allowed by BIP1)=C2=A0=C2=A0

6. The coinbase space is limited to 100 bytes and is already overloaded by = many different purposes. I think any additional consensus critical message = should go to a dummy scriptPubKey like the witness commitment. You may cons= ider to=C2=A0 have a new OP_RETURN output like BIP141, with different magic= bytes. However, please don't make this output mandatory (cf. witness c= ommitment output is optional if the block does not have witness tx)

6a. "..........due to lack of space to include the proper ack tag in a= block": this shouldn't happen if you use a OP_RETURN output

I'm not sure about this. The fact that the space = for acknowledge and proposal is short has been seen by other developers a b= enefit and not a drawback. It prevent hundreds of sidechains to be offered,= which might hurt solo miners. 70 bytes allows for approximately 10 active = polls.
=C2=A0
=C2=A0
7.=C2=A0 "It can be the case that two different secondary blockchains = specify the same transaction candidate, but **at least** one of them will c= learly be unauthentic."

thnks.

8. Question: is an ack-poll valid only for 1 transaction? When the transact= ion is confirmed, could full nodes prune the corresponding ack-poll data? (= I think it has to be prunable after spending because ack-poll data is effec= tively UTXO data)

Yes, there is no ack-poll data stored except for the = coinbase field cache, which periodically cleans itself by using a FIFO appr= oach.
=C2=A0
=C2=A0
9. No matter how you design a softfork, "Zero risk of invalidating a b= lock" couldn't be true for any softfork. For example, even if a mi= ner does not include any txs with OP_COUNT_ACKS, he may still build on top = of blocks with invalid OP_COUNT_ACKS operations.

I'm not sure. I assumed that transactions redeemi= ng a script using OP_COUNT_ACKS=C2=A0 would be non-standard, so the the pro= blem you point out would only happen if the block including the transaction= would be mined specifically for the purpose to defeat subsequent miners. A= honest pre-fork miner would never include a redeemScript that that verifie= s an OP_COUNT_ACKS, since that transaction would never be received by the p= 2p protocol (it could if the miner accepts non-standard txs by a different = channnel). =C2=A0

But I must check this in the BIP source code if O= P_COUNT_ACKS is really non-standard as I designed it to be.

(Thanks Jonhson Lau for taking the time to analyze the BIP.)

Sergio.

=C2=A0
=C2=A0---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via bitc= oin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote ----
=C2=A0> Since Scalin= gBitcoin is close, I think this is a good moment to publish our proposal on= drivechains. This BIP proposed the drivechain we'd like to use in RSK = (a.k.a. Rootstock) two-way pegged blockchain and see it implemented in Bitc= oin. Until that happens, we're using a federated approach.
=C2=A0> I'm sure that adding risk-less Bitcoin extensibility through= sidechains/drivechains is what we all want, but it's of maximum import= ance to decide which technology will leads us there.
=C2=A0> We hope this work can also be the base of all other new 2-way-pe= gged blockchains that can take Bitcoin the currency to new niches and test = new use cases, but cannot yet be realized because of current limitations/pr= otections.
=C2=A0>
=C2=A0> The full BIP plus a reference implementation can be found here:<= br> =C2=A0>
=C2=A0> BIP (draft):
=C2=A0> https://github.com/rootstock/bips/blob/master/BIP-R10.md
=C2=A0>
=C2=A0> Code & Test cases:
=C2=A0> https://github.com/rootstock= /bitcoin/tree/op-count-acks_devel
=C2=A0> (Note: Code is still unaudited)
=C2=A0>
=C2=A0> As a summary, OP_COUNT_ACKS is a new segwit-based and soft-forke= d opcode that counts acks and nacks tags in coinbase fields, and push the r= esulting totals in the script stack.
=C2=A0>
=C2=A0> The system was designed with the following properties in mind: =C2=A0>
=C2=A0> 1. Interoperability with scripting system
=C2=A0> 2. Zero risk of invalidating a block
=C2=A0> 3. No additional computation during blockchain management and re= -organization
=C2=A0> 4. No change in Bitcoin security model
=C2=A0> 5. Bounded computation of poll results
=C2=A0> 6. Strong protection from DoS attacks
=C2=A0> 7. Minimum block space consumption
=C2=A0> 8. Zero risk of cross-secondary chain invalidation
=C2=A0>
=C2=A0> Please see the BIP draft for a more-detailed explanation on how = we achieve these goals.
=C2=A0>
=C2=A0> I'll be in ScalingBitcoin in less than a week and I'll b= e available to discuss the design rationale, improvements, changes and idea= s any of you may have.
=C2=A0>
=C2=A0> Truly yours,
=C2=A0> Sergio Demian Lerner
=C2=A0> Bitcoiner and RSK co-founder
=C2=A0>
=C2=A0>= =C2=A0 _______________________________________________
=C2=A0> bitcoin-dev mailing list
=C2=A0> bitcoin= -dev@lists.linuxfoundation.org
=C2=A0> https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
=C2=A0>



--94eb2c073c10a5fae3053fb32717--