I did above, it's also covered on the pull request above—  it means that absent some agreement a miner you'll have to use quanta for your colored coins large enough to pass the rule.  This works out sensibly in any case, because it means that even if your colored coins lose their colored value there will still be some economic incentive for people to sweep up the set of unspent transaction outputs.

Not just coinlab: "F.2. CoinLab shall not, directly or indirectly (including through legal entities ultimately owned by the same person or persons as CoinLab) provide services similar to the Services on any website". When I read the 'owned by the same persons' bit, my eyes kinda bugged out.  Unless I'm confused about the involved parties, I believe that coinlab may be in default. God knows how this contract would be read though. I imagine that a lot more context will be needed to actually ascertain the minds of the involved parties here.

Just so.  If there are no limitations at all a griefer (or other malicious force, like an antiquated payment system that feels threatened by Bitcoin) could just flood bitcoin with inconsequential "non-transactions" producing hundreds of gigabytes of bloat and making bitcoin unusuable and non-decenteralized (because if Bitcoin required 200GB of storage right now in its infancy, who would run it??).  So there must be something to rate limit attacks.

Fees have generally served this purpose— but they are a blind mechinsm that doesn't really distinguish abusive use from good use, they just hope abusers use the network a lot more. But as there is more legitimate economic use and value people want the base fees to go down and not up.  Fortunately, some of the more obnoxious abuse these days looks categorically different from ordinary transactions: They create tons of 1e-8 value outputs (not 0 value, because the node software already blocks zero value outputs) which encode data.  By having a minimum output value it increases the cost of that bloat by a factor of over 5000 without impeding pretty much any normal transactions.  It also reduces the incidence of people getting irritated because they've received payments which cost them more in fees to spend then they're worth.

0.01 was actually the minimum available in software at the start.

And Satoshi also added mandatory fees for transactions producing outputs under 0.01.

They do.

There is. It's just set off the configuration option that sets the amount of fee treated as zero. As I've been saying over and over and over again.

No, it's a freeking commandline setting.

You sure like that word. I thought I did too ... too bad you're well on your way to destroying its meaning.

What the heck are you talking about? How was anyone censored? Or are you just happily making up stuff?

And you're still free to do that, just add the 5000x more (1/10th what you otherwise needed as fee) to the actual output value. Not only does it cost less marginally than litecoin's multiply the fee by the number of dust outputs, but the recipient isn't saddled with a bunch of inputs that cost them more to spend then they yield in coin.

No it doesn't— just use larger (but still 'subcent') colored coins... at least then when someone loses interest in some color (or the color becomes worthless) there is some economic incentive to go remove them from perpetual fast storage by sweeping them up.

Uh. Bitcoin has _always_ had restrictions, without any restrictions it wouldn't be worthwhile— it would be over the first time some anti-social jackass types   "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.0000001 ; done".  No one should be forced to carry around megabytes of random people's non-finanicial data storage just because they want to be a Bitcoin node, no one should receive payments that cost more to redeem than they are worth,  Bitcoin wouldn't be practically decentralized today if some evil visa-operative could run my above shell script and have made the blockchain 200gbytes in size, etc.  The opposite of control isn't no control.

Don't even need to— it's set based on the fee value that gets treated as zero for priority purposes. So presumably miners will lower that amount (no recompile is required) if the value of Bitcoin increases, so even absent new versions with revised defaults we're not stuck with it entirely.

The earlier versions of the software in the days of Satoshi only used two digits, in fact.

Uh. You realize your "should" are describing the change here, right?

Huh? this has little to nothing to do with SD. AFAIR they no longer create _very_ small outputs at the level implicated here.

Yes, assuming you mean "with a single input of value 3.000005"* that is the current (since 0.3.19?) behavior.

*(if instead your wallet had, say two inputs of respective values 3 and .000005 it would just use the first exactly)

You're misunderstanding. This doesn't inhibit the _spending_ of small outputs, it inhibits the creating of them.

The wallet software already avoided creating them because they'd trigger fees higher than the amount being received as change.

You can still do it, but instead of having to pay 50,000 times the amount in fees— you have to find a miner willing to do it or mine the block yourself (with p2pool if you want to pool).... this is no worse than all the other kinds non-standard transactions that I listed, which you happily ignored. Instead of paying an enormous amount in fees, you can instead just add that to the amount you are paying. It's silly to force you to give funds away from miners as a proxy for trying to get you to not create outputs that aren't worth spending.

As I mentioned, there are tons of transactions you already cannot easily make. For example, you currently can't easily send 1e-8 to someone without including a fee which is 50,000 times larger than the amount you are sending. You cannot easily make a payment which requires 2 keys out of 20 to redeem.  You cannot easily make a payment that adds 5 kilobytes of extra "message" data in a transaction. You cannot easily send a txout with value 0 zero to someone... etc. All of these things are non-standard transactions.  The protocol rules permit them, so miners can add them— but you have to find a miner willing to modify their software to do it.  Whats new here is an additional kind "you can't easily use a transaction which creates txouts which are small relative to the amount miners treat as zero", which can be freely overridden by miners changing that amount.

Thats not correct. This isn't a protocol rule. As miners shift down the fee value they consider to be 0 for priority purposes it shifts this threshold down too.

The word censorship loses meaning if you erroneously apply it to everything you don't like.

People can create txoutputs which cost more in fees to spend than they provide in bitcoins. This results in an increase in the perpetual unprunable data and the working set size of full nodes, and people use these outputs to also force all bitcoin users to carry around non-bitcoin data.  Making the default behavior to not mine the creation of new outputs that can't be economically spent directly addresses the issue of outputs which are uneconomical to spend.

People are demanding that the fees be _decreased_ while the non-bitcoin junk data storage is _increasing_ under the current fees.  This is the same general mechanism and it's also adjustable.

What the change does is makes it so that you can't pay a single 0.0001 fee and create a ton of 0.00000001 outputs.  The base fee was 0.0005btc/KB in 0.8.1 and 0.8.2 _lowers_ the base fee to 0.0001BTC/kb but refuses to mine transactions which create outputs which are so small that they'd be uneconomical to spend considering the miner's configured minimum-fee-to-not-treat-as-zero.


Uh. You are so thoroughly confused I don't know where to start.

(1) The change doesn't block anything.  Your "CENSORSHIP" here is crying wolf. It changes the default mining behavior to not include some transactions which are very likely to be abusive non-financial transactions, but it's just a default and its adjustable. It doesn't make them not able to be included. You've been told this multiple times. You've acknowledged that you understand that it's a configurable default, so are you intentionally telling lies now?

(2) There are VERY many transaction kinds which are inhibited in exactly the same way— in fact, unlike this most of them can't be permitted without modifying the source code. (Search for 'bitcoin standard transactions')

It's not a protocol rule and miners are free to include transactions with outputs smaller. The change causes miners not include transactions with outputs which are a small fraction of the fee amount they have configured to treat as zero for the purpose of priority. They can change the setting and the network doesn't mind. It's a default, not a rule.

This is expected to reduce the problem of people creating data storage transactions which are uneconomical (or impossible) to redeem, but shouldn't effect actual financial transactions (even if the value of Bitcoin goes through the roof— as people will adjust the fee-treated-as-zero as that happens, and the defaults will be updated as time goes on, the network isn't require to be consistent as— again— it's not a protocol rule).

IIRC, Satoshi himself put in the first rule against very small transactions— making the node behavior to only mine or relay if a fee of 0.01 or greater was provided for transactions without any outputs smaller than 0.01 in order to stop dust flooding attacks. Because fees of 0.01 became rather large they were subsequently lowered to 0.0005 and now 0.0001 but a single fee is being abused to cram many megabytes of child porn website directories and other such junk in unspendable txoutputs. Requiring larger outputs is hopefully less intrusive than requiring the same value as a larger fee.

The same thing was on sourceforge a few weeks ago as "bitcoin-qt" (note the dash) and we got sourceforge to remove it.  Thanks.

How did you find this?

Then you just adjust the threshold down. The behavior isn't a protocol rule, miners can still include transactions with smaller outputs. The whole idea is just to prevent floods of transaction outputs which are uneconomical to redeem (e.g. costs more to redeem than the value of the txout returned), and to increase the cost of abusing the blockchain for data storage in that way.

No, litecoin is forked from a very old copy of bitcoin with some of the security fixes backported (depending on which litecoin repository you pull from).

I'd heard that there were some plants to rebase litecoin on more modern Bitcoin but I have no clue where that stands.

The common (only?) GBT pool server software checks to make sure the work matches the assigned user, and doesn't credit the wrong user. Stratum has a user ID as part of the coinbase, IIRC it's not in the share results, so the work must be submitted as the correct user.

For fees, yes, but only to the extent that there is not a backlog of available fees beyond what you can put into a block and that the fee difference is less than the lost subsidy (right now fees are something like 0.07% of mining income, so it's a non-issue).

If there are not enough transactions to fill the block there are other issues— e.g. the greedy-rational mining behavior can easily be to constantly try to orphan the current non-self best block until enough txn show up that you can't fit more and increase your income.  Retep (Peter Todd) proposes that people should be producing all their transactions nlocktimed based on how early an honest network would conceivable mine them, thus creating a constant base of transactions which _cannot_ be mined at the current height and producing an incentive to move forward. E.g. at a minimum you lock to be only mine-able at the current height, but if you don't need fast processing or you see that there is already a long backlog ahead of you you might lock at one or two blocks further in the future.

Mining is absolutely categorically emphatically undoubtedly NOT a "first past the post race". There is no upper bound on the number of blocks solved per unit time. When a new block is found on the network you simply switch to extending the new chain.  Someone else finding a block does not diminish your chances of finding a block, no work of yours is "lost" when the chain moves to the next state because none is accumulated... and the hashcash process is not a search of a finite space (there may be many solutions or no solutions for a particular header, indeed there is only one valid nonce in ten million headers these days).

The reason people pool is simply because receiving Bitcoins in quanta of tens of times your expected return per day is high variance.  I happily solo mine and have had days where my farm produces >>40x the expected return, and days when it gets nothing. On the average I'm a couple percent higher than the expected value. _It is not a race_, if it were I'd either never have a block at all or would only have a tiny fraction of what the expectation.

There is some overall work on the network lost due to chain fraying— but because all nodes experience latency there isn't a relative disadvantage created by this. As you note this creates some small advantage for an attacker— but it's only a very small amount so long as the time between blocks is large relative to network diameter (latency). If the time between blocks becomes small relative to diameter then the network will start having convergence failures and large reorgs (even absent an attacker). Controlling the time between blocks is also important for minimizing bandwidth and computation, especially for SPV nodes.  Amiller had made a nice suggestion regarding merging orphans for the purpose of making the block time dynamically adapt to the diameter, though that doesn't itself address keeping the network usable by SPV nodes.

FWIW, "P2pool" does solve the variance nicely— including allowing miners variable difficulty work (though confined to not result in shares faster than six per minute, to control the cost and prevent convergence problems)— without burdening the perpetually stored Bitcoin network with frequent tiny blocks.