New transaction malleability attack wave? Another stresstest?

[unamis76]

Besides this, Satoshi seems to have had quite a few reasons to develop
Bitcoin such as fleeing from banks, creating a trustless system, etc.

OK. So my reason is to protect your life savings from this ponzi scheme called bitcoin
I want to prove that decentralized trustless system can not exists in long term.
It either transforms to centralized system or loses its security.

Since you're giving me valid advice, I'll give you valid advice too: don't put all your eggs on the same basket

As for long term decentralization, we'll see. The system may fail, but competition may rise and prove to be even more up to the task (that's why some testing is important too).

Problems will eventually find a solution where there is a need.

[1715138628]

1715138628

[1715138628]

1715138628

[Mickeyb]

So is malleability attack still under way? I have a friend that had to move coins very urgently, he has just called me and asked me what's wrong and what should he do.

His transaction is not showing up on the other side.

Thanks guys!

[dexX7]

What goal you want to achieve? Do you want to tighten transaction validation rules?
Isn't it better not to confirm txs with high-S by miners?

The goal is to minimize malleability in the long run, and there are few parts playing together:

  1. wallets, which create transactions with "compliant" or "non-compliant" signatures
  2. nodes, which relay or don't relay transactions with "non-compliant" signatures
  3. miners, which mine or don't mine transactions with "non-compliant" signatures

("compliant" -> low s, "non-compliant" -> high s)

If BIP 62 rule 5 becomes a standard policy (or is enforced), then it would become harder to relay non-compliant transactions, though, the transactions of non-compliant wallets would also be rejected, which is probably not a favorable outcome.

Ideally miners don't mine non-compliant transactions, but assuming they reject all of them right now, at a time when not all wallets create low s values, then the same issue applies: legit transactions are not mined.

The ongoing active mutation of transactions made me wonder, whether targeted mutation could be leveraged - by miners or nodes - to facilitate the process:

By "fixing" non-compliant transactions the issue of dropped or rejected legit transactions would be addressed to some degree, and if primarily non-compliant transactions are mutated, then it could serve as wake up call for wallet software creators (and user's of such wallets), as the sentiment may shift from "let's pitchfork amaclin for messing with our transactions" to "let's create/use better wallets, which don't create bad transactions".

Once that happened, it could be considered to only accept low s signatures, first in form of a standard policy, and at some point it could enforced.

[BitcoinNewsMagazine]

So is malleability attack still under way? I have a friend that had to move coins very urgently, he has just called me and asked me what's wrong and what should he do.

His transaction is not showing up on the other side.

Thanks guys!

Supposedly you can check if the attack is on at Satoshi - Transactios third chart down. Right now the attack is off per the chart.

[coins101]

You are confusing the price volatility of bitcoin with the utility of being able to transact internationally without the pain of banks or middle men.

Price to any currency does not matter. Currencies volatile to each other, so it is not possible to create non-volatile crypto.
If the price is not volatile to dollar - it will volatile to brasilian real.

You see. You proved the point. Economic speculation.

[dooglus]

The really juicy bit about this thing is that the core developers don't want to fix it because it might prevent future vaporware uses of the bitcoin protocol to be established.
https://np.reddit.com/r/Bitcoin/comments/3nfb2y/eli5_for_double_spends_bitcoin_being_sent_twice/cvnl2wo

Any idea what this is referring to?

schemes that make malleability irrelevant are subject to dangerous signature replay attacks if not handled very carefully

Is he saying that implementing BIP 62 opens up a new known attack vector?

What I meant was the idea that what goes into transaction should be "open to the user".
Imagine you had a database and added to the ability to store arbitrary information into each row, this is why rational databases exist which require you to define the type of data you want to store before you do add that information. The game of whack-a-mole is because even when they remove malleability for necessary transaction data it still doesn't prevent that attack because each entry has "scrap space" after that.
My suggestion is to abandon that concept because it's not a sane approach to storing data but a software engineering nightmare.

Sorry, but I still don't get it. If BIP62 was implemented, what new attack vector does it open up? What's this "scrap space" you mention? BIP62 appears to shut down all the different ways to maleate a transaction and specifically addresses "Superfluous scriptSig operations" in step 6, which is the closest I can find to anything that might be considered "scrap space".

And you guys have the nerve to call other crypocurrencies "shitcoins".

Well, they are mostly just clones of bitcoin anyway, and so have exactly the same issue unless they fixed it themselves. It's not like copying the bitcoin source and changing a few numbers fixes anything.

This is great news. It exposes the vulnerabilities and weaknesses of bitcoin and allows for better cryptocurrencies, like Litecoin, to grow.

How was this fixed in Litecoin? Do you have a link to the pull request please?

So my reason is to protect your life savings from this ponzi scheme called bitcoin
I want to prove that decentralized trustless system can not exists in long term.
It either transforms to centralized system or loses its security.

But this attack proves no such thing.

The ongoing active mutation of transactions made me wonder, whether targeted mutation could be leveraged - by miners or nodes - to facilitate the process:

Yes, and that sounds like a good solution. Miners could mutate all transactions into their 'canonical' state before mining them. That way well behaved wallets aren't affected, and wallets creating weird transactions still have their transactions mined, but with a different txid.

[gmaxwell]

Yes, and that sounds like a good solution. Miners could mutate all transactions into their 'canonical' state before mining them. That way well behaved wallets aren't affected, and wallets creating weird transactions still have their transactions mined, but with a different txid.

This is a fine thing to do (though it requires first getting the amount of non-canonical producers down to a negligible amount, something I've been trying to accomplish for two years!); but it does not achieve the goals of BIP62,  which is to make transactions involving refunds safe... doing that requires that the solution not depend on miner honesty. Thus BIP62... that it fixes third party txid aggravation for a subset of transactions is a helpful side effect (though first/second party txid changes and malleability will _always_ remain in general, because it's a feature.. not a bug. And wallets do need to handle it sanely).

But it seems people are much more interested in whining here than working even the basic detective work to cut out the last of the non-canonical users on the network (which I've asked people to do _twice_ in this thread, and not a single message has made progress towards that).   Come on people,  don't prove Amaclin right about the Tragedy_of_the_commons comment.

[dexX7]

This is a fine thing to do (though it requires first getting the amount of non-canonical producers down to a negligible amount, something I've been trying to accomplish for two years!); but it does not achieve the goals of BIP62,  which is to make transactions involving refunds safe... doing that requires that the solution not depend on miner honesty.

I actually considered it as first step to pave the way, not as ultimate solution. Besides reducing the rate of rejected legit transactions (edit: just to clarify, the reduced rate of rejected transactions is only applicable, if there a mechanism in place to block non-canonical signatures), users whose transactions are mutated in a favorable format are likely still annoyed to some degree, so it's a bit like shaking a tree, and seeing what falls down (i.e. which wallet implementations are mentioned, if users complain about the mutations).

[TooDumbForBitcoin]

Besides this, Satoshi seems to have had quite a few reasons to develop
Bitcoin such as fleeing from banks, creating a trustless system, etc.

OK. So my reason is to protect your life savings from this ponzi scheme called bitcoin
I want to prove that decentralized trustless system can not exists in long term.
It either transforms to centralized system or loses its security.

In the one million instances where someone has lazily called Bitcoin a ponzi scheme, I have yet to see anyone provide the answer to this obvious, but heretofore unasked, question:

If Bitcoin is a ponzi scheme, who is  Bitcoin's Bernie Madoff?  If there is no Madoff (or more respectfully, no Ponzi), there is no ponzi scheme.

Investors (speculators) in Bitcoin are not relinquishing their capital to anyone for nothing in immediate return, with the expectation of nothing more than a high-interest yield on that capital.  They are buying a commodity/tool/currency.  They may have an expectation of return/profit/yield/revolution/utility that will not materialize to their satisfaction, but they also holding something in their hand while they're waiting.  They have not turned control of their capital over to a central actor - Madoff, or Ponzi, or whatever imaginary unnamed actor the "ponzi scheme" gossips are inadvertently invoking.

Bitcoin may be something imperfect doomed to failure, even doomed to manipulation, but it is not a ponzi scheme.

One by one - everyone should stop malleating the vocabulary of the criminal financial world. 

[amaclin]

If there is no Madoff (or more respectfully, no Ponzi), there is no ponzi scheme.

Wrong logic.

[Mickeyb]

So is malleability attack still under way? I have a friend that had to move coins very urgently, he has just called me and asked me what's wrong and what should he do.

His transaction is not showing up on the other side.

Thanks guys!

Supposedly you can check if the attack is on at Satoshi - Transactios third chart down. Right now the attack is off per the chart.

Oh ok, this is very handy. I will let my friend know about this site. Thanks for the help!

[hhanh00]

This is a fine thing to do (though it requires first getting the amount of non-canonical producers down to a negligible amount, something I've been trying to accomplish for two years!);

Wouldn't seeing their transaction rejected by the miners be a good incentive for them to update their code or put pressure on their wallet developer to do so?

[Zombier0]

Is the attack still going?

[unamis76]

Is the attack still going?

Apparently not. Source

[Zombier0]

If there is no Madoff (or more respectfully, no Ponzi), there is no ponzi scheme.

Wrong logic.

Will u re-run it soon? I have made a small fork of qt and would like to test it

[gmaxwell]

If you are changing bitcoin core in response to this you are likely doing something wrong.

You can simply test anything here on your own too, just use two wallets in regtest mode and sign a transaction twice to get two versions.

Running this attack makes it hard to collect data on which signer software needs to be updated to produce lowS signatures-- which is important for fixing the behavior--, so it would certainly be preferable if it weren't going on. (... not like this thread actually gives a darn about fixing the behavior. )

[GermanGiant]

People don't even need to be developers to help-- I posted a list of highS producing addresses, if we can identify more software which produces this form and get it fixed then we'll be well positioned to move forward. Why are people still whining here instead of sluthing? Come on-- I'm not even asking anyone to write code.

From the list, how do we understand which addresses are creating Tx using which wallet software ? It would be like finding a needle in a haystack. Instead, if you please provide some script, that would allow us to run on Tx hashes and tell us whether they are using highS, then we can report that to you.

I'd also like to know, how this highS is determined. Say, this is an example Tx...

36d047abcb966f58aa668f050d60254730a3c07c9fd51e869e8b1a773c05d516

This is the Tx Hex...

Code:

0100000001c2a66993d8bf1997dc134ce74c96f47e26c1c4043523abfe7ff04eb3eff573be000000006b483045022100bf7c30e07374ab9aac0163fd7ba10ae3c9b4b9324993bfd984d9670edf707ea502206a5611667d1eb147d6a7352cbf37a2ddec8d9b37fcad17a0c9a9c6caff287f24012102f148462ebe0250cf2b057017f5a8435f47468a3c3385befa4475b57292ff88e2feffffff02e0930400000000001976a914f219f28b2be61ba587b0f4dbe4191155c93c388688ac091e1600000000001976a914a86d009f3d9e2e8380b9bcb53b83ac332ae4e4fc88acacc30500

This is the raw Tx...

Code:

{
    "received": "2015-10-06T22:53:03.821252153Z", 
    "inputs": [
        {
            "script_type": "pay-to-pubkey-hash", 
            "prev_hash": "be73f5efb34ef07ffeab233504c4c1267ef4964ce74c13dc9719bfd89369a6c2", 
            "addresses": [
                "1PGCqwTrnqcHybfBknfj22pUrDhrW97Vmi"
            ], 
            "script": "483045022100bf7c30e07374ab9aac0163fd7ba10ae3c9b4b9324993bfd984d9670edf707ea502206a5611667d1eb147d6a7352cbf37a2ddec8d9b37fcad17a0c9a9c6caff287f24012102f148462ebe0250cf2b057017f5a8435f47468a3c3385befa4475b57292ff88e2", 
            "output_value": 1749713, 
            "age": 7, 
            "sequence": 4294967294, 
            "output_index": 0
        }
    ], 
    "confirmations": 0, 
    "vout_sz": 2, 
    "addresses": [
        "1PGCqwTrnqcHybfBknfj22pUrDhrW97Vmi", 
        "1P57cHP5wRycFLtAYy248FVsh5DUpfnToA", 
        "1GMZ6rFQLatu8o6LGB1Ky5HHkyBXsqEUKd"
    ], 
    "fees": 232, 
    "size": 226, 
    "preference": "low", 
    "hash": "36d047abcb966f58aa668f050d60254730a3c07c9fd51e869e8b1a773c05d516", 
    "double_spend": false, 
    "total": 1749481, 
    "lock_time": 377772, 
    "vin_sz": 1, 
    "block_height": -1, 
    "ver": 1, 
    "outputs": [
        {
            "script_type": "pay-to-pubkey-hash", 
            "addresses": [
                "1P57cHP5wRycFLtAYy248FVsh5DUpfnToA"
            ], 
            "value": 300000, 
            "script": "76a914f219f28b2be61ba587b0f4dbe4191155c93c388688ac"
        }, 
        {
            "script_type": "pay-to-pubkey-hash", 
            "addresses": [
                "1GMZ6rFQLatu8o6LGB1Ky5HHkyBXsqEUKd"
            ], 
            "value": 1449481, 
            "script": "76a914a86d009f3d9e2e8380b9bcb53b83ac332ae4e4fc88ac"
        }
    ], 
    "relayed_by": "54.166.175.155"
}

How do I determine whether it is signed with highS or not ?

[achow101]

How do I determine whether it is signed with highS or not ?

According to BIP 62, Low S is between 0x01 and  0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If it is bigger than that number, it is considered high S.

[monsterer]

OK. So my reason is to protect your life savings from this ponzi scheme called bitcoin
I want to prove that decentralized trustless system can not exists in long term.
It either transforms to centralized system or loses its security.

You are failing to prove that... In fact, you are actually helping to prove that you *need* a consensus to make accepting transactions safe.

[amaclin]

OK. So my reason is to protect your life savings from this ponzi scheme called bitcoin
I want to prove that decentralized trustless system can not exists in long term.
It either transforms to centralized system or loses its security.

You are failing to prove that...

This stress-test wasn't direct attempt to prove anything.
I do not how to explain it. It is like a chess-game.
You can donate a chess piece to your opponent or make a nonclear turn to win a game.