Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VIWNo-0001uy-DO for bitcoin-development@lists.sourceforge.net; Sun, 08 Sep 2013 04:13:56 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.212.178 as permitted sender) client-ip=209.85.212.178; envelope-from=jgarzik@bitpay.com; helo=mail-wi0-f178.google.com; Received: from mail-wi0-f178.google.com ([209.85.212.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VIWNn-0003K2-1V for bitcoin-development@lists.sourceforge.net; Sun, 08 Sep 2013 04:13:56 +0000 Received: by mail-wi0-f178.google.com with SMTP id hn9so2225789wib.11 for ; Sat, 07 Sep 2013 21:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o6FdSqCT4i3yl+r5q4Kanou7HpSaPRoNsjkuRH2r3bs=; b=Uo/8bsMx0s1Xy++QBwatpKZnmxBksllXhL1pwwraSalsgghCWHu60mLQBPAMgRmi/F +Bbc0jrC8pAaHcINdwYb+MO4YmUaUfeVFKbur1ImUerwCgr0SZKFq/TvlurbpgQBSnl4 jYpoocBTCLoM4xWzuOIm/U4vkAMFppzdwxm6fqwSJ1lVN5AXZEV7ST/I2B5zF6P48GJz N0qk1B0g+9Ixe9hHYmk/guEo6wL3QJScR+zXT2PZihutOQPzN2iSjZe8uT4iqNvLHRQ8 P5tpAdCpUQsS8jFUWjE3o3k6RS1hPvQvSnCSsD0yusJdLjTNxAfuH4cYFtGqHVVr7I9s h9+Q== X-Gm-Message-State: ALoCoQlPcMQTW/xaA+2uXO5CFQIC80VvrssWLsO5eLGBfQi0enVWYU80b+7PbfsT6tZ/CnORnibf MIME-Version: 1.0 X-Received: by 10.181.12.16 with SMTP id em16mr3902161wid.36.1378613628229; Sat, 07 Sep 2013 21:13:48 -0700 (PDT) Received: by 10.194.236.69 with HTTP; Sat, 7 Sep 2013 21:13:48 -0700 (PDT) In-Reply-To: <4016ea53a3a78392e6070979a97bb429@astutium.com> References: <201309072333.53026.luke@dashjr.org> <4016ea53a3a78392e6070979a97bb429@astutium.com> Date: Sun, 8 Sep 2013 00:13:48 -0400 Message-ID: From: Jeff Garzik To: rob.golding@astutium.com 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 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: 1VIWNn-0003K2-1V Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Blockchain archival 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: Sun, 08 Sep 2013 04:13:56 -0000 This is all FAQ territory, and has been covered on the forums for years. Balance-at-point-in-time is not completely trust-free, as it is a dataset that must be bootstrapped into trust by... an earlier dataset. Continue this logic and you have a... chain. There is plenty of on-going discussion on UTXO snapshotting -- UTXO lockin for each block, or something. This is /somewhat/ like balance-at-point-in-time, but no one pretends it is trust-free. The /only/ way to have a completely trust-free solution is to be able to verify all data from genesis through $now. However, it is not necessary for all bitcoin wallets to download and verify all those gigabytes of data; that is what SPV mode is for. Jeff On Sat, Sep 7, 2013 at 11:56 PM, wrote: >> (there's no way to be completely trust-free without this). > > Not quite true, as I said balance-at-point-in-time would solve that > (and make the storage requirements much lower) > >>> If going that route, then solutions to the 'consolidate >>> addresses/wallets' >>> question and formal 'discard' of addresses could get addressed. >> >> Not sure what you mean here. Addresses and wallets are two completely >> different things. Addresses are single-use destinations that point to >> a wallet >> (which is itself private and unknown to the network). > > For bitcoin to grow beyond interesting experiment into global everyday > use a number of things would have to happen, not least of which is > taking 'average punter' into account. Whilst new ideas can filter into > the general consciousness over time,sometimes concepts have to go with > 'what already works' :) > > People's concept of money hasn't really changed in over 1,000 years - > it remains 'something of known value i can exchange for something else'. > > No-one outside of bitcoin dev's and early adopters really gets the > one-shot concept of addresses - possibly rightly so - keeping issues of > it lowering levels of anonymity etc out of the discussion - it doesn't > fit with the mindset people have - it's difficult enough getting > merchants to setup separate addresses for each client, one per > transaction is simply a waste (of addresses, storage, blockchain size, > numnber of inputs|outputs when spending etc) > > I'm sure the wife would love a new handbag everytime she gets some > money, but the real-world just isnt like that ;) > > Addresses are perceived as the equivalent of a jar you stick your coins > in. You can have lots of jars. Each jar can be for a specific reason or > whatever, but the analogy is there. > > Wallets are like a box you keep some of your jars in. With the added > interesting concept that a jar can be in multiple boxes at the same > time. Only the person with the right 'key' can open the jar and take the > contents. > > However unlike the 3 money boxes I have behind me right now - which i > can take 1 single penny out of one and put it into another - if I want > to move bitcoins from one addresses (jar) to another *of my own* I have > to pay a fee. Worse still if the jar doesnt have much in it I'm denied > that ability. > > End user will neither understand why or want to pay the fee, for > dealing with their own coins. > If a jar breaks I can just tip the contents into a new one - unless I'm > very careless, the amount in the new one = the amount in the old one - > people will want/need it to work like that. > > Similarly if you do have all these addresses around, you may want (as > good housekeeping) discard some of them (after moving the cash). > > So having the ability to specify address to send from is essential (and > a sadly missing feature of the QT client) > > 'intra-wallet' transfers with an 'also discard the sending address' > would be a way of (once confirmed) stopping any further use of that > address (denied any further transactions by miners ?) and when > balance-at-point-in-time is implemented, a way of shrinking the storage > for all other bitcoin users (who chosse not to have a full transaction > set). > > > If i send luke 10, and luke sends me back 3, i have 3, luke has 7. > If luke sends me 2, and i send luke 1, i have 4 and luke has 6. > To verify my ability to send jeff 4, all that is needed is to know that > I have 4, not all the transactions that led to that state - thats how > its done now, thats not necessarily efficient as bitcoin grows > > If luke sends me 4 more, i now have 4 again, luke has 3 > If i send 1 to each of the children, they have 1 each (*4) > > Having a 'family' wallet means when on holiday they can have that > rental of quad-bikes - to send the rental company 4 the client only > needs to know that those addresses now have 1 each in them, not all the > previous transactions - if they didnt exist at the point-in-time > balance, then yes, it would need to know about the luke>rob>kids > transactions, but thats all > > I moved to a new netbook recently - it took 140 *hours* to d/load and > process the blockchain (yes the wifi was that bad), I heard from one of > our clients that (although they only had the client running during > working hours) that to their desktop it was over 9 days before it had > caught up. > > If all I was d/loading were the transactions since the last difficulty > change (as one example of a fixed point), and the remaining balance on > any not-discarded address as at that point it would have been much much > quicker, and not be shagging my shiny new hard drive. > > There's more but it's 4.45 in the morning, and I cant think coherently > until after a few hours kip and some good coffee :) > > Rob > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/