Post
Topic
Board Bitcoin Discussion
Re: Analysis and list of top big blocks shills (XT #REKT ignorers)
by
AlexGR
on 16/01/2016, 16:08:54 UTC
Define spam.
Is Gambling spam?
Daily-payouts of cloudminers?
Every kind of blockchain-graffiti?
everything < 1$?
<5$

Who decides what spam is and what usecases to restrict? If you decide now that some kind of transaction are considered as spam and thus prohibited, you act like a regulator. Every node and miner can decide to prohibit spam - and should be allowed to chose his own definition of spam - but we don't need a central regime where a bunch of people decide which transactions are not worth to get in the chain.

Satoshi placed BTC in the "Small enough to include what you might call the top of the micropayment range" market segment.

If I had to take a guess, with paypal charging ~0.35$ for receiving money (plus % fees), I'd say that it's highly impractical for things that are close to 1$. Banks typically charge 0.30 euro to 0.35 euro for card transactions or epayments over here where I live. So BTC could probably be used for like 1$ transactions right now, but not a few cents. This could change in the future though.

Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments.

Forgot to add the good part about micropayments.  While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall.  If Bitcoin catches on on a big scale, it may already be the case by that time.  Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms.  Whatever size micropayments you need will eventually be practical.  I think in 5 or 10 years, the bandwidth and storage will seem trivial.

I am not claiming that the network is impervious to DoS attack.  I think most P2P networks can be DoS attacked in numerous ways.  (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee.  0.1.5 actually had an option to set that, but I took it out to reduce confusion.  Free transactions are nice and we can keep it that way if people don't abuse them.

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it's still small, it's nice to keep it small so new users can get going faster.  When I eventually implement client-only mode, that won't matter much anymore.

There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee.