From: Jeff Garzik <jgarzik@bitpay•com>
To: rob.golding@astutium•com
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Blockchain archival
Date: Sun, 8 Sep 2013 00:13:48 -0400 [thread overview]
Message-ID: <CAJHLa0N1A8fH+pbZSKFjtLcLHhJOwcEZVZ4cKGPjh5P46zP26Q@mail.gmail.com> (raw)
In-Reply-To: <4016ea53a3a78392e6070979a97bb429@astutium.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/
prev parent reply other threads:[~2013-09-08 4:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-07 21:06 Chris Evans
2013-09-07 23:21 ` rob.golding
2013-09-07 23:33 ` Luke-Jr
2013-09-08 3:56 ` rob.golding
2013-09-08 4:13 ` Jeff Garzik [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJHLa0N1A8fH+pbZSKFjtLcLHhJOwcEZVZ4cKGPjh5P46zP26Q@mail.gmail.com \
--to=jgarzik@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=rob.golding@astutium$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox