summaryrefslogtreecommitdiff
path: root/91/fe4b3f42d211d516013422bc00f9f73e028868
blob: 32d51fb1b8b0efd94cd014268ac38973ac7e9c41 (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <luke@dashjr.org>) id 1Wd56T-0000cr-97
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 21:53:17 +0000
X-ACL-Warn: 
Received: from zinan.dashjr.org ([192.3.11.21])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Wd56P-0007rA-5r for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 21:53:17 +0000
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:be5f:f4ff:febf:4f76])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 580AC108011E;
	Wed, 23 Apr 2014 21:53:43 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 23 Apr 2014 21:53:05 +0000
User-Agent: KMail/1.13.7 (Linux/3.12.6-gentoo; KDE/4.11.5; x86_64; ; )
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<CAAS2fgTwuBjGJjTC0UyYG5n603m=tf6226FGRo4cyVi93kzKkA@mail.gmail.com>
	<535831BC.1090707@gk2.sk>
In-Reply-To: <535831BC.1090707@gk2.sk>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201404232153.06471.luke@dashjr.org>
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1Wd56P-0007rA-5r
Subject: Re: [Bitcoin-development] New BIP32 structure
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: Wed, 23 Apr 2014 21:53:17 -0000

On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> > Hopefully it would be clarified as only a MUST NOT do so silently...
> > "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> > sounds like a terrible user experience. :)
> 
> That is a subjective matter. To me it makes PERFECT SENSE that funds
> across accounts NEVER MIX. One can still send funds from one account to
> another and then perform another spend.

Only by crossing the blockchain unnecessarily.

> That's what I consider a consistent and thus GOOD user experience.
> What's the purpose of Accounts if wallet mixes coins among them anyway?

To keep balances separated. For example, I might have an account for each of 
my children, move their allowance money to it every day/week (off-chain), and 
they can spend only what they have in their account. Or an exchange might have 
an account for each user's deposits. In neither case, would it make sense to 
pay special attention to which UTXOs are consumed in transactions from any of 
the account.

The only use case that requires tracking UTXOs per-account is when you want to 
have multiple uncoordinated copies of the wallet in use at the same time, and 
therefore need to immediately identify which account a transaction came from 
based on the UTXOs it consumed - although even then, you could still mix funds 
as long as you use only the first UTXO for tracking, so maybe there isn't even 
a niche use case! In any case, Trezor, being a hardware wallet, should never 
overlap with this niche...?

> I know it's not good to use classic bank accounts as analogy, but that's
> exactly how they work. Or have you every done ONE transaction from two
> bank accounts simultaneously?

Bad analogy. Banks *always* mix funds. You don't expect your bank wire to use 
exactly the specific dollar bills you deposited, do you??

Luke