Topic: Huge increase in satoshidice spam over the past day - page 6. (Read 8855 times)

Flood defense against individual nodes doesn't really make sense and is just punishing that node for no reason.  The point is to protect against flood from particular addresses.  Also note that it doesnt really effect the hard-coded fee policy which addresses radically different aspects of a tx's "badness".  That said, I do agree that hardcoded fee policy is bad, but its really there to prevent other trivial DDoSing, as most standard txes should never hit that.

SatoshiDice isnt flooding the network because they have high volume, they are flooding the network because they refuse to use features like multisend which would keep their network load down, while still allowing them to have the same volume.

That is an interesting change to the trust model...But it is significantly easier to simply have a full node/SPV node distinction and have all full nodes do the checking.

So...SPV clients after the Bloom filter change...

>8 outgoing connections is not really an option.  Last I checked (which was a while ago) the ratio of open incoming connection slots on listening nodes to outgoing connection slots on all nodes wasnt great.  Even if it is, increasing the outgoing connection slots on every node has a huge effect on that ratio, and it would be very easy to blow through the listening slots available on the network.  Even hurting that ratio makes some attacks much easier.

That would apply to Electrum/Stratum architecture, but there is no such thing as a trusted node in etotheipi's proposal.

If it's just a "flood defense" then I'm fine with it, as long as it is configurable. Like, in my config file, I add that a node sending >10tps during >3s is flooding, so I stop downloading some or all of his tx.
Such a thing could finally allow the devs to drop the hardcoded transaction fee policy, which should never have existed IMHO.

Now, where I strongly disagree with you, is that SatoshiDice is flooding the network. It is not. Their transactions are legit. Something should be considered DoS if that's the sole goal of it. Like, someone creating as many transactions to self as he manages and broadcasting them all, only to flood the network. That's bad behavior.
SatoshiDice is not flooding and is legitimately paying for his transactions. Transactions paying something above a certain low limit in fees should never be considered DoS - and this limit should also be configurable.

+1

I don't get this talk of alternate chains or why it should be so damn difficult.

If there is a block with an invalid tx someone reports it over the peer network. The bandwidth usage, even if you have send the documenting block, would be negligible as it would happen so rarely.

To get your own balance you query your peers as with torrents and if there's an update they send that block to you.

To work you would need more than 8 peers/a smarter protocol, but that's hardly rocket science.


That is like 2-3 updates, what reason NOT to do it?

The point isnt that we cant handle the volume.  We clearly can.  I dont see Bitcoin dying right now.  The issue is that its much better to have the network /slowly/ transition into SPV nodes so that we can closely monitor and make sure there are enough listening full nodes.  Additionally, events like this are important as it lets us reexamine the existing incentive structure and address issues like what is, to most end-user essentially a DoS attack.  The issue isnt that we have a place to point a finger at, its that one user is abusing the network.  Im suggesting a way to discourage people from abusing the network in such obvious ways, hopefully encouraging people to use more sane send-methods.

Actually, its not targeted at a specific service.  Its targeted at all services that have high volume and can reasonably wait for confirmations.  I never said it would be hard for people to work around the deprioritization, quite the opposite.  But it would force people to think about what they are doing.

Thats what Im suggesting - a way to attempt to accommodate the rapid increase - make people who insist on DoSing the network in an obvious way wait longer for confirmations.

From trusted nodes.

A quick question.

Does downloading of few kilobytes imply a connection to full nodes for that or the same lightweight nodes might also happen to have this info?

If network is mostly populated by nodes who are asking for those small downloads and most of the nodes don't have the data then where is it going to come from?

This should be a non-issue in the long term:  If the network can't handle 50k tx per day, Bitcoin was never meant to succeed.  The only reason it's such a big issue right now is because it's a single entity producing the volume -- and thus there's somewhere to point the finger when it was really our lack of preparation to handle it.  It could've just as easily been a piece of some other market that latched onto BTC and produced 50k tx per day in a less-centralized manner.  

It's a downside of having a completely open, decentralized, apolitical, global currency scheme -- people must have the ability to use it as they please, and the rest of the system must find equilibrium.  Talk of deprioritizing certain behavior, especially targeted at a specific service is completely counter-productive and inappropriate:  people who want to repeat the discouraged behavior will find a way around it, and other people who are otherwise legitimate may suffer by being inappropriately affected by the change.

In my mind, the only reason this is an issue is because the community was not prepared to handle the rapid increase in size -- and it will work itself out once users/dev figures out the way to accommodate it.  There just may be some turbulence in the short-term.  

Why not? the point is its to the benifit of the people running bitcoind, so its in their best interest to do such rate-limiting.  In the end, its really less of a deprioritization and more of a "stop-DDoSing me, Im gonna rate limit your transactions"-feature.  The goal is to tweak incentives so that the end-users and those running forwarding nodes can have a say in the incentive structure, as is ultimately fair, as they are putting in way more effort than miners in terms of verifying transactions.

Its a bit of both, and really depends on the disk.  On an SSD/tmpfs its more CPU, on a spinning disk, its more disk.  Note that multisend helps with the database lookups a /TON/.

https://github.com/bitcoin/bitcoin/pull/1233 Depends on where in the chain you are, but it does help some.

Well, it's the official client for one.
For two, the more people that stop using a "full" client, the fewer full client nodes we have, and the less secure the network is.

Exactly! I am glad someone else gets it.

Right now the BTC network is very small, but the VISION that we have all invested in is HUGE -> "BTC replaces dollar/VISA/Mastercard".

To get there you can't have the network breaking down over something like satoshidice NOR miners starting to ask ridiculous fees.


If you just want BTC to be another small time linden dollar with no future wtf are we all doing here?


Yes a bunch of super computers COULD run the BTC network at VISA size with normal users being light clients, BUT that would leave us wide open to attacks, being shut down or miner-dictatorship = VISA.

Pruning needs to get done or yes bitcoin might not die per say; it will just become pointless.

The tiny fees they pay are very, very, very far from paying for the damage they are doing to people's disks/cpus/bandwidth.  Miners (currently) have plenty of finance with 50BTC/block, but even if we switched to 0BTC/block tomorrow, the amount that satoshidice is paying compared to the load that they put on mining bitcoinds is very close to not worth it to the point its almost easier to just drop them and not have to worry about spending too much time generating blocks.

Being generous to miners does not help end-users.  My point here is the incentive structure is really a deal between transactions senders and miners, without thinking about end-users.  Hence why end-user nodes could deprioritize forwarding high-volume address transactions to tweak the incentive structure.  

Agreed, but sadly, in the end, its hugely to the detriment of Bitcoin as a whole.  Hence why Im suggesting we adjust the incentives to discourage bad players like SatoshiDice.  That said, using multisend would not require any user-facing changes while lowering the load on bitcoin clients significantly.  

It means they are interested in supporting Bitcoin's growth.  In fact, because of SatoshiDice's volume, free transactions are being force out of blocks, when it is important for users to be able to use Bitcoin.  The idea is to deprioritize high-volume address transactions so that regular users can get their transactions into blocks in reasonable time, while sites that dont need fast confirmations (like satoshidice) can have their transactions fairly delayed.

Please, really please don't make that a rule embedded in bitcoind.


Really? CPU time checking signatures is slower than the database indexation? I always thought it was the other way around. At least my laptop seems to access the disk like crazy when it's getting up to date... I'll check CPU usage.

By the way, I heard you were working on a patch to make the chain update more asynchronous, and thus faster, and that you were obtaining good results. Is that so?

Miners/pool operators may prioritize whatever they want.

It is a horrible idea if done by the developers of bitcoind. I'm not comfortable even with the hardcoded fee policy left by Satoshi.

What might be acceptable at "bitcoind level" are configurations. Like, a file where you specify fee policy parameters, if you're a solo-miner/pool operator.


"Normal" users should not be using bitcon-qt.

Everyone deprioritizes every address that is heavily used, thats the point.  
If you think about the use of single address for high tx volume, pretty much all of it can be safely delayed getting into a block.
1. Green Addresses.  A. people shouldnt be using green addresses to begin with. B. the whole point is you trust the person sending, so being late getting into a block is no problem.
2. Poorly-designed sites that use single addresses to receive transactions from everyone (eg SatoshiDice).  uhh...thats the point of this thread.
3. Donation sites.  If you are getting a large volume of donations, I dont think you are worried about being able to spend each new donation now vs in 24 hours.

What? Thats 6kb/s.  Even if your node is only up for one hour/week, you only need 1134 kb/s to download the chain.  I think thats perfectly reasonable.  

Chain download isnt limited by bandwidth, not by a long shot (unless you start downloading from a very slow peer, which is possible, but something that should be worked around soonish).  Chain download is limited by disk speed, but mostly CPU speed at checking signatures.  Hence my statements that sites like Deepbit and SatoshiDice need to implement things like multisend which allow for faster checking of transactions as txindex.dat is able to have fewer keys.

Thats the point of this thread...

You're being too harsh on SatoshiDice.
AFAIK, they're paying fees for every transaction they send. In the end, they're contributing to the network security by financing miners. The fact that non-miners are having problems to follow the chain progress is less relevant IMHO, as that will necessarily be the situation in the future if bitcoin "succeeds".

I'd argue they're doing more good than damage with all these paying transactions. They're actually being generous, because if they were to use send-many and reduce their number of transactions, they'd be paying less fees to miners. (and about having a balance, I think they've been so successful precisely because they don't require you to have an account).

And if miners/pools are still accepting free transactions, it just means they don't give a damn to the overhead. (at least not yet).

Deprioritizing sounds like a horrible idea. Who gets to decide who to limit?

Maybe 25 GiB/year isn't too much storage-wise, but it is way too much bandwidth-wise.

"Hey have you heard about Bitcoin?" "Yeah, last month" "Why aren't you using it? I find great deals every day on BitMit" "Blockchain's still downloading"

  right...

The size of the blockchain will soon be a huge hindrance to widespread adoption

The all nodes are equal premise was broken more than a year ago when GPU miners started to become popular.  Anyway, the point of this thread is you dont have to break the ability of people to use full clients because one service refuses to work in a reasonable way.  Strongly encouraging miners to deprioritize high-volume addresses and making the satoshi client refuse to forward the full volume of such transactions puts a cap on basic stupidity.  Yes, they can simply switch to using dynamic addresses, but it does force them to spend a bit of extra time coding, and the hope would be that they might add something like multisend and hopefully allow users to carry a balance like virtually all other bitcoin sites.

Its obviously coming, but there are issues with a drastic network-style shift overnight, such changes should happen slowly to give people a chance to watch the shift very closely and make changes where required.
No one wants to hardfork for an issue like this, its simply not worth it.  Hardforking is a huge ordeal.

In any case, this topic has gone far off topic.  The goal was to discuss deprioritizing satoshidice and other similar transactions.

The first part of this message is not a constructive critic:

Many people (like me) anticipated it: It need just one disruptive use of Bitcoin (like satoshidice) to break the "all nodes are equal premise".

Now the constructive part: four possible solutions exists:

1- SPV nodes / full nodes distinction and related ideas.
2- Balance sheets (breaks compatibility)
3- Add a new transaction format of much sorter length (e.g.: no scripts, use of firstbits) (breaks compatibility)
4- Add a new (less CPU-demanding) signature standard (e.g. MAVEPAY or Merkle-Wintenitz) (breaks compatibility)

Check out the info at https://en.bitcoin.it/wiki/Hardfork_Wishlist (this page is not well cross-linked).

Best regards!