diff options
| author | Lautaro Dragan <lautarodragan@gmail.com> | 2018-08-15 23:22:21 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-08-16 02:22:35 +0000 |
| commit | 06ad17a58b77d68d96534c940b5fdf71d08c9c41 (patch) | |
| tree | d572d5bcdbc35726d98946628495020b116cc3bb | |
| parent | 427704f9dbd48409724b4fae0cb1ba2271b7618b (diff) | |
| download | pi-bitcoindev-06ad17a58b77d68d96534c940b5fdf71d08c9c41.tar.gz pi-bitcoindev-06ad17a58b77d68d96534c940b5fdf71d08c9c41.zip | |
Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
| -rw-r--r-- | b9/5625e1658cfe9232e89ec58b1b1ee12ef66ba2 | 257 |
1 files changed, 257 insertions, 0 deletions
diff --git a/b9/5625e1658cfe9232e89ec58b1b1ee12ef66ba2 b/b9/5625e1658cfe9232e89ec58b1b1ee12ef66ba2 new file mode 100644 index 000000000..7f04862e7 --- /dev/null +++ b/b9/5625e1658cfe9232e89ec58b1b1ee12ef66ba2 @@ -0,0 +1,257 @@ +Return-Path: <lautarodragan@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id B67FF25A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 16 Aug 2018 02:22:35 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F02441A0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 16 Aug 2018 02:22:34 +0000 (UTC) +Received: by mail-wm0-f51.google.com with SMTP id l2-v6so14353967wme.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 15 Aug 2018 19:22:34 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:reply-to:from:date:message-id + :subject:to:cc; + bh=REvIgGrXTXMzVh/nd0otRAPoe5FdW4u2harYESsM300=; + b=h2d6FCRfh3YgQ8f2vHy7KYbMvXKSq5/8Z84oeX5m1DzQou8NGMi3udIRrmz+l1ZyWJ + MmMmCzLsI1yGPQz2lEVQQDNgJElKw2tLog9QQY6ZlX0uA+ZwQ6q50QS/IFrpVjjABpJA + MgqoRrEsUXT2qdYY3xKM+sPVrYbpumX3UnR9y9GEmZtwTJ+fH4iJZamNaw8FMdUSHn2t + VFc6YTzCjpUySRBY3gWjl9DTEgrPe5QWWjZJ1suMzzyyQduEq/PvvyWh1Sm4Lu/4XsOr + Nqo1Co50Kk9Ll8AjVb8yVx3eFaRB1d2pMC3aOvBJtiDPgBW5c+vGQ8h1glCP0oAvsXaI + MwsA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:reply-to + :from:date:message-id:subject:to:cc; + bh=REvIgGrXTXMzVh/nd0otRAPoe5FdW4u2harYESsM300=; + b=hRxrrBCg+ko5lb9BLvBtqCZFTgFdc3kFkziQRL0LQ3hRglAt4hzyVWW3C9Q2fwcCGD + 9/C3MXKKlrAei9VLNKDEBqv7PPvZls8KO+Gj2ezDy4As+/N0gKhXCMPCNB7/dyO9I5mf + T/P4OPbKJ/1a7ysZSLmvvvVzUILATIQ3UTP5pmE2He5oqyNdexOLM47szsCK8y3HDzDo + 6hS2zpIggEgsc1OgtUQlflLJtsd2Sso1cgAl9+XFpxzo1fRhCEzJNWRINxc5901yELFs + idO62W1bBmCa1uVlkM1FSWyWNGpHILz61XOZPvsE+0TV1AQcBKcEN4+ZlrHhC/0td/dh + 9nYw== +X-Gm-Message-State: AOUpUlFHPBtt91sg5icjp5MLEg8gH6cwoG8q2HXwpw85mLNQajedeb2a + dM2Lus7zk4EnA9/xNOXV9y+sqgXb8s7urSlidEoV1g== +X-Google-Smtp-Source: AA+uWPzEyzWHgwt6IlYNS+peSiR3A02qiSoEIzzGIlBo4q3/MDbkrV4NvgPfGjWiGDNeX4TVBoLtNcZxd44az2fToPI= +X-Received: by 2002:a1c:1805:: with SMTP id 5-v6mr14075001wmy.25.1534386153376; + Wed, 15 Aug 2018 19:22:33 -0700 (PDT) +MIME-Version: 1.0 +References: <CACrqygD_5jpkTvvcFo7eHxZfiH4evzZQc=YB=opBo6M_0EsZTQ@mail.gmail.com> + <CAFsQEP1ttFbAZZzz49Jg3E3jbZjztNRDVGJAKOWULYzrn+7obQ@mail.gmail.com> + <CACrqygBJ=RdPpHqHzPNqqj0V2w5XL6GVtKobOWnj1EsVykUS8w@mail.gmail.com> + <201808160106.54960.luke@dashjr.org> +In-Reply-To: <201808160106.54960.luke@dashjr.org> +Reply-To: lautaro.dragan@gmail.com +From: Lautaro Dragan <lautarodragan@gmail.com> +Date: Wed, 15 Aug 2018 23:22:21 -0300 +Message-ID: <CAK6DEso4-R78qLtQLfGxNUML5B1Y8gxXXVzrzmSwkPabMfkW+w@mail.gmail.com> +To: Luke Dashjr <luke@dashjr.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000009ed1560573841d75" +X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLYTO,HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 16 Aug 2018 11:50:08 +0000 +Subject: Re: [bitcoin-dev] Claiming an OP_RETURN Prefix +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: Thu, 16 Aug 2018 02:22:35 -0000 + +--0000000000009ed1560573841d75 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks Christopher. + +> op_return outputs can be pruned because they are not spendable. +putting a hash on in the witness script data won't make things better +(it would actually make them worse) and it definitely doesn't help +"block size bloat". + +Agreed + +> I think I'm missing some context, but if you're using op_return purely +for timestamping I would recommend using pay 2 contract instead. + +And + +> If you're *actually* just doing timestamping you're better off using +OpenTimestamps. But many times people think they're just doing timestamping +in reality mere timestamps are insufficient for the task. + +No, it's not only timestamping. Think of it as storing the URL of something +in the OP_RETURN, only that instead of a URL it's a hash. But it's not just +the hash of the work =E2=80=94 IPFS adds a few other elements that affect t= +his +hash, so calculating it out of the file being added won't do. Also, the +batching OTS uses and the batching we use (using IPFS directories) are +incompatible. + +> Can a miner identify which transactions came from your software simply by +running a copy themselves? If so, then they can censor your transactions +no matter how you encode them. + +Miners would have to try and `ipfs cat` every OP_RETURN of every +transaction (maybe filtering by byte length), which is a relatively high +cost operation. But such a script is straight forward to write and can be +hosted in a cheap AWS machine. We're talking about less than a week of +coding and less than a hundred bucks of hosting, so if they're out to get +you it won't make a difference. + +> Choosing not to mine transactions is not censorship. + +Is it not, if for political rather than economical reasons? These +transactions pay fees like any other. + + + +El mi=C3=A9., 15 de ago. de 2018 a la(s) 22:08, Luke Dashjr via bitcoin-dev= + < +bitcoin-dev@lists.linuxfoundation.org> escribi=C3=B3: + +> On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev +> wrote: +> > On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev < +> > bitcoin-dev@lists.linuxfoundation.org> wrote: +> > > Can a miner identify which transactions came from your software simpl= +y +> by +> > > running a copy themselves? If so, then they can censor your +> transactions +> > > no matter how you encode them. +> > +> > Possibly, but in the IPFS case I suspect the latency required to inspec= +t +> > all hashes would likely impact the ability of the miner to succeed in +> the +> > block. (True? I don=E2=80=99t touch mining software.) +> +> Not true at all. +> +> > Thus as long as all hashes look the same, and there are multiple conten= +t +> > addressable schemes that use hashes that have to be searched in order t= +o +> > know to censor, you have to censor all or none. +> +> Choosing not to mine transactions is not censorship. +> +> Luke +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--0000000000009ed1560573841d75 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Thanks Christopher.=C2=A0<div><br></div><div>>=C2=A0<sp= +an style=3D"color:rgb(33,33,33)">op_return outputs can be pruned because th= +ey are not spendable.</span></div><span style=3D"color:rgb(33,33,33)">putti= +ng a hash on in the witness script data won't make things better</span>= +<br style=3D"color:rgb(33,33,33)"><span style=3D"color:rgb(33,33,33)">(it w= +ould actually make them worse) and it definitely doesn't help</span><br= + style=3D"color:rgb(33,33,33)"><span style=3D"color:rgb(33,33,33)">"bl= +ock size bloat".</span><br style=3D"color:rgb(33,33,33)"><div><span st= +yle=3D"color:rgb(33,33,33)"><br></span></div><div><span style=3D"color:rgb(= +33,33,33)">Agreed</span></div><div><span style=3D"color:rgb(33,33,33)"><br>= +</span></div><div><span style=3D"color:rgb(33,33,33)">>=C2=A0</span><spa= +n style=3D"color:rgb(33,33,33)">I think I'm missing some context, but i= +f you're using op_return purely</span></div><div class=3D"inbox-inbox-u= +yb8Gf" style=3D"color:rgb(33,33,33)"><div><div class=3D"inbox-inbox-F3hlO">= +for timestamping I would recommend using pay 2 contract=C2=A0 instead.</div= +></div></div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)= +"><br class=3D"inbox-inbox-Apple-interchange-newline"></div><div class=3D"i= +nbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">And</div><div class=3D"inb= +ox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br></div><div class=3D"inbo= +x-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">> If you're *actually*= + just doing timestamping you're better off using OpenTimestamps. But ma= +ny times people think they're just doing timestamping in reality mere t= +imestamps are insufficient for the task.</div><div class=3D"inbox-inbox-uyb= +8Gf" style=3D"color:rgb(33,33,33)"><br></div><div class=3D"inbox-inbox-uyb8= +Gf" style=3D"color:rgb(33,33,33)">No, it's not only timestamping. Think= + of it as storing the URL of something in the OP_RETURN, only that instead = +of a URL it's a hash. But it's not just the hash of the work =E2=80= +=94 IPFS adds a few other elements that affect this hash, so calculating it= + out of the file being added won't do. Also, the batching OTS uses and = +the batching we use (using IPFS directories) are incompatible.</div><div cl= +ass=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br></div><div cla= +ss=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">> Can a miner id= +entify which transactions came from your software simply by running a copy = +themselves?=C2=A0 If so, then they can censor your transactions no matter h= +ow you encode them.</div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:r= +gb(33,33,33)"><br class=3D"inbox-inbox-Apple-interchange-newline"></div><di= +v class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)">Miners would h= +ave to try and `ipfs cat` every OP_RETURN of every transaction (maybe filte= +ring by byte length), which is a relatively high cost operation. But such a= + script is straight forward to write and can be hosted in a cheap AWS machi= +ne. We're talking about less than a week of coding and less than a hund= +red bucks of hosting, so if they're out to get you it won't make a = +difference.</div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33= +,33)"><br></div><div class=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,= +33)">> Choosing not to mine transactions is not censorship.</div><div cl= +ass=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br class=3D"inbox= +-inbox-Apple-interchange-newline"></div><div class=3D"inbox-inbox-uyb8Gf" s= +tyle=3D"color:rgb(33,33,33)">Is it not, if for political rather than econom= +ical reasons? These transactions pay fees like any other.</div><div class= +=3D"inbox-inbox-uyb8Gf" style=3D"color:rgb(33,33,33)"><br></div><div><span = +style=3D"color:rgb(33,33,33)"><br></span></div></div><br><div class=3D"gmai= +l_quote"><div dir=3D"ltr">El mi=C3=A9., 15 de ago. de 2018 a la(s) 22:08, L= +uke Dashjr via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfou= +ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>> escribi=C3=B3:<b= +r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= +-left:1px #ccc solid;padding-left:1ex">On Wednesday 15 August 2018 21:54:50= + Christopher Allen via bitcoin-dev wrote:<br> +> On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> > Can a miner identify which transactions came from your software s= +imply by<br> +> > running a copy themselves?=C2=A0 If so, then they can censor your= + transactions<br> +> > no matter how you encode them.<br> +><br> +> Possibly, but in the IPFS case I suspect the latency required to inspe= +ct<br> +> all hashes would likely=C2=A0 impact the ability of the miner to succe= +ed in the<br> +> block. (True? I don=E2=80=99t touch mining software.)<br> +<br> +Not true at all.<br> +<br> +> Thus as long as all hashes look the same, and there are multiple conte= +nt<br> +> addressable schemes that use hashes that have to be searched in order = +to<br> +> know to censor, you have to censor all or none.<br> +<br> +Choosing not to mine transactions is not censorship.<br> +<br> +Luke<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> + +--0000000000009ed1560573841d75-- + |