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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
