📅 Original date posted:2013-11-02 📝 Original message:I actually had a use case ...

Allen Piscitello [ARCHIVE] /

npub1xvn…5rqg

2023-06-07 15:08:29

in reply to nevent1q…v7pg

📅 Original date posted:2013-11-02
📝 Original message:I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
It was either that or making sure I had no unspent outputs. The use case
of doing it was laziness in just creating a single key.

On Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr <luke at dashjr.org> wrote:

> On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> > This was one of my concerns when implementing a scheme where you sign a
> > refund transaction before the original transaction is broadcast. I
> > originally tried to pass a hash and have the server sign it. However, I
> > had no way to know that what I was signing wasn't a transaction that was
> > spending my coins! So I changed the code to require sending the full
> > transaction, not just the hash. The other way to mitigate this is
> through
> > not having any unspent outputs from this key.
>
> Well, there's no use case to sign with an address that has already been
> sent
> coins. The main problem with enforcing this is that you can't exactly stop
> someone from sending to an "identity" address.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131102/8c7dc481/attachment.html>;

Author Public Key

npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqg

Show more details

Published at

2023-06-07 15:08:29

Kind type

1 Short Text Note

Event JSON

{ "id": "1ba5475fd42d5397eb9b1616ce987d2888c361d6cb3d5c3afa407b506f365132", "pubkey": "3327325c47cd736ff7b6960a646e8e38456e62cb2aa3cee04ac2560680ca8a3c", "created_at": 1686150509, "kind": 1, "tags": [ [ "e", "724c6f13ca667850218ef24a7051f9062418fb5d7bd972070be69e4bf08accba", "", "root" ], [ "e", "b625757b5cc93e9826b45bbd3cc2ebe543d9c4c83b9c248fed7ad7e1a6fe3b23", "", "reply" ], [ "p", "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1" ] ], "content": "📅 Original date posted:2013-11-02\n📝 Original message:I actually had a use case in my case where it was possible, and that was\nthe check I used to get around it, just configured it so that I always\ngenerated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.\n It was either that or making sure I had no unspent outputs. The use case\nof doing it was laziness in just creating a single key.\n\n\nOn Sat, Nov 2, 2013 at 7:33 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:\n\u003e \u003e This was one of my concerns when implementing a scheme where you sign a\n\u003e \u003e refund transaction before the original transaction is broadcast. I\n\u003e \u003e originally tried to pass a hash and have the server sign it. However, I\n\u003e \u003e had no way to know that what I was signing wasn't a transaction that was\n\u003e \u003e spending my coins! So I changed the code to require sending the full\n\u003e \u003e transaction, not just the hash. The other way to mitigate this is\n\u003e through\n\u003e \u003e not having any unspent outputs from this key.\n\u003e\n\u003e Well, there's no use case to sign with an address that has already been\n\u003e sent\n\u003e coins. The main problem with enforcing this is that you can't exactly stop\n\u003e someone from sending to an \"identity\" address.\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131102/8c7dc481/attachment.html\u003e", "sig": "588899774ecf6e990d7890fee7cf2eed48d9b4de6e64675220a6ba57320cfdd5c14ca8717c39370a4723fe9ef1c8daa7f0e9870313449b13191e232dfa54b1a1" }