📅 Original date posted:2014-04-26
📝 Original message:On 04/26/2014 04:33 PM, Mike Hearn wrote:
>
> Let's assume we use one shared branch for everyone. Then two
> cosigners could need a new receiving address at the same time, and
> get the next unused address on that branch.
>
> This is the part I struggle to understand. There is no shared branch
> because each user/cosigner has their own unique seed and thus unique
> key hierarchy, right? What you described above could be an issue if
> all co-signers shared the same seed but then the scheme wouldn't work.
>
Consider two people with phones, using 2-of-2, using private seeds k1
and k2. Every address generated by either party is:
2-of-2(K1/a'/b/c, K2/a'/b/c)
So for any a, b and c you end up with a 2-of-2 address. The
seeds/branches will not be used for single-sig receiving... it's always
a multisig 2-of-2. In fact it behaves much like a regular wallet, you
give an a, b, and c value, and you get an address -- it's just that this
wallet always gives you a P2SH multisig address.
The problem is that if you follow BIP32 in the the most obvious way,
both devices will generate receiving addresses along the last index,
i.e. K/a'/b/0, K/a'/b/1, K/a'/b/2,... If I am at one store and my
wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382)
at the same time not realizing the other one has distributed that
address. There's not a good way to coordinate the devices well enough
to avoid it. But we don't have to.
The solution is to use two separate branches -- both phones will
follow/watch both branches, but each only only distributes payment
addresses from one such branch.
The original proposal here suggested adding a level to the tree using
the "cosigner index" as a branch point for doing this... I recommended
simply having 2*N values for "b", so that each participant has a
receiving line and change line, that won't conflict with other devices.
However, all devices will still watch all 2*N branches to know the total
balance of the wallet, and will use UTXOs from those branches when
constructing spending transactions/proposals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/72bca647/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:20:21
in reply to nevent1q…c96y
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:20:21Event JSON
{
"id": "77fc409e5ed464503914291dd985746c8e71e90e64b57298be1ce566cd8b12f2",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686151221,
"kind": 1,
"tags": [
[
"e",
"45de98fa0a16b5f67e8d57b3611100db0254d90b3432adb54b3f92ffceab38f6",
"",
"root"
],
[
"e",
"7e5d37917b985a845a127a7f44eb0c429743b17b2bbe36fe6171da298368cf84",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-04-26\n📝 Original message:On 04/26/2014 04:33 PM, Mike Hearn wrote:\n\u003e\n\u003e Let's assume we use one shared branch for everyone. Then two\n\u003e cosigners could need a new receiving address at the same time, and\n\u003e get the next unused address on that branch.\n\u003e\n\u003e This is the part I struggle to understand. There is no shared branch\n\u003e because each user/cosigner has their own unique seed and thus unique\n\u003e key hierarchy, right? What you described above could be an issue if\n\u003e all co-signers shared the same seed but then the scheme wouldn't work.\n\u003e\nConsider two people with phones, using 2-of-2, using private seeds k1\nand k2. Every address generated by either party is:\n\n2-of-2(K1/a'/b/c, K2/a'/b/c) \n\nSo for any a, b and c you end up with a 2-of-2 address. The\nseeds/branches will not be used for single-sig receiving... it's always\na multisig 2-of-2. In fact it behaves much like a regular wallet, you\ngive an a, b, and c value, and you get an address -- it's just that this\nwallet always gives you a P2SH multisig address.\n\nThe problem is that if you follow BIP32 in the the most obvious way,\nboth devices will generate receiving addresses along the last index, \ni.e. K/a'/b/0, K/a'/b/1, K/a'/b/2,... If I am at one store and my\nwife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382)\nat the same time not realizing the other one has distributed that\naddress. There's not a good way to coordinate the devices well enough\nto avoid it. But we don't have to.\n\nThe solution is to use two separate branches -- both phones will\nfollow/watch both branches, but each only only distributes payment\naddresses from one such branch.\n\nThe original proposal here suggested adding a level to the tree using\nthe \"cosigner index\" as a branch point for doing this... I recommended\nsimply having 2*N values for \"b\", so that each participant has a\nreceiving line and change line, that won't conflict with other devices. \nHowever, all devices will still watch all 2*N branches to know the total\nbalance of the wallet, and will use UTXOs from those branches when\nconstructing spending transactions/proposals.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/72bca647/attachment.html\u003e",
"sig": "1513c2a2cc07ea61d976af4203bde3daefb7fe5c7483e01ce19a5ccf0fbc5f8cb5f0ee436a70372e474277edee0f48a7c847cb39fb58513c003a0d100dc8dce6"
}