Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TBWM2-00052U-Ha for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 19:42:38 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.175 as permitted sender) client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com; helo=mail-iy0-f175.google.com; Received: from mail-iy0-f175.google.com ([209.85.210.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TBWM1-0006Ov-NE for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 19:42:38 +0000 Received: by iaky10 with SMTP id y10so698432iak.34 for ; Tue, 11 Sep 2012 12:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.178.97 with SMTP id cx1mr17302762igc.48.1347392552391; Tue, 11 Sep 2012 12:42:32 -0700 (PDT) Received: by 10.64.56.66 with HTTP; Tue, 11 Sep 2012 12:42:32 -0700 (PDT) In-Reply-To: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk> References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk> Date: Tue, 11 Sep 2012 15:42:32 -0400 Message-ID: From: Gregory Maxwell To: Matthew Mitchell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.2 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -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 0.4 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TBWM1-0006Ov-NE Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft. 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: Tue, 11 Sep 2012 19:42:38 -0000 On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell wrote: > For some reason sourceforge is not sending me updates anymore but I can s= ee the replies online=E2=80=A6 > > There could be a slightly more simple protocol which gives all the transa= ctions hashes and nodes can then download the transactions separately. Howe= ver there are two problems: > > 1. Downloading all the transactions individually might be inefficient. My= proposal will allow nodes to request multiple transactions at once. Someone can do that just by pipelining the one at a time requests. How much bandwidth do you think you could save over that? > 2. Why not add a few additional components to the protocol to allow reque= sts for any level of the merkle tree? It's not very complicated at all and = protects against the future. I don't see what value this provides. For protecting against the future you might as well suggest uploading x86 code which gets executed to select transactions. "Protects against the future". Can you clarify some more about exactly how you think it would help? It's sometimes desirable to be more general rather than more special case when it's costless... but having couple extra p2p protocol messages to implement, test for interop, guard against vulnerability, etc. isn't costless... and should be justified with concrete benefits. it's not clear to me how your proposal is really all that useful for very large blocks: I looks like it would lot of bytes sending redundant tree data. >The block sizes at the moment are about 0.1MB but what if the bitcoin dema= nd starts pushing that into megabytes? And what if? _Bitcoin_ blocksizes can't be any larger. Some future incompatible system? well perhaps. But we're working on the protocol for bitcoin now. > And yes the ~0.95MB limit needs to be changed in order for bitcoin to gro= w that far. Why would the limit not be lifted? How will bitcoin demand be s= atisfied other than having large fees to deter transactions, hoping the fee= s are large enough to balance the demand with the block size limits to prev= ent many transactions being unconfirmed and annoying users? That limit has = got to go eventually. And then it could be that block sizes do become large= enough to worry about the performance in relaying. The finite size=E2=80=94 and ultimately the contention for space it causes= =E2=80=94 is the only thing will creates non-trivial fees. Without the fees there is no honest economic motivation to mine with adequate computing power to provide security (lots of dishonest motivations=E2=80=94 e.g. applying control over the currency exist), you'd just have a race to the bottom, given unbounded block sizes it is always rational for decentralized to include any transaction with a fee even if it is very small=E2=80=94 otherwise the next rational solver is just going to include = it. Bitcoin gets its value through scarcity. There are two kinds of scarcity that are economically important, scarcity of the coins=E2=80=94 th= ere will never be more than 21 million=E2=80=94 and scarcity of the block space which, as the protocol is defined and enforced by every node can not be more than 1MB. The latter scarcity is what makes the security model economically sane. Fortunately, its perfectly possible to make transactions denominated in bitcoin outside of the blockchain, and in a secure and distributed manner that respects the principles that make bitcoin attractive, but with information hiding that improves privacy, transaction speed, and scalability. See, e.g. the good work being done by Open transactions to create distributed cryptographic banks. So blockchain scarcity itself doesn't prevent Bitcoin from being a one world currency (something which isn't at all sane no matter how big you make the blocks if you don't allow for other modes of transaction processing=E2=80= =94 who the heck wants to possibly wait an hour to get a 1 confirm sodapop??). From the beginning it was obvious that confirmations would eventually be slower (or expensive to make merely slow; Bitcoin is incapable of reliable fast confirmations)=E2=80=94 thats the nature the stochastic consensus and the fee based security support. You could instead imagine a future where bitcoin's security came by collusion by major financial cartels and governments, and where fees aren't important.... But I reject that future, it's a perfectly viable one, but why bother with Bitcoins in the first place? To make some early adopters a little bit of money starting off the next big centrally controlled fiat? Boring. I can't say for sure if the 1MB limit will stay exactly as is forever, as I expect the economics work with any limit out of a fairly broad range that is low enough to both make the space seriously scarce and low enough that 'inexpensive' (e.g. privately owned) hardware can continue to audit it to preserve the decentralized security, and the economic importance of the size limit is more subtle than the inflation resistance... but I know that changing it is precisely as technically difficult as changing the 21 million limit: all Bitcoin node software must be replaced with incompatible software, and I believe it would be just as economically risky=E2=80=94 if not more so=E2= =80=94 if done wrong, as at least inflation would have a easily understood direct dillution effect while inadequate security would potentially make all Bitcoin worthless. As such I don't think it's even worth discussing until there is an urgent demand to clarify the tradeoffs... Should the block size ever be increased the message format used for relaying the larger blocks will be the smallest of the issues being discussed.