Bitcoin Pastebin Series

"Malleability School" (On Bitcoin; 2017)


Thing of the day
Who knows what this is?


In terms of metallurgy I have a reasonable idea.


changing txid post submission, yeah?


S to -S
Due to the symetric nature of EcDSA


so, you brought it up, got a proposal?


3rd Party for that at least

Proposal... for what?

It is not an issue. That is the proposal


a fix or for people to stop making it seem like the end of the world


That addresses ECDSA S and -S by rejecting -s

No, education so they see it is all a lie

I am going to start here.

And work out

Arguably, benign malleability is always present in that a given piece of data often has multiple encodings, and any non-malleable scheme can be transformed into a benignly malleable one by applying such an encoding,

So, anything they do always has some form of malleability.

That already started

The “attack” involved not only extracting the signature, but also changing R to R’ in the elliptic curve cryptography.

That is NOT benign malleability, it is a miner crafting their own TXs. Miners CANNOT change other people's R values

In Bitcoin, the (r,s) pair is set following BIP 66 to not allow (R, -s)

S could in non-DER be changed to -s

But it cannot have R changed without access to the PRIVATE Key

So, this is NOT a malleability attack

It was a lie as is all the BS


Misreporting then?





So, where now is this need to change the protocol drastically?

Active malleability is something that Blocks solve, when it is in a block, it is not able to be altered

Benign malleability is a BIP 66 solution (and it was never an issue in any event) just bad process


so, BCC¹ devs discussing rolling block generation would also solve?

(¹an early acronym for the chain which did not fork to segwit)


You cannot solve something that is not broken

So, the change is, a user makes a change to a TX and doublespends.

Double spends when you have a private key are not something that can be solved other than to stop RBF and other anti-0-conf ideas


Just interjecting that I love that BSCore see Malleability as a gaping hole that needs fixing yet RDF is fine


That is just it

Malleability was the false flag used to make things like RBF and segwit seem needed

More generally, if one or more of the signers of the transaction revise their signatures then the transaction remains valid and pays the same amounts to the same addresses, but the txid changes completely because it incorporates the signatures. The general case of changes to signature data (but not the outputs or choice of inputs) modifying the transaction is called scriptSig malleability.

Bitcoin Core

Segregated Witness Benefits

That was called - a changed TX and SegWit does not fix this.

Then they say

Segwit prevents third-party and scriptSig malleability by allowing Bitcoin users to move the malleable parts of the transaction into the transaction witness, and segregating that witness so that changes to the witness does not affect calculation of the txid.

We have A.

We do B

But, it is done as a magic trick where you do not see that they talk about one senario and address a separate one


Hocus Pocus.


Bitcoin Transaction 683f45578328242a06bc5c54acbcbe6e70a5435b4561fc8b0570a59ab09f8bfa

This is the example used

That is why BS Core say it needs fixing

The transaction is INTENTIONALLY designed to be able to be signed once and sent in separate forms.

That is ALSO not addressed in SegWit

*So, the so-called attack*

Alice makes a TX and sends it to Bob

Bob has control of a LARGE (>50%) of miners (or this is just a probabilistic senario.

Bob uses his nodes to accept (r,-s) (which was depreciated in BIP30, BIP66 with DER enforcement)

Alice watches for the TX ID to go to BOB and be on the blockchain

Alice IGNORES the Bitcoin address that she sent coin to. This will show Alice -> Bob, but she looks only to find the TXID associated with (r,s)

Alice decides... oh, this is slow... I will send again and again as I want Bob not to miss out

Alice watcher her wallet show unconfirmed TX after unconfirmed TX as her balance goes down

But states, "what the Fuck" and keeps sending

Bob runs off with the money

*So, seem realistic*



If Bob keeps insisting he didn't receive it, maybe.

And Alice would have to be plenty stupid.


The TX is STILL recorded as Alice to Bob

If she uses Block Explorer, she can show Bob that the TX is there...

The assumption is that Bob will be looking for a TXID and that is also what Alice watches and that they ignore all other information

When we consider non-benign malleability, that is also known as a double spend. It cannot be changed with FT or SegWit


Well I always search by address so it wouldn't catch me.


Before continuing, I want to re-emphasize that Bob can’t change where Alice’s money comes from, where it goes, or how much is sent. These parameters are all cryptographically signed by Alice, using her private key. Bob can really just change the actual txid shown to humans. How does this work exactly?

So, as Core state....

*Bob can’t change where Alice’s money comes from, where it goes, or how much is sent.*


In other words, it's so obscure as to not ever need "fixing" at all.




And only if the wallet really is fucked

And Alice is dumb

The Miner attack on Malleability is - a classic double spend.

So, NOT solved


In a basic TX (not one designed to be malleable with additions and which is easy to ignore), how many possible signature pairs are there for each Sig?


so, what's the point of eliminating signatures?


It saves a few bytes.


i mean, even if they introduce centralized authority, will they just re-introduce signatures?


makes them have patents around Bitcoin


they're unilateral contracts as is, and fully binding


NO, they will hold them on their own nodes that the rest of us do not see


oh, and maybe one day they will introduce showing us the signatures for a fee, for anyone wanting to keep the full chain on a new rPi node


but theoretically, i could run a LN node if i had capital to do so as well, so i would see the txs, but still none of these nodes would be able to pull signature data, since it's gone and the signatures were never recorded

i mean, why don't you want signatures EVER viewable again?

is it privacy through obscurity?


@CSW Have you looked at Tomas van der Wansem's Malleability fix proposal?

- Leaves Tx format unchanged, except for re-defining "previous-tx" field for Tx inputs

- Merkle tree construction remains exactly the same, including Full sig data in Merkle leaf


Yes @Xenophon


i mean, if you take away signatures, you can bring into question the legal status of bitcoin

it' isn't fungible anymore

you can't prove person A was person A and in fact paid person B


@mengerian Why?

I am working on getting it all together

There are just so many false ideas to get fixed

It is taking time


thanks for that


@mengerian That BIP seems ok, but for why? It is a fix for something that is easy to fix without all the changes and that does not address the real issue


Why do the Mallleability fix? Some of the miners seem to want it, I'm not sure precisely why.




They have been taught the lie


But at least that proposal leaves the construction of the Merkle tree unchanged


Hardly  a one of them understands that this idea is *Nonintentional malleability becomes impossible.* - but the attack is INTENTIONAL

Preventing scriptSig malleability is being considered as well. Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed, and eventually this rule may extend to enforcing that the stack have exactly one item after execution. However doing that may interfere with later extensions to Bitcoin.


Yeah, the originator of the Tx could still mine a block full of "malleated" sigs


This is the other thing.

BS CORE have MAST and Alpha

They have been teaching us that scripts that can change are BAD

They want to have all the scripting as they have things to lock you into sidechains

Tomas does not and cannot fix non-benign malleability


I don't have a strong opinion about malleability, but I like Tomas' approach because it makes the minimal change needed

So at least that way it can be evaluated more easily


It is only when a block is mined that this is never possible

Before, it is probabilistic

Tomas van der Wansem has the best approach to a change that should not be made.


Ha ha 🙂


Tomas of course also makes a form that is not compatible with later script use

Right now, if a TX has anything other than data push operations in their scriptSig are considered non-standard and are not relayed ***********************

But, this can be fixed and changed in Cash

BS Core DID NOT want to have script as this would make sidechains and Alpha of no use

That does not preclude this from being something that Cash again does, as scripts are NOT spam if you pay for it ***************************

And miners *EARN MORE*

Special TXs can be costed at a higher rate

This, miners make fees

Cash is cheap, script and contracts cost

Here is the other thing... the thing core say is crap...

Implement Business rules

If an exchange has a withdraw, do not just assume when a client states they are not paid that the TX was not sent!


Move funds to a pay address

So, Alice has 10 BCH in wallet A1

She needs to pay 5 BCH to Bob later on. She can move 5 BCH to Alice's own wallet, A2

Now, she cannot spend more than 5 BCH as the TX will only allow the amount she holds to be spent.

If Alice is tricked (stupid girl) into sending a second amount from A2 to Bob, she does this, but the wallet only has 5BCH

Hence, it fails if the other is in a block

Issue solved.

Adding these *Malleability fixes* kills off a lot of script uses that we can have working again now that we are not seeing coloured coins and document signing and gambling as spam! ***************



my latte has arrived

thank the gods




I don't understand how the Malleability fix kills off the other use cases, I'll have to research it more.


Love my SatoshiDice. 🙂


But at least Tomas' proposal is a "minimal" approach, so it lets us understand the change in isolation without all the other changes that Flex Trans makes



It means that data that can be validly changed in script (and hence that alters the TXID) is not valid

Yes, it is a minimal approach, but to ensure we cannot easily enable scripting and all its ability again

That leads us right into the Core path

They get Alpha and sidechains

We have... low value TXs and no more

Hence, I am starting to try and educate people as to what Malleability really is


Yeah, I think part of the motivation is to enable Lightning-type off chain stuff


And it is ONLY benign malleability that can be changed by others

And the values are s or -s

Then only allow DER S sigs

Detect and ignore -s


Any approach lets the originator change the script.

It only makes subsequent Tx's that refer to it become non-valid


Alice can ALWAYS try and doublespend


Sighash, Anyone can pay


I believe Cash already enforces the strict DER


They do

So, 99.99% of the issue is not a Cash issue that we are solving....

So, you use SIGHASH_ANYONECANPAY and chain the TX that way

TX0 -> TX1 -> TX2



What in that is the attack?

To answer:

1. Added TXs over the value are added and the original output is fulfilled and a lucky miner earns more

2. A random party pays first and stops Allice needing to pay whilst having the TX go to her

I call that the random run up and pay for another persons purchase attack

In it, a person randomly runs over, dumbs cash on the table and runs off leaving you to leave the store without having paid and the store to be happy


"This ensure that the HF activates STRICTENCODING (just standard right now, not consensus)"...

Reject non replay protected transactions after the fork. · Bitcoin-ABC/bitcoin-abc@e49826c

Summary: This ensure that the HF activates STRICTENCODING (just standard right now, not consensus) and it'll reject any transaction not using SIGHASH_FORKID after the fork. To make sure we get a cl...

The only "attack" I know of was when BitClub mined some blocks where they purposely malleated all the transactions.

ViaBTC Complained about it.

But I'm not sure how serious of a problem the attack was. It seemed like more of an annoyance than a serious problem


It was also changing R to -R

That means they altered their own TX

A miner can always try and doublespend or change their own TX


Oh I was under the impression they altered other people's Txs

I can't see how you could prevent people from altering their own Txs


Only the originator can alter the R value in a TX

To change (R, s) to have -R means that you need to have access to the private key


Hmm, I thought they had altered ViaBTC transactions. Maybe I was mistaken


There was another "Attack" as well.

But that was not really an attack either


perpetuated by Bitclub, correct?


And again, S to -S just means checking


How did you guess

Everyone's fav miner it seems


Shillhard really is trying it seems


So, if all miners BUT Bitclub accept S and reject -S...

The change to reject -S is a "softfork" and miners can override this.



So, if DER changes such as BIP 66 were mandatory (which BS Core did not want as this is a HF and does not allow their story)

If a miner does the "attack"

They lose a block

Now, one of the examples P Wullie uses is:

F' P1 CHECKSIG NOT fails (changed)

F is any invalid but DER-compliant signature (including 0, the empty string). F' is any invalid and non-DER-compliant signature.

Now... How many times do you want to accept a script that is:


That NOT is generally a give away and is constructed to fail...


i get why its not a problem but why is mallaebility useful



Script mallability and SigHash types allows yhings such as secure high speed trades settled in 10 mins

It allows derivatives

It allows financial instruments to be created

All things Core wants on Alpha and encourages their shills to hate

Parallel processes


Option contracts

Loans and owner tokens

Without Eth


sounds like a good topic for the next Nchain blog post or CoinGeek


Getting there

Long year

Much to do


Can someone feel me in on what happened with Viabtc? How did someone changing a transactionid (I'm assuming through malleability) invalidate a transaction chain?


See above.

There is a softfork for malleability

This was ignored by a certain BTC club

The nature of signatures in EcDSA is they have two values:

(R, S) and (R, -S)

Anyone with the public key can calculate -S from S given the modulus (set in Bitcoin for the curve) and the public key - exposed to miners on sending a TX

The change there was to make a change and create a block using -S in place of S

That is it. That is the GREAT attack

The coin amounts and addresses they are paid to do not change


So because of that, the transactions in that block was seen as invalid by some nodes?


Negative S is not allowed as per BIP 66.


So I missed this, was this on the BTC or BCC chain?


It is not supposed to be allowed

DER encoding was set in BIP 66 as a soft fork


BIP 66 can be seen as the first attempt to fix malleability. But then some argued that there were more forms, such as changing the push-data opcode.


That is Script Malleability

And 66 was sofforked in place of a 62 harder fork


Yes. But because there are multiple ways to malleate the input scripts (not just the sigs), the idea of softforking out all forms was abandoned

Though I think  it may be possible to fix it that way.


And, As I wewnt over last night, there are 3 forms of malleability

And only one of these, bengin malleability is addressed

And for that matter, non-benign malleability cannot be addressed other than reverting away from RBF as Cash has done

As for methods - BIP 66 "Examples" Covered this


So just to clarify for laymen, this bug was introduced by RBF?


No, the attack was

Before RBF, if you malleated, the TX was still paid.

Now, with RBF, the user can change the TX as a double spend.

1. Alice pays Bob

2. Bob chains a TX to Charles

3. Bob watches for the TXID he has used

4. Alice malleates the TX and replaces it using RBF

5. Bob now has a payment to Charlie that fails.

Only works with RBF


stupid question, is RBF compatible with segwit transactions?



Bob has a sighash anycanpay

Then without RBF, the payment from Allice can be chained with malleability

Altering the R,S pair to R,-S means nothing and the payment from Bob to Charle goes through

Yes RBF is SegShit compatible

*The attack... if you call it this for sighash anycanpay....*

Mallory jumps in and sends money into Bob's TX before Allice

Alice keeps her money or sends to Bob

Bob sends to Charlie and either has funds from Alice or not

Alice, Bob and Charle have their money

But EITHER Alice or Bob has a refund from Mallory


I believe I understand how malleability can break chained transactions that are not yet comitted to the blockchain, but in relation to ViaBTC, did they have an entire mined block that was rejected because of the -s exploit?


I call it the haha I paid for your purchase and run  off attack


lol, that is quite the "attack"

the "pay it forward" attack


No, it was not a lost block


the transactions were just invalid so it's like it was an empty block? or what


As noted last night, this was an issue with TXID and ViBTC systems - not bitcoin, their business systems

ViaBTC Should have used separate addresses for each deposit. Then, they could have mapped the payment to the user.


So what motivation or message were they trying to spread by doing this?


ViaBTC needed to suspend deposits and withdrawls

It was a result of poor accounting practices


Other exchanges that re-used deposit addresses were not also affected?


The Attack was designed to cause a few issues - some know what business process failures an exchange has

Exchanges that map TXID and not the actual address deposit can be impacted

Malleability does not change the to nor from address nor the amount paid

Right now, if a TX has anything other than data push operations in their scriptSig are considered non-standard and are not relayed

But, this can be fixed and changed in Cash

BS Core DID NOT want to have script as this would make sidechains and Alpha of no use

That does not preclude this from being something that Cash again does, as scripts are NOT spam if you pay for it

And miners *EARN MORE*

Special TXs can be costed at a higher rate

This, miners make fees

Cash is cheap, script and contracts cost

Here is the other thing... the thing core say is crap...

Implement Business rules

If an exchange has a withdraw, do not just assume when a client states they are not paid that the TX was not sent!


Move funds to a pay address

So, Alice has 10 BCH in wallet A1

She needs to pay 5 BCH to Bob later on. She can move 5 BCH to Alice's own wallet, A2

Now, she cannot spend more than 5 BCH as the TX will only allow the amount she holds to be spent.

If Alice is tricked (stupid girl) into sending a second amount from A2 to Bob, she does this, but the wallet only has 5BCH

Hence, it fails if the other is in a block

Issue solved.

*So, the Business rule attack is...*

Find an exchange that has not implemented recommended practices.

Malleate a TX

Say you did not get a payment

Request the exchange send again

*Basically* something that banks solved in the 1700s

Validate the ledger and not the TXID

If you use a deterministic address for deposits, that is, you map each one separately (as any good exchange will do)

And you only pay based on amounts added

Then, this is not an issue.


the argument for TXID mapping is that it makes bookkeeping simple, because issuing a new address for each client/payment request would require the business to integrate with bitcoin wallet which could technically be too hard :stuck_out_tongue:


It is also a factor that if an exchange has poor practice in one area, it will in others. So, I am brutal here. The exchange SHOULD have good practice or it SHOULD be allowed to fail.

No blaming myths. Reality bites

And they do not need to hold keys, just monitor the deposits

And, they also should have a delay time in adding and removing funds. It is not a bank, it is an exchange

And sending notification of a withdrawal and having time for the user to block it is a basic security control

So, the Malleability fix is an excuse *AT BEST* to have BAD systems last longer and get bigger before they crash and burn

And they WILL crash and burn if they do not fix process and FUD the way out of it


my proposed solution for businesses that do not want to issue a new address for each customer --- just have one cold storage address for payments, but require slightly different amount of bitcoins from each customers (add a random number of satoshis in the range of 0-999 to the end of the requested amount). so if you have 2 customers who both have to pay you 1 bitcoin, ask the first one to send you 1.00000157 and the second one 1.00000521. that way you can poll for confirmed payments using your favorite block explorer, and the receiving address can be a cold storage address. yes this is a kludgy hack, but it works very well, has been using this for 3 years and I wouldn't want to change it



If you create a payment address that is used - you can also pre-sign TXs even with cold storage


Exchange makes a TX with:

Input - 

Exchange_Address - 1000 Sat

OutPut -

Exchange_Address - 1,000,010,00 Sat (just over 1 BTC)

To be valid, the others need to send funds and add them to this TX.

As the output is to the exchange address and it is SIGHASH_ALL|SIGHASH_ANYONECANPAY

It means that the exchange can send this and it is ALWAYS valid

That is, it is a TX that can be used and re-used

The user either taks on a


Which is like a blank cheque

Or better a SIGHASH_SINGLE to sign the output

These are combined and the exchange is paid.

*Rather than change Bitcoin*

How about learning how the system works...

@Hermolycus had a *wonderful* post of real quality on CPFC

*** edit: I searched slack to try and find the post CSW is talking about - I think these are links referred to

child pays for parent

If this was coupled with SigHash flags


you mean CPFP? 🙂 child pays for parent


He would have a tremendously effective system to chain TXs

Keeping you on your toes and I need more espresso


yeah yeah, typical trick from a true professor's handbook, just checking if the students pay attention 😂


This is a write-up on what Bitclub was doing:


BitClub, why are you doing Malleability Attack now?

The site is almost down (cannot query the data of the blocks mined by you), this can make their users confusing too.

I do not agree with that claim

If users watch their address they will see the TX hit when the block is released

What happened was Bitclub malleated but also hid the changes

So, a block would be released and it would have a malleated TX and not the one with the original TXID

The payment was still there and in your block.

Again, only an issue if you have bad business processes.

ViaBTC have fixed this from what I hear, so that is good

But it should not have been an issue in the first place...

Oh... and this is the issue with *SoftForks*

Bitclub used a -s

As Tom stated, this is a no no - but a miner can  mine a block and ignore Softfork rules and still be allowed

In a hard fork, this would not be an issue as Bitclub would have dropped the malleated TX in a block and all other miners would have orphaned it

Again... Softforks are good for the Core BS narative

Not Bitcoin


the core wallet uses unconfirmed outputs when there are not enough confirmed funds in the wallet, and this can cause giant mess for businesses who allow withdrawals that depend on long unconfirmed TX chains. let's suppose the first TX gets malleated, so none of the customers receive their deposits :stuck_out_tongue: tech support hell, and crafting your own TXs with `createrawtransaction` seems to be avoided due to the paranoia of messing something up with the fees and such


Yes, but this is a Core BS issue

Not a Bitcoin issue

Core failed to make a robust wallet

Not that maleation is the issue

On top of that, they added RBF


yes, malleation is not the issue, the issue is the wallet that lacks of proper RPC to absolutely deny using unconfirmed funds as inputs for new TXs


This is ALSO the issue with why there is :

no ETF in the US

SEC warnings

PBoC warnings

Basically, it is not malleability - it is making a good product that is going to make Bitcoin succeed

But BS Core do not want this. They seek to stay _underground_. No banks, no businesses and no companies

Hence, they are not trying to fix the business process issues, they want these


Blockchain and disruptive tech and startups at SiGMA17

SiGMA will host Malta’s largest gaming exhibition yet, along with eleven conferences at the Malta Fairs and Conventions Centre from November 22-25.

Sep 25th at 9:24 PM

On a different note


nice, looking forward to seeing that talk if it's recorded. Talking bigger picture stuff I assume?


@CSW What about future txids. Mulitsig with nLockTime

@CSW Changing the signature is always possible if you have the key. With segwit only the witness data is changed. However for a normal tx, the txid is changed.

Let say we do a pure 2 of 2 multisig. But you want to make sure that in case I disappear you can get a refund after a certain time

So you let me sign the refund tx (locktimed) which is based on the multi sig funding tx which is NOT YET included in the chain

This refund tx needs the txid of the funding multi sig TX.

The problem is that if I manage to include our multi sig funding tx with a replaced signature (first party malleabililty), then we still have a 2 of 2 multisig but your refund tx will never be valid.

With segwit your refund tx will be still valid since the agreement does not depend on my signature of the funding tx


If you have the key, SegWit TXs can also be altered

_Mulitsig with nLockTime_


SegWit, FT etc etc do nothing to stop non-benign malleability

In fact, it is an issue only if:

1. The miner doublespends

2. RBF allows the user to doublespend

This refund tx needs the txid of the funding multi sig TX.



If a random party screws up your refund by paying the refund BEFORE you... do you care?

Next, CLTV is there, so is CSV. They are incorporated into script, like it or not

So, you can use these for the refund you propose



This is a business process issue and comes to learning and implementing how to use the features in Bitcoin rather than changing Bitcoin to fit the square peg in a round hole.

You have a square hole. People just do not use it.


I'd prefer a round hole though, personally 😉


Oh and @Mnester

nLockTime is depreciated... so your TX is screwed if not already in the chain


I like choice

I like the option of a round or a square hole

We would need to see what was implemented, but it is a possible that it could be killed off.


I was not using flextrans in my example just normal versus segwit

@CSW The process was this: Create multi a sig address, only the public address only the public keys are needed 

You want to have agreement for a refund BEFORE you pay to the multi sig. 

In order to do that you need the details of the utxo generated by the funding tx (e.g. double escrow). 

But this will depend on signatures.

Txid should not depend on random signatures. But there are now and there used in every tx.

In order to send fund you make a reference to a utxo


So... one of the things that FT and SegShit fix

*Sighash flags based masking*,  Sighash flags can be used to ignore certain parts of a script when signing.

This also means that the use cased for several functions that cxan be added and created again (such as ones Mike H started) such as Lighthouse are also killed off



In the next few days a video will be out on CoinGeek from HK

This is where I start discussing thresholds and Blinding

You can do all that and not even use P2SH

No changes to Bitcoin needed


@CSW How can you alter a segwit tx. The actual tx (changing only the txid but nothing else), not the witness?

How do you alter the txid of a segwit tx?


The parties recreate

But I am not interested in SegShit, so I will not be going into it more


that was the main argument.. that txid cannot be changed.. only witness changes..


Basically, I will not go into segwit problems further as I have no interest in segwit solutions being made.

SegWit does not address same party malleability

Do not fall for that


@CSW Ok so how will my problem be solved without using txid, because that is malleable?

You want to have agreement for a refund BEFORE you pay to the multi sig.

and I need to make a reference to a utxo


In the case you note, you have a multi-sig address and you require collusion. So, the issue is not a malleability case. In fact of point, you do not need to create the TX in the manner you did you achieve the results.

No @Mnester

I know I keep stating this:


And there is scripting with CLTV / CSV


ok will look up for that


All that can be done in script WITHOUT segwit

And easier


can you go more in detail.. I have a hunch that maybe there is the devil hiding 😉 So I just need to create a tx with SIGHASH_ALL and CLTV  to have future refund tx working?