Jochen Hoenicke [ARCHIVE] on Nostr: 📅 Original date posted:2016-05-14 📝 Original message:Am 13.05.2016 um 15:16 ...
📅 Original date posted:2016-05-14
📝 Original message:Am 13.05.2016 um 15:16 schrieb Daniel Weigl via bitcoin-dev:
>
> With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses.
> I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.
>
The discussion so far shows that starting a new BIP is a very good idea.
Otherwise everyone would do it slightly different.
With P2(W)SH you mean P2WPKH embedded in P2SH, right? P2WSH is
completely different and used for example for multisig.
> In my opinion there are two(?) different options:
To summarize, option 1 means one account that supports both non-segwit
and segwit addresses. With option 2 you have one p2pkh-only account and
one segwit-only account, which are completely separated.
I personally would vote for option 1. Scanning twice the addresses can
be avoided with Aaron's trick. The second disadvantage remains:
> -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
A non-segwit wallet would ignore all segwit outputs, which means that
the balance it shows is smaller (and it doesn't show transactions that
spend from previous segwit outputs). I don't see that this can lead to
losing money except maybe when sweeping the account with a p2pkh-only
wallet and then throwing the xprv away.
Of course, you can also do option 2 and let it appear to the user as if
it was only one account, but what is the advantage over option 1 in that
case? Also you need two xpubs to watch this joined account.
Jochen
Published at
2023-06-07 17:50:45Event JSON
{
"id": "c24ed9bbc0f1d6331bc444e9d5345d7d11f573bdb6c86b706c80ce1969b178a9",
"pubkey": "5f325e2a1875039f7993aa44faeaa213e27f236f1388a14ae04289d0c742bc95",
"created_at": 1686160245,
"kind": 1,
"tags": [
[
"e",
"dde2d1a2608d8708981e63f6426a506001e25543a593f3cfcddbdaafeb9e6b7d",
"",
"root"
],
[
"e",
"600e4bd17ed8704ea0c84e18aa8f6bdab20e83b7728be569a632ceb1e75a80d7",
"",
"reply"
],
[
"p",
"3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3"
]
],
"content": "📅 Original date posted:2016-05-14\n📝 Original message:Am 13.05.2016 um 15:16 schrieb Daniel Weigl via bitcoin-dev:\n\u003e \n\u003e With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses.\n\u003e I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.\n\u003e\n\nThe discussion so far shows that starting a new BIP is a very good idea.\n Otherwise everyone would do it slightly different.\n\nWith P2(W)SH you mean P2WPKH embedded in P2SH, right? P2WSH is\ncompletely different and used for example for multisig.\n\n\n\u003e In my opinion there are two(?) different options: \n\nTo summarize, option 1 means one account that supports both non-segwit\nand segwit addresses. With option 2 you have one p2pkh-only account and\none segwit-only account, which are completely separated.\n\nI personally would vote for option 1. Scanning twice the addresses can\nbe avoided with Aaron's trick. The second disadvantage remains:\n\n\u003e \t-) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types\n\nA non-segwit wallet would ignore all segwit outputs, which means that\nthe balance it shows is smaller (and it doesn't show transactions that\nspend from previous segwit outputs). I don't see that this can lead to\nlosing money except maybe when sweeping the account with a p2pkh-only\nwallet and then throwing the xprv away.\n\nOf course, you can also do option 2 and let it appear to the user as if\nit was only one account, but what is the advantage over option 1 in that\ncase? Also you need two xpubs to watch this joined account.\n\n Jochen",
"sig": "ba712a75e23a42afbddf1c4a377519b08f69d1c001149265b0e17ff3d5a047c0b00f44cf083613d4f595ba8fe794f3588472faab71224feffe889606ff960def"
}