From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TBZmV-0006aq-RM for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 23:22:11 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.175 as permitted sender) client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com; helo=mail-qc0-f175.google.com; Received: from mail-qc0-f175.google.com ([209.85.216.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TBZmU-0006p3-VB for bitcoin-development@lists.sourceforge.net; Tue, 11 Sep 2012 23:22:11 +0000 Received: by qcad10 with SMTP id d10so715781qca.34 for ; Tue, 11 Sep 2012 16:22:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.207 with SMTP id k15mr5291802qct.60.1347405725510; Tue, 11 Sep 2012 16:22:05 -0700 (PDT) Received: by 10.49.35.180 with HTTP; Tue, 11 Sep 2012 16:22:05 -0700 (PDT) In-Reply-To: <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk> References: <2104FC7F-0AE0-4C55-9987-B20EFCE19FC3@godofgod.co.uk> <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk> Date: Tue, 11 Sep 2012 19:22:05 -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.3 (-) 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.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TBZmU-0006p3-VB 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 23:22:11 -0000 On Tue, Sep 11, 2012 at 5:48 PM, Matthew Mitchell wrote: > You wouldn't need to pipeline the requests, just place more than one inve= ntory vector in get data, right? Well my messages would save the space of t= hose inventory vectors. Instead of needing 36 byte inventory vectors for ea= ch transaction and a var int, you would need two var ints only. And then th= e transaction responses only need one header, so you save 24 bytes for each= transaction after the first. You could say that is a small benefit. But you only need to request the transactions you don't have. Most of time you should already have almost all of the transactions. > Look at bittorrent. With bittorrent you don't download files from a singl= e peer all at once. You can fetch transactions from multiple peers with just a simple mechanism that gives you the headers plus the txn list. And if you want ArgumentAdSomethingElse, thats what bittorrent does too: the torrent file contains the list of block hashes, and you get it from one place. > Why wouldn't requesting minimum fees in the software work as is done curr= ently? Because there is no motivation not to set them to zero, if you don't someone else will. Right now the income from fees is hardly relevant, and the ability to drive more non-existant because there isn't enough load to create scarcity. > So what you essentially suggest is having bitcoin banks that maintain tru= st through Open Transaction contracts which contains proof of agreement, pr= oviding some legal protection? One wonders why have bitcoin at all then? Wh= y not have an elaborate e-money system between several banks using Open Tra= nsactions? Because it can't resist inflation. You have to trust that the banks won't conspire to their mutual benefit to inflate the base currency. OT can make it so a 'bank' (which is really a distributed collection of nodes, not a single point of trust) can trivially prove how much "gold certificates" it has issued, but you also need to prove how much 'gold' exists and which keys hold it, and for that you need a _global_ consensus; which bitcoin provides... If you don't like >Bitcoin doesn't just contain proof of if something was done right or not, = it contains actual certainty that it will be done right. And how does Open = >Transactions prevent fractional reserve fraud? Well, Bitcoin gives you no certainty that any particular transaction will be confirmed at all, ever; so perhaps best not to overstate it too much. But yes, Bitcoin is great. ... but all that greatness depends on there being a way to fund enough computation so that attacks are too costly to be justified and that the cost of maintaining a system to fully validate the system's rules (e.g. that the miners aren't mining duplicate txns to create inflation for themselves) is low enough that it will naturally enormously distributed so that a conspiracy is effectively impossible. Otherwise everything consolidates down to a few meganodes and the attractive properties are all gone. OT's issuers can prove how much bitcoin they hold on the blockchain (by nothing more sophisticated than signmessage) and they can prove how many tokens they've issued against it. And I didn't mean to suggest OT as a unique solution. Another path is ripple, the idea of which is a sort of a p2p hawala where you have pairwise trust and debt. It can allow you to circulate around tokens between a community of users and only settle infrequently (as determined by your level of trust, the debt involved, and the cost of the bitcoin transaction) against bitcoin. > I suppose when people consider bitcoin banks, they will consider bitcoin = being useless. They already exist, in crappy centralized form=E2=80=94 e.g. look at mtgox codes and user to user instant transfers; and bitcoin isn't useless. Plus some extra system of some kind is the _only_ way to securely irreversible transactions which are reliably fast, so it's not like there is any real prospect of using bitcoin directly for all kinds of uses at scale. (yes, blocks are 'only' 10 minutes apart on average, but if you care about fast, you care about e.g. the 99% not the average) > As far as I see it, if bitcoin won't scale, then it's worth looking at so= mething different to bitcoin that will scale. Bitcoin scales fine. It is not a singular replacement for everything you can imagine it being a replacement for, however, or at least not a good replacement. The fact that you could conceivably make it directly scale up to handle e.g. the volume of all the credit network doesn't make that a good idea. It would still be a very poor replacement for a credit network (slow transactions; which can't be fixed by tweaking some parameters, the bitcoin blockchain consensus algorithm has infinite convergence time when the block time falls below the hash-power-weighed latency), and that kind of scaling would absolutely ruin the decentralization, making it so only large states and megabanks could run full nodes, and even at that level it couldn't match the worldwide volume of cash transactions or 'internal' money transactions (like money moving around on all the poker tables in the world). It's like someone made the mistake of saying the floor wax is edible (linseed oil) and now you complain that its a crappy desert topping. :P Maybe people will ultimately agree to raise the block sizes, but I expect and hope that they'll only do so when it is entirely uncontroversial that doing so won't significantly degrade the decentralization (certainly not the case today: a large portion of the network appears to have trouble keeping up with large blocks right now, though upcoming software improvements will help enormously), or the mining economics. And yes, of course, you schedule the change for the future, but as you note that it doesn't solve the problem of people opposing it.