It's not really "working against the rest of the network". If they're really honest miners, they'll just replace the double-spend they're being payed to avoid. They can pretty well replicate all other honest transactions. At most there'll be a "blip" in the confirmation count of others.

Well, in my country, robbers blow ATMs up with dynamite, get as much untainted cash as they manage to, and run away, all that in less than 2 min. AFAIK most of the time they're not caught.

So, yeah, you'd better protect yourself against double-spending!

Hello,

Can someone please point me to the full criteria set used by Satoshi client to calculate whether a transaction should have a "mandatory" fee?
Initially I thought it was only transaction size in bytes and the amounts in outputs ("dust"), as said here: https://en.bitcoin.it/wiki/Transaction_fees#Minimum_transaction_fees

But apparently that's not all. A friend of mine was testing some bitcoins transfers. He received 1 BTC. He tried to send that 1 BTC to another address. It went, no fees required. Then he tried to send it again to another address. The client required him a fee. He canceled, and some days after tried again, and then it passed without requiring fees.
So, well, data size and output amounts are not the only criteria... what are the others?

Thanks!

Banning IP and calling the cops is useless.
Of course, for a 0,01BTC tx the damage would be so trivial that the risk is also trivial, you can pretty much take it.

There are some use cases where 0-conf would be interesting and the damage caused by a double-spend would not be that trivial though. Take cash ATMs for instance. It would be annoying to wait for confirmation, but the ATM cannot risk a double-spend when giving cash away. Or imagine an ATM like this one: https://en.wikipedia.org/wiki/Gold_to_Go

OP, in what is that better than Green Addresses?
In both models there's trust in a third party, and Green Addresses are probably cheaper (so far they're free, aren't them?)


P2Pool AFAIK requires the miner to have a full client. That's not scalable.
I don't know about this memorypool you talk about though.

Good point.


And good analogy as well.


I'm pretty sure Matt Corallo's brain works very well, though.
The debate here is more fundamental. Some people are all angry with SatoshiDice because they've finally increased Bitcoin's transaction volume, making it harder for people that do not have to store and validate  the blockchain to keep storing and validating the blockchain. They believe it would be nice if such unnecessary and unscalable behavior could go on for longer, and want to punish those that are making this difficult.

I don't agree with it, as my messages in this topic make it clear. But my greatest worry here is that such kind of "punishment" should never be part of the protocol. Pool operators and solo-miners are the only ones who should be taking arbitrary decisions concerning which transactions get included or not. End-users should have no say. And, mostly important, the protocol should be neutral. As the "reference implementation", bitciond should remain neutral too.

If Matt wants this so badly, then, well, I guess he's skilled enough to make a patch and provide it to those who agree with them. I just sincerely hope such patch doesn't get included in the main branch of bitcoind. (and I'd find it a pity that he stops to work on this much more important branch he's working on, about making the blockchain update process more efficient, to work on a thing like this.. but well, that's his choice)

+1 to that also.

I feel there's something wrong with the block download process. It seems it does everything too synchronously, but I don't know. That's why I liked to hear that you, Matt Corallo, was working on a patch trying to improve that. This is the way to go. Make the system more efficient, without trying to censor users which are donating more to the network than the average user is.

+1. Well said.
Pruning, storing the chain in raw format without verifying it, and SPVs, these are the ways to go IMHO. Not trying to "punish" a particular way of doing transactions, specially when the sender of these transactions is paying more than the average bitcoin user pays for them.

 

What about, instead of releasing a client with built-in transaction fee policy, you release a client where the fee policy can be easily configured in a text file? You make the "default" text file provided with the executable have the same configuration the current embed fee policy has, in order not to change things abruptly.

I find it better this way.

They have "no incentive" because they're earning money with SatoshiDice. No harm is being done to the network. Only those that want to store and validate the chain "for nothing" are having to wait a little more to get up to date.


That's relative. For example, I honestly think that what SatoshiDice is doing is rather positive to the network security, as they're paying fees for their transactions.


What does please me is that they (being a loose term not just for SatoshiDice) choose to implement very simple technologies that hugely increase their donations to Bitcoin as a whole.

See how this is relative?


Illegitimate implies "cheating". They are not cheating. They are perfectly playing by the rules.


You sound like those who are fearful of ASICs.
Define "drastic change", or "switch over quickly"...
I'm still running my full node on my primitive laptop. And I'll probably remain for a while. I am not sure this migration is going that fast. Bitcoin evolution as a whole is even faster.


But they are being payed for it. If what they're earning as fees is not enough, maybe the devs of p2ppool should change the fee policy of the protocol to require an amount in fees that pays off the inclusion of a transaction by the average p2ppool miner.

Or perhaps there should be centralized pools operating as nodes in p2ppool, allowing miners not to have the full chain. The advantage of such is that, by operating in p2ppool, the pool operator clearly shows that he's willing to follow p2ppool rules, and thus cannot "go rogue".

See? These are your personal preferences.

I agree with item 2, but I don't want to see a "network rule" of some kind forcing people to do so.
The protocol should be agnostic.

Didn't understand this.


It doesn't make sense punishing someone for using the same address multiple times. If you're a solo miner or pool operator and want to apply this rule to your blocks, be my guest. But as a network policy, it doesn't make sense. You're just picking on a particular way of spending bitcoins that you consider "braindead" and trying to punish people who don't do as you like.
bitcoind should not contain personal preferences like that.


I don't see a problem in forcing fees per se, I just don't like that it's implemented in bitcoind. A particular fee policy should not be a "implementation reference". At most, it should be configurable.


Please, of course is legit. They're not attacking the network, nor trying to cheat, double-spend, >50% or anything. They're just spending money in a way that's bothering you and making it harder for non-miners to do what they don't need to do (have a full node running).


They are paying for it. I repeat: end-users do not need to run full nodes. Only solo-miners and pool operators need. They are the only ones who should care about SatoshiDice load of transactions, and apply their arbitrary rules if they feel like.

If an user which is not solo-mining nor operating a pool is using a full node, that's his choice. His choosing to dedicate his resources to the network, charitably. He'll handle the load in exchange of no monetary incentive. He should know all that.

Wanting to embed such an arbitrary rule in the reference implementation is really not appropriate. The Bitcoin protocol per se should be totally agnostic of whether people use multiple addresses or the same address every time.

Err... for the reason of punishing flooders? If you're relaying the DoS you're a flooder yourself too.


But then the flooder just generates more addresses. What's the point?


But it is avoiding these "trivial DDoS" I'm talking about. But doing so via download limits and all, not via fee policy.


Regardless, they're making a legit use of the technology, not a DoS attack. Specially if they're paying for it.

There's nothing "official" in Bitcoin, and the fact that you think there is shows an understanding issue.
Saying that bitcoin-qt is the "official Bitcoin client" is like saying Microsoft Outlook is the "official POP3 client" or that Firefox is the "official HTTP client".

Granted, it is the "reference implementation", the only one so far which fully implements the protocol, and as consequence, the one which actually defines it. That's different from being "official" though.


Network security is much more related to the amount of computing power behind mining than the amount of full nodes in the network.
It's unlikely that someone manages to DDoS or hack all full nodes at the same time, even if only solo-miners and pool operators were running full nodes.

And, please, understand: if bitcoin succeeds, it is just a matter of time until this happens (few full nodes). If that really makes Bitcoin less secure as you say, then you may say Bitcoin is not secure by design.

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.

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.

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).

I'm not even sure developers themselves should worry with this. This is a problem to pool operators mainly. It's up to them to come out with a solution, or eventually finance one by offering bounties.
I find "securing your private key(s)" a much more urgent matter than this.

What a drama, come on...

This will not kill bitcoin. Even without pruning, professional pool operators should be able to handle much more traffic than this. https://en.bitcoin.it/wiki/Scalability

It seems you people are thinking "ordinary users" should be full nodes. That's not the case. Only solo-miners and pool operators have such need.

But anyway, since that's what being debated here, I always wondered if there couldn't be a "relay mode". Something lighter than the full mode of bitcoin-qt, but heavier than the lightweight mode of BitcoinJ.
You store the whole blockchain, but in its raw format. You only validate its headers, not its transactions. You index only the transactions that concern you, plus a simple index to locate the blocks in the big raw file. You relay everything as a full node would.
The greatest charge that a full node imposes today is the indexation of the database. Storing in raw format would allow those that want to contribute their nodes as relays (as me and probably you) to keep doing it for a longer time, I guess.
But, honestly, I'm not even sure we should encourage this. For it to scale, the bitcoin network will have to change to a network where only some full nodes exists and all the others connect to them as lightweight nodes. So maybe SatoshiDice is just encouraging us to take this step.