Re: [Bitcoin-development] Blockchain archival

[Jeff Garzik <jgarzik@bitpay.com>]

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/