📅 Original date posted:2015-04-16
📝 Original message:At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r" <s7r at sky-ip.org> wrote:
> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" <s7r at sky-ip.org <mailto:s7r at sky-ip.org>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from all the
> >> transactions in the latest 1000 blocks are version 'n' mark all previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet software to
> > be changed.
> >
> > --
> > Pieter
> >
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150416/17968d0a/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:32:30
in reply to nevent1q…mzqh
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:32:30Event JSON
{
"id": "ea5c365c402b2abd9fb2543ab901905a6bfa48df88583f1939c9328e0407f67d",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686151950,
"kind": 1,
"tags": [
[
"e",
"8b8a2347eb8a1165154b18f1aa6b1f8a0b99712f1e1f9461e574d86e0b7c9986",
"",
"root"
],
[
"e",
"84fb2212dbabcb66dc56a9c403101e51bfb8afc0cb2d2204677f914727342fa1",
"",
"reply"
],
[
"p",
"947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1"
]
],
"content": "📅 Original date posted:2015-04-16\n📝 Original message:At this moment anyone can alter the txid. Assume transactions are 100%\nmalleable.\nOn Apr 16, 2015 9:13 AM, \"s7r\" \u003cs7r at sky-ip.org\u003e wrote:\n\n\u003e Hi Pieter,\n\u003e\n\u003e Thanks for your reply. I agree. Allen has a good point in the previous\n\u003e email too, so the suggestion might not fix anything and complicate things.\n\u003e\n\u003e The problem I am trying to solve is making all transactions\n\u003e non-malleable by default. I guess there is a very good reason why BIP62\n\u003e will not touch v1 anyway.\n\u003e\n\u003e I am trying to build a bitcoin contract which will relay on 3 things:\n\u003e - coinjoin / txes with inputs from multiple users which are signed by\n\u003e all users after they are merged together (every user is sure his coins\n\u003e will not be spent without the other users to spend anything, as per\n\u003e agreed contract);\n\u003e - pre-signed txes with nLockTime 'n' weeks. These txes will be signed\n\u003e before the inputs being spent are broadcasted/confirmed, using the txid\n\u003e provided by the user before broadcasting it. Malleability hurts here.\n\u003e - P2SH\n\u003e\n\u003e In simple terms, how malleable transactions really are in the network at\n\u003e this moment? Who can alter a txid without invalidating the tx? Just the\n\u003e parties who sign it? The miners? Anyone in the network? This is a little\n\u003e bit unclear to me.\n\u003e\n\u003e Another thing I would like to confirm, the 3 pieces of the bitcoin\n\u003e protocol mentioned above will be supported in _any_ future transaction\n\u003e version or block version, regardless what changes are made or features\n\u003e added to bitcoin core? The contract needs to be built and left unchanged\n\u003e for a very very long period of time...\n\u003e\n\u003e\n\u003e On 4/16/2015 8:22 AM, Pieter Wuille wrote:\n\u003e \u003e\n\u003e \u003e On Apr 16, 2015 1:46 AM, \"s7r\" \u003cs7r at sky-ip.org \u003cmailto:s7r at sky-ip.org\u003e\u003e\n\u003e \u003e wrote:\n\u003e \u003e\u003e but for transaction versions? In simple terms, if \u003e 75% from all the\n\u003e \u003e\u003e transactions in the latest 1000 blocks are version 'n', mark all\n\u003e \u003e\u003e previous transaction versions as non-standard and if \u003e 95% from all the\n\u003e \u003e\u003e transactions in the latest 1000 blocks are version 'n' mark all previous\n\u003e \u003e\u003e transaction versions as invalid.\n\u003e \u003e\n\u003e \u003e What problem are you trying to solve?\n\u003e \u003e\n\u003e \u003e The reason why BIP62 (as specified, it is just a draft) does not make v1\n\u003e \u003e transactions invalid is because it is opt-in. The creator of a\n\u003e \u003e transaction needs to agree to protect it from malleability, and this\n\u003e \u003e subjects him to extra rules in the creation.\n\u003e \u003e\n\u003e \u003e Forcing v3 transactions would require every piece of wallet software to\n\u003e \u003e be changed.\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e Pieter\n\u003e \u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT\n\u003e Develop your own process in accordance with the BPMN 2 standard\n\u003e Learn Process modeling best practices with Bonita BPM through live\n\u003e exercises\n\u003e http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-\n\u003e event?utm_\n\u003e source=Sourceforge_BPM_Camp_5_6_15\u0026utm_medium=email\u0026utm_campaign=VA_SF\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150416/17968d0a/attachment.html\u003e",
"sig": "3b7d184c1b98929fd0963dbe2558927174a168556a82a2b04ba68b911dd495732b55f771d03e69d8689b1d29a2b3519f709144c77251440b6ca7de81c88214ad"
}