diff options
| author | Jeff Garzik <jgarzik@bitpay.com> | 2013-09-08 00:13:48 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-09-08 04:13:56 +0000 |
| commit | 9aea3212c308516b4a390b0d0264ea34ee1ffa79 (patch) | |
| tree | f449e501fce60782e369eba5cd482d3b547f09a7 | |
| parent | 8ace79cae5f536df9fe2d6207b23478038e85adc (diff) | |
| download | pi-bitcoindev-9aea3212c308516b4a390b0d0264ea34ee1ffa79.tar.gz pi-bitcoindev-9aea3212c308516b4a390b0d0264ea34ee1ffa79.zip | |
Re: [Bitcoin-development] Blockchain archival
| -rw-r--r-- | eb/77713bd44ff4e71827a63f84df13c6f9d4678f | 211 |
1 files changed, 211 insertions, 0 deletions
diff --git a/eb/77713bd44ff4e71827a63f84df13c6f9d4678f b/eb/77713bd44ff4e71827a63f84df13c6f9d4678f new file mode 100644 index 000000000..f97e3dd59 --- /dev/null +++ b/eb/77713bd44ff4e71827a63f84df13c6f9d4678f @@ -0,0 +1,211 @@ +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 <jgarzik@bitpay.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CAE0e52XQSMJj9pDb3OEMyAYkChi7=Y9=phKMm34zh1NQFSdcLw@mail.gmail.com> + <eb196950d9bf667a3b149a74c0d99ab0@astutium.com> + <201309072333.53026.luke@dashjr.org> + <4016ea53a3a78392e6070979a97bb429@astutium.com> +Date: Sun, 8 Sep 2013 00:13:48 -0400 +Message-ID: <CAJHLa0N1A8fH+pbZSKFjtLcLHhJOwcEZVZ4cKGPjh5P46zP26Q@mail.gmail.com> +From: Jeff Garzik <jgarzik@bitpay.com> +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 <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Blockchain archival +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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, <rob.golding@astutium.com> 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/ + + |