📅 Original date posted:2019-02-19
📝 Original message:Even besides NOINPUT, such a wallet would simply never show a second payment
to the same address (or at least never show it as confirmed, until
successfully spent).
At least if tx versions are used, it isn't possible to indicate this
requirement in current Bitcoin L1 addresses. scriptPubKey might not be
impossible to encode, but it isn't really clear what the purpose of doing so
is.
If people don't want to use NOINPUT, they should just not use it. Trying to
implement a nanny in the protocol is inappropriate and limits what developers
can do who actually want the features.
Luke
On Tuesday 19 February 2019 19:22:07 Johnson Lau wrote:
> This only depends on the contract between the payer and payee. If the
> contract says address reuse is unacceptable, it’s unacceptable. It has
> nothing to do with how the payee spends the coin. We can’t ban address
> reuse at protocol level (unless we never prune the chain), so address reuse
> could only be prevented at social level.
>
> Using NOINPUT is also a very weak excuse: NOINPUT always commit to the
> value. If the payer reused an address but for different amount, the payee
> can’t claim the coin is lost due to previous NOINPUT use. A much stronger
> way is to publish the key after a coin is well confirmed.
>
> > On 20 Feb 2019, at 3:04 AM, Luke Dashjr <luke at dashjr.org> wrote:
> >
> > On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> >> While this seems fully compatible with eltoo, is there any other
> >> proposals require NOINPUT, and is adversely affected by either way of
> >> tagging?
> >
> > Yes, this seems to break the situation where a wallet wants to use
> > NOINPUT for everything, including normal L1 payments. For example, in the
> > scenario where address reuse will be rejected/ignored by the recipient
> > unconditionally, and the payee is considered to have burned their
> > bitcoins by attempting it.
> >
> > Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 18:16:15
in reply to nevent1q…cqv4
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 18:16:15Event JSON
{
"id": "8fa2a3e4d99751d2b7511ac87dcfc1c59b686a9ec4cd5d903fdb2fc47c01a5d2",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686161775,
"kind": 1,
"tags": [
[
"e",
"d115c2cf2fc1879f7295a540eec6df49284da7ea0208c40bff09a5bb6df1c817",
"",
"root"
],
[
"e",
"b6ed4fc38dcf03187d1660703a4325900431beb6b470aad558cfad9f7babe72d",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2019-02-19\n📝 Original message:Even besides NOINPUT, such a wallet would simply never show a second payment \nto the same address (or at least never show it as confirmed, until \nsuccessfully spent).\n\nAt least if tx versions are used, it isn't possible to indicate this \nrequirement in current Bitcoin L1 addresses. scriptPubKey might not be \nimpossible to encode, but it isn't really clear what the purpose of doing so \nis.\n\nIf people don't want to use NOINPUT, they should just not use it. Trying to \nimplement a nanny in the protocol is inappropriate and limits what developers \ncan do who actually want the features.\n\nLuke\n\n\nOn Tuesday 19 February 2019 19:22:07 Johnson Lau wrote:\n\u003e This only depends on the contract between the payer and payee. If the\n\u003e contract says address reuse is unacceptable, it’s unacceptable. It has\n\u003e nothing to do with how the payee spends the coin. We can’t ban address\n\u003e reuse at protocol level (unless we never prune the chain), so address reuse\n\u003e could only be prevented at social level.\n\u003e\n\u003e Using NOINPUT is also a very weak excuse: NOINPUT always commit to the\n\u003e value. If the payer reused an address but for different amount, the payee\n\u003e can’t claim the coin is lost due to previous NOINPUT use. A much stronger\n\u003e way is to publish the key after a coin is well confirmed.\n\u003e\n\u003e \u003e On 20 Feb 2019, at 3:04 AM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:\n\u003e \u003e\u003e While this seems fully compatible with eltoo, is there any other\n\u003e \u003e\u003e proposals require NOINPUT, and is adversely affected by either way of\n\u003e \u003e\u003e tagging?\n\u003e \u003e\n\u003e \u003e Yes, this seems to break the situation where a wallet wants to use\n\u003e \u003e NOINPUT for everything, including normal L1 payments. For example, in the\n\u003e \u003e scenario where address reuse will be rejected/ignored by the recipient\n\u003e \u003e unconditionally, and the payee is considered to have burned their\n\u003e \u003e bitcoins by attempting it.\n\u003e \u003e\n\u003e \u003e Luke",
"sig": "751a8dee8c5bed63d9cd8aaf8e1a79c01882918021736b686a0b4cd04e0e22eb7e397a732905f9dd462e98f8c845af1e20db9b66bb85c4637ce8701d03632a48"
}