Bitcoin Forum
May 22, 2019, 02:12:33 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Paper discusses solution to transaction malleability  (Read 1830 times)
malefice
Newbie
*
Offline Offline

Activity: 37
Merit: 0


View Profile
January 08, 2014, 03:03:27 PM
Last edit: January 08, 2014, 11:13:17 PM by malefice
 #1

This paper suggests to leave out input scripts in the tx hashes, so that a tx can not be duplicated with a nonce.
It seems a good idea, can we lobby for discuss this with the core developers?

http://eprint.iacr.org/2013/837.pdf
Get signals when whales enter & exit a market 74% average win rate
full binance integration
TRY NOW!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558491153
Hero Member
*
Offline Offline

Posts: 1558491153

View Profile Personal Message (Offline)

Ignore
1558491153
Reply with quote  #2

1558491153
Report to moderator
1558491153
Hero Member
*
Offline Offline

Posts: 1558491153

View Profile Personal Message (Offline)

Ignore
1558491153
Reply with quote  #2

1558491153
Report to moderator
1558491153
Hero Member
*
Offline Offline

Posts: 1558491153

View Profile Personal Message (Offline)

Ignore
1558491153
Reply with quote  #2

1558491153
Report to moderator
Altoidnerd
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


http://altoidnerd.com


View Profile WWW
January 08, 2014, 09:21:37 PM
Last edit: January 08, 2014, 09:34:16 PM by Altoidnerd
 #2

1) Is there a reason that the hashes of transactions currently depend on the input scripts? Wondering if the modification of section [3.2] has any drawbacks.  

>>We propose to compute those hashes over the transaction without its input scripts...

is a quickly presented essential prerequisite for this proposal.

2) I was immediately concerned with "simultaneous" as used in the introduction, which leads me to section 4 in the preconditions box, #6.  Is maxBB a time corresponding to the expected time required for the next block to be mined, or something else?

Do you even mine?
http://altoidnerd.com 
12gKRdrz7yy7erg5apUvSRGemypTUvBRuJ
iddo
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250


View Profile
March 04, 2014, 04:20:08 PM
 #3

Given the recent interest in transaction malleability, I'd like to bump this old thread.

The suggestion in this paper (section 3.2) is to get rid completely of TXID in the Bitcoin protocol itself, and use only NTXID to reference a transaction (i.e. hash of the simplified transaction without the input scripts).

I'm trying to understand what are the problems with this simple suggestion.
What I can see is that we would lose some of the expressive power that Bitcoin scripts currently allow. For example, Suppose that Alice can redeem an unspent output whose script is of the form (if w1 then true, else if w2 then true, else false), meaning that there can be two different witnesses w1 and w2 (for example preimages of hashed values H(w1),H(w2)) that Alice can provide to redeem the coins. So when Alice broadcasts a transaction that redeems that unspent output, and her transaction is added to the blockchain, the blockchain NTXID hash wouldn't express whether Alice revealed w1 or w2. Therefore, if Bob and Carol have some contract that says "if Alice knows w1 then Bob gets 5 BTC from Carol, and if Alice knows w2 then Carol gets 5 BTC from Bob", then Bob and Carol wouldn't be able to rely on the NTXID in the blockchain in order to settle their contract (there would be plausible deniability that Alice broadcasted the other witness).

Is that the only kind of problem, or are the much more immediate/crucial problems that I failed to see? (other than making sure that generation transactions have a unique NTXID, which is mentioned in that paper). If this was discussed before, please just give me a link to the relevant info (I searched but didn't find much).


Also, a different question: would it be possible to eliminate all the mutations (like subtracting secp256k1_order from the S value of the ECDSA signature) in nonstandard scripts, or only in standard scripts? It seems to me that nonstandard scripts can always simulate NOOP operations, therefore malleability is inherent? If that's the case, maybe there should be some sort of an updated standard-v2 scripts that are still restricted more general than the current standard scripts, where these standard-v2 scripts cannot be mutated?
iddo
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250


View Profile
March 06, 2014, 04:42:16 PM
 #4

I'll reply to myself, because I discussed it with Bitcoin devs at #bitcoin-wizards (freenode IRC), so they shouldn't waste their time replying here too.

The issue with that simple suggestion indeed appears to be along the lines of what I suspected it to be. From the point of view of programmers who are responsible to deploying the protocol, it may still make sense to simplify and use only NTXID, i.e. to compromise and lose some of the expressive power that Bitcoin scripts allow. There could also be other options, such as attaching the signature (for the implicit message of the entire transaction) outside of the ScriptSig input-script.

Fortunately, we can indeed get rid of transaction malleability with a softfork that keeps the current scripts infrastructure in place. The thing that I missed about NOOP operations w.r.t. malleability is that the ScriptSig input-script (that doesn't get signed) doesn't really need to contain executable opcodes, only data. In other words, if the user can redeem an unspent output by providing a witness w that satisfies a circuit (script) phi(w)==true, then it's too general to require that w can be an executable circuit in itself. If I understand correctly, this sensible restriction is specified as new rule #4 at https://gist.github.com/sipa/8907691
FiatKiller
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
March 06, 2014, 04:51:53 PM
 #5

So, a summary for the people without a 160 IQ... they are planning on implementing a change soon to prevent this?

LTC: LdxgJQLUdr8hZ79BV5AYbxkBUdaXctXAPi
MoonCoin Gambling: https://coin-horse.com/MON/
Lukasz Mazurek
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
March 12, 2014, 11:43:01 PM
 #6

Iddo, you are right that there are some scenarios in which we would lose some expressive power of contracts. However, we are not aware of any known contracts which would be affected this way.

On the other hand, our change has a significant advantage for the contracts over the proposed softfork, namely it allows to sign a transaction B which redeems A before A is signed. In this case we cannot compute TXID(A) (and therefore create the transaction B) because it depends on the signature on A and the sender of A is always able to create multiple valid signatures on it. Usage of NTXID would allow to create and sign a chain of transactions with input scripts, which will be determined later. We believe it substantially enhances the possibilities of designing contracts.
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 541
Merit: 514


View Profile WWW
March 13, 2014, 07:54:18 PM
 #7

My suggestion:
Create a new opcode:
 PUSH_SIG <n>

Which pushes a signature on the stack, where the signature is taken as the n-th element from a vector that is appended to the transaction but it is not part of the transaction hash. So transaction inputs are left IN the transaction, but signatures are NOT.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1002


View Profile
March 13, 2014, 08:10:57 PM
 #8

My suggestion:
Create a new opcode:
 PUSH_SIG <n>

Which pushes a signature on the stack, where the signature is taken as the n-th element from a vector that is appended to the transaction but it is not part of the transaction hash. So transaction inputs are left IN the transaction, but signatures are NOT.

That is a hard fork right?  If so, then using the (no inputs) signature hash instead of the full transaction hash for previous inputs seems like a better plan.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!