Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A5079486 for ; Sat, 8 Aug 2015 22:45:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 36D651C8 for ; Sat, 8 Aug 2015 22:45:30 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so98830810wib.0 for ; Sat, 08 Aug 2015 15:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=pjVurC4ghSflXW4eysB4LigE/dDO88i1OVJLDllzPbc=; b=as0+eNhQhHtm8Otm87eEzU64gOkpK7sBzOHIVP2JyL49QB56kbh3NQ5EJBdIhWJyb8 AmxjQcw/L7gCuo/OmKyW81a9rbsB3DUcc7/c+tHbkSahS4zQZF7d4Qp7lDbokZ2hSGnS ikYqdC6IiowrRUUj9uxxKIt3hF0vFTHa1gT/DOvNN/y6wbqL/B/0Lx7cYXMh/VYF0HQR SeV3dwFdNyJAHYb8rEjXb40+hCN3jLQBLbfnWuF0vgvTZLY4ks1VavXhNiQwvr3iJ280 WDKy4t4/wqRk8O7YLQ1i4AlcKlSrm3N2c+b6AwA6hVYIYne7Jcs5vTdSpzTypVc02FcG U/Zw== MIME-Version: 1.0 X-Received: by 10.180.76.232 with SMTP id n8mr10858409wiw.72.1439073928809; Sat, 08 Aug 2015 15:45:28 -0700 (PDT) Sender: dscotese@gmail.com Received: by 10.27.184.134 with HTTP; Sat, 8 Aug 2015 15:45:28 -0700 (PDT) In-Reply-To: References: <2586092.4ZtH253X8E@coldstorage> Date: Sat, 8 Aug 2015 15:45:28 -0700 X-Google-Sender-Auth: mWel9-IookxlCT7Az3-ikechtxY Message-ID: From: Dave Scotese To: Bitcoin Dev Content-Type: multipart/alternative; boundary=f46d043893f95512af051cd48203 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Fees and the block-finding process X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 22:45:31 -0000 --f46d043893f95512af051cd48203 Content-Type: text/plain; charset=UTF-8 I see value in lowering the block size or leaving it where it is. We expect to run out of space, and I think it's a good idea to prepare for that, rather than avoid it. When we run out of space and the block size is low, we will see problems. If we raise the block size, we will NOT see these problems until bitcoin is bigger and more important and the pressure is higher. Someone mentioned that when the backlog grows faster than it shrinks, that is a real problem. I don't think it is. It is a problem for those who don't wait for even one confirmation, but backlogs in the past have already started training users to wait for at least one confirmation, or go off-chain. I am comfortable leaving those zero-conf people in a little bit of trouble. Everyone else can double-spend (perhaps that's not as easy as it should be in bitcoin core) and use a higher fee, thus competing for block space. Yes, $5 transactions suck, but $0.15 is not so bad and about twice the average right now. Meanwhile, the higher fees everyone starts feeling like paying, along with the visibility of the problems caused by full-blocks, will provide excellent justification and motivation for increasing the limit. My favorite thing to do is to have a solution ready for a problem I expect to see, see the problem (so I can measure things about it) and then implement the solution. In my experience, the single biggest reason not to run a full node has to do with starting from scratch: "I used to run a full node, but last time I had to download the full blockchain, it took ___ days, so I just use (some wallet) now." I think that has been improved with headers-first, but many people don't know it. I have some ideas how a "full node" could postpone being "full" but still be nearly completely operational so that the delay between startup and having a full blockchain is nearly painless. It involves bonded representation of important not-so-large pieces of data (blocks that have my transactions, the complete UTXO as of some height, etc.). If I know that I have some btc, I could offer it (say, 100 or 1000 transaction fees' worth) to anyone who will guarantee good data to me, and then when I have the whole blockchain, I will know if they were honest. If done right, the whole network could know whether or not they were honest and enforce the bond if they weren't. Credit the Lightening paper for parts of this idea. Dave On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Please try to focus on constructive technical comments. > > On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev > wrote: > > What will the backlash be when people here that are pushing for > "off-chain- > > transactions" fail to produce a properly working alternative, which > > essentially means we have to say NO to more users. > > But > 99% of Bitcoin transactions are already off-chain. There are > multiple competing companies offering consumer & retail service with > off-chain settlement. > > I wasnt clear but it seemed in your previous mail that you seemed to > say you dont mind trusting other people with your money, and so > presumably you are OK using these services, and so have no problem? > > > At this time and this size of bitcoin community, my personal experience > (and > > I've been part of many communities) saying NO to new customers > > Who said no to anything? The systems of off-chain transfer already > exist and are by comparison to Bitcoins protocol simple and rapid to > adapt and scale. > > Indications are that we can even do off-chain at scale with Bitcoin > similar trust-minimisation with lightning, and duplex payment > channels; and people are working on that right now. > > I think it would be interesting and useful for someone, with an > interest in low trust, high scale transactions, to work on and propose > an interoperability standard and API for such off-chain services to be > accessed by wallets, and perhaps periodic on-chain inter-service > netting. > > Adam > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --f46d043893f95512af051cd48203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see value in lowering the block size= or leaving it where it is. We expect to run out of space, and I think it&#= 39;s a good idea to prepare for that, rather than avoid it.=C2=A0 When we r= un out of space and the block size is low, we will see problems.=C2=A0 If w= e raise the block size, we will NOT see these problems until bitcoin is big= ger and more important and the pressure is higher.

Someone men= tioned that when the backlog grows faster than it shrinks, that is a real p= roblem.=C2=A0 I don't think it is.=C2=A0 It is a problem for those who = don't wait for even one confirmation, but backlogs in the past have alr= eady started training users to wait for at least one confirmation, or go of= f-chain.=C2=A0 I am comfortable leaving those zero-conf people in a little = bit of trouble.=C2=A0 Everyone else can double-spend (perhaps that's no= t as easy as it should be in bitcoin core) and use a higher fee, thus compe= ting for block space.=C2=A0 Yes, $5 transactions suck, but $0.15 is not so = bad and about twice the average right now.

Meanwhile, the high= er fees everyone starts feeling like paying, along with the visibility of t= he problems caused by full-blocks, will provide excellent justification and= motivation for increasing the limit.=C2=A0 My favorite thing to do is to h= ave a solution ready for a problem I expect to see, see the problem (so I c= an measure things about it) and then implement the solution.

I= n my experience, the single biggest reason not to run a full node has to do= with starting from scratch: "I used to run a full node, but last time= I had to download the full blockchain, it took ___ days, so I just use (so= me wallet) now."=C2=A0 I think that has been improved with headers-fir= st, but many people don't know it.

I have some ideas = how a "full node" could postpone being "full" but still= be nearly completely operational so that the delay between startup and hav= ing a full blockchain is nearly painless.=C2=A0 It involves bonded represen= tation of important not-so-large pieces of data (blocks that have my transa= ctions, the complete UTXO as of some height, etc.).=C2=A0 If I know that I = have some btc, I could offer it (say, 100 or 1000 transaction fees' wor= th) to anyone who will guarantee good data to me, and then when I have the = whole blockchain, I will know if they were honest.=C2=A0 If done right, the= whole network could know whether or not they were honest and enforce the b= ond if they weren't.=C2=A0 Credit the Lightening paper for parts of thi= s idea.

Dave
On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
Please try to focus on= constructive technical comments.

On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> What will the backlash be when people here that are pushing for "= off-chain-
> transactions" fail to produce a properly working alternative, whi= ch
> essentially means we have to say NO to more users.

But > 99% of Bitcoin transactions are already off-chain.=C2=A0 Th= ere are
multiple competing companies offering consumer & retail service with off-chain settlement.

I wasnt clear but it seemed in your previous mail that you seemed to
say you dont mind trusting other people with your money, and so
presumably you are OK using these services, and so have no problem?

> At this time and this size of bitcoin community, my personal experienc= e (and
> I've been part of many communities) saying NO to new customers

Who said no to anything?=C2=A0 The systems of off-chain transfer alr= eady
exist and are by comparison to Bitcoins protocol simple and rapid to
adapt and scale.

Indications are that we can even do off-chain at scale with Bitcoin
similar trust-minimisation with lightning, and duplex payment
channels; and people are working on that right now.

I think it would be interesting and useful for someone, with an
interest in low trust, high scale transactions, to work on and propose
an interoperability standard and API for such off-chain services to be
accessed by wallets, and perhaps periodic on-chain inter-service
netting.

Adam
___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev



--
I like to provide some work at no cha= rge to prove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I= 'm the webmaster for The Voluntaryist which now accepts Bitcoin.
I also code for = The Dollar Vigila= nte.
"He ought to find it more profitable to play by the rules&= quot; - Satoshi Nakamoto
--f46d043893f95512af051cd48203--