From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Wed, 23 Apr 2014 22:23:08 +0100 Message-ID: From: Tier Nolan To: Gregory Maxwell 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. > > > ------------------------------------------------------------------------------ > 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
An interesting experiment would be a t= ransaction "proof of publication" chain.

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.

If the size was limited, then it doesn't even require sp= am protection.

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.

The locktime/final field could be used for transactions whic= h want to be replaceable.

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.



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 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.

---------------------------------------------------------------------------= ---
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.n= et/sfu/ExoPlatform
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11351ccec7a36c04f7bc562b--