📅 Original date posted:2022-06-28
📝 Original message:Hi Ruben,
Good to see your input here.
>I agree it's not as efficient as it could be, but how big is this problem in practice? Expecting payments on more addresses doesn't seem like a huge overhead. Or are you talking about the hassle of having to support spending from all these address types?
My worry is that once the number of standard scripts becomes significant, wallets will have to watch all of them. This could create a performance hit eventually, though I don't know what that would be in practice. Maybe someone else can offer more insight. It's possible to mitigate that using a tighter gap limit. But we still have the problem of wallets not supporting certain scripts. For example, Bob's wallet may not support wrapped segwit but Alice could accidentally send funds there assuming Bob can spend them.
SP proposes to use Taproot-only (as we've been discussing elsewhere), but I still don't think it's the right solution to lock down the BIP to a single script type, for the sake of future proofing if nothing else. Having address type flags solves these issues at the expense having a couple of extra bytes.
>but it does make it rather difficult to support light clients.
That's correct. This can't take advantage of compact block filters. Doing so would require having a notification address again. The scanning scheme is lighter and a bit simpler to implement than the one proposed by SP but it still presumes a full node.
>The basic idea is that everyone publishes a single pubkey on-chain,
It even seems to me that Bob doesn't even have to publish his key on-chain unless he intends on sending funds. Only senders would have to do so, and pure recipients (if there would be any such entities) would just have to publish their codes off-chain (e.g. website donation address). The downside is that Alice now has to publish her pubkey on-chain, which creates a footprint. She's now a confirmed user of stealth addresses. She can mitigate that by publishing an ephemeral pubkey for each recipient, but this might spiral out of control fast if the standard gains wider acceptance.
>Note that this mechanism is not safe against miners, as they can pay themselves arbitrarily high fees with no downside.
Good point. Perhaps the solution is to require an OP_RETURN burn instead. I thought it's better to benefit the ecosystem by sending coins back to miners, but burning is also possible.
Alfred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220628/78d3b1f1/attachment.html>;
Alfred Hodler [ARCHIVE] /
npub1xg…xyna2
2023-06-07 23:10:48
in reply to nevent1q…3n85
Author Public Key
npub1xgx24fy2k0d2jsqs3zt8m9kx70235ex4yswl9drjq6juy36swhgspxyna2Published at
2023-06-07 23:10:48Event JSON
{
"id": "f9d6e41d61983a9060e6675581c8d98b434a8eb8c8753a7f44c630dfd3057be8",
"pubkey": "320caaa48ab3daa9401088967d96c6f3d51a64d5241df2b47206a5c2475075d1",
"created_at": 1686179448,
"kind": 1,
"tags": [
[
"e",
"2c117deceb80922b32181925f44f4eb7705b67956a1c3a9bf3e3a63b07a98031",
"",
"root"
],
[
"e",
"9f3bc3f39f57f1796589d7510f40f2c22b3b53e912661dda14d552aa9d4f0431",
"",
"reply"
],
[
"p",
"c4c73e48c7d7f313938a90d71ff5e4be5d01dd4157f98ed99adf14737bfb78e0"
]
],
"content": "📅 Original date posted:2022-06-28\n📝 Original message:Hi Ruben,\n\nGood to see your input here.\n\n\u003eI agree it's not as efficient as it could be, but how big is this problem in practice? Expecting payments on more addresses doesn't seem like a huge overhead. Or are you talking about the hassle of having to support spending from all these address types?\n\nMy worry is that once the number of standard scripts becomes significant, wallets will have to watch all of them. This could create a performance hit eventually, though I don't know what that would be in practice. Maybe someone else can offer more insight. It's possible to mitigate that using a tighter gap limit. But we still have the problem of wallets not supporting certain scripts. For example, Bob's wallet may not support wrapped segwit but Alice could accidentally send funds there assuming Bob can spend them.\n\nSP proposes to use Taproot-only (as we've been discussing elsewhere), but I still don't think it's the right solution to lock down the BIP to a single script type, for the sake of future proofing if nothing else. Having address type flags solves these issues at the expense having a couple of extra bytes.\n\n\u003ebut it does make it rather difficult to support light clients.\n\nThat's correct. This can't take advantage of compact block filters. Doing so would require having a notification address again. The scanning scheme is lighter and a bit simpler to implement than the one proposed by SP but it still presumes a full node.\n\n\u003eThe basic idea is that everyone publishes a single pubkey on-chain,\n\nIt even seems to me that Bob doesn't even have to publish his key on-chain unless he intends on sending funds. Only senders would have to do so, and pure recipients (if there would be any such entities) would just have to publish their codes off-chain (e.g. website donation address). The downside is that Alice now has to publish her pubkey on-chain, which creates a footprint. She's now a confirmed user of stealth addresses. She can mitigate that by publishing an ephemeral pubkey for each recipient, but this might spiral out of control fast if the standard gains wider acceptance.\n\n\u003eNote that this mechanism is not safe against miners, as they can pay themselves arbitrarily high fees with no downside.\n\nGood point. Perhaps the solution is to require an OP_RETURN burn instead. I thought it's better to benefit the ecosystem by sending coins back to miners, but burning is also possible.\n\nAlfred\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220628/78d3b1f1/attachment.html\u003e",
"sig": "dc2076ffb4b5d418182b3b9c4d6d7574ff5f36ab02e1bea06764168a1fbc7ec5d80738af8589d7d2d3ca35668d4243aea001d0f926d1b60e3bc5e6fecc863101"
}