diff options
| author | Sergio Demian Lerner <sergio.d.lerner@gmail.com> | 2016-10-25 13:38:59 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-10-25 16:39:42 +0000 |
| commit | 743db6dc41d3232d84d68d5327739fae2460318e (patch) | |
| tree | 2458857929e6f76077727eee54d69467328f2aca | |
| parent | ae581e66525136edd452a30fa82f4c97a00d8fae (diff) | |
| download | pi-bitcoindev-743db6dc41d3232d84d68d5327739fae2460318e.tar.gz pi-bitcoindev-743db6dc41d3232d84d68d5327739fae2460318e.zip | |
Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS
| -rw-r--r-- | e5/662ba11bb616ec73ccc98c75fbd55780f47c11 | 429 |
1 files changed, 429 insertions, 0 deletions
diff --git a/e5/662ba11bb616ec73ccc98c75fbd55780f47c11 b/e5/662ba11bb616ec73ccc98c75fbd55780f47c11 new file mode 100644 index 000000000..62739a74e --- /dev/null +++ b/e5/662ba11bb616ec73ccc98c75fbd55780f47c11 @@ -0,0 +1,429 @@ +Return-Path: <sergio.d.lerner@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D35B371 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 25 Oct 2016 16:39:41 +0000 (UTC) +Received: by mail-qk0-f175.google.com with SMTP id z190so263433904qkc.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAKzdR-rsy1m-H4fYFuCim5+YJi_C2kgjxymM8A7_nEuqsZoO+g@mail.gmail.com> + <157f7c47e65.afdd12df33806.8370403107286597157@xbt.hk> +From: Sergio Demian Lerner <sergio.d.lerner@gmail.com> +Date: Tue, 25 Oct 2016 13:38:59 -0300 +Message-ID: <CAKzdR-pDduY_iLkGJVvux2MkP15T5CSZa6HTTqHPBULYKGNxqA@mail.gmail.com> +To: Johnson Lau <jl2012@xbt.hk> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jl2012@xbt.hk> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 + +<div dir=3D"ltr">Responding between lines...<br><div><div class=3D"gmail_ex= +tra"><br><div class=3D"gmail_quote">On Mon, Oct 24, 2016 at 2:37 PM, Johnso= +n Lau <span dir=3D"ltr"><<a href=3D"mailto:jl2012@xbt.hk" target=3D"_bla= +nk">jl2012@xbt.hk</a>></span> wrote:<br><blockquote class=3D"gmail_quote= +" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= +padding-left:1ex">Some comments and questions<br> +<br> +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)<br></blockquote><div><br></div><div>You're right.I wil= +l change the naming asap.<br>=C2=A0<br></div><blockquote class=3D"gmail_quo= +te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= +);padding-left:1ex"> +<br> +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.<br></blockquote><div><br></div><div>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.<br>=C2= +=A0 <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= + 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +<br> +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.<br></blockquote><div><br></div><div>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.<br><br></div><blockquote class=3D"gmail_quote" s= +tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= +ding-left:1ex"> +<br> +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 (<a href=3D"htt= +ps://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki" rel=3D"norefer= +rer" target=3D"_blank">https://github.com/bitcoin/<wbr>bips/blob/master/bip= +-0114.<wbr>mediawiki</a>)<br> +<br></blockquote><div>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.<br><br>=C2= +=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = +0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> +5. It seems this is the first BIP in markdown format, not mediawiki (but th= +is is allowed by BIP1)=C2=A0=C2=A0<br></blockquote><blockquote class=3D"gma= +il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= +04,204);padding-left:1ex"> +<br> +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)<br> +<br> +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<br> +<br></blockquote><div>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.<br>=C2=A0<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style= +=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= +-left:1ex"> +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."<br> +<br></blockquote><div>thnks. <br><br></div><blockquote class=3D"gmail_quote= +" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= +padding-left:1ex"> +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)<br> +<br></blockquote><div>Yes, there is no ack-poll data stored except for the = +coinbase field cache, which periodically cleans itself by using a FIFO appr= +oach.<br>=C2=A0<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"= + style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= +adding-left:1ex"> +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.<br> +<br></blockquote><div>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 <br><br>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.<br><br></div><d= +iv>(Thanks Jonhson Lau for taking the time to analyze the BIP.)<br><br></di= +v><div>Sergio.<br></div><div><br>=C2=A0<br></div><blockquote class=3D"gmail= +_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= +,204);padding-left:1ex"> +=C2=A0---- On Sun, 02 Oct 2016 23:49:08 +0800 Sergio Demian Lerner via bitc= +oin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi= +n-dev@lists.<wbr>linuxfoundation.org</a>> wrote ----<br> +<div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">=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.<br> +=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.<br> +=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.<br> +=C2=A0><br> +=C2=A0> The full BIP plus a reference implementation can be found here:<= +br> +=C2=A0><br> +=C2=A0> BIP (draft):<br> +=C2=A0> <a href=3D"https://github.com/rootstock/bips/blob/master/BIP-R10= +.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/rootstock/<wbr= +>bips/blob/master/BIP-R10.md</a><br> +=C2=A0><br> +=C2=A0> Code & Test cases:<br> +=C2=A0> <a href=3D"https://github.com/rootstock/bitcoin/tree/op-count-ac= +ks_devel" rel=3D"noreferrer" target=3D"_blank">https://github.com/rootstock= +/<wbr>bitcoin/tree/op-count-acks_<wbr>devel</a><br> +=C2=A0> (Note: Code is still unaudited)<br> +=C2=A0><br> +=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.<br> +=C2=A0><br> +=C2=A0> The system was designed with the following properties in mind:<b= +r> +=C2=A0><br> +=C2=A0> 1. Interoperability with scripting system<br> +=C2=A0> 2. Zero risk of invalidating a block<br> +=C2=A0> 3. No additional computation during blockchain management and re= +-organization<br> +=C2=A0> 4. No change in Bitcoin security model<br> +=C2=A0> 5. Bounded computation of poll results<br> +=C2=A0> 6. Strong protection from DoS attacks<br> +=C2=A0> 7. Minimum block space consumption<br> +=C2=A0> 8. Zero risk of cross-secondary chain invalidation<br> +=C2=A0><br> +=C2=A0> Please see the BIP draft for a more-detailed explanation on how = +we achieve these goals.<br> +=C2=A0><br> +=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.<br> +=C2=A0><br> +=C2=A0> Truly yours,<br> +=C2=A0> Sergio Demian Lerner<br> +=C2=A0> Bitcoiner and RSK co-founder<br> +=C2=A0><br> +</div></div><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">=C2=A0>= +=C2=A0 ______________________________<wbr>_________________<br> +=C2=A0> bitcoin-dev mailing list<br> +=C2=A0> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin= +-dev@lists.<wbr>linuxfoundation.org</a><br> +=C2=A0> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi= +tcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundati= +on.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +=C2=A0><br> +<br> +<br> +</div></div></blockquote></div><br></div></div></div> + +--94eb2c073c10a5fae3053fb32717-- + |