s7r [ARCHIVE] on Nostr: 📅 Original date posted:2015-04-18 📝 Original message:Understood. That is ...
📅 Original date posted:2015-04-18
📝 Original message:Understood. That is unfortunate, but not the end of the world. If you
could please give feedback also to these last comments / questions:
How far are we at this moment from BIP62? Can an user send a
non-malleable tx now, if enforces some additional rules?
As for the security of the system, it does not fully rely on txids being
non malleable, but see this quote from my previous email:
[QUOTE]
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
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...
[/END QUOTE]
Can you comment on the quote please?
So, basically transaction malleability could affect the system in the
way that a pre-signed tx which offers the insurance and which is sent to
the user before the user sends the coins (spending user's coins back to
him after a certain period of time) could be invalidated. The insurance
tx signature will still be good, but invalid overall since the input
(txid) being spent does not exist (was altered / modified). The coins
won't be stolen or lost, but a new tx needs to be signed with the
altered (new) txid, for the system to work.
So, an user creates a transaction TX1 sending the coins to the server
but does not broadcast it. Instead, he provides the txid of TX1 to the
server. Server generates another transaction TX2 which spends TX1 back
to the user, with an nLockTime. User checks and if everything ok
broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2
will become invalid (since it will be spending an inexistent input), and
the server will need to re-create and sign TX2 with the new
(altered/modified) txid of TX1, as per agreed contract. Should the
server disappear after user broadcasts TX1 and before the
altered/modified txid of TX1 gets confirmed, user's coins are forever
locked. It is true that no third party can benefit from this type of
attack, only the user will result with coins locked, but it is something
which could be used by competition to make a service useless / annoying
/ too complicated or less safe to use.
How could I mitigate this?
Thanks you for your time and help.
On 4/17/2015 12:02 PM, Pieter Wuille wrote:
>> 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.
>
> Don't assume that because it does not (frequently) happen, that it
> cannot happen. Large amounts of malleated transactions have happened in
> the past. Especially if you build a system depends on non-malleability
> for its security, you may at some point have an attacker who has
> financial gain from malleation.
>
>> >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)?
>
> In theory, yes, anyone can alter the txid without invalidating it,
> without mining power and without access to the sender's private keys.
>
> All it requires is seeing a transaction on the network, doing a trivial
> modification to it, and rebroadcasting it quickly. If the modifies
> version gets mined, you're out of luck. Having mining power helps of course.
>
> After BIP62, you will, as a sender, optionally be able to protect others
> from malleating. You're always able to re-sign yourself.
>
> --
> Pieter
>
Published at
2023-06-07 15:32:31Event JSON
{
"id": "97a3361c7df816ef9bb57dc0f4fa9d2fa9704a8caff79f80bbafa5023ddb1eb7",
"pubkey": "947955301a8805054c8d6a2c9ac2abf07a7a18f4a33b0a573a277868302953b1",
"created_at": 1686151951,
"kind": 1,
"tags": [
[
"e",
"8b8a2347eb8a1165154b18f1aa6b1f8a0b99712f1e1f9461e574d86e0b7c9986",
"",
"root"
],
[
"e",
"416ef745675a55f0f8dd54d3c7d289b46167eee24a3ee3b82f9d545eb12d3f69",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-04-18\n📝 Original message:Understood. That is unfortunate, but not the end of the world. If you\ncould please give feedback also to these last comments / questions:\n\nHow far are we at this moment from BIP62? Can an user send a\nnon-malleable tx now, if enforces some additional rules?\n\nAs for the security of the system, it does not fully rely on txids being\nnon malleable, but see this quote from my previous email:\n\n[QUOTE]\nI am trying to build a bitcoin contract which will relay on 3 things:\n- coinjoin / txes with inputs from multiple users which are signed by\nall users after they are merged together (every user is sure his coins\nwill not be spent without the other users to spend anything, as per\nagreed contract);\n- pre-signed txes with nLockTime 'n' weeks. These txes will be signed\nbefore the inputs being spent are broadcasted/confirmed, using the txid\nprovided by the user before broadcasting it. Malleability hurts here.\n- P2SH\n\nAnother thing I would like to confirm, the 3 pieces of the bitcoin\nprotocol mentioned above will be supported in _any_ future transaction\nversion or block version, regardless what changes are made or features\nadded to bitcoin core? The contract needs to be built and left unchanged\nfor a very very long period of time...\n[/END QUOTE]\n\nCan you comment on the quote please?\n\nSo, basically transaction malleability could affect the system in the\nway that a pre-signed tx which offers the insurance and which is sent to\nthe user before the user sends the coins (spending user's coins back to\nhim after a certain period of time) could be invalidated. The insurance\ntx signature will still be good, but invalid overall since the input\n(txid) being spent does not exist (was altered / modified). The coins\nwon't be stolen or lost, but a new tx needs to be signed with the\naltered (new) txid, for the system to work.\n\nSo, an user creates a transaction TX1 sending the coins to the server\nbut does not broadcast it. Instead, he provides the txid of TX1 to the\nserver. Server generates another transaction TX2 which spends TX1 back\nto the user, with an nLockTime. User checks and if everything ok\nbroadcasts TX1. In case the txid of TX1 will be altered/modified, TX2\nwill become invalid (since it will be spending an inexistent input), and\nthe server will need to re-create and sign TX2 with the new\n(altered/modified) txid of TX1, as per agreed contract. Should the\nserver disappear after user broadcasts TX1 and before the\naltered/modified txid of TX1 gets confirmed, user's coins are forever\nlocked. It is true that no third party can benefit from this type of\nattack, only the user will result with coins locked, but it is something\nwhich could be used by competition to make a service useless / annoying\n/ too complicated or less safe to use.\n\nHow could I mitigate this?\n\nThanks you for your time and help.\n\nOn 4/17/2015 12:02 PM, Pieter Wuille wrote:\n\u003e\u003e Anyone can alter the txid - more details needed. The number of altered\n\u003e\u003e txids in practice is not so high in order to make us believe anyone can\n\u003e\u003e do it easily. It is obvious that all current bitcoin transactions are\n\u003e\u003e malleable, but not by anyone and not that easy. At least I like to\n\u003e think so.\n\u003e \n\u003e Don't assume that because it does not (frequently) happen, that it\n\u003e cannot happen. Large amounts of malleated transactions have happened in\n\u003e the past. Especially if you build a system depends on non-malleability\n\u003e for its security, you may at some point have an attacker who has\n\u003e financial gain from malleation.\n\u003e \n\u003e\u003e \u003eFrom your answer I understand that right now if I create a transaction\n\u003e\u003e (tx1) and broadcast it, you can alter its txid at your will, without any\n\u003e\u003e mining power and/or access to my private keys so I would end up not\n\u003e\u003e recognizing my own transaction and probably my change too (if my systems\n\u003e\u003e rely hardly on txid)?\n\u003e \n\u003e In theory, yes, anyone can alter the txid without invalidating it,\n\u003e without mining power and without access to the sender's private keys.\n\u003e \n\u003e All it requires is seeing a transaction on the network, doing a trivial\n\u003e modification to it, and rebroadcasting it quickly. If the modifies\n\u003e version gets mined, you're out of luck. Having mining power helps of course.\n\u003e \n\u003e After BIP62, you will, as a sender, optionally be able to protect others\n\u003e from malleating. You're always able to re-sign yourself.\n\u003e \n\u003e -- \n\u003e Pieter\n\u003e",
"sig": "d36ae16459c9271af543cfc603c221a90ebc4a1b4c135ece8f2b5984fb6c73a326fc77efbf12d25d93a35ec214a19f06cddcc420f147968be2c0bc3a7cd20598"
}