summaryrefslogtreecommitdiff
path: root/49/aa598888e62fc689de6e3ea37821a536bc054b
blob: 24927d8e34bb97168069bfa0d8c441572f7059a3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <rob.golding@astutium.com>) id 1VIW6s-0001HO-Mr
	for bitcoin-development@lists.sourceforge.net;
	Sun, 08 Sep 2013 03:56:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of astutium.com
	designates 80.76.216.60 as permitted sender)
	client-ip=80.76.216.60; envelope-from=rob.golding@astutium.com;
	helo=cpanel4.hosting.astutium.com; 
Received: from cpanel4.hosting.astutium.com ([80.76.216.60])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1VIW6q-0008HY-90
	for bitcoin-development@lists.sourceforge.net;
	Sun, 08 Sep 2013 03:56:26 +0000
Received: from localhost ([127.0.0.1]:38877 helo=astutium.com)
	by cpanel4.hosting.astutium.com with esmtpa (Exim 4.80.1)
	(envelope-from <rob.golding@astutium.com>) id 1VIW6j-0007yE-HB
	for bitcoin-development@lists.sourceforge.net;
	Sun, 08 Sep 2013 04:56:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 08 Sep 2013 04:56:17 +0100
From: rob.golding@astutium.com
To: <bitcoin-development@lists.sourceforge.net>
In-Reply-To: <201309072333.53026.luke@dashjr.org>
References: <CAE0e52XQSMJj9pDb3OEMyAYkChi7=Y9=phKMm34zh1NQFSdcLw@mail.gmail.com>
	<eb196950d9bf667a3b149a74c0d99ab0@astutium.com>
	<201309072333.53026.luke@dashjr.org>
Message-ID: <4016ea53a3a78392e6070979a97bb429@astutium.com>
X-Sender: rob.golding@astutium.com
User-Agent: Roundcube Webmail/0.8.5
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - cpanel4.hosting.astutium.com
X-AntiAbuse: Original Domain - lists.sourceforge.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - astutium.com
X-Get-Message-Sender-Via: cpanel4.hosting.astutium.com: authenticated_id:
	rob.golding@astutium.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: -3.9 (---)
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
	-2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1VIW6q-0008HY-90
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 03:56:26 -0000

> (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