* [Bitcoin-development] Blockchain archival
@ 2013-09-07 21:06 Chris Evans
2013-09-07 23:21 ` rob.golding
0 siblings, 1 reply; 5+ messages in thread
From: Chris Evans @ 2013-09-07 21:06 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 95 bytes --]
bitcoin protocol needs an archival system so the blockchain doesn't become
too big to download
[-- Attachment #2: Type: text/html, Size: 140 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Blockchain archival
2013-09-07 21:06 [Bitcoin-development] Blockchain archival Chris Evans
@ 2013-09-07 23:21 ` rob.golding
2013-09-07 23:33 ` Luke-Jr
0 siblings, 1 reply; 5+ messages in thread
From: rob.golding @ 2013-09-07 23:21 UTC (permalink / raw)
To: bitcoin-development
> bitcoin protocol needs an archival system so the blockchain doesn't
> become too big to download
Some people may want it all ...
Balance at Point-In-Time summaries (say up to the penultimate
difficulty adjustment) would be one simple way.
And make new-adopters get up and running in minutes not days, which can
only be a good thing.
If going that route, then solutions to the 'consolidate
addresses/wallets' question and formal 'discard' of addresses could get
addressed.
Rob
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Blockchain archival
2013-09-07 23:21 ` rob.golding
@ 2013-09-07 23:33 ` Luke-Jr
2013-09-08 3:56 ` rob.golding
0 siblings, 1 reply; 5+ messages in thread
From: Luke-Jr @ 2013-09-07 23:33 UTC (permalink / raw)
To: bitcoin-development
On Saturday, September 07, 2013 11:21:31 PM rob.golding@astutium•com wrote:
> > bitcoin protocol needs an archival system so the blockchain doesn't
> > become too big to download
>
> Some people may want it all ...
>
> Balance at Point-In-Time summaries (say up to the penultimate
> difficulty adjustment) would be one simple way.
> And make new-adopters get up and running in minutes not days, which can
> only be a good thing.
There's no reason to require the full blockchain download before being up and
running. Bitcoin-Qt 0.9 will (probably) have Pieter's work in this area to be
usable very quickly, and download/verify the history in the background
(there's no way to be completely trust-free without this).
> 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).
Luke
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Blockchain archival
2013-09-07 23:33 ` Luke-Jr
@ 2013-09-08 3:56 ` rob.golding
2013-09-08 4:13 ` Jeff Garzik
0 siblings, 1 reply; 5+ messages in thread
From: rob.golding @ 2013-09-08 3:56 UTC (permalink / raw)
To: bitcoin-development
> (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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Blockchain archival
2013-09-08 3:56 ` rob.golding
@ 2013-09-08 4:13 ` Jeff Garzik
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Garzik @ 2013-09-08 4:13 UTC (permalink / raw)
To: rob.golding; +Cc: Bitcoin Dev
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/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-09-08 4:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-07 21:06 [Bitcoin-development] Blockchain archival 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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox