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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdLXd-0003ur-7c for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 15:26:25 +0000 X-ACL-Warn: Received: from p3plsmtpa06-10.prod.phx3.secureserver.net ([173.201.192.111]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WdLXb-0004aP-QD for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 15:26:25 +0000 Received: from [192.168.0.23] ([201.231.95.129]) by p3plsmtpa06-10.prod.phx3.secureserver.net with id trDh1n00A2nUpUh01rDimA; Thu, 24 Apr 2014 08:13:44 -0700 Message-ID: <53592A24.5000007@certimix.com> Date: Thu, 24 Apr 2014 12:13:40 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mike Hearn , bitcoin-development References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/alternative; boundary="------------090405060002080201030106" X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [173.201.192.111 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WdLXb-0004aP-QD 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: Thu, 24 Apr 2014 15:26:25 -0000 This is a multi-part message in MIME format. --------------090405060002080201030106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 23/04/2014 05:51 p.m., Mike Hearn wrote: > On Wed, Apr 23, 2014 at 10: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. > > > The 10 minute average comes from a desire to balance wasted work due > to natural chain splits with latency. With a very fast block interval > you end up with lots of forks and things take longer to converge, > also, it can make attacks easier because an attacker is building on > his own blocks so he doesn't suffer propagation delays and the > attendant splits. > > It's not clear you can just make a faster block chain. 10 minutes is > somewhat arbitrary, it could be 5 minutes and the system would still > work, but it probably can't be 5 seconds. 5 seconds block interval is possible. I've simulate it with great success and I encourage anyone to repeat or check my simulations. There are a very few protocol modifications that are required to allow 5 seconds block, and most of them have already been discussed in the forums. For more information you can check my post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows 100 tps and .... it's based on BitcoinJ (NimbleCoinJ now). So not only it is possible, but it was coded by Mike itself. Important note: the 5-sec block interval method probably requires a block reward forever. It doesn't work well if there is no block reward at all. > > Unfortunately for best physical-world usability you really need very > fast payments. A few seconds is competitive with modern credit cards. Another solution to achieve <5 secs block intervals is this: http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/ So the problem with 0-confirmations is solely of Bitcoin and other alt-coins, new alt-coins may achieve instant transactions and no not have to rely on 0-confirmations. Best regards, Sergio. --------------090405060002080201030106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 23/04/2014 05:51 p.m., Mike Hearn wrote:
On Wed, Apr 23, 2014 at 10: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.

The 10 minute average comes from a desire to balance wasted work due to natural chain splits with latency. With a very fast block interval you end up with lots of forks and things take longer to converge, also, it can make attacks easier because an attacker is building on his own blocks so he doesn't suffer propagation delays and the attendant splits.

It's not clear you can just make a faster block chain. 10 minutes is somewhat arbitrary, it could be 5 minutes and the system would still work, but it probably can't be 5 seconds.
5 seconds block interval is possible. I've simulate it with great success and I encourage anyone to repeat or check my simulations.

There are a very few protocol modifications that are required to allow 5 seconds block, and most of them have already been discussed in the forums.
For more information you can check my post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows 100 tps and .... it's based on BitcoinJ (NimbleCoinJ now). So not only it is possible, but it was coded by Mike itself.
Important note: the 5-sec block interval method probably requires a block reward forever. It doesn't work well if there is no block reward at all.


Unfortunately for best physical-world usability you really need very fast payments. A few seconds is competitive with modern credit cards.
Another solution to achieve <5 secs block intervals is this: http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/

So the problem with 0-confirmations is solely of Bitcoin and other alt-coins, new alt-coins may achieve instant transactions and no not have to rely on 0-confirmations.

Best regards,
 Sergio.

--------------090405060002080201030106--