Possible Guide on how to "disable" the bitcoin network(?)

[TwinWinNerD]

Even if this was possible what woud you do to prevent it?

Increase the max blocksize and introduce a methode to bootsstrap the blockchain, so that it doesn't bloat

They are already working on both of those issues.  Go help them.

I am currently not capable of doing so.

But back to the topic, is this following statement true?

"It is possible to slow down the processing time of transactions with this attack, although it is extremly expensive and not very practicable."

No it is not true.

then tell me why, because the explanation from before is not enough.

[1713538953]

1713538953

[1713538953]

1713538953

[1713538953]

1713538953

[1713538953]

1713538953

[1713538953]

1713538953

[MoonShadow]

You say that so many have tried. How many managed to get the TPS above 10?

  If you are producing 14 tps from the same wallet.dat file, it's impossible for them to not be dependent upon each other.  So your first transaction must be processed before your 2nd, and so on.  You don't introduce a condition that you can delay anyone but yourself, althoug you can still manage to spend fees pretty fast.

You can set up a couple of nodes and with enough BTC in stock you can always send fresh satoshis + the minfee.
[/quote]

At some point, multiple wallet.dat files repeatedly sending each other transactions still become dependent upon one another.  The same thing would happen if every user on the system were repeatedly sending each other transactions, and that is the point.  The delays protect the system regardless of where the delays originate.  If the delays are truely legitimate, then yes the network can get bogged down, which is why the network will favor higher fees for short term processing.  If you need that kind of speed, you can pay for it.  But there is no one with enough money that can screw the system over for any significant period of time.

[TwinWinNerD]

You say that so many have tried. How many managed to get the TPS above 10?

  If you are producing 14 tps from the same wallet.dat file, it's impossible for them to not be dependent upon each other.  So your first transaction must be processed before your 2nd, and so on.  You don't introduce a condition that you can delay anyone but yourself, althoug you can still manage to spend fees pretty fast.

You can set up a couple of nodes and with enough BTC in stock you can always send fresh satoshis + the minfee.

At some point, multiple wallet.dat files repeatedly sending each other transactions still become dependent upon one another.  The same thing would happen if every user on the system were repeatedly sending each other transactions, and that is the point.  The delays protect the system regardless of where the delays originate.  If the delays are truely legitimate, then yes the network can get bogged down, which is why the network will favor higher fees for short term processing.  If you need that kind of speed, you can pay for it.  But there is no one with enough money that can screw the system over for any significant period of time.
[/quote]

That is just your assumption and it think it is not true.

Lets do the math on this again.

We send EVERYTHING from one wallet!

600.000 Transactions per day. 0.0001 Fee + 0.00005000 amount
= 600000*0.00015 = 90 BTC needed in that wallet at the start of the day. That hardly seems impossible, and there is ZERO conflict

[TwinWinNerD]

Hey Dumbass OP,


You do realize that you are advocating destroying a value system that measures its value with in multiples of BILLIONS OF USD?

Do you really want to convince some powerful people that you are a threat to their years of work and wealth?

Not very conducive to a long and healthy life.

You might want to rethink this "Guide"


~BCX~

You know that if you keep silent about a possible exploit in a system, that this bug doesn't go away from its own? I just want to see a fix before someone decides to exploit that.

[MoonShadow]

Even if this was possible what woud you do to prevent it?

Increase the max blocksize and introduce a methode to bootsstrap the blockchain, so that it doesn't bloat

They are already working on both of those issues.  Go help them.

I am currently not capable of doing so.

But back to the topic, is this following statement true?

"It is possible to slow down the processing time of transactions with this attack, although it is extremly expensive and not very practicable."

No it is not true.

then tell me why, because the explanation from before is not enough.

<sigh>

Alright, I'll explain the mechanics as best as I can remember the details.  I could easily get the actual numbers wrong, but this is basicly how the system works.

The transaction queue in the bitcoin client is ordered by points, not the order of arrival.  There are two ways to get points, you can buy them or wait them out.  When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points.  IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately.  Of course, free transactions can get processed as long as it has enough points.  Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block.  For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction.  But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed.  So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly.  No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.

[TwinWinNerD]

<sigh>

Alright, I'll explain the mechanics as best as I can remember the details.  I could easily get the actual numbers wrong, but this is basicly how the system works.

The transaction queue in the bitcoin client is ordered by points, not the order of arrival.  There are two ways to get points, you can buy them or wait them out.  When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points.  IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately.  Of course, free transactions can get processed as long as it has enough points.  Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block.  For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction.  But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed.  So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly.  No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.

I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind.

[MoonShadow]

<sigh>

Alright, I'll explain the mechanics as best as I can remember the details.  I could easily get the actual numbers wrong, but this is basicly how the system works.

The transaction queue in the bitcoin client is ordered by points, not the order of arrival.  There are two ways to get points, you can buy them or wait them out.  When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points.  IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately.  Of course, free transactions can get processed as long as it has enough points.  Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block.  For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction.  But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed.  So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly.  No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.

I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind.

You're still overlooking a critical point that I've mentioned three times.  No matter how long you age your wallet.dat file(s), the number of independent & processed transactions in those files are finite.  As soon as you run out of aged transactions to use, you are immediately dependent upon the first set of transactions being processed before your second set can even buy their way in; so you can make all your transactions in advance and hit the network all at once, and your second wave is still denpendt upon the first wave beign processed in a timely manner.  And even if you succeed at that, your second wave doesn't have any age advantage anymore.  You're second wave woudl require a significantly higher fee in order to trump my older transaction, more so if I choose to include a fee myself.  If I'm in a hurry and see that the network is jammed, I can easily outbid your per transaction fee to get through.  It's a self regulating system, yo ucan only make it cost more until you run out of funds.  You can never completely deny service to other users, even for a short time.

[TwinWinNerD]

<sigh>

Alright, I'll explain the mechanics as best as I can remember the details.  I could easily get the actual numbers wrong, but this is basicly how the system works.

The transaction queue in the bitcoin client is ordered by points, not the order of arrival.  There are two ways to get points, you can buy them or wait them out.  When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points.  IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately.  Of course, free transactions can get processed as long as it has enough points.  Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block.  For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction.  But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed.  So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly.  No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.

I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind.

You're still overlooking a critical point that I've mentioned three times.  No matter how long you age your wallet.dat file(s), the number of independent & processed transactions in those files are finite.  As soon as you run out of aged transactions to use, you are immediately dependent upon the first set of transactions being processed before your second set can even buy their way in; so you can make all your transactions in advance and hit the network all at once, and your second wave is still denpendt upon the first wave beign processed in a timely manner.  And even if you succeed at that, your second wave doesn't have any age advantage anymore.  You're second wave woudl require a significantly higher fee in order to trump my older transaction, more so if I choose to include a fee myself.  If I'm in a hurry and see that the network is jammed, I can easily outbid your per transaction fee to get through.  It's a self regulating system, yo ucan only make it cost more until you run out of funds.  You can never completely deny service to other users, even for a short time.

I think you don't read my posts at all. I have accounted for that.

In my example we start with 1800 BTC, that is enough to send 12.000.000 Transactions WITHOUT USING A SINGLE INPUT/OUTPUT TWICE! Those 1800 BTC are enough to last for 20 consecutive days. That is MORE than a short time...

[MoonShadow]

<sigh>

Alright, I'll explain the mechanics as best as I can remember the details.  I could easily get the actual numbers wrong, but this is basicly how the system works.

The transaction queue in the bitcoin client is ordered by points, not the order of arrival.  There are two ways to get points, you can buy them or wait them out.  When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points.  IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately.  Of course, free transactions can get processed as long as it has enough points.  Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block.  For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction.  But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed.  So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly.  No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.

I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind.

You're still overlooking a critical point that I've mentioned three times.  No matter how long you age your wallet.dat file(s), the number of independent & processed transactions in those files are finite.  As soon as you run out of aged transactions to use, you are immediately dependent upon the first set of transactions being processed before your second set can even buy their way in; so you can make all your transactions in advance and hit the network all at once, and your second wave is still denpendt upon the first wave beign processed in a timely manner.  And even if you succeed at that, your second wave doesn't have any age advantage anymore.  You're second wave woudl require a significantly higher fee in order to trump my older transaction, more so if I choose to include a fee myself.  If I'm in a hurry and see that the network is jammed, I can easily outbid your per transaction fee to get through.  It's a self regulating system, yo ucan only make it cost more until you run out of funds.  You can never completely deny service to other users, even for a short time.

I think you don't read my posts at all. I have accounted for that.

In my example we start with 1800 BTC, that is enough to send 12.000.000 Transactions WITHOUT USING A SINGLE INPUT/OUTPUT TWICE! Those 1800 BTC are enough to last for 20 consecutive days. That is MORE than a short time...

Okay, but even if you have that much to blow, as soon as you begin you just drive up the price.  I can still outbid your per transaction fee if I need to get something done sooner rather than later.  And if you do try this, most users would learn pretty fast that the delays were due to a transaction spam attack, and either increase their fees or wait you out.  Either way, this doesn't have any real effect upon the price of bitcoin.

And when I say I can outbid you, I mean I know I can outbid you, personally.  I actually have access to a storage wallet with ages over two years and counting.  I'm sure I'm not alone.  Once again, go ahead and try it.  Either way, you'll be remembered for it.

[TwinWinNerD]

<sigh>

Alright, I'll explain the mechanics as best as I can remember the details.  I could easily get the actual numbers wrong, but this is basicly how the system works.

The transaction queue in the bitcoin client is ordered by points, not the order of arrival.  There are two ways to get points, you can buy them or wait them out.  When you pay a fee, you're effectively buying enough points to reach the minimum number of points to get processed, because no transaction gets processed before it has enough points.  IIRC, one satoshi = one point, and the minimu fee is the minimum number of points required to process immediately.  Of course, free transactions can get processed as long as it has enough points.  Any transaction that has it's YOUNGEST input transaction old enough to have enough points gets processed, at one point per block.  For example, if I didn't use my wallet for several weeks, my free transaction might still end up with more points than your minimum fee transactions based upon a brand new input transaction.  But in addition to that, no transaction that has not had it's inputs processed can have any points at all, regardless of the fee, because the network won't even recognize your #2 transaction until the inputs from #1 are processed.  So no matter how many wallet.dat files you're using to do it, your processed transaction input are finite, and I would stil be able to get my transaction based upon a 3 week old input through before your 1 second old transaction with a fee, unless and until you were willing to increase your fee significantly.  No matter how you do it, your spamming costs you an exponentially increasing amount of money to maintain, and since most users don't need to have their transactions processed in less than an hour anyway, most users wouldn't even notice your efforts.

I actually know all these points, thats why i said that you start from a single wallet with enough founds that you don't need to use any fund twice. If we need 90 BTC per day to occupy all slots, we can buy/collect 1800 BTC and just let them sit for a/couple months and then just"freeze" the network for 20 consecutive days. Most people won't have a problem with 1 hour waiting time, but if their transactions are held in limbo for 2 weeks, they WILL mind.

You're still overlooking a critical point that I've mentioned three times.  No matter how long you age your wallet.dat file(s), the number of independent & processed transactions in those files are finite.  As soon as you run out of aged transactions to use, you are immediately dependent upon the first set of transactions being processed before your second set can even buy their way in; so you can make all your transactions in advance and hit the network all at once, and your second wave is still denpendt upon the first wave beign processed in a timely manner.  And even if you succeed at that, your second wave doesn't have any age advantage anymore.  You're second wave woudl require a significantly higher fee in order to trump my older transaction, more so if I choose to include a fee myself.  If I'm in a hurry and see that the network is jammed, I can easily outbid your per transaction fee to get through.  It's a self regulating system, yo ucan only make it cost more until you run out of funds.  You can never completely deny service to other users, even for a short time.

I think you don't read my posts at all. I have accounted for that.

In my example we start with 1800 BTC, that is enough to send 12.000.000 Transactions WITHOUT USING A SINGLE INPUT/OUTPUT TWICE! Those 1800 BTC are enough to last for 20 consecutive days. That is MORE than a short time...

Okay, but even if you have that much to blow, as soon as you begin you just drive up the price.  I can still outbid your per transaction fee if I need to get something done sooner rather than later.  And if you do try this, most users would learn pretty fast that the delays were due to a transaction spam attack, and either increase their fees or wait you out.  Either way, this doesn't have any real effect upon the price of bitcoin.

And when I say I can outbid you, I mean I know I can outbid you, personally.  I actually have access to a storage wallet with ages over two years and counting.  I'm sure I'm not alone.  Once again, go ahead and try it.  Either way, you'll be remembered for it.

You can outbid me because you have such an old wallet, others might read about it and increase their sending fee. BUT the majority of transactions use the formula where for every 1 kb 0.0001 Fee is applied. So all automated transactions would come to a halt and most user transactions.

I still think that this is a risk we have to completely solve, but it is not as severe as i thought.

Thank you for the discussion btw!

[lnternet]

So far I have not seen TwinWinNerD's attack refuted.


I own 1000 BTC.

I am investing 180 BTC in my attack and sell the other 820 on the exchange. I divide them into outputs of size exactly 0.1mBTC+1satoshi over a few weeks onto several node's I control. That will be about 1.8 million tx I can spam once set up. That is more than 3 consecutive days of 6 tx/s. 

Once ready, I unleash the kraken, send 10tx/s in burst mode. The queue will grow long very quickly until tx are dropped at the end of it.

Now most people will not know what is going on, but simply see their cashout from bitstamp or their transfer to a friend not show up for a looong time. Of course, the core crew here knows to just increase the mining fee a bit to jump to the front of the queue, but that's not something 90% of the users even know how to do (wild estimate).

This will cause a bit of a sell off of coins. These coins, however, don't even arrive at the exchange within a day (caught in queue / dropped). Now people panic. Price drops 20% in a day (wild estimate).

I buy BTC back, with the money I got from selling earlier. At 20% lower price, I can afford 1020 BTC.

Voila I made 20 BTC profit.

FF a week. The newst -qt is released which has a dynamic automatic fee. The BTC price reaches pre-attack levels. My 20BTC profit is now in the money as well.



Where does this attack fail? (Besides the wildly estimated numbers of course.)

[MoonShadow]

You can outbid me because you have such an old wallet, others might read about it and increase their sending fee. BUT the majority of transactions use the formula where for every 1 kb 0.0001 Fee is applied. So all automated transactions would come to a halt and most user transactions.

Yes, of course you can cause some delays if you're willing to spend the funds.  But your costs are ever increasing as the attack continues.  Personally, I don't think 1800 BTC would be enough to maintain such an attack of any significance for two weeks.  And we haven't even talked about the 'soft' blocksize limit rules.  The blocksize can "stretch" somewhat when the fees increase significantly, which would also increase your attack vector costs or limit your effectiveness.  The end result is the same.

I still think that this is a risk we have to completely solve, but it is not as severe as i thought.

Thank you for the discussion btw!

It's not something that can be completely "solved", although the developers are working on "naked" blocks, which would improve the effective throughput of the network significantly, even without increases in the blocksize limits.  Because there is no way for a computer to distiguish between a spammer willing to pay the price from a group of honest users.  Individual miners can add additional sorting rules as they see fit, however, so if you come up with a new one that might further limit such damage, or cost attackers more, feel free to propose it.  Some will take it up, and complete compliance with the rules are not required most of the time.

[MoonShadow]

So far I have not seen TwinWinNerD's attack refuted.


I own 1000 BTC.

I am investing 180 BTC in my attack and sell the other 820 on the exchange. I divide them into outputs of size exactly 0.1mBTC+1satoshi over a few weeks onto several node's I control. That will be about 1.8 million tx I can spam once set up. That is more than 3 consecutive days of 6 tx/s. 

Once ready, I unleash the kraken, send 10tx/s in burst mode. The queue will grow long very quickly until tx are dropped at the end of it.

Now most people will not know what is going on, but simply see their cashout from bitstamp or their transfer to a friend not show up for a looong time. Of course, the core crew here knows to just increase the mining fee a bit to jump to the front of the queue, but that's not something 90% of the users even know how to do (wild estimate).

This will cause a bit of a sell off of coins. These coins, however, don't even arrive at the exchange within a day (caught in queue / dropped). Now people panic. Price drops 20% in a day (wild estimate).

I buy BTC back, with the money I got from selling earlier. At 20% lower price, I can afford 1020 BTC.

Voila I made 20 BTC profit.

FF a week. The newst -qt is released which has a dynamic automatic fee. The BTC price reaches pre-attack levels. My 20BTC profit is now in the money as well.



Where does this attack fail? (Besides the wildly estimated numbers of course.)

There are other tricks of the protocol not yet mentioned.  One is the stretchy nature of the blocksize limit.  You had better hurry if you wish to test this theory, though.  It won't be much longer before the "naked block" protocol is ready for prime time.  Like I already said, if you've got the funds and the balls, put it to the test.  If you succeed in breaking the network, so be it; it was bound to happen eventually anyway and better sooner than later.  If you fail, then you will have spent a lot of money to prove something the rest of us believe.  Whatever the outcome, you'll be remembered.

[NewLiberty]

So far I have not seen TwinWinNerD's attack refuted.

More accurately, the refutations required minor work-arounds.
Wallets are free, a finite amount of wallets are required for such an attack.
It is doable, and very possibly profitably so.

For what its worth, I've anticipated this precise attack for quite a while and so have my default miner fee above the minimum.
Also, I <3 miners.

It is also not the greatest current threat to the Bitcoin network, but still worth mitigating.

[Soros Shorts]

If this were to happen many people who run full nodes would probably install a patch in bitcoind that drops these junk micro transactions. The end result is that these junk transactions would propagate slower across the network. A couple of years ago people installed the Satoshi Dice patch which ended up forcing them to make their protocol less wasteful.

[johnyj]

So far I have not seen TwinWinNerD's attack refuted.


I own 1000 BTC.

I am investing 180 BTC in my attack and sell the other 820 on the exchange. I divide them into outputs of size exactly 0.1mBTC+1satoshi over a few weeks onto several node's I control. That will be about 1.8 million tx I can spam once set up. That is more than 3 consecutive days of 6 tx/s. 

Once ready, I unleash the kraken, send 10tx/s in burst mode. The queue will grow long very quickly until tx are dropped at the end of it.

Now most people will not know what is going on, but simply see their cashout from bitstamp or their transfer to a friend not show up for a looong time. Of course, the core crew here knows to just increase the mining fee a bit to jump to the front of the queue, but that's not something 90% of the users even know how to do (wild estimate).

This will cause a bit of a sell off of coins. These coins, however, don't even arrive at the exchange within a day (caught in queue / dropped). Now people panic. Price drops 20% in a day (wild estimate).

I buy BTC back, with the money I got from selling earlier. At 20% lower price, I can afford 1020 BTC.

Voila I made 20 BTC profit.

FF a week. The newst -qt is released which has a dynamic automatic fee. The BTC price reaches pre-attack levels. My 20BTC profit is now in the money as well.



Where does this attack fail? (Besides the wildly estimated numbers of course.)

What if your bank closed for holiday and do not process the transactions? You use another bank account     Bitcoin is not the only currency

BTW, it is possible that a hedge fund might noticed a perfect buying opportunity on exchange and start to buy a lot at 10% price drop, and you sold all your coins and never be able to buy them back at a lower price

[anti-scam]

https://en.bitcoin.it/wiki/Transaction_fees

Calculation of a transaction's priority (which partially determines how quickly it makes it into a block) is partially based on the age of the input (how recently the coins involved have been spent last). I'm pretty sure that this has always been the case which means that this problem was solved by Satoshi before the original version of Bitcoin was released years ago.

All must repeat after me: "I have probably not found a way to disable a multibillion dollar network. I should go read the wiki and see where I'm wrong."

[Sonny]

https://en.bitcoin.it/wiki/Transaction_fees

Calculation of a transaction's priority (which partially determines how quickly it makes it into a block) is partially based on the age of the input (how recently the coins involved have been spent last). I'm pretty sure that this has always been the case which means that this problem was solved by Satoshi before the original version of Bitcoin was released years ago.

30,000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block.
Then transactions that pay a fee of at least 0.0001 BTC/kb are added to the block, highest-fee transactions first, until the block is not more than 300,000 bytes big.

So, as long as you pay the min fee, you really don't care much about the tx priority.

[anti-scam]

https://en.bitcoin.it/wiki/Transaction_fees

Calculation of a transaction's priority (which partially determines how quickly it makes it into a block) is partially based on the age of the input (how recently the coins involved have been spent last). I'm pretty sure that this has always been the case which means that this problem was solved by Satoshi before the original version of Bitcoin was released years ago.

30,000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block.
Then transactions that pay a fee of at least 0.0001 BTC/kb are added to the block, highest-fee transactions first, until the block is not more than 300,000 bytes big.

So, as long as you pay the min fee, you really don't care much about the tx priority.

But then you eventually run out of coins. Point is that it's not an infinite attack that can be conducted using the free transaction space in blocks so it can't really "disable" anything.

[BombaUcigasa]

But then you eventually run out of coins. Point is that it's not an infinite attack that can be conducted using the free transaction space in blocks so it can't really "disable" anything.

You also run out of coins faster during the sustained attack, as you have to increase your TX fees to overcome the priority of other TXs that have higher fees. As you use coins to spam the network, you will need to use more and more. After the others pay more transactions, so must you. If you don't, your transactions are ignored.

Yes, you will cause the network to be more expensive to use while you sustain the attack, and you will spend money to do so. The miners will collect these fees. They will be happy and invest in more hardware and raise the price, thus increasing your cost for new coins. Everyone gets richer while you waste away money.

The refutation is made by simply reading the code or the documentation regarding the TX fees. If you pay fees, so will others, and if they pay more you don't do anything to the network.

Please also look at https://blockchain.info/, I see 771kb/3000kb used in the last hour. You would need to increase the TX frequency 400% to affect the speed of lowest fee paying transactions.

Also answer yourself, why hasn't this happened yet? Surely someone is bored enough to have over 1000 BTC and no brains and simply troll everyone. You think you are smarter and more informed than everyone else? Is this an original idea that the world has never seen? Well?

This did happen on other less intelligently designed altcoins. The solution? Simply change TX fee rules, get miners to update, attack vector completely annihilated.