Can anybody stall Bitcoin for 72BTC per hour? ANSWER: NO

[FreeMoney]

Such an 'attack' would make the price of BTC skyrocket. In order to sustain this 'attack' a lot of bitcoins would need to be purchased. The laws of supply and demand dictates if there is a limited supply and a large demand price will go up. At 72BTC needed per hour the demand for BTC would be enormous. The longer this 'attack' lasts the more bitcoins are in demand the more expensive they become. This would make such an attack unsustainable for even the richest entities. Even though transactions won't be able to process for a while I doubt anybody would complain when seeing the value of their bitcoins skyrocketing.

Yes, and if the attack was actually working they wouldn't be able to buy more since no one could get coins to the exchanges, rofl.

[phelix]

Such an 'attack' would make the price of BTC skyrocket. In order to sustain this 'attack' a lot of bitcoins would need to be purchased. The laws of supply and demand dictates if there is a limited supply and a large demand price will go up. At 72BTC needed per hour the demand for BTC would be enormous. The longer this 'attack' lasts the more bitcoins are in demand the more expensive they become. This would make such an attack unsustainable for even the richest entities. Even though transactions won't be able to process for a while I doubt anybody would complain when seeing the value of their bitcoins skyrocketing.

Yes, and if the attack was actually working they wouldn't be able to buy more since no one could get coins to the exchanges, rofl.

besides of what gavin said: do you seriously think a couple of days of bitcoin not working would not affect the price?

[dooglus]

+ Fill up part of the block with the highest transactions, regardless of fees

I guess you mean "highest priority transactions".

It would appear so.  From src/main.cpp:

Code:

    // How much of the block should be dedicated to high-priority transactions,
    // included regardless of the fees they pay
    unsigned int nBlockPrioritySize = GetArg("-blockprioritysize", 27000);

So by default only the first 27k of each block is dedicated to the highest priority transactions.

[qwk]

besides of what gavin said: do you seriously think a couple of days of bitcoin not working would not affect the price?

Maybe calling it "not working" is just a little too harsh.

A couple of days where the average user experiences massive delays for at least a part of his/her transactions and where bitcoin based services face unexpected extra costs for their infrastructure, is what i would call it.

And that seems tough enough.

[phelix]

+ Fill up part of the block with the highest transactions, regardless of fees

I guess you mean "highest priority transactions".

It would appear so.  From src/main.cpp:

Code:

    // How much of the block should be dedicated to high-priority transactions,
    // included regardless of the fees they pay
    unsigned int nBlockPrioritySize = GetArg("-blockprioritysize", 27000);

So by default only the first 27k of each block is dedicated to the highest priority transactions.

hmmm....  roughly 65 transactions....   edit: currently about 14.4%

besides of what gavin said: do you seriously think a couple of days of bitcoin not working would not affect the price?

Maybe calling it "not working" is just a little too harsh.

A couple of days where the average user experiences massive delays for at least a part of his/her transactions and where bitcoin based services face unexpected extra costs for their infrastructure, is what i would call it.

And that seems tough enough.

agreed

[solex]

+ Fill up part of the block with the highest transactions, regardless of fees

I guess you mean "highest priority transactions".

It would appear so.  From src/main.cpp:

Code:

    // How much of the block should be dedicated to high-priority transactions,
    // included regardless of the fees they pay
    unsigned int nBlockPrioritySize = GetArg("-blockprioritysize", 27000);

So by default only the first 27k of each block is dedicated to the highest priority transactions.

hmmm....  roughly 65 transactions....   edit: currently about 14.4%

besides of what gavin said: do you seriously think a couple of days of bitcoin not working would not affect the price?

Maybe calling it "not working" is just a little too harsh.

A couple of days where the average user experiences massive delays for at least a part of his/her transactions and where bitcoin based services face unexpected extra costs for their infrastructure, is what i would call it.

And that seems tough enough.

agreed

So, is this yet another plus for an algorithmic block size limit, which could then absorb such an "attack" and still allow most other legitimate transactions through in a timely manner?

[AbsoluteZero]

You cannot stall Bitcoin.

But For 2400 satoshis Per Block In transaction fees, you can make It that only paying
(or High priority) transactions make It into the Block.

This would cost about 0.12 cents of FIAT Per day

[gmaxwell]

But For 2400 satoshis Per Block In transaction fees, you can make It that only paying
(or High priority) transactions make It into the Block.

Surprise: The people working on this stuff are not actually idiots. Very tiny fees are treated as zero, precisely to close off that sort of funny business.

[AbsoluteZero]

But For 2400 satoshis Per Block In transaction fees, you can make It that only paying
(or High priority) transactions make It into the Block.

Surprise: The people working on this stuff are not actually idiots. Very tiny fees are treated as zero, precisely to close off that sort of funny business.

Ok, how about 2400 transactions per block from old coins?

[Digigami]

How does one go about changing or modifying the rules that the client they run follows? Are there options in the config file to do this or does this need to be done on a source code level and then compiled by the user?

I'm curious how out of reach it is for average joe - somewhat knowledgeable individuals this is, or is this exclusive to the experts who can re-write the source?

I run a fairly well connected Satoshi client node. I used to solo mine from it, quite a long time ago but have been a pooler since. I opted to keep the node on line to help support the network, as it is run at very little cost to me, I don't use the wallet attatched to it, so really it's only purpose is to help relay transactions, and of course help distrubute the chain to re syncing/new clients as I am able to maintain a relatively large number of connections. On and off I will see my node in blockchain's hub-nodes list, and frequently it will be listed on transactions as the relaying IP.

Basically, I am curious to know what options a node operator such as myself has at my disposal should I decide I want my node to limit relaying or broadcasting low priority tx's such as satoshidice activity, or other low priority transactions? If I was still mining solo or if I was a pool operator, and still used the Satoshi client, to change the rules of which transactions I would include in blocks once again is this adjusted via user friendly flags or options or does one need to be a coder to change the rules?

I don't think I even want to modify my client, at least not this well connected node because basically I feel it is my single greatest contribution to Bitcoin as a whole, not because I wouldn't want to do more, but because my expertise is limited, and other then being a faithful user and advocate I am otherwise not the type who can add much to what's going on.

In the future, if the developers as a whole have not introduced changes which address the emerging issue with spam transactions, I would almost feel it my duty to all Bitcoiners that I adjusted my node to at least reduce it's participation in the problem, and ignore/not relay transactions which are troublesome. I doubt it will come to this, I have faith in our dev team that the problem with be adequately addressed before it comes down to users such as myself taking action, but I would like to know it is at least possible to do something should the need arise.

Appreciate any feedback you all have on the topic. Thanks

[poly]

Such an 'attack' would make the price of BTC skyrocket. In order to sustain this 'attack' a lot of bitcoins would need to be purchased. The laws of supply and demand dictates if there is a limited supply and a large demand price will go up. At 72BTC needed per hour the demand for BTC would be enormous. The longer this 'attack' lasts the more bitcoins are in demand the more expensive they become. This would make such an attack unsustainable for even the richest entities. Even though transactions won't be able to process for a while I doubt anybody would complain when seeing the value of their bitcoins skyrocketing.

Absolutely. Default clients sending the general fee won't go through, so there would be less bitcoins sold on the market. This would continually increase the price of BTC and such an attack is unsustainable.

However, I'll leave a conspiracy theory of the current rally is caused by the supposed establishment buying up bitcoins to halt it.

[btcusr]

The default block-filling algorithm that most miners are running is:

+ Fill up part of the block with the highest transactions, regardless of fees
+ Then fill up the rest of the block with as many fee-paying transactions as possible, highest fee-per-kilobyte first.

Point 1 can also be manipulated. Anyways, I am just moving BTC between my addresses. For others it would look like spending, but in reality I own all 6K addresses in a block. so, it is like, for about 3k transactions, we would need 3000 BTC to prevent transactions below 1 BTC to enter into blockchain. plus, whatever we are paying for transaction fee.

We don't need 3000 BTC for every block, it is just one time amount required, and we are just moving this amount around.

[Sukrim]

I guess Gavin meant "highest priority transactions"? As coin age is factored in there, you can pull this off just once.

[phelix]

I guess Gavin meant "highest priority transactions"? As coin age is factored in there, you can pull this off just once.

he definitely meant priority. see doglus' post above.

[Gavin Andresen]

Yes, I definitely meant priority. Highest priority transactions (transferring lots of old coins) get included in blocks first under the default block-filling rules.

And also notice that I said "most miners are..." There are at least a few big mining pools that have their own idiosyncratic ways of deciding which transactions get into blocks, including private deals with big exchanges/merchants/etc.

Also note that because finding blocks is a random process the Bitcoin network "stalls" for an hour every three weeks or so, with no blocks found.

My guess is that if an attacker tried to monopolize block space most of us wouldn't even notice. If you're really worried about it, then encourage some big mining pool(s) to have a completely different block-filling strategy ("randomly select from the memory pool" would be easy to implement).

[phelix]

Yes, I definitely meant priority. Highest priority transactions (transferring lots of old coins) get included in blocks first under the default block-filling rules.

And also notice that I said "most miners are..." There are at least a few big mining pools that have their own idiosyncratic ways of deciding which transactions get into blocks, including private deals with big exchanges/merchants/etc.

Also note that because finding blocks is a random process the Bitcoin network "stalls" for an hour every three weeks or so, with no blocks found.

My guess is that if an attacker tried to monopolize block space most of us wouldn't even notice. If you're really worried about it, then encourage some big mining pool(s) to have a completely different block-filling strategy ("randomly select from the memory pool" would be easy to implement).

An hour is acceptable but not a day even if it is only 85%.

But again you have a good argument. After a couple of hours pools can react and change the block-filling strategy. They make less short-term but hopefully enough are wise enough to realize it will pay of long term.

Maybe an emergency block-filling strategy should be implemented and tested so that pools can switch quickly should there be need.

[phelix]

[...]
The old settings were default, with the 250,000 byte limit, 27k for high-priority (regardless of fee).  The new settings we're trying (subject to change, and not on all servers yet) is 500kB block max size, no reserved space for no-fee transactions with high priority, and a minimum size set to 50 kB to grab high priority/no-fee transactions if there aren't that many unconfirmed paid transactions.

so much for that...

[phelix]

With the block size limit currently in fact being 256kb... this is even cheaper.

A chunk of old coins and 50btc per hour. Somebody will give this a try for a day or a couple of days sooner or later.

Hopefully we will get a higher block size limit soon so it gets a little more expensive.

[phelix]

psst. tx fee assumption in op is off by a factor of 10. don't tell PP.

[phelix]

Looks like somebody finally gives it a try: https://bitcoinmagazine.com/21125/bitcoin-network-still-backlogged-tens-thousands-unconfirmed-transactions-causing-delays/