From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Thu, 24 Apr 2014 16:52:14 +0200 Message-ID: From: Adam Ritter To: Bitcoin Development , Gregory Maxwell , Mike Hearn 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter 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
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)= .
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.

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 R= itter <aritter@gm= ail.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 transacti= ons,
> the Bitcoin blockchain wouldn't even be needed.

Large scale consensus can't generally provide instantly irreversi= ble
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. =C2=A0And 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--