TX Malleability

[Hyena]

I have debated quite a few SegWit supporters. It seems to me their main argument is that SegWit will fix Transaction Malleability. Well it does, sure, but in a really ugly way. The vulnerability should definitely be fixed but programmically in a clean and elegant manner. BU support has recently dropped but I keep on debating SegWit fanboys. I need more ammo though. It would be super nice if Bitcoin Unlimited had its fix for TX Malleability.

Also, I'd like to have an option for my Bitcoin Unlimited node to deliberately reject all SegWit TXs. Even if SegWit gains super consensus I don't want to relay its transactions. Anyone else thinks it would be a good idea?

 

[solex]

@Hyena Welcome to bitco.in/forum!
Certainly good to see you here. I am in awe at your staying-power on bct.

In line with hard-forks (general upgrades) are OK philosophy then malleability can be properly fixed in a clean manner for all transactions.

Our front-runner for this is BUIP037 which is an HF version of SegWit with the controversial stuff left out, and adopting aspects of Classic's FlexTrans.

In terms of a BU patch in the case of SegWit activation I imagine a lot of people will be asking for the same thing. Plenty of water to go under the bridge first though.

BU support with the miners is still strong, except that BitFury makes life hard by massively ramping up its hash-rate.

 

[AdrianX]

@Hyena Hi and welcome

re: "I'd like to have an option for my Bitcoin Unlimited node to deliberately reject all SegWit TXs."

BS/Core have already seen to that request, only segwit nodes relay segwit transactions, Bitcoin nodes will not relay segwit transactions because they are non standard.

that fact has a number of ramifications - firstly reducing the effectiveness of the network, security and nullifying the position to a hard fork is bad because it is reducing the number of nodes that don't upgrade.

re: It would be super nice if Bitcoin Unlimited had its fix for TX Malleability

What exactly is broken and who is asking for the fix?

So much this. Why is it that in the last three years, we have seen lots of efforts for off-chain stuff, and potentially quite dangerous off-chain stuff at that (and, yes I am now getting more and more firmly against 'fixing' malleability until we have a clear path forward on open-ended blocksize and a clear picture on what we would gain/lose by 'fixing' it). Whereas nothing on the comparatively simple UTXO commitment front?

Ok, Ptodd and Mr Bittorrent are discussing that on the ML. At least I have seen that. So the idea is out there.

But UTXO commitments should be a priority.

Oh, I also must say that I welcome Jorge Timon (jtimon is his reddit handle, correct?) at least starting to ask what could be done about Segwit to let it pass. This shows a) that we're a force now that is being taken serious by them and b) Blockstream might have learned to take the propaganda job away from Greg.

I am still very reluctant regarding 'fixing' malleability and SegWit, but at least it is good that he seems to appear to be more willing to talk.

With Greg, there were moments where it seemed like he wanted to talk/discuss/bargain , but he always pulled back from that in the last moment.

I am willing to entertain the idea that Jorge Timon is a more reasonable guy.

and my thoughts

The framing needs to change - malleability is associated with MtGox as being the reason people lost money, hence a bug. it doesn't look like a bug but more like a feature. Why is it something that needs to be fixed?

It's a feature that's preventing moving fee paying transactions off the blockchain, fees being a good thing that secure the blockchain as the subsidy diminishes.

Malleability is a behavior that encourages network participants using the network in other ways to have functions other than money confirm on the blockchain. Its functions should be defined and agreed before it's classified as something needing a fix, it's not a bug it's not harmed bitcoin, if anything it's been a scapegoat used to arguer fraud and that bitcoin is not broken and works for everyone, fix this and we fix fraud (NOT).

Bitcoin Transaction Malleability puts individual users who want to be their own bank on the same playing field as multinational corporations who want to use bitcoin to build a private banking layer on top of bitcoin, why remove it?

Fixing malleability is like fixing your cat.

It's the owner that gets to define the problem and it's the cat that gets fixed. (The cat works just fine with it's manhood intact)

Malleable transaction haven't stopped Bitcoin from working. In fact malleable transactions prevent types of applications that move fee paying transactions off the Bitcoin network and onto other networks like the Lightning Network - resulting in less fees to pay for bitcoin security

 

[SamG]

Malleability is an obvious problem for smart contracts or any applications with bitcoin that require chaining transactions. The benefit of the backwards compatibility that Core implemented in the SegWit soft-fork is that existing services with standard tx can continue to be used, and new services can be developed to take advantage of the witness block.

Furthermore, it doesn't have to be perfect the first time around. If BU really does intend to continue development, it can be cleaned up and optimized with additional updates.

I can already see that BU will likely splinter very quickly with infighting over this very issue.

 

[AdrianX]

@SamG thanks for your input. What do you say to the concerns @awemany made above?

 

[bitPico]

This can be fixed in all of 5 minutes. You simply strip the script sig portions that can be modified "in-flight" and hash it to obtain the Transaction ID. This is a consensus rule change but so is SegWit's 50,000 lines of code.

This solution was deployed into Zcash.

 

[deadalnix]

And this is hard fork, so highly disruptive so you'd better have some bang for the bucks.

 

[AdrianX]

@bitPico thanks for your input. What do you say to the economic incentive design concerns @awemany made regarding transaction malleability a few posts up?

as you point out it's easy to fix transaction malleability from a technical perspective however it seems it would have economic implications and come bagged with political ideologies, what are your toughs on the economic issues?

 

[bitPico]

@AdrianX It is a technical issue, I leave emotions out of it. Economically it would be positive and protect exchanges and merchants further, it is a bug (in-flight modification) but could be deployed as a BIP9 Soft Fork if done properly.

 

[AdrianX]

Thanks, @bitPico so given malleable transaction haven't stopped Bitcoin from working, in fact it encourages waiting for on chain confirmations when using the blockchain for other applications or smart contracts. The technical fix seems then to be a low priority for the vast majority of bitcoin users (almost all but for a hand full of corporations), do you see any reason to deploy it sooner than when the network is ready for it, say withing the next 10-15 years.

I believe it would be technical astute to wait until the at least the block limit has been increased, as malleable transactions prevent types of applications that move fee paying transactions off the Bitcoin network and onto other networks like the Lightning Network - resulting in less fees to pay for bitcoin security.

So leaving emotions out of it, how do you assess the benefit of pushing a malleability fix before increasing the block size knowing it will give off chain payment networks artificial stimulation at the expense of bitcoin transactions that pay fees to secure bitcoin?

 

[deadalnix]

@AdrianX It is a technical issue, I leave emotions out of it.

Economically it would be positive and protect exchanges and merchants further,

You may want to stop contradicting yourself if you want to be taken seriously.

it is a bug (in-flight modification) but could be deployed as a BIP9 Soft Fork if done properly.

You haven't explained how to do this so far. The fact you already proposed what you think is a solution, and that it is a hard fork shows you either don't understand the problem you are trying to solve well enough, or you are willfully deceptive.

 

[bitPico]

Thanks, @bitPico so given malleable transaction haven't stopped Bitcoin from working, in fact it encourages waiting for on chain confirmations when using the blockchain for other applications or smart contracts. The technical fix seems then to be a low priority for the vast majority of bitcoin users (almost all but for a hand full of corporations), do you see any reason to deploy it sooner than when the network is ready for it, say withing the next 10-15 years.

I believe it would be technical astute to wait until the at least the block limit has been increased, as malleable transactions prevent types of applications that move fee paying transactions off the Bitcoin network and onto other networks like the Lightning Network - resulting in less fees to pay for bitcoin security.

So leaving emotions out of it, how do you assess the benefit of pushing a malleability fix before increasing the block size knowing it will give off chain payment networks artificial stimulation at the expense of bitcoin transactions that pay fees to secure bitcoin?

LN won't work with a simple malleability fix but we would get the benefits of safer zero confirmation transactions.

 

[AdrianX]

Zero confirmation transactions being a subjective preference, and are not a necessity for bitcoin, so apart from this emotional appeal to those who may value them, do you have any technical responses to the question proposed above?

PS transaction malleability is not the reason some people try zero confirmation double spends.

 

[bitPico]

"Since 0-confirmation transactions are practically useful for people, we encourage innovations that enhance their security without undermining other key properties of the Bitcoin network." - The Bitcoin Unlimited Articles of Federation

Malleable transactions make double spending easier because at ZERO COST you can modify the original transaction and amplify mutated copies of it confusing remote wallets before reusing the same inputs with a higher fee and causing a double spend.

I've been a bitcoin developer for 3.5 years and coded a high performance full node and SPV client implementation in C++11. I also operate an Unlimited mining farm of several Petahashes and have large holdings in BTC. I have a deep knowledge of all aspects Bitcoin and all of my skin in the game. ;-)

To answer your question: There is no benefit of deploying a malleability fix until Unlimited has majority hash rate and has completed it's fork. I feel this way about all time consuming or consensus related proposals.

 

[freetrader]

coded a high performance full node and SPV client implementation in C++11.

That sounds interesting. Is it open source?

 

[bitPico]

@freetrader A few months and it will all be open sourced here: https://github.com/bitPico

The code is Unlimited aware and will implement xthin, etc as we plan to follow the Unlimited roadmap and hopefully can form a standards group. We are just polishing up the GUI's right now and dealing with Apple is always a struggle.

 

[AdrianX]

@bitPico just to be clear: the Bitcoin Unlimited Articles of Federation are not infallible - that point was added as a reaction to RBF and in support of Sub-chains and the overriding idea behind bitcoin being digital cash.

While removing transaction malleability is partially supported by BU's mandate your argument comes with trad offs those trade offs need to be understood and evaluated, not ignored.

To answer your question: There is no benefit of deploying a malleability fix until Unlimited has majority hash rate and has completed it's fork. I feel this way about all time consuming or consensus related proposals.

BU is not completing a fork, BU just removes friction and risk that allows the Bitcoin network to just upgrade by removing the block size limit if and when it deems it necessary.

There is enough ambiguity around soft and hard forks to just look at all changes objectively and assess all risks and benefits without categorizing them - the arbitrary labeling of soft and hard does not help in the analyzing of risks and benefits.
[doublepost=1488999530][/doublepost]ps @bitPico - a "feature" of this forum is you can't quote the comment above yours. If you do 2 posts in a row they are combined. - makes for easy reading - so I'm told.
you can always cut and past between [ quote=anyname ] the quote [ /quote ]

for a result like this

the quote

or whatever. ;-)

 

[SamG]

How do you think the impasse over a tx malleability fix will impact many projects currently waiting for a fix? I suspect they may just run out of money and give up, knowing that BU has no intentions of fixing this issue in the near future.

 

[bitPico]

If Unlimited has no intentions of fixing malleability then they will not gain much support from Merchants. Merchants cannot have wallet corruption due to "in-flight" modification of script's. This is a flaw, and I don't support people calling it a feature.

LN cannot function without SegWit so fixing malleability isn't going to help Core or anyone else.

Those that say Unlimited is not forking Bitcoin are silly. Bitcoin XT and Classic had the courage to call it a fork, we should be honest and not deceptive since it is by fact a hard fork that will win via the most proof of work. Let's not be like Core and tell half truths or spin things.

 

[SamG]

I agree 100% bitPico with your sentiments about fixing tx malleability.

At this point, I am giving up on Bitcoin and selling all but a small amount.

Two reasons:

1) If the Bitcoin network can be taken over through a coordinated effort of ASIC manufacturers, mining pools, and one of the most influential & wealthy bitcoiners, this does not bode well for the future of decentralization.

2) The much needed fix for tx malleability won't happen because BU will block SegWit, and the BU team will never agree on the best way to implement it. It's especially worrisome since many wallets, exchanges, and device manufacturers have already invested the time to support SegWit.