š
Original date posted:2015-04-16
š Original message:On 4/16/2015 8:34 PM, Mark Friedenbach wrote:
> At this moment anyone can alter the txid. Assume transactions are 100%
> malleable.
>
Anyone can alter the txid - more details needed. The number of altered
txids in practice is not so high in order to make us believe anyone can
do it easily. It is obvious that all current bitcoin transactions are
malleable, but not by anyone and not that easy. At least I like to think so.
>From your answer I understand that right now if I create a transaction
(tx1) and broadcast it, you can alter its txid at your will, without any
mining power and/or access to my private keys so I would end up not
recognizing my own transaction and probably my change too (if my systems
rely hardly on txid)?
> On Apr 16, 2015 9:13 AM, "s7r" <s7r at sky-ip.org <mailto: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> <mailto: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
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
s7r [ARCHIVE] /
npub1j3ā¦cwg9h
2023-06-07 15:32:30
in reply to nevent1qā¦j372
Author Public Key
npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9hPublished at
2023-06-07 15:32:30Event JSON
{
"id": "f93254b61e8b53a659aeada4830b36f17c120ea9e94b919d1c469b33c9e4cc7a",
"pubkey": "947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1",
"created_at": 1686151950,
"kind": 1,
"tags": [
[
"e",
"8b8a2347eb8a1165154b18f1aa6b1f8a0b99712f1e1f9461e574d86e0b7c9986",
"",
"root"
],
[
"e",
"ea5c365c402b2abd9fb2543ab901905a6bfa48df88583f1939c9328e0407f67d",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "š
Original date posted:2015-04-16\nš Original message:On 4/16/2015 8:34 PM, Mark Friedenbach wrote:\n\u003e At this moment anyone can alter the txid. Assume transactions are 100%\n\u003e malleable.\n\u003e \n\nAnyone can alter the txid - more details needed. The number of altered\ntxids in practice is not so high in order to make us believe anyone can\ndo it easily. It is obvious that all current bitcoin transactions are\nmalleable, but not by anyone and not that easy. At least I like to think so.\n\n\u003eFrom your answer I understand that right now if I create a transaction\n(tx1) and broadcast it, you can alter its txid at your will, without any\nmining power and/or access to my private keys so I would end up not\nrecognizing my own transaction and probably my change too (if my systems\nrely hardly on txid)?\n\n\u003e On Apr 16, 2015 9:13 AM, \"s7r\" \u003cs7r at sky-ip.org \u003cmailto:s7r at sky-ip.org\u003e\u003e\n\u003e wrote:\n\u003e \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\n\u003e 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\n\u003e \u003cmailto:s7r at sky-ip.org\u003e \u003cmailto:s7r at sky-ip.org \u003cmailto:s7r at sky-ip.org\u003e\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\n\u003e all the\n\u003e \u003e\u003e transactions in the latest 1000 blocks are version 'n' mark all\n\u003e 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\n\u003e 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\n\u003e 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 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 \u003cmailto:Bitcoin-development at lists.sourceforge.net\u003e\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "51a00a02e469d017123f48d7dec4823730347e083932232a727df1ee6f0402c7cc86165c5b1c70f09fb8b3eafbd6b9cd2556f311e229528af4ad3c67cac4c7fc"
}