diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2014-04-23 22:23:08 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-23 21:23:15 +0000 |
| commit | 247336258f3965d7330f4d252927b315a4ee89c4 (patch) | |
| tree | b2438788c09bd8f3990d2eb8406ee66dcb4935e5 | |
| parent | 312829f7a5ae057c5ea7b789552f9c3faae84ae7 (diff) | |
| download | pi-bitcoindev-247336258f3965d7330f4d252927b315a4ee89c4.tar.gz pi-bitcoindev-247336258f3965d7330f4d252927b315a4ee89c4.zip | |
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
| -rw-r--r-- | cd/43ca96422903e6b3ccc74abe0ae2d6a73e3e5a | 206 |
1 files changed, 206 insertions, 0 deletions
diff --git a/cd/43ca96422903e6b3ccc74abe0ae2d6a73e3e5a b/cd/43ca96422903e6b3ccc74abe0ae2d6a73e3e5a new file mode 100644 index 000000000..6e52a4466 --- /dev/null +++ b/cd/43ca96422903e6b3ccc74abe0ae2d6a73e3e5a @@ -0,0 +1,206 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <tier.nolan@gmail.com>) id 1Wd4dP-0007U7-8m + for bitcoin-development@lists.sourceforge.net; + Wed, 23 Apr 2014 21:23:15 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.192.48 as permitted sender) + client-ip=209.85.192.48; envelope-from=tier.nolan@gmail.com; + helo=mail-qg0-f48.google.com; +Received: from mail-qg0-f48.google.com ([209.85.192.48]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Wd4dO-000726-6p + for bitcoin-development@lists.sourceforge.net; + Wed, 23 Apr 2014 21:23:15 +0000 +Received: by mail-qg0-f48.google.com with SMTP id q108so1626590qgd.7 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 23 Apr 2014 14:23:08 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.140.48.13 with SMTP id n13mr877901qga.90.1398288188677; Wed, + 23 Apr 2014 14:23:08 -0700 (PDT) +Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 14:23:08 -0700 (PDT) +In-Reply-To: <CAAS2fgRWfcxYaLRY69=LE_+sDfYLNUTcimw4cE-2Byw7QonC=w@mail.gmail.com> +References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com> + <CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com> + <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com> + <CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com> + <CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com> + <CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com> + <CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com> + <CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com> + <CAAS2fgRWfcxYaLRY69=LE_+sDfYLNUTcimw4cE-2Byw7QonC=w@mail.gmail.com> +Date: Wed, 23 Apr 2014 22:23:08 +0100 +Message-ID: <CAE-z3OX7AppQeBcMBArccELQxnZBPNCefiRJvTt0gYYjxKAQuQ@mail.gmail.com> +From: Tier Nolan <tier.nolan@gmail.com> +To: Gregory Maxwell <gmaxwell@gmail.com> +Content-Type: multipart/alternative; boundary=001a11351ccec7a36c04f7bc562b +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (tier.nolan[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, + no trust [209.85.192.48 listed in list.dnswl.org] + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1Wd4dO-000726-6p +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage + Finney attacks +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 23 Apr 2014 21:23:15 -0000 + +--001a11351ccec7a36c04f7bc562b +Content-Type: text/plain; charset=UTF-8 + +An interesting experiment would be a transaction "proof of publication" +chain. + +Each transaction would be added to that chain when it is received. It +could be merge mined with the main chain. + +If the size was limited, then it doesn't even require spam protection. + +Blocks could be "discouraged" if they have transactions which violate the +ordering in that chain. Miners could still decide which transactions they +include, but couldn't include transactions which are double spends. + +The locktime/final field could be used for transactions which want to be +replaceable. + +The chain could use some of the fast block proposals. For example, it +could include orphans of a block when computing the block's POW. + + + +On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote: + +> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter <aritter@gmail.com> wrote: +> > Isn't a faster blockchain for transactions (maybe as a sidechain) solving +> > the problem? If there would be a safe way for 0-confirmation +> transactions, +> > the Bitcoin blockchain wouldn't even be needed. +> +> Large scale consensus can't generally provide instantly irreversible +> transactions directly: Increasing the block speed can't help past the +> point where the time starts getting close to the network diameter... +> you simply can't tell what a consensus of a group of nodes is until +> several times the light cone that includes all of them. And if you +> start getting close to the limit you dilute the power working on the +> consensus and potentially make life easier for a large attacker. +> +> Maybe other chains with different parameters could achieve a different +> tradeoff which was better suited to low value retail transactions +> (e.g. where you want a soft confirmation fast). A choice of tradeoffs +> could be very useful, and maybe you can practically get close enough +> (e.g. would knowing you lost a zero-conf double spend within 30 +> seconds 90% of the time be good enough?)... but I'm not aware of any +> silver bullet there which gives you something identical to what a +> centralized service can give you without invoking at least a little +> bit of centralization. +> +> +> ------------------------------------------------------------------------------ +> Start Your Social Network Today - Download eXo Platform +> Build your Enterprise Intranet with eXo Platform Software +> Java Based Open Source Intranet - Social, Extensible, Cloud Ready +> Get Started Now And Turn Your Intranet Into A Collaboration Platform +> http://p.sf.net/sfu/ExoPlatform +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +--001a11351ccec7a36c04f7bc562b +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div><div><div>An interesting experiment would be a t= +ransaction "proof of publication" chain.<br><br></div>Each transa= +ction would be added to that chain when it is received.=C2=A0 It could be m= +erge mined with the main chain.<br> +<br></div><div>If the size was limited, then it doesn't even require sp= +am protection.<br></div><div><br></div>Blocks could be "discouraged&qu= +ot; if they have transactions which violate the ordering in that chain.=C2= +=A0 Miners could still decide which transactions they include, but couldn&#= +39;t include transactions which are double spends.<br> +<br></div><div>The locktime/final field could be used for transactions whic= +h want to be replaceable.<br></div><div><br></div>The chain could use some = +of the fast block proposals.=C2=A0 For example, it could include orphans of= + a block when computing the block's POW.<br> +</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D= +"gmail_quote">On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell <span dir=3D= +"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@= +gmail.com</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div class=3D"">On Wed, Apr 23, 2014 at 1:44= + PM, Adam Ritter <<a href=3D"mailto:aritter@gmail.com">aritter@gmail.com= +</a>> wrote:<br> + +> Isn't a faster blockchain for transactions (maybe as a sidechain) = +solving<br> +> the problem? If there would be a safe way for 0-confirmation transacti= +ons,<br> +> the Bitcoin blockchain wouldn't even be needed.<br> +<br> +</div>Large scale consensus can't generally provide instantly irreversi= +ble<br> +transactions directly: Increasing the block speed can't help past the<b= +r> +point where the time starts getting close to the network diameter...<br> +you simply can't tell what a consensus of a group of nodes is until<br> +several times the light cone that includes all of them. =C2=A0And if you<br= +> +start getting close to the limit you dilute the power working on the<br> +consensus and potentially make life easier for a large attacker.<br> +<br> +Maybe other chains with different parameters could achieve a different<br> +tradeoff which was better suited to low value retail transactions<br> +(e.g. where you want a soft confirmation fast). A choice of tradeoffs<br> +could be very useful, and maybe you can practically get close enough<br> +(e.g. would knowing you lost a zero-conf double spend within 30<br> +seconds 90% of the time be good enough?)... but I'm not aware of any<br= +> +silver bullet there which gives you something identical to what a<br> +centralized service can give you without invoking at least a little<br> +bit of centralization.<br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +---------------------------------------------------------------------------= +---<br> +Start Your Social Network Today - Download eXo Platform<br> +Build your Enterprise Intranet with eXo Platform Software<br> +Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br> +Get Started Now And Turn Your Intranet Into A Collaboration Platform<br> +<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n= +et/sfu/ExoPlatform</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</div></div></blockquote></div><br></div> + +--001a11351ccec7a36c04f7bc562b-- + + |