diff options
| author | Adam Ritter <aritter@gmail.com> | 2014-04-24 16:52:14 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-24 14:52:21 +0000 |
| commit | e8ca6e88090812569c0fd35b28038db808962649 (patch) | |
| tree | 2e321dc715e5c269e3948bec9634c7d9fa02b514 /d0 | |
| parent | 783dff5a4545e35b6d87e4b9006688016f0ed3e1 (diff) | |
| download | pi-bitcoindev-e8ca6e88090812569c0fd35b28038db808962649.tar.gz pi-bitcoindev-e8ca6e88090812569c0fd35b28038db808962649.zip | |
[Bitcoin-development] Fwd: Coinbase reallocation to discourage Finney attacks
Diffstat (limited to 'd0')
| -rw-r--r-- | d0/cdea8408893df5c729271e2917946b634fa758 | 167 |
1 files changed, 167 insertions, 0 deletions
diff --git a/d0/cdea8408893df5c729271e2917946b634fa758 b/d0/cdea8408893df5c729271e2917946b634fa758 new file mode 100644 index 000000000..8d73f63c3 --- /dev/null +++ b/d0/cdea8408893df5c729271e2917946b634fa758 @@ -0,0 +1,167 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <aritter@gmail.com>) id 1WdL0f-0004Qj-G9 + for bitcoin-development@lists.sourceforge.net; + Thu, 24 Apr 2014 14:52:21 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.220.179 as permitted sender) + client-ip=209.85.220.179; envelope-from=aritter@gmail.com; + helo=mail-vc0-f179.google.com; +Received: from mail-vc0-f179.google.com ([209.85.220.179]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WdL0e-0003BM-HZ + for bitcoin-development@lists.sourceforge.net; + Thu, 24 Apr 2014 14:52:21 +0000 +Received: by mail-vc0-f179.google.com with SMTP id ij19so3154630vcb.10 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 24 Apr 2014 07:52:15 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.221.27.8 with SMTP id ro8mr1042124vcb.30.1398351135047; Thu, + 24 Apr 2014 07:52:15 -0700 (PDT) +Received: by 10.220.140.208 with HTTP; Thu, 24 Apr 2014 07:52:14 -0700 (PDT) +In-Reply-To: <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@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> + <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com> +Date: Thu, 24 Apr 2014 16:52:14 +0200 +Message-ID: <CAKuKjyVxQGezxo-2-063oMavQhi6cTOPwPacmLGkSJQ488UA2w@mail.gmail.com> +From: Adam Ritter <aritter@gmail.com> +To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>, + Gregory Maxwell <gmaxwell@gmail.com>, Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=001a11336baaad06fb04f7cafe78 +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 + (aritter[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 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: 1WdL0e-0003BM-HZ +Subject: [Bitcoin-development] Fwd: 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: Thu, 24 Apr 2014 14:52:21 -0000 + +--001a11336baaad06fb04f7cafe78 +Content-Type: text/plain; charset=UTF-8 + +I wouldn't mind having $5 of my money held at +Apple/Google/VISA/Mastercard/BitPay (and I wouldn't be sad of losing $5 if +any of these companies go bankrupt). +Actually I had in mind creating a centralized version of Bitcoin for +ultra-fast payments. With keeping all addresses on SSDs, asking for 1 cent +/ address month, 1 cent / transaction should be possible to reach even with +6x replication. Companies could compete in price as long as the API is +standardized. Automatic top-up should be simple as well. + + +On Wed, Apr 23, 2014 at 10: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. +> + +--001a11336baaad06fb04f7cafe78 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">I wouldn't= + mind having $5 of my money held at Apple/Google/VISA/Mastercard/BitPay (an= +d I wouldn't be sad of losing $5 if any of these companies go bankrupt)= +.<br> +<div>Actually I had in mind creating a centralized version of Bitcoin for u= +ltra-fast payments. With keeping all addresses on SSDs, asking for 1 cent /= + address month, 1 cent / transaction should be possible to reach even with = +6x replication. Companies could compete in price as long as the API is stan= +dardized. Automatic top-up should be simple as well.</div> + +</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b= +r><br><div class=3D"gmail_quote">On Wed, Apr 23, 2014 at 10: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>On Wed, Apr 23, 2014 at 1:44 PM, Adam R= +itter <<a href=3D"mailto:aritter@gmail.com" target=3D"_blank">aritter@gm= +ail.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> +</blockquote></div><br></div> +</div></div></div><br></div> + +--001a11336baaad06fb04f7cafe78-- + + |