From: s7r <s7r@sky-ip.org>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Christian Decker <decker.christian@gmail.com>
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout
Date: Wed, 2 Oct 2019 18:11:25 +0300 [thread overview]
Message-ID: <51d80db6-83d9-2473-d007-f3601c940f28@sky-ip.org> (raw)
In-Reply-To: <20191001155929.e2yznsetqesx2jxo@erisian.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 1721 bytes --]
Anthony Towns via bitcoin-dev wrote:
[SNIP]
>
> My thinking at the moment (subject to change!) is:
>
> * anyprevout signatures make the address you're signing for less safe,
> which may cause you to lose funds when additional coins are sent to
> the same address; this can be avoided if handled with care (or if you
> don't care about losing funds in the event of address reuse)
>
It's not necessarily like this. Address re-use is many times OUTSIDE the
control of the address owner. Say I give my address to a counterparty.
They send me a transaction which I successfully spend. So far so good.
After that, I have no control over that counterparty. If they decide to
re-use that address, it does not mean I wanted to re-use it and it also
does not mean that I don't care about those funds being lost.
This could create a lot of problems in the industry and I think it
should be avoided. Address re-use has been strongly discouraged ever
since I can remember, and all (proper) wallet implementations try as
hard as possible to enforce it, but it's not always possible. A
counterparty that decides to re-use an address, either accidentally or
not, is not under the control of the user who handed out the address in
the first place.
There are also a lot of use cases with P2SH addresses that are some
smart contracts particularly designed to be re-used multiple times over
time.
My 2 cents are that this is not a good way to go. If you try to index
the entire blockchain until now you'll see that address re-use is more
common than we'd want it to be and there's no clear way to prevent this
from further happening without hurting the economic interests of the users.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-02 15:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 13:23 [bitcoin-dev] Continuing the discussion about noinput / anyprevout Christian Decker
2019-09-30 16:00 ` ZmnSCPxj
2019-09-30 23:28 ` ZmnSCPxj
2019-10-01 14:26 ` Christian Decker
2019-10-01 14:45 ` Anthony Towns
2019-10-01 15:42 ` ZmnSCPxj
2019-10-01 14:20 ` Christian Decker
2019-10-01 15:35 ` ZmnSCPxj
2019-10-03 9:42 ` Christian Decker
2019-10-01 12:23 ` Chris Stewart
2019-10-01 13:31 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-03 10:01 ` Christian Decker
2019-10-03 9:57 ` Christian Decker
[not found] ` <CACJVCgJ9PL-2jTS71--tXsa=QkK+f5_ciYLwv468WUno=XXAig@mail.gmail.com>
2019-10-01 14:27 ` Ethan Heilman
2019-10-01 15:14 ` Chris Stewart
2019-10-03 10:30 ` Christian Decker
2019-10-01 15:59 ` [bitcoin-dev] " Anthony Towns
2019-10-02 2:03 ` ZmnSCPxj
2019-10-03 1:47 ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2019-10-03 3:07 ` ZmnSCPxj
2019-10-03 15:05 ` [bitcoin-dev] OP_CAT was " Ethan Heilman
2019-10-03 23:42 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-10-04 0:48 ` Ethan Heilman
2019-10-04 5:02 ` Jeremy
2019-10-04 7:00 ` ZmnSCPxj
2019-10-04 18:33 ` Jeremy
2019-10-04 11:15 ` Peter Todd
2019-10-04 18:40 ` Jeremy
2019-10-05 15:49 ` Peter Todd
2019-10-06 8:46 ` ZmnSCPxj
2019-10-06 9:12 ` Peter Todd
2019-10-06 7:02 ` Lloyd Fournier
2019-10-09 16:56 ` Andrew Poelstra
2019-10-02 15:11 ` s7r [this message]
2019-10-03 11:08 ` [bitcoin-dev] " Christian Decker
2019-10-05 10:06 ` Anthony Towns
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=51d80db6-83d9-2473-d007-f3601c940f28@sky-ip.org \
--to=s7r@sky-ip.org \
--cc=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=decker.christian@gmail.com \
--cc=lightning-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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