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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V1Zoj-0004VB-TU for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 10:27:41 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179; envelope-from=pieter.wuille@gmail.com; helo=mail-ob0-f179.google.com; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V1Zoi-0000ID-P3 for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 10:27:41 +0000 Received: by mail-ob0-f179.google.com with SMTP id xk17so9779170obc.10 for ; Tue, 23 Jul 2013 03:27:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.93.2 with SMTP id v2mr19122229icm.25.1374575255349; Tue, 23 Jul 2013 03:27:35 -0700 (PDT) Received: by 10.50.20.225 with HTTP; Tue, 23 Jul 2013 03:27:35 -0700 (PDT) In-Reply-To: References: <20130723093759.GB6198@vps7135.xlshosting.net> Date: Tue, 23 Jul 2013 12:27:35 +0200 Message-ID: From: Pieter Wuille To: Andreas Schildbach Content-Type: text/plain; charset=ISO-8859-1 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 (pieter.wuille[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: 1V1Zoi-0000ID-P3 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind 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, 23 Jul 2013 10:27:42 -0000 On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach wrote: > Sweeping paper wallets is a common feature request. People switch to > centralized services just for getting that. That means they value convenience more than the trust-freeness of a decentralized solution. The only way to avoid that is by making sure the decentralized one is convenient enough. But relying on unauthenticated data itself is equally bad - it means you lose whatever benefit the decentralization had. > It is my understanding that for the usecase, an address-indexed UXTO is > enough. So you probably don't need to worry about script-indexed for now. The difference between script-indexed and address-indexed is absolutely trivial compared to the effort needed to implement and maintain such authenticated trees by all full nodes. Restricting things at the network level (which doesn't even know about a thing like an address) to address-based indexes is ridiculous IMHO. > Security issues could be mitigated by applying trust to the REST server, > e.g. because its your own or the one of your apps vendor. Of course, > link-level security would be needed for this (e.g. SSL). Sure, once you introduce trust, a lot can be done. But it's not really Bitcoin anymore in that case - it's relying on a third party to do the heavy indexing for you. And if that is the best-scaling solution, sure - but I don't think we should encourage that. Or at least, we should first search for alternatives. And encourage infrastructure that doesn't require it. > Paper wallets that include the necessary additional information is > something I have been thinking about. I see some issues: > > - Paper wallets are already quite widespread. You still won't be able to > sweep those. > - Some people like to "top up" a paper wallet or even just sweep a > portion of it. That would not be possible, and in some cases even lead > to loss of coins because of the "involuntary fee" you described. Yeah, those are inherent problems with how there are used today. But today there is also little problem - the UTXO set is tiny. > - Does the necessary info fit into a QR code? Absolutely, though a slightly bigger one. -- Pieter