Bitcoin Forum

Hey all,

we're seeing a lot of malleated transactions on our nodes. Anyone else?

Tx listed on https://blockchain.info/double-spends are also all malleated (click on links, if marked as "conflicted" blockchain.info has seem two versions of the same* tx).

What's the point? Another stresstest?

* or close enough :)

yes

Here is a case of such double-spending - https://bitcointalk.org/index.php?topic=1197096.0

Even after 29 days of broadcast, while one Tx has already got confirmed, another is still hanging in some node's mempool...

https://live.blockcypher.com/btc/tx/07dd024065a6ef12652670618e510503e1af4e0f4d75ddc6f4d2a55f002c9bc0/

It's strange , i have something very similar....
I do not own a miner or anything but just now i sent some payments though it doesn't show up in my blockchain wallet unless i login. I see two txs to same address of same amount , one confirmed and one not. and there is a incoming tx which is not confirmed and probably double -spent but which is not possible , it was sent using CoinBase...
Anyone knows, what's going on ?

https://www.reddit.com/r/Bitcoin/comments/3n5zvw/can_someone_help_explain_what_happened_here/
https://www.reddit.com/r/Bitcoin/comments/3n72yq/ongoing_bitcoin_malleability_attack_low_s_high_s/
https://www.reddit.com/r/Bitcoin/comments/3n62l8/bitcoins_stuck_with_blockchaininfo_shared_coin/
http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high

Interestingly, it seems that the later transactions (ie, the malleated one, not the original one) that are confirming.
At least in our case.

Can someone confirm this? More importantly, if your transactions are being malleated, which one is confirming?
Yours or the other one?

Some explanation: Malleated transactions face the same difficulty as doublespends: they need to be accepted
by a miner before the original tx (or the miner needs to replace the original tx). The first case isn't very likely,
the second requires the miner to run some non-standard software (Peter Todd's RBF-FSS).

If it's mostly malleated transactions that are confirming, we're facing something new. Either someone is
colluding with miners, or many miners are running RBF-FSS, or there's a bug.

The real problem am facing here because of this is not 0 confirmation but something else...
one incoming tx is pending , which will sooner or later be ok i suppose....
BUT, i sent some coins and now when i open my wallet and check - it shows me two similar tx to same address - one confirmed and one not....
How does it affect me ??


https://i.imgur.com/G64YiHw.jpeg


The bitcoins has been deducted twice and am not getting it back i suppose...
https://i.imgur.com/HfQ0vPZ.jpeg

any ideas?

This is the malleability problem: someone is creating copies of transactions that result in the same result but look different to the network (different transaction id).
In your screenshot, you see that both transactions are "doing" the same thing. They are basically the same tx under a different name.
As long as one of the two confirms, you're good. You can ignore the one that does not confirm.

And no, bitcoins aren't deducted twice, don't worry. Only confirmed ones count towards your balance.
Note that your wallet software might be confused and thus show an incorrect balance until the unconfirmed tx is discarded.

Actually i checked and the balance has been deducted twice , means i will get this btc back once the unconfirmed tx clears? but we can't say it will even clear right ??? :(

Well for bitcoin core you could just rescan the wallet, Im not sure how you would do that with... what looks like blockchain.info.

yeah that's blockchain.info :-\

Seems it's finally time i switch to bitcoin core as well..

Hope fully soon it will be ok....

Thanks

OK. This is not "someone". It is me.
Right now the stress-test is paused. I reserve a right to resume it.
Ask me anything.

if it's really you! you owe me some btc :P
I mean really , why ??? :-\

Because I am able to do it.

With Great power comes great responsibility my child...... ;)

PS - all tx removed , got mail by Blockchain.info , incoming one removed , will send it again and duplicate txs also removed... :D :D :D

and yes , duplicate txs had deducted the btc which i got back now :)

Not in bitcoin world. Responsibility for whom? I do not know you. You do not know me.
There is no third party who can punish me, because I am wrong and you are right.

well, wateva... :P
Do as you like...

I am not surprised.  You were my prime suspect. :)

This "attack" probably stops spam scripts that generate long chains of unconfirmed txs.  It might actually be a good thing to leave this running.

The main word is "probably".
Spam engine should not broadcast predefined set of transactions, but should monitor all transactions on the network from different nodes and build on-the-fly next transaction on top of previous one received from the peer. Splitting the "chain" to a "binary tree" just adds more fun :)

Better way to stop spam is to malle spammer chain txs on mining pool.

I do not think so. I do not see any benefits for me running it. Today.

This is also the correct way to do it.


Perhaps to remind the community not to rely on chains of unconfirmed txs.

Btw, I wonder if it is possible to design scripts immune to this attack, e.g.


The wallet software needs to "mine" a 73byte sig (not very hard).
The malleated sig is always 1 byte bigger, so cannot be used.

I do not see profit for me doing this. I am not a bitcoin hoDLer, I am not even a long/short bitcoin trader.
I am not a part of community.

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
 

  BIP: 62
  Title: Dealing with malleability
  Author: Pieter Wuille <pieter.wuille@gmail.com>
  Status: Draft
  Type: Standards Track
  Created: 2014-03-12

What are you talking about?


What else can we do on Sunday?
http://www.youtube.com/watch?v=gcWvW-DgJtU

@amaclin do you have a list of transactions that you modified? Or can you alternativly confirm whether or not this[1] tx was affected?

[1] f3724b1c1d58b9b505b2255ef9c6d0992874dfe55b734c22b8fa3a09798a561d

no

Are you sure you are not doing this because you are attempting to execute some kind of double spend attack? I would consider the chances of this being high considering your history of maliciously taking advantage of websites/businesses that accept 0/unconfirmed transactions.

How can I prove it?

btw. nigers problems don't fuck sheriff

So you are trying to execute some kind of malicious attack against some site/business?

not today, man.

It's a rather rainy Sunday in the UK right now.

Besides BIP 62, which will take time to finalize, what can be done to prevent this attack? What steps can wallets and payment processors take? Thanks for being a good sport.

First of all you should ask yourself - should this problem ever been fixed?
(I am very sorry, it is difficult for me to explain in clear English - it is not my native language)
Note, that the process of fixing malleablity problem - is a problem for bitcoin itself.
And this may be dangerous.

These are different questions.
I do not quite understand what is "payment processor" in bitcoin?
Bitcoin itself - is a way to deal without third party. Without payment processor.

The main thing you should think every day - there is nothing "free or cheap" in the real life and in bitcoin world.
If you pay nothing - you have nothing and can not complain.

Stop relying on others to validate your transactions and watch the blockchain for you.
Also, (this is the biggest one) don't categorize transactions based on transaction ID, then store them away and never check them again.

It's not that hard. But it's hard when the wallet is already built from the ground up under the assumption that "Once we see a transaction, even with 0 confirmations, it's as good as done."

Stop making that assumption, and code your wallets accordingly.

Also, there needs to be vigilance on the user side as well.

If you spend unconfirmed change, you are risking the chain being broken.
If you accept unconfirmed transactions with unconfirmed inputs, you are at a large risk of being double spent if you don't wait for at least one confirmation.

The only sure-fire way to prevent becoming a victim is to wait for confirmations.

Wrong. There are no "100%-safe" ways at all.
First way is "risky & cheap". Second way is "no-so-risky as first, but not-so-cheap"
Bitcoin itself is risky. If you do not want to be a victim - pay to third party banks and use your national currency.

Never said 100%.
third party banks and national currencies are proven to not be 100% safe either.

If anyone is looking for a 100% safe thing in life, they're in for some big disappointments.

Right. There is a relation between "safe" and "cost".
In bitcoin world you pay nothing to developers. And you are totally unsafe.
Sorry, man. Bitcoin is unsafe by design.

Props for admitting this and for your attitude. Have a great Sunday!

I am not a "hodler" either; I am not financially or emotionally invested in Bitcoin.  I was just curious as to what the effect on the network would be, so was disappointed that it stopped.  But it has since restarted.

This attack is "free".  There is no profit but also no cost.  The attack is also not very difficult I think, so if you stop then someone can easily start again.

Is the attack ongoing again?

Yesterday it caused me to waste an hour of time because funds in my trezor were unspendable, I had to restore wallet from seed on another device then create new trezor wallet to send the funds there. Annoying...

This attack is very good at exposing bad software.

Eh, you realise this kind of thing doesn't need any power, right?

It's literally just a few lines of code in any old boring node...

yes

Complain to yourself and the developers of your software/hardware.

Any suggestions?

Good thing you only wasted an hour. I'm waiting for over 6 hours for this particular transaction to confirm: http://btc.blockr.io/zerotx/info/844f88ef20fb5d2d2ecf897772d429d9bca1d3cab6314e5ed3017b48940f096a

This tx will not confirm.  It belongs to a tx chain that has already been invalidated by a malleated tx (https://blockchain.info/tx-index/105072504) (original is here (https://blockchain.info/tx-index/105074334)).

Bit-x signature payout gone wrong. This is exactly what you should not do currently, spend unconfirmed inputs.

LOL. They say on their ad that they are professionals in crypto.
But they are blockchain spammers. They even do not know how to combine several payouts to one transaction.

Bit-X is a cloud mining ponzi with an eyewash of legitimacy. They have 1 Phs vouch from BitFury and selling unmetered hash power. Reliable, professional etc. are all vague words flying in bitcoin industry.

So does this necessarily mean that any outputs in that transaction won't be received by the address it was sent to? If so, the balance won't be affected if the transaction was invalidated, right?

Any suggestions?
[/quote]

Well, my only suggestion now is to use a different wallet because the trezor is not currently able to rescan its transaction and ignore the 0 confirmation duplicated tx.

Regarding your sentiment to "pay to third party banks and use your national currency", no thank you I will choose to be a victim!

The entire tx chain (from the tx I linked to) has been invalidated.  This means that the sender needs to create new txs otherwise you'll never get paid.

Quoted.  ;D Let us talk about it later.

Thanks for the clarification. Already requested a separate payout with the reason you have just stated in here.

Is your argument that since you pay a bank to use their service, it's more secure?
How is putting your trust in a single entity more secure?

Stop posting BS for signature payment only. Check my post date. I posted 2 days ago. That was not a Sunday.

If myTrezor.com is currently not able to handle the duplicate transactions gracefully what wallet are you using with your Trezor and how well is it working?

Apparently you used the low/high s attack (http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high).

How is it possible that so many transactions were affected if v2 transaction are protected against this kind of attack?
http://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented

https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
Why? Apparently rules 1-6 have been implemented, 7 only affects special outputs and 8,9 shouldn't be a problem (for third party malleability)
EDIT: Ok, all txs are version 1. Version 2 hasn't implemented yet.

You are my personal hero of the day.

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



Also, see my sig.

Rules 2-6 are also not implemented, and BIP 66 extended rule 1 to all transactions, regardless of their version.

But the main reason it isn't suitable right now is the "Block validity" section, which uses block version >=3 to trigger it.
We already are on block version 3 for BIP 66, so this needs to be updated for another version.

Furthermore, when we were initially planning to begin roll-out, Peter Todd (IIRC) brought forward some very real issues with the BIP that would have potentially been problematic, so there was a general feeling that BIP 62 had not been sufficiently reviewed/considered, and was therefore too risky.

I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?

You're conflating standards with the IsStandard filter.
The former is defined by common use, while the latter is miner/relay policy entirely up to the individual user to decide.
You can decide to filter with SCRIPT_VERFIY_LOW_S if you like, but maybe 5% of legit transactions will probably be filtered if you do so.
If everyone did, then those 5% would never confirm until someone malleated them.

I wonder if any of us can double bitcoin due to this attack :)

What about removing malleability altogether?
Just a thought. I know you guy's won't do that because of dumb ideological reasons.

In case that is claimed to be not clear: Enumerate every necessary use case in the transactions and remove the ability to encode anything else into transaction data.

Any idea what this is referring to?


Is he saying that implementing BIP 62 (https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) opens up a new known attack vector?

That is I wanna say

Because it would block ordinary transactions from many implementations.

I have been nagging implementers on and off for a long time to fix their behavior.  In this latest round it looks like Strongcoin, Bter, Kraken, anything using pybitcointools (full of really scary broken crypto, nothing should use it), electrum (just fixed because ThomasV is awesome), were things I could easily identify.

It's been slow going-- even BIP62 only applied that restriction to flagged transactions.

If anyone feels like playing detective, here is a report someone else ran for me of addresses which were violating low-S (before the recent attacks): https://people.xiph.org/~greg/high-s-reusecnt.log (leading number is how many times the pubkey was reused in the analysis window).

Getting more implementations to produce low-s for all their transactions would be very productive.

Mods deleted my post, because I bashed your whiny attitude. So let me stress this again.
Bitcoin needs all the bugs exploited so they can be fixed for a brighter future. That you worked with some fake txs is your own problem.

OK. Why don't you... Yes, I've said: "you"
Why don't you fix this bug now?... Yes, I've said "now"
Why should core developers fix this for *your* bright future?
What is the reason for them to carry you on their necks to a bright future?

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.

Oh, I see, thanks! This was what I feared.

I assume the issue is mostly one of awareness and the (lack of) seeing the need to take action.

Given that the transformation seems fairly simple, it would probably help to guide the process a bit: publish information about the issue and how to tackle it. A more radical approach and counter messure could be to setup miners/nodes, which actively mutate transactions to comply. Users with non compliant transactions would be affected, which likely causes some confusion (though certainly not more than during the "attack"), but it could help to pin down specific implementations that need to be improved.

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

It is an annoyance to have my normal transactions reading as double spends from blockchain both of them are from the same source and won't fail but having a warning message appear and having it spam the network is urksome.


Not unless we do a Bitcoin update to a new core client and have it deviate again  ;)

s/unless/if

Was referencing OK pay and block 225430, I presume that when we do finally decide on what to do with 1mb it will be smooth as we all have had a long notice.
https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448

paused

Do you mean that Litecoin does not have the mealleability bug?

Apparently this is still ongoing, had it happen on a transaction of mine. The question is why and how...

Does one have to control a significant number of nodes to disrupt a lot of transactions?

No need to have even one node.
The stress-test is paused right now. You can see the statistics and network health here:
http://statoshi.info/dashboard/db/transactions
Third chart "Transactions Accepted vs. Rejected"

Litecoin is almost identical to Bitcoin, so shouldn't Litecoin also be vulnerable to the same attack?

No doubt someone will call me a troll .. which is the standard behavior toward people that share their opinion which happens to be contrary to the shared (although now seemingly badly fragmented, which may be a good thing in the long run. If there is descent there may still be hope) consciousness of the all holy developers (assuming of course the fragmentation isn't just a manufactured front to confuse everyone even more than they already are) :

Malleability is what the "venerable" Mr Karples blamed the fall of Mt. Gox on .. whether or not this is true can perhaps be disputed, BUT,  IF I was a developer of a piece of software that based it sole purpose of existence on the TRUST of its ability to reliably  transact in an accurate and secure fashion, I image it would be a high priority to fix any possible exploits that might expose its total lack of ability to do this - which this attack - ONCE AGAIN PROVES.  If this happens to be because of a toolkit that is broken then I would take it upon myself to provide alternative tools that might produce better results -i.e. instead of shitting on people, allowing them to eat mutated transaction that could potentially put them out of business and then call it "a good test". It's like poisoning your baby to see if it's strong enough to walk. Ridiculously retarded.  PS:  I am not calling the attacker retarded. He is highlighting a valuable lesson that needs to be learned at some point. I wonder if it will happen any time soon?

I believe it is almost November - time to light another candle.. I need to check and see if the accounting system has been deprecated yet. meh .. you know I don't actually care. This whole thing dying a slow and horrible death and the fucking retarded attitude towards the whole ecosystem makes me very very sad.

I bet this post gets deleted by his highness gmaxwell .. whatever..  

I have to repeat: fixing this particular "exploit" is more dangerous than leaving it "as is".

I think the thing I am trying to express is that I am neither for nor against the exploit or the fix or non fix.. the point is Bitcoin is a solution stack and should be provided as such- MT Gox was the first most visible point when malleability became an issue- it should have been addressed conclusively then, why this word remain in our lexicon astonishes and perplexes me.

Credit card companies don't give people credit cards with gay abandon not knowing how it will be settled on the back end. Bitcoin should be no different if it wishes to compete with them (I believe our ideological best use scenario).

May I ask a question?
Why you... Yes, I've said "you"!
Why you did nothing these 1.5 years and this word is still in our lexicon?
Who should do anything for you? Me? Or core developers?

Of course amaclin can...

https://blockchain.info/address/13p5iQkqBEVgKmPeJqEL2LBRS44PjX1dZL

Final balance: -1148.99999964 btc. All Tx confirmed. ::)

This is a glitch on bc.i
This service counts the sum on account incorrect

https://tradeblock.com/bitcoin/address/13p5iQkqBEVgKmPeJqEL2LBRS44PjX1dZL
Confirmed Balance   0.00000036

http://btc.blockr.io/address/info/13p5iQkqBEVgKmPeJqEL2LBRS44PjX1dZL
Unconfirmed -1,048.00000000 BTC
Note: Unconfirmed balance is not part of the address balance or total.

Lol .. funny. May I ask you the same question ? why don't "YOU" ? You seem very fond of it.

EDIT : And may I say .. you seem very interested in protecting the developers ... why is that ?
EDIT2: And frankly .. who the fuck are "you" to ask "me" what I have or haven't done lately?
 

Bitcoin concept is broken. Nobody can fix it. Point.
I do not have any reason to do useless (in long term) things.

Because I am software developer either. I do not work in bitcoin-related industry.
You are asking something from the bitcoin core developers, but you are not paying them and even not contributing.
Is it correct behavior?

Again .. what is it that you know about me that leads you to these conclusions? Nothing. So STFU bro. ( and by bro I mean asshat )

Sorry. This question is for everyone who reads this topic.
I respect your privacy.

Statoshi has so many charts, I forgot to check it for that one, thanks :D So it's confirmed, when I made my transaction, attack was still ongoing.

Without a node with modified code how does one get around to doing what you're doing in an automated way?

Also, a follow up question, what are your main reasons behind this? Are you doing this to prove a point, like with the transaction spam attacks?

Not so! (well, if the concept is broken, after all it isn't due to the substance of this thread.)

Harsher than I would have said; but there is a point there.  Often on these things what happens is that people who don't know have one view of the priorities, and people in the know have another. If someone's priorities differ they need to step up--- and sometimes that does happen but once they learn more their priorities change. :) See also table 1: http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf  the greatest pain vectors of malleability can be avoided simply with careful wallet design.

In the case of BIP62 one of the reasons it has not progressed is that we haven't had enough review capacity to achieve confidence that such a broad scoping change would actually achieve its goals and not cause collateral damage-- especially because with "random pain" mostly answerable via wallet design-- the goal of it becomes making multstep contracts secure... which is something that can't be approximate.

BIP66 pulled forward part of BIP62 that was done and ready.

Folks here like int03h suggest that nothing has been done, but the opposite is true-- in terms of easily malleability on ordinary transactions, IsStandard-like-checks almost completely cover it. Every known vector of malleability has been closed off that way, except the one where common wallets still emit random forms. If we could enforce lowS as a standardness rule this issue would likely no longer be a source of intermittent annoyance for ordinary transactions. Bitcoin Core has been ready for that for roughly two years. But since we don't want a world where everyone is forced to run Bitcoin Core (much less the latest version of Bitcoin Core) reality is limited by what improvements people adopt.

People don't even need to be developers to help-- I posted a list (https://people.xiph.org/~greg/high-s-reusecnt.log) 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.

FWIW, virtually every cryptocurrency (including litecoin) has the same kind of issue, even some promoted as "immune to malleability"... Even most created after this issue was well understood in bitcoin have not bothered learning from it. That this property existed in Bitcoin is unfortunate but easily justifiable, that so many others have slavishly replicated  this well known poor behavior, even when the Bitcoin community knew exactly what was needed to stop it completely, is something else entirely.  My own published alternative network work, the Elements Alpha testnet sidechain, eliminated this whole class of issue in a very complete and robust way-- but its approach is not easily applied to Bitcoin because the deployment would be disruptive. Fortunately, for what people are currently complaining about nothing that complete is required.

Take a look at this (https://web.archive.org/web/20151005180227/https://btc.blockr.io/address/info/13p5iQkqBEVgKmPeJqEL2LBRS44PjX1dZL) and this (https://web.archive.org/web/20151005165103/https://blockchain.info/address/13p5iQkqBEVgKmPeJqEL2LBRS44PjX1dZL). Are applications using APIs from those block explorers affected?

Malleability is not a problem for bitcoin at all.
The major problem is that Tragedy_of_the_commons (https://en.wikipedia.org/wiki/Tragedy_of_the_commons) can not be solved by decentralized consensus

Some kind of pseudo-node. No code from any other client.

Just because I am able. Isn't it funny? I have not any other reason today. But... I have some ideas for future.
Why did Satoshi invent bitcoin? I really think he had the same reason - because he was able to do it.

Understood, thank you.


Although the groundwork and the ideas that are the basis to Bitcoin were laid out throughout the years, Bitcoin is still quite innovative, so I'm not sure Satoshi started Bitcoin knowing he could develop it, finish it and release it.

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

Despite this, you are obviously free to do something for no reason in particular, but I don't think you'll let this opportunity escape and you'll eventually put this "stress test" in use to prove a point (I think you're already proving it, unintentionally or not)

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.

May be you are successful for a short period of time to disrupt the network. But, there are too many stakeholders in bitcoin who are more able than you to keep the network safe. In the long run you'll lament that you have wasted your time to do some unselfish destructive work, while you could do some selfish constructive work. Good luck with your endeavour.

Yo do not listen me.  :'(
Malleability is not a problem for a network. Stress-tests can make the network even stronger.

Could you flip your bot and mutate signatures with high s values, to target users with well, "non-compliant" software?

Nice idea.
What about privacy?
And what if someone runs the bot which converts low-S to high-S and my bot do the opposite?
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?

We have a consensus now. Do you want to change the rules? Are you against the current consensus?

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.

For example: one of the problems to be figured out is how to get money across borders so that poor people can get the money they need without having to spend the whole day travelling from a poor village with no infrastructure or services to a town where they wait in line to get some money.

$100 goes to $85 after WU and middlemen have taken their cut at the sending end; goes to $75 after the person at the other end has traveled to pick-up their money and made the conversions. When you are poor, that loss of nearly $30 is a lot of money.

Stress testing of any kind is good. Problems will eventually find a solution where there is a need.

Analogy - why do people ask singers for their political views, like having a good voice somehow makes you a political genius?  Same goes for technical capability and economic / price speculation.

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.

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).


:)

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!

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.

Supposedly you can check if the attack is on at Satoshi - Transactios (http://statoshi.info/dashboard/db/transactions) third chart down. Right now the attack is off per the chart.

You see. You proved the point. Economic speculation.

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".


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.


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


But this attack proves no such thing.


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. :)

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).

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. 

Wrong logic.

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

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?

Is the attack still going?

Apparently not. Source (http://statoshi.info/dashboard/db/transactions)

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

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. :( )

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...


This is the raw Tx...


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.

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

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.

What makes you think that trustless systems always have to tend towards centralisation?

Because it is more economically reasonable solution in long term.
The centralized system takes less energy. Always. Point. No exceptions. Look around. Look to yourself.
Decentralized system either takes more energy or less secure in long term.

>>> It either transforms to centralized system or loses its security.

This is correct.  I disagree about the "Ponzi" comment, but that is irrelevant really.  

I wonder if anyone in Bitcoin has ever thought about how this pure decentralized system has no counterpart in nature?  None.  

A game:   cite of an example where the universe has evolved a natural system exhibiting coordination of behavior by a full decentralization of group consensus, and I will tell you why it is wrong.  

Bitcoin isn't supernatural, it's not special just because humans made it and can "outsmart" the constraints of the medium they exist in.  

Energy loss, signal propagation limits, information entropy,  nature itself abhors decentralization (of the Bitcoin sort) and will tend to centralize due to self-signalling feedback effects, or lose signal integrity due to entropy.  Consensus, when confronted with the hard limits of signalling in the medium it is sustained, must specialize by losing least significant inputs or decompose into fragments.

No getting around this.  Bitcoin cannot "win" the battle to scale while remaining decentralized; there is no possible win condition unless the criteria for "decentralization" are loosened (which, abstractly, is what larger blocks and overlay/sidechains both do).

But centralized bitcoin - is nonsense. We already have FED.

I mean that all earnings in this system can be get only from the money from next members.

The starfish.

https://en.wikipedia.org/wiki/Starfish

> But centralized bitcoin - is nonsense. We already have FED.

Not disagreeing here, but centralization and decentralization are not the only states possible.  They are two abstract ideal ends on a continuum.  A fully centralized system doesn't exist; centralization of information asymptotically approaches total singularity, and decentralization likewise approaches total entropy.

> I mean that all earnings in this system can be get only from the money from next members.

I believe what you are trying to make is a practical, moral observation about who benefits from Bitcoin's cash flows. But really this is necessarily true of any system that requires its participants to distinguish between the value of resources outside itself vs inside itself, and who must choose, based on this distinction, whether to move some of their own resources from outside to inside.

Good choice.  There are a couple like this, and some better ones, but they are still wrong.

For the starfish has no central nervous system, but it does have a radially centralized body plan - and more subtly, a solid body is an information signalling medium of its own. If one arm pulls, the rest of the creature comes with it.  A brain need not agree to this, or even a network of nerves. The entire physical unity of its mass does the job of "maintaining consensus" about a direction for the creature to move. To lose this consensus (such as arms pulling in opposite directions, or being pulled by outside forces) would be to physically fragment the creature. The nervous system described above is an overlay network which helps prevent this from happening.  

Also, there are natural constraints to how big starfish can become before they cannot sustain physical integrity.  

Who is the winner between two players in a game? When all other factors are the same?
The person, who spends less energy (takes less resources outside the system)

This is very good point.
Let us calculate together the "product" and the "resources" based on principles "outside" and "inside".
What is the product of any transaction system like fiat money and bitcoin?
What banks do produce? What bitcoin system produces?

Banks do not produce money and bitcoin network do not produce bitcoins.
Both systems produce secure transactions.

In this game the winner will be the system, where the cost of resources per one transaction is less (if we talk about the same security)
These systems can co-exist together if one of them is better in security for users and another is better by cost of usage.
Right now bitcoiners think that the cost of usage is small. They are confused the "cost of usage" and "transaction fees".
Transaction fees are small, but the cost of usage is very high.
It can be calculated as ( AmountOfElectricuty + CostOfHardWare ) / NumberOfTransactions

> Who is the winner between two players in a game? When all other factors are the same?

How long is the game?  

> In this game the winner will be the system, where the cost of resources per one transaction is less (if we talk about the same security)

The big catch is that bitcoiners do not recognize security that is based on maintaining a loop of sterile, mechanically rigid, clearly understood consensus rules that they can see in the open, as being something fundamentally comparable to security based on trusting other people to be, in the aggregate, slightly more honest than corrupt when working out of sight.

For bitcoiners, the fact that "decentralized" security costs more is worth it, because in their view it is a better quality product worth paying a premium for.   A decentralization premium.  

While both of them able to fight.

The cost is high, but nobody sees it, because the payment is delayed for future. Like in every pyramid scheme.

The cost is subsidised by the block reward.

You are forgetting the cost of 'lost trust' in centralised systems; governments and banks can make terrible decisions which have a huge cost to those relying on those systems. This lost trust may compensate for the increased decentralisation cost in p2p currencies.

This is the question:

And this is the answer:
So, the game will be over when the cost is more than block reward.
Do not count the "cost" in dollars. Count it in joules or kwh.

After it we will see decreasing hashrate and ongoing decreasing the security of confirmed transactions.
All the factors which allowed bitcoin system to grow in past will push the system down.

Today you can easy reorganize the blockchain in some dead altcoin with an obsolete asic.
Tomorrow you will be able to reorganize bitcoin blockchain with your currently running asic.
Somebody definitely will "test" is because "he will be able to do it with small efforts"

I repeat: I think not about today. Like a chess-master I think several turns in future.

May I suggest writing to the bitcoin-dev@ mailing list asking wallet authors to check their code behavior? It's not perfect, but, in theory, it's likely to get a chance of being read by the relevant people.

Your December, 2014 "BTC price to King's pawn and $10 value by March 2015" gambit cost you several thousand Grand Master points.  Have you been reading more chess books since then?

:)
OK, bitcoin network is little bit stronger than i thought a year ago :)
But the physics remain the same.

By that time, it is supposed that transaction fees will compensate. No one can predict the future, if they do no problem, if they don't there is a problem.

Not if blocksize keeps increasing it wont: bitcoin would either have to find an alternative subsidy or die.

Step 1: find the signature in the scriptSig

In your example the format is:


To visually explore it, the ASM code or a block explorer of your choice may help. I really like this one:

http://srv1.yogh.io/#tx:id:36d047abcb966f58aa668f050d60254730a3c07c9fd51e869e8b1a773c05d516

https://i.imgur.com/lU7OOsN.png

Step 2: split the signature into components

https://i.imgur.com/mYhfMOB.png

Via bitcoin.stackexchange.com (http://bitcoin.stackexchange.com/questions/12554/why-the-signature-is-always-65-13232-bytes-long)

Note that the image also includes the "signature hash type", which is not part of the DER encoding, but usually shown on explorers.

Step 3: check, whether the S value is below the curve order

Compare:


In this case the S value is indeed smaller than n, and therefore it's "low S".

By that time year numbers are all less than 2016.
No one can predict the future.
If last six year numbers were all less that 2016 - there is no problem to think that this is true forever :)
Do you see logic here?  ;D

If adoption of bitcoin remains constant (as of now) there needs to be a transaction backlog in order for fees to compensate.

Today the bitcoin network spends several hundred thousands dollars daily only for electricity bills.
And there is only 100k transactions daily.
So, to compensate the electricity bills (only them!) every transaction fee should rise to several dollars :)

You do not see the difference between the "fee" and "cost".

Fees per block need to rise to 25 BTC to break even with the current subsidy, which is a fee of 0.025 BTC per transaction with 1000 transactions per block. This is $6 / transaction.

Good. How many bitcoiners send their funds paying $6 fees?
How many transactions will be daily if the minimum tx fee is $6? (Let us assume this number is X, I think X is much less than 100k)
What would the minimum fee if the daily tx number is X?

I don't know the answer to your question, and I'm too dumb to be able to quote post signatures, but I think your post signature indicates you have found a way to profit from your stress test.

Like a true capitalist, you make money on both sides of the trade.

Clearly, the number of transactions per block must rise higher than 1000 in order for this to be viable with bitcoin at its current price.

Not yet. But I promise to tell you if I do it in future.
PS. I've removed forum signature. It was only a joke.

This is not enough. Users should pay $6 per every tx. Only to remain current price  ;D

At 1000 / block, yes. More transactions per block mean lower fees for users.

I have the same problem.

Transaction: Kraken -> Localbitcoins

Those are the 2 transactions generated:
CONFIRMED: https://blockchain.info/tx/7bfc03459c267dee5ad4a407642bf819b09bb0e6f290537bee1ffb99758d9187
UNCONFIRMED (double spend): https://blockchain.info/tx/2de9e19a9b6945912c763eb18294447d24201f30e2b0ca57231b851d2389c1eb

As soon as Blockchain is concerned the unconfirmed transaction should disappear from the network in the long run and the confirmed one is valid.

Can anybody confirm that?

I've also opened a ticket with Kraken and Localbitcoins for being sure of that: I won't spend those bitcoins unless the unconfirmed transaction will disappear.


Best Regards.

So you are saying Bitcoin has a P/E ratio of ~10,000:1  or so?

Quite high even for tech but not outside the limits of imagination for an asset that could be, in the eyes of it's supporters, the foundation for a new universal value regime.   

Of course those who use language like that are quite often using it to refer to religious beliefs.  Zealotry has frequently paid much, much higher prices for its idealism.

Suppose the price per Tx rises by a factor of 10, and the price of BTC drops by 75% to come into line with the approximate cost of overpowering or capturing the network's security.  P/E of ~250 would not raise many eyebrows on Wall St. 

I wouldn't call this an attack, it's completely benign on its own. However external software that doesn't properly account for this could result in money being lost, but can't blame Bitcoin itself for that.

Very easy to write a little code and cause blockchain-wide impacts, the dust giveaway is a good example. Hopefully Amaclin doesn't find a real exploit, so far Bitcoin has been impervious, but there must be a true weakness somewhere. If he or anyone else figures out a real weakness then that weakness can be exploited worldwide instantly.

Yes but bigger blocks could mean that it's more expensive for miners to process the blocks.
Cost vs Fees again.

You want your name on www.bitcoinobituaries.com. Admit it!

Yes it is.

Bitcoin core.  Protocol incompetently designed so it has malleability bug. Protocol and software incompetently maintained because bug has yet to be fixed after several years.  Protocol developers incompetent in foreseeing and avoiding problems their incompetent code and designs have created.  Leaders unable to lead, paralyzed by fear.

The problem is not the protocol developers (core devs) but the rather with the other wallet developers who support and use High S values. If they are so incompetent, why don't you help and write code and implementations? Please read the thread before posting FUD like this.

Attack is back

Of course Bitcoin has higher costs, they are a trade-off for its decentralized redundancy.
On the other hand, Bitcoin provides (or strives to) some features unavailable in traditional systems: permissionless and trustlessness of payments, anonymity. The question is whether anyone is willing to pay for these costs to get these features.

If this were FUD, the network wouldn't be having problems.  The solution to this problem isn't writing software, the problem is not fundamentally a software problem.  It is a distributed systems problem and a human problem.  It requires leadership. The code is the easy part.

If there were a clear protocol specification there would be a simple way to declare the other wallet developers out of bounds.  Even without a protocol specification, bitcoin core could be changed so that bitcoin core nodes would not relay ill formed transactions, nor accept and propagate blocks that contain ill formed transactions.

There has been ample time to phase in a solution to the problem.  Some old clients would cease to work.  That would be good, not bad.  People with funds in an obsolete wallet could always export their private keys and sweep them into proper new software.  (This part of the argument is the "leadership" problem.)

One consequence of some of these software implementations being obsoleted would be a demand for a firm protocol specification that could be discussed and debated independently from any code base. With a specification there could be the beginning of work on protocol verification and proofs of correctness.  Accomplishing this would require creating some kind of governance structure, such as is used to manage the IETF.  Adults would step into positions of leadership to replace children...

Sure the extra validation/processing cost pales into insignificance compared to the cost of finding the POW?

That's why POS coins like Peercoin have a bright future.

I declare all software that doesn't transfer all your coins to me out of bounds! I declare all software that doesn't assign me a trillion bitcoins out of bounds! Hurrah! This is fun.

... Come on.  Going and dictating to people what software they could run would not be well aligned with the principals that make Bitcoin (or the internet) interesting in the first place..., particular because taking that approach to it's logical conclusion we'd rapidly reach a state where Bitcoin Core was the only or nearly only software people could use with the network (as it has an order of magnitude more development effort going into it).

I have considerable experience in the IETF, and I have to say your comment drew a bit of a chuckle from me... The IETF has no authority to control what software or behavior other parties have. You're drawing exactly the wrong comparison there.

In Bitcoin Core we discovered, designed solutions, implemented them, adjusted the behavior of our own software, specified the needed behavior, and recommended these changes to others. We've even gone out and reviewed, audited, advised, and contributed patches to other implementations. I'd say we'd done everything short of written invitations, but if you count emails-- I've sent many an invitation (many of which have been warmly received and resulted in improvements in wallet implementations).

And basically all of this was done by people who weren't being paid a cent for it, by you or anyone else-- I might add. And when there was a simple, not very technical, part of the effort that I thought wider help would be important for, I plead for it here-- to seemingly no effect. Apparently its not as big a deal as some are making it out to be.

... so in the meantime, while all of that was going on ... precisely what have you done except insult the few people who've done anything productive at all about this subject?

Kind of you to confirm that you're responding in this thread without having read it (or my response to you in the other thread on the same subject.)

Specific forms of malleability are useful and intentional design features of the protocol. Additional forms allowing unintended malleability arose primarily out of undocumented behavior in underlying cryptographic libraries which have also resulted in CVEed vulnerabilities in unrelated applications-- indeed those later kind were a design error-- but most of them (save the one whos fix was inhibited by wallet behavior were largely closed off ages ago). Meanwhile, in spite of these issues having been well understood for years virtually every altcoin is also vulnerable to them including many 'from scratch ones' and ones created years after the issues were known in Bitcoin and fixed in Bitcoin Core (and even, in at least one case-- one that specifically promotes itself as being 'immune').  While it is unfortunate the the system was created with merely superhuman foresight and not perfect foresight, if you're looking to complain about _incompetent_ you need to go look to those other places, not Bitcoin Core which immediately implemented solutions for every known unintended malleability vector once they were first highlighted as an issue and discovered several new ones along the way.

The network itself is working fine and is completely uninterrupted by this stuff, whats impacted are some wallets in some applications. See also http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf

Sorry, man. I have bad news for you.

Crap !
What have I missed ?

Decentralized systems like PoS are either very expensive to hodlers (compared to their stack) or unsecure to them in long term.
In fact, current fiat system is PoS - the big holders can change the consensus rules, because they have 51% of funds.

If you are looking for a leader or more efficient ways to do stuff by introducing centralization and single points of failure, then you are not at the right place, nor in the right project.



Bitcoin is an open-source project open to every one who wishes to contribute: if you think you can bring value contributing, you are welcome.

Else please go away and waste another project's time with your unproductive comments.

The is an easy rule-of-thumb to spot high-S signatures.  For example, the following sig is high-S

3046022100aea3c7faf22df9ecf795ddb470d000bb2345679363fde6c24df4ab9c6922ff5d022100ae2ff77a2cd10794f166cbb7782316d6ceb74fc22c2188a22c52f6f1847401fa01

If the highlighted hex "022100" appears in the middle of the sig, then it is high-S.  Compare with the low-S equivalent:

3045022100aea3c7faf22df9ecf795ddb470d000bb2345679363fde6c24df4ab9c6922ff5d022051d00885d32ef86b0e99344887dce927ebf78d2483271799937f679b4bc23f4701

The low-S has "0220" (highlighted) or something else.

This test is not quite precise, so implementers of bitcoin software shouldn't implement the test this way. :) The threshold is not a power of two, so no tidy hex digit sniffing can be precise.

you are too pedantic.  ;D
but.
this is not a consensus rule.
everybody has a right to search the pattern 022100 "in the middle of signature" and reject all unconfirmed transactions with it.

Who's behind this stress test?

Amaclin is. Did you even read the thread? He admitted it on the first page.

OT

Thank You for your reply.

/OT

Bitcoiners do not rAEd anything. They hoDL!  ;D

FYI a quick note: active mutation of high S -> low S appears to have started, according to some discussion (http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1444332212.0) on IRC.

I like it! Let us start a big tournament!

Hehe, it would be interesting to know your success rate. Do you keep track of the mutated transactions?

Yes, validation/processing cost itself small compared with cost of finding the POW. But you need multiply it by number of all nodes in BTC network.
There are a lot of miners too, but cost of finding the POW is split between them. Each do only small part.
While validation/processing cost do not split - each BTC node need to "pay" it.

How do you calculate cost per transaction in a fiat system, for example the USD?
Think about all the energy that is used by a fiat monetary system.

Same formula, isn't it?

How about cost of employees, cost of real estate, etc. etc. in a fiat system?
I wonder what the cost of the USD system would be.

First we have to agree on units, then a baseline.

Compared to the existing system that one finds preferable to USD, what is the average gain (or loss), per participant, in:

life expectancy
opportunity for independence (political, financial)
time spent completing a transaction (financial, social, commercial)
access to <food, health care, environmental security, education, information>     What is a good word encompassing the <  >?

It was meant to be a "rule of thumb" for humans -- not a precise test.

Seems to me that major pools restart their hardware to increase the parameter -mintxrelayfee

block 000000000000000000a5b95580d2962fd249cff732bf77dd81054e8412c2cecc (BitFury)
was mined a hour after the previous block but contains only 200 transactions

good time for doublespending :)

amaclin, did you restart the attack?

I'm seeing this on statoshi:
https://i.imgur.com/CirHhM4.png

Its far simpler than that.

First, the banks have themselves said that blockchains can save them nearly $30bn each year in costs. What costs? That would be middle layers that can be deleted. Within that $30bn of savings are many servers living inside data centres, with many additional data centres for back-ups, DR and support - in many countries around the world.

Then there is all the testing and sign-off that takes place. Training, useless meetings, etc.

Second, when an international transaction takes place within the banking system, the data bounces from one system to the next to pass around the layers routers and transaction processors. Just this aspect would have the same electrical footprint / cost as the Bitcoin network.

If you don't know what is involved in moving money around the world, how can you claim to known the hidden costs in order to compare them to the Bitcoin network.

meh.

Yes

if this is a technical stress test for bank bandwidth, there should be a maintenance page informing us or something, beside why have we to guess, like blockchain cant share news or if is it really out of their control and they getting swamped head over tail with double spent issues?... mine deposit wasnt double spent yet still not going thru like their server stop sending outward confirmation altogether

found this interesting, an alternative already exist apparently in github dunno test phase or something, not a programmer  ::)

A test net (alternative bitcoin block chain) implementation of the replace-by-fee idea is already available on GitHub.
https://github.com/petertodd/bitcoin/tree/replace-by-fee

quote: Eric Springer is the founder of BitUndo, a company that attempts to retrieve unconfirmed transactions on-blockchain. He says that ideas such as replace-by-fee could solve the possible implications of double spending unconfirmed transactions on-block by enforcing the replacement of an existing transaction only with another that has a higher fee.

Said Springer:

    "Bitcoin would be a much better and more secure place with such a policy."

http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/ (http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/)

found info from coindesk

apparently we knew it had a flaw when implenting Bitcoin Core:

Double Spending Risk Remains After July 4th Bitcoin Fork
http://www.coindesk.com/double-spending-risk-bitcoin-network-fork/ (http://www.coindesk.com/double-spending-risk-bitcoin-network-fork/)

also it seem its the miners who must quote "implementation of a Bitcoin Core update by" ... "of the network's miners"

something about 30 confirmations (time 10 minutes.. hmm 5 hours ugly
"is advising these entities wait an additional 30 confirmations before considering transactions valid."

this the info about the core developer warning
https://bitcoin.org/en/alert/2015-07-04-spv-mining (https://bitcoin.org/en/alert/2015-07-04-spv-mining)

if its not too much to ask and a Core Developer is able this implement "replace-by-fee" in a Bitcoin Core seem promising if to try for bettement and before the zombie blocks spread and spoil everyone transaction time

Did the attack restart? Having same problems again....

This is old info and is completely unrelated to this transaction malleability attack.

well, thats your opinion based on your perceptions of thing. im not saying it was but implying that the result are similar..   :-*

anything that touches Txs time it takes to be validated even if its thru spoofing of the Tx IDs is related in that it creates zombie blocks.

im trying to get experienced developers to think about solutions, and sharing news about updates to further ameliorate this blockchain services...

my thought was this; wouldnt a similar replace-by-fee process be developed to ensure if but the Tx IDs difer but the rest of the block hash is equal to the highest fee, than just would make ignore the other spoofed Ids, make the problem go away ?    :D

He kinda has a good point. (refering to amaclin) core devs don't get paid for theirs work. At least not enough.
Don't get me wrong i hate what he is doing cause its causing us huge problems. But he does have a good point about devs not getting paid.

Now my question is are there any donation wallets setup for "paying" core devs?

And also i would even dare to suggest that there should be donation button in Bitcoin wallet.

People use Bitcoin on daily bases and we need core devs to continue working on it so we should pay them.
When i say we i mean every user of Bitcoin. At least through some donation type of deal.

Nope. Replace-by-fee means that another transaction spending the same inputs is sent, but with a higher fee. It is just another normal transaction, which amaclin (or anyone else) with an automated script can and will just mutate it just like any other transaction. It doesn't help except to create more backlog in the mempool.

What replace-by-fee does help with is with those idiots who send transactions thinking they can get away with low or no fees at all. Replace-by-fee allows them to resend the transaction with a higher fee so that it can actually be confirmed.

Replace-by-fee also would help the author of a real spam attack.  Not the "stress tests" that we had so far, that only cause annoyance to nodes and delay low-fee transactions, but a real attack that aims to delay some fraction of the legitimate traffc.

To do that, the attacker needs to continuously issue transactions with proper fees, so as to ensure that he will take most of the space in the next block.

The current average effective capacity of ~0.800 MB/block and actual traffic is ~0.400 MB/block.  If he wanted to let only 50% of that traffic to go through, for example, he would have to issue at least 0.600 MB of transactions every 10 minutes, with fees calibrated to beat all unconfirmed transactions in the pool except the top 0.200 MB.  

Obviously he would have to keep raising his fees, as legit clients raise theirs.  Currently, that means that many of his own transactions would end up stuck in the mempool too, and would be confirmed after the attack ends, costing him a lot of BTC.  With replace-by-fee, he could instead recycle those transactions during the attack, saving money.

The network was impacted, not just some wallets.  I know this for a fact, because I personally had to fix two nodes that I run.  Both of these nodes were running your latest release software with default configurations, BTW.

I'm running a node on my raspberry pi 2 and it was running fine for the last 2 months without reboot.

Since some days i have some problems, the deamon fills the whole ram and even >1GB swapspace is used. I have to restart the deamon every day. The weeks before it was running  @ ~50% RAM-usage all the time. Does that have something to do with this attack ?

Is there something I can do or configure to prevent that memory bloat ?

I am not sure, but I guess yeah, this is causing mempol to raise >1GB, currently according to this https://www.smartbit.com.au/txs/unconfirmed unconfirmed tx are 84k and 1.03GB of backlog.

Try putting these into your bitcoin.conf file and restarting:
minrelaytxfee=0.00005
limitfreerelay=5

This has been bugging me. I've read elsewhere about the real cost of sending transactions on the Bitcoin network being much, much higher than the banking or Visa network.

I'm sure this has been pointed out before since 2009, but I can find any references. So....

Lets assume that Bitcoin scales to Visa levels by 2030:

https://i.imgur.com/7fo6g0s.png
https://www.nerdwallet.com/blog/credit-card-data/credit-card-transaction-volume-statistics/

Lets also multiply the cost of Bitcoin mining by a factor of 10 to ~$3bn / year - costs which are covered by fees and or other sources.

As Visa charge ~ 2%, their charges amount to more than $60bn. Lets say costs to run are actually 30%, so $18bn.

So, comparing apples with apples, Bitcoin will be far more economical to operate.

This attack wont stop

Unless miners start to ignore High-s.

They are not skilld enough

The cost per bitcoin transaction includes the cost of running the full nodes.  This includes the nodes that forward the unconfirmed transaction to the node that eventually mines the tranaction, the full node that eventually mines the transaction, and the other full nodes that verify and store the block containing mined transaction.

Assuming the software were 100% efficient, this would, at least include the cost of transmitting the transaction to each node, the cost of verifying the transaction and the cost of storing the transaction.  (In practice there are additional costs and overheads, but these are the essentials based on the design of bitcoin which requires all full nodes to receive and verify the entire block chain.  Most of the extra overheads can, at least potentially, be avoided by clever software design.)

A transaction has an average of two digital signatures to be verified (most of the processing) and 500 bytes of data to be received (and on average transmitted) and stored.  The costs can be worked out, but will depend on the users location.  Some (SWAG) figures for bandwidth cost and storage cost are $0.10 per GB.  You can do your own math and figure out how much it costs a node to process an average bitcoin transaction.  This has to be multiplied by the number of nodes in the network (or the number of nodes that you think are useful to have in the network).

The cost of mining is a fixed cost of running the network.  It remains constant regardless of the number of transactions that are in the blocks being mined.  This is the cost of protecting the value of the bitcoins held by the private key holders.  It is not the cost of processing transactions.

Can somebody explains in a simple sentence (subject + verb + object) what's the problem with this attack, besides that can be a possible duplicate for your transaction that never gets accepted by the Blockchain and gets deleted by the Blockchain after 1 week (estimated time)?

There are two problems:

1. Some wallets get confused should they send a transaction that gets changed by the attack, giving wrong status information to the user.

2.  The attacker can increase the size of the memory pool of unconfirmed transactions, which uses extra processing resources, memory resources and network bandwidth, potentially causing sluggish performance of the network and crashing weak nodes.

6,000 nodes x $100/month hosting costs (which would be on the higher end), works out at $7m / year. Lets say 300,000 full nodes x $500/month each, that gets you to $1.8bn in full node costs. Add that to $3bn, no lets say $5bn in mining costs. You still get less than $10bn annual costs to operate the network vs. Visa costs of $18bn - $30bn, before taking into consideration MasterCard, banks costs, etc.

At mass payments scale, Bitcoin running its own decentralized back-ups / disaster recovery network is way more efficient.

So: only the weak will suffer.

Thank You for your reply.


Best regards.

https://github.com/bitcoin/bitcoin/pull/6769

> only the weak will suffer.

https://i.imgflip.com/se7l3.jpg

I don't understand: how the weak suffering has something to do with centralization?


Thank You and Best regards.

When you suppress the agency of the weakest members of a group, they either forfeit their ability to contribute to it (a.k.a. they leave) or else delegate it to those slightly stronger. 

This next slightly stronger group is now the new "weakest" and the cycle continues. 

The result is that strength of the entire group becomes increasingly concentrated toward a center (or centers, in a multimodal distribution) of mass. 

OT

Are we the new strongest?

Do you have something in contrary of been one of the strongest?

Best regards.
/OT

I will tell more

I have Mycelium 2.5.2. It allows to spend from unconfirmed transactions (without this feature a user could not make a next transaction until a next block in blockchechain will be generated but user should have a right to spend a change al least for example from a previous payment without waiting)
But this attack has a biggest problem as you could think - now i cannot spend my money from HD account already 3 days because this attack affected my Mycelium wallet. How it happens:

I did Tx - A. After soon i did other Tx - B. The B uses inputs from Tx A. Both transactions were unconfirmed. But attacker rebroadcasted  a changed new transaction - A'. And this transaction was confirmed! After refreshing in the Mycelium wallet the last one forgot about A and replaced it by A' Tx. But after i had the A', the B transaction which used inputs from my other Txs and from the A! But the A already doesn't exist because it was double-spended for blockchain! And the Tx B looks like normal transaction (not double-spend!) because it has input from A transaction (other hash) - there is original TxID and its Tx was forgotten. Miners and full nodes think that they have the B transaction but didn't get a the A yet (other inputs refere to valid Txs of course). And this transaction hangs in mempool already three days and i cannot use other inputs! As a result of this - i as user cannot use other bitcoins already some days. I tried to archive account in Mycelium, wait 1-2 days and activate account again - and this "zombie" B Tx restored again and holds other outputs of other Tx from spending because the B has them (i see it happens because the Mycelium company has own bitcoin blockchain explorer which remembers this B Tx long time).

I think it problem is not only of the Mycelium wallet software.

While malleability will be in current protocol and the BIP62 doesn't work yet - any atacker will be able to make many shit to other users with wallet software - in this case there will be only one way to use bitcoin: to make one transaction in wallet -> wait until confirmation -> doing next transaction... It is stupid and very not comfortable way of bitcoin using.

What do you think about this?

P.S. I am as an advanced user exported xpriv key in Electrum and after this made new transaction and did double-spend of other inputs which were blocked by B Tx... But should what do not-advanced user? He will think that bitcoin sucks and he lost a money...

I updated Mycelium to v2.5.3 and I couldn't make 3-4tx in a row without being confirmed last tx, then try to send others, here what error I get when I try to send 2nd tx without being confirmed first one http://imgur.com/I7HDhQf which is bullshit as my wallet was synced !

As far as I know you could make tx from Mycelium without being confirmed or make tx like as much as you want before first, second .. tx without being confirmed, but I think these changes are from v.2.5.3 and I think it's better for begginers to wait until this attack is over or BIP62 or whatever is implemented to fix this issue/attack.

I think that you are not advanced bitcoin user.

I think about you same too.

P.S. Do you have anything to talk about this problem not about me?

P.P.S. Ecть чтo пo дeлy cкaзaть, или нa личнocти бyдeм пepexoдить?

What problem? Malleability? THIS IS NOT A PROBLEM.

Sorry. I know too little about bitcoin, malleability, etc. I am newbie. You are right. I am not advanced user. Thank you for notice it.

It's problem for wallet software. Read above.

If mycelium does not allow you do use unconfirmed change by default, it is fixed and the error you got was perfectly fine. Transactions always refer to other transactions via the ID, thus if the ID changes your 2nd TX becomes invalid. It points to a TX that lost a race for confirmation and is now invalid.

If you have several inputs available Mycelium might be able to use more than one confirmed input and thus can issue several TX without waiting for a confirmation.

http://www.youtube.com/watch?v=unYrzvtC4Q0

Sarcasm does not go easily through the internet.  You should use ";D"even when you think it is obvious.

Just wanted to quote this for my "best of amaclin" compilation. Best if read while drinking Stoli and imagining amaclin's voice that of crazy Russian hacker from YouTube. :P

I think that has more to do with assburgers than internets,

Looks like 0.11.1 will do something about the attack -> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011500.html

I made some money on this attack, im happy

dirty money?

How would you have made money due to the attack?

Maybe he tricked someone with a broken implementation into sending him money multiple times.

Easy. Send a tx to yourself, use those inputs for a second transaction to someone else who accepts 0/unconfirmed transactions, then mutate the txid of the first transaction, making the 2nd transaction invalid, allowing you to double spend the 2nd transaction.

You could do a double-spending without this attack :P
This attack doesn't help in this...

Yes, these are gold rules... But many companies don't follow these rules.
The gold rule for bitcoin receivers to wait at least 1 confirmation. But many companies who paid to me don't follow these rules and after this attack i should resolve some unpaid trasnactions from them... They think that paid to me (they pay to me through some gateways) but i don't have bitcoins.

This attack has benefited. But for many it is better understood, it is necessary to continue the attack for a long time.

During time of this attack i thought that a bitcoin price will be dropped but one only grown :(

It makes it much easier. More nodes will accept the mutated transaction then would accept a transaction that outright conflicts with an existing transaction in it's mempool so the chances of getting the mutated transaction confirmed are greater.

If you make a first transaction will be first to yourself and after immadiatly you will pay to other who accept 0-confirmed tx - yes, this can help to you if your first tx will be duplicated by attacker firstly and be accepted by miners. Ok. But it's difficult way. Ok, you are right, may be it will help.

That attack won't work.If you want to malle a tx you gotta do it the same second as the other tx.Lets say you send it to a gambling site ok but you have to wait at least few seconds for the deposit to show up and for the outcome.If there's at least 1 second delay the first tx will be propagated through the nodes already.

"Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector."

Are there any negatives to this fix?

I suggest reading this thread.

Seriously. such an embarrassment.  So much grunting and flinging of poo and people don't bother to read messages of actual substance.

If all miners use this rule, a few users with old clients that create high S signatures will not be able to get a confirmation for their transactions. A solution would be to fix their client, wait until the network forgot about this transaction an send new a transaction with a low S signature. Or somebody changes the transaction to low S by using the malleability mechanism.

Here's my summary of the substance.

The "negative" is that old, defective implementations will no longer work.  Users of these defective implementations will have to upgrade, or if that is not possible, they will have to export their private keys and switch to newer software.

Some of us believe that this is not a "negative", rather that it is a "positive".  The fix is not just a convenience fix, it is a security fix, because the continued existence of the bug admits for denial of service attacks.  It also enables malevolent cancellation of transactions that depend on unconfirmed transactions.

This is very close to hardfork.
Yes. I do understand that it is not a hardfork in strict terms.

So, are you sad that your latest attempt to save people from this great Ponzi is being crippled? I see, you are having great time with buttcoiners here...

https://www.reddit.com/r/Buttcoin/comments/3okxo5/does_amaclin_need_some_btc_to_wreck_havoc/

What is your next plan? Going back to your boring job or buying some BTC as retirement fund?

I do not remember when and where I said this.
These are your words, not mine.

I don't agree, not even in the most lax of terms.

It's a standardizes rule,  and already on the order of 95% (https://github.com/bitcoin/bitcoin/pull/6769#issuecomment-146100684) of transactions were already conforming.  If a wallet produces a non-conforming transaction anyone in the world can mutate it to the conforming form.  Even absent the auto-mutation, when it doesn't work-- it fails safe: you can still receive transactions, but your sends may not work; and you can either update your software or find someone/something to mutate them for you. It's likely that due to 'helpful' mutation and non-upgraded nodes and miners the remainder will continue to get confirmed (with delays) for some time... and that 5% remaining should drop as electrum and armory get updates out.

I would have preferred to continue to wait to activate the filtering, which has been implemented and waiting in Bitcoin core for years now, until even more users were upgraded... but the ongoing attacks made that a poor trade-off:  There is no reason that the creators of 95% of the transactions should suffer attacks because we were worried about inconveniencing the remaining 5%.   I also called in this thread multiple times for help driving that 5% down to nothing and no one else cares, so-- how much can the negative impact matter when basically none of all the noisy people in this thread cared to lift a finger to help mitigate it?

All the other avenues for "nuisance mutability" that we're aware of were closed long ago, some of those also required getting wallets to update, but far fewer wallets were broken with respect to those rules. Fortunately, until recently, no one who wanted to attack had bothered figuring out how to perform this particular attack (as it's ever so slightly tricker-- can't just be done by stuffing an extra byte in a transaction); unfortunately that didn't last, and so we got to lose huge amounts of effort dealing with this and creating a small amount of additional collateral disruption instead of working on other things; the result will likely also delay the deployment of CLTV some due to difficult in getting miners to update twice in rapid succession... but thats life.

I dunno, maybe some folks are busy working on producing results instead of kvetching about it on btctalk/reddit ?

I mean you force somebody to do something.
I do not want to discuss now your good intentions. They are good. Today. Yours.
I absolutely agree that transaction malleability should be fixed. (OK, in fact not absolutely, but who cares?)
Was wondering why it was not fixed in BIP-66 when we changed the rules by "voting method".

I only notice that this is one another small step from decentralization to dictate.
You force the people which agreed to consenus rules in the past do something, but tell them that the consensus rules
have not changed. What if I say: "OK, do not use Bitcoin Core! It is too old software, use [name]"

Technically saying, if developers are able to force miners to upgrade their software today to "improved version"
then it woluld be possible to force them switch to a hardfork tomorrow.

What a big fat liar you are! Here is what you said...

I think he was being sarcastic when he said that.

Sarcastic or not, there is no point in blatantly denying something that someone actually said.

I did not say that this attempt is latest. No, I am not sad.

That was a fact. You or me stating that fact makes no difference whatsoever. So, you did not say what is your next plan? Going back to your boring job or buying some BTC as retirement fund? ::)

I am 100% sure that BTC (or any other crypto) is bad investment. Point.

Is there any script or webservice that allows one to check transactions for low-s signatures? Basically a service that does https://bitcointalk.org/index.php?topic=1198032.msg12624538#msg12624538 automatically.

Congratulations Amaclin for your successful attack . It seems that you have excellent coding skills, and thank you for invest your time showing to the bitcoin world such attack its feasible and possible.

Im totally agree with you, people only take things for free. Who support the core developers ? Bitcoin world, a 6 billion capitalization currency, lots of software implementations, lots of apps, lots os business, lots of transactions, but nobody cares about the code....someone will fix it ! they say

I think bitcoin its a powerful idea, and maybe a decentralized system is not cheaper, but i think its needed, its very possitive to have an alternative system, im convinced bitcoin will never scale and i think its better for the bitcoin ecosystem. Bitcoin will have a brillant future as an alternative currency : scarcity, secret, special, tool, elite ,... = value

So we have a brillant currency, but we dont want flaws, so a professional team of developers , 10 full time c developers well motivated and well payd its mandatory, how? through commissions... bitcoin network users must to pay for this service or there is no brillant future for bitcoin.

Who? You? Me? Thanks, but no thanks
Just one another ponzi scheme.
No, it is not needed.
No, there is no future for any crypto. It is too expensive for maintaining.
Wrong. You have nothing, but 50 GB of junk data on your harddrive and a dream to be a $ millionare.

Good time for this post.  Marks the one year anniversary of Amaclin's prediction of $10 BTC "...within three months..."

I was wrong.
I thought that bitcoiners are more clever and able to do basic arithmentics :)
I was wrong.
They are dumb hodlers :)
Ok, this bubble is alive even today

Oh for sure we need a decentralized monetary system, and a decentralized world too.

You mention Tragedy of commons , an example of that you have in 2008 Lehman brothers collapse, pursuing they own rationale incentives, the banks and investment funds destroyed their loveled system, a flawed one , more than malleable,...

I have no time to arguee more,... but think , we have a world of 6 billion people , and surprise !! there are almost 100 people who control all this minds, they have the power. You are a smart guy, give me a reason why you are not  in this group of 100.

In the year 2116 people will laugh about this social-economical comepetitive system, and for sure they will ask themselves,.... why. 

In the year 1816 there was 8 year old children working at coal mines, not too smart i think , better for society in overal to keep those children learning things, so we ask ourselves today ,.... why.

Bitcoin and other cryptos are flawed? ok, but we are on the way, we have to explore , if we take a snapshop of global economy today , is not very promising , and is not a fair game, ...as a westerner i believe i have no more rights over a chinesse , indian or Tuvalu citizen to live in this world, so i dont pursue be millonarie, i pursue a better world for all

"we need" is not equal to "anyone wants to pay for it"

Hey man, love your work. What brings you back to this forum? Did you suddenly feel an urge to bash bitcoiners?

Such idealogy just smacks of communism doesn't it? Life is not fair, neither should we expect it to be.

If it don't burst - it ain't bubble. Choose different word.

You aren't the Pawel Pszona they think is Satoshi from this thread https://bitcointalk.org/index.php?topic=1345468.0 are you?

 :o  ;)