This attack wont stop
Unless miners start to ignore High-s.They are not skilld enough
Topic: New transaction malleability attack wave? Another stresstest? - page 4. (Read 41234 times)
October 11, 2015, 02:09:23 PM
They are not skilld enough
October 11, 2015, 01:43:13 PM
This attack wont stop
Unless miners start to ignore High-s. October 11, 2015, 01:16:15 PM
This attack wont stop
October 11, 2015, 11:38:18 AM
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?
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://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.
October 11, 2015, 11:08:23 AM
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 ?
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
October 11, 2015, 07:17:50 AM
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 ?
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.
October 11, 2015, 06:38:17 AM
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 ?
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 ?
October 10, 2015, 12:41:43 PM
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
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.
October 10, 2015, 11:08:49 AM
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.
October 10, 2015, 10:37:26 AM
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 ?
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. 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 ?
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.
October 10, 2015, 06:47:55 AM
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.
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.
October 10, 2015, 05:39:11 AM
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 ?
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 ?
October 09, 2015, 09:02:39 PM
this the info about the core developer warning
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
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
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/
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 is old info and is completely unrelated to this transaction malleability attack. Double Spending Risk Remains After July 4th Bitcoin 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."
October 09, 2015, 08:51:03 PM
Did the attack restart? Having same problems again....
October 09, 2015, 08:31:22 PM
this the info about the core developer warning
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
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
October 09, 2015, 08:16:32 PM
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/
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."
Double Spending Risk Remains After July 4th Bitcoin 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."
October 09, 2015, 08:08:34 PM
http://www.coindesk.com/double-spending-unconfirmed-transactions-concern-bitcoin/
found info from coindesk
found info from coindesk
October 09, 2015, 08:01:09 PM
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."
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."
October 09, 2015, 07:30:10 PM
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
October 09, 2015, 07:23:35 PM
Yes
Jump to: