From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5mh1-0003kh-6P for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 00:28:51 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.174 as permitted sender) client-ip=209.85.217.174; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f174.google.com; Received: from mail-lb0-f174.google.com ([209.85.217.174]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1U5mgy-0006sS-F6 for bitcoin-development@lists.sourceforge.net; Thu, 14 Feb 2013 00:28:51 +0000 Received: by mail-lb0-f174.google.com with SMTP id l12so1388112lbo.33 for ; Wed, 13 Feb 2013 16:28:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.125.237 with SMTP id mt13mr21995923lab.45.1360801721806; Wed, 13 Feb 2013 16:28:41 -0800 (PST) Received: by 10.112.96.164 with HTTP; Wed, 13 Feb 2013 16:28:41 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 16:28:41 -0800 Message-ID: From: Gregory Maxwell To: Stephen Pair Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.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 (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 X-Headers-End: 1U5mgy-0006sS-F6 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain 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, 14 Feb 2013 00:28:51 -0000 On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair wrote: > If you've already validated the majority of transactions in a block, isn'= t validating the block not all that compute intensive? Thus, it's really n= ot blocks that should be used to impose any sort of scarcity, but rather it= 's the costs associated with the validation and propagation of the transact= ions themselves...which is the way it should be. The cost to whom? This is important because the cost of validating blocks is borne by all the participants in Bitcoin=E2=80=94 or at least all the participants who haven't given up on the decenteralized trustless stuff and are simply trusting someone else. Even a small cost becomes large when hundreds of thousands. And perhaps you don't lament people delegating their trust to large entities=E2=80=94 but keep in mind: Bitcoin was created for the express purpose of creating a money system which didn't require trust because it was based on cryptographic proof=E2=80=94 mathematical law=E2=80=94 inst= ead of politics and human law. Take that away and you have a really poorly understood inefficient system operated by entities which are less trustworthy and rightfully entitled to authority than the ones operating the established major currencies. > When I think about issues like this, I like to remind myself that the mes= h network isn't really an essential part of Bitcoin. Thats absolutely true=E2=80=94 but I don't know that it's relevant in this = case. > Nodes can at some point start to charge fees to collect and distribute tr= ansactions and blocks. They can=E2=80=94 but doing so would radically undermine Bitcoin. A refresher: If you combine digital signatures with simple transaction rules you can have a purely autonomous monetary system based entirely on math. It would be perfect, anonymous, scalable ... except for the problem of double spending. To solve double spending the participants must agree on which of a set of duplicated payments is one the authoritative one. Coming to this agreement is fundamentally hard just at the basics of physics=E2=80=94 a result of relativity is that observers will perceive events in different orders depending on the observer's and the events relative locations. If no observer is privileged (a decenteralized system) you have to have a way of reaching a consensus. This kind of efficient consensus we need=E2=80=94 which which participants = can join or enter at any time, which doesn't require exponential communication, and which is robust against sock-puppet participants=E2=80= =94 was long believed to be practically impossible. Bitcoin solved the problem by using hashcash to vote=E2=80=94 because real resources were fore= ver expended in the process the sock-puppet problem is solved. But the vote only works if everyone can see the results of it: We assume that the majority of hashpower isn't a dishonest party, and that honest nodes can't be prevented from hearing the honest history. Nodes choose then rules-valid history that has the most work (votes) expended on it... but they can only choose among what they know of. As Satoshi, wrote: "[Bitcoin] takes advantage of the nature of information being easy to spread but hard to stifle". The requirement for everyone to hear the history doesn't get talked about much=E2=80=94 at least with reasonably sized blocks and today's technical and common political climates the assumption that information is easy to spread but hard to stifle is a very sound one. It's a good thing, because this assumption is even more important than the hash-power honesty assumption (a malicious party with a simple majority of hashpower is much weaker than one who can partition the network). ... but that all goes out the window if communicating blocks is costly enough that the only way to sustain it is to jealously guard and charge for access/forwarding. The consequence of such a change is that the Bitcoin consensus algorithm would be handicapped. How long must you wait before you know that the history you have won't get replaced by a more authoritative one? Today an hour or two seems relatively solid. In a world with non-uniform block forwarding perhaps it takes days=E2=80=94 if ever=E2=80= =94 before any participant is confident that there isn't a better history lurking. All doubly so if the bookkeeping required for this payment ends up necessitating additional transactions and adds to the load. [This is also the flaw in the 'Red Balloons' paper, making transactions a dozen times longer just to attach credit for forwarding doesn't seem wise compared to keep transactions so cheap to transmit that even a small number of altruists make the equilibrium state be liberally-forwarding] > They would also charge for the propagation of blocks based on the work re= quired to validate them. Large miners would obviously locate and connect to each other. Even enormous blocks are no problems for big industrial players. Don't want to pay the cost to get their big blocks from them? Your loss: If you don't take their blocks and they constitute the longest history, you'll be believing the wrong history until such a time as you wise up and pay the piper. Your transactions will be reversed and you'll lose money. You can hypothesize some cartel behavior external to the rules of the system=E2=80=94 where by some consensus mechanism (????) some super large m= ass of participants agree to reject blocks according 'extrajudicial rules', some rule existing outside of Bitcoin itself=E2=80=94 but there mus= t be a consensus because rejecting blocks by yourself only gets you ripped off. I don't see how this works=E2=80=94 it basically embeds another hard consen= sus problem (what is the criteria for blocks to be valid?) inside our solution to a hard consensus problem (which are the best valid blocks?), but doesn't benefit from the same incentive structure=E2=80=94 locally-greedy miners obviously want to produce the largest blocks possible=E2=80=94 and in hashpower consensus non-miners don't have a voice. That might be acceptable for ordering, but now you're deciding on the rules of the system which all non-trusting participants must validate. You could instead solve that consensus problem with politically stipulated regulation or industry cartels, or good old-fashion kneecap busting or whathave you. But then Bitcoin loses the transparency and determinism that make it worthwhile. I sure hope to hear something better than that. This is basically the gap: Right now I could afford hardware that could process multiple gigabyte blocks=E2=80=94 maybe it only costs as much= as a small house which is not an insane cost for a large business. But the cost would be decidedly non-negligible and it would be rational for me to let someone else take it. Applied to everyone, you end up with a small number of the most vested parties doing all the validation, and so they have full ability to manipulate like today's central banks. For a great many to perform validation=E2=80=94 keeping the system honest a= nd decentralized as it was envisioned=E2=80=94 without worrying about the cost requires that the cost be almost unnoticeable. A tiny fraction of what some industrial player=E2=80=94 who profit from consolidation and manipulation=E2=80=94 could easily handle. I'm skeptical about the system internally self-regulating the size because of what gets called "evaporative cooling" in social sciences=E2=80=94 the cost goes up, some people cross their "hey, I'm better off if I externalize the cost of keeping Bitcoin secure by not participating" boundary and lose their voice. There is probably some equilibrium where Bitcoin is compromised frequently enough that more validators spin up (and ignore past rule violations which can't be undone without economic Armageddon), and eat the costs even though there is an insane amount of freeloading going on. The trustworthiness of today's monetary systems suggests to me that if there is an equilibrium point here it isn't a very trustworthy one. There is an even stronger equilibrium state available too: don't use Bitcoin at at all. If you want a system which is dominated by political whim and expedience and large industrial players and is, as a result, only somewhat trustworthy you can just use government issued currencies=E2=80=94 they're well established and have a lot less overhead t= han this decentralized stuff. (And generally=E2=80=94 Security makes for a terrible market, security is naturally a lemon market. The need is only clear in hindsight. In our case it would be one with an enormous freeloading problem) > P.S. such a fee structure would address the spam issue with economics rat= her than rules about spammy transactions Our current anti-spam one is primarily an economic one=E2=80=94 transaction= s prioritized based on fee per KB in scarce blocks or priority (another scarce commodity), the only really non-very-economic part is the very-small-output heuristic. I would argue that our economic anti-spam mechanisms are currently failing at their job: Various parties are engaging in transaction patterns with near pessimal efficiency=E2=80=94 using a dozen (=E2=80=94 sometimes thousands) of transa= ctions where one or two would be adequate. This isn't limited to just one or two sites=E2=80=94 many parties are using inefficient transaction patterns= =E2=80=94 creating externalized costs on all future Bitcoin users=E2=80=94, simply because there is hardly any incentive not to. Though much discussion among technical people, no one has come up with any reparametrizations that seem likely to achieve the desired incentive alignment in the near term. Of all the elements of the anti-spam policy, it seems to me that the least economic=E2=80=94 the minim= um output size=E2=80=94 is actually the most effective (most spam suppression relative to efficient usage suppression), especially as we move to focusing on the UTXO set size. (The minimum output value requirement discourages the creation of UTXOs which will never be economically rational to redeem).