From: Johnson Lau <jl2012@xbt•hk>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
Date: Wed, 20 Feb 2019 03:22:07 +0800 [thread overview]
Message-ID: <B58087BD-50F2-40DF-BDF0-8D1FDFDCDE03@xbt.hk> (raw)
In-Reply-To: <201902191904.04412.luke@dashjr.org>
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@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
next prev parent reply other threads:[~2019-02-19 19:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 12:32 Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
2018-12-17 20:08 ` Johnson Lau
2018-12-18 10:48 ` Johnson Lau
2018-12-19 22:09 ` Christian Decker
2018-12-20 11:00 ` Johnson Lau
2018-12-20 17:20 ` Christian Decker
2018-12-20 18:04 ` Johnson Lau
2018-12-21 11:15 ` Christian Decker
2018-12-21 16:21 ` Johnson Lau
2018-12-21 11:40 ` ZmnSCPxj
2018-12-21 15:37 ` Johnson Lau
2018-12-22 14:25 ` ZmnSCPxj
2018-12-22 16:56 ` Johnson Lau
2018-12-24 11:47 ` ZmnSCPxj
2019-01-31 6:04 ` Anthony Towns
2019-02-01 9:36 ` ZmnSCPxj
2019-02-08 19:01 ` Jonas Nick
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 16:48 ` Johnson Lau
2019-02-10 4:46 ` Anthony Towns
2019-02-09 16:54 ` Jonas Nick
2019-02-09 10:15 ` Johnson Lau
2019-02-09 16:52 ` Jonas Nick
2019-02-09 17:43 ` Johnson Lau
2019-02-19 19:04 ` Luke Dashjr
2019-02-19 19:22 ` Johnson Lau [this message]
2019-02-19 20:24 ` Luke Dashjr
2019-02-19 20:36 ` Johnson Lau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B58087BD-50F2-40DF-BDF0-8D1FDFDCDE03@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox