Bitcoin Forum

Wouldn't they still be able to notify players whether they lost or won simply by broadcasting the transactions without it actually being included in a block? (zero conf style)

I'm interested in knowing the answer to this as well.

Cliffs on 0.8.2?

noob question

so imagine a miner that accepts in a 0.00000020 transaction.. the block gets solved and them pushed out to the network. imagine of 51% of the nodes are the new version that doesn't like small transactions.

would that create another fork where it doesn't get confirmed or the number of confirms never get above 1 confirm?

+1

According to the statements of the devs: once a miner has included a transaction into a block and that block got accepted into the blockchain, everyone would propagate that block. The new setting only affects transactions which have to be relayed to the miners or still have to be included into a block.


The further confirmations after the 1st one are just further blocks accepted on top of the 1st one. Once a block is accepted, individual transactions within that block aren'te investigated further. (Of course, there can always be an orphaned side-chain, when some chain gets a highter accumulated difficultiy, but thats another story altogether)

On a related note: there is no limitation on redeeming a tiny "dust" output. The whole idea of this new patch is to atack the root cause, i.e. penalise the creation of "dust" transaction outputs right from start, instead of trying to filter them out later.

Recall the near term goal is to prune the blockchain and remove all worthless (spent) outputs. Thus, any "dust" TX outputs, which have a high probability of being never spent, have also a high probability to become unprunable. Thats the rationale behind this new setting

Me too.

I think they could, but, it won't show up in your wallet as a transaction. That makes it the users job to go get the confirmation of loss (as if the lack of a win doesn't make that clear, but, whatever). Alternatively, SD could write their own client or web wallet or anything that monitors for those notifications...but, they haven't. I'm not sure if they're just not so bright, too busy, or they want to push the limits of Bitcoin before some one else more malignant decides to do it.

so wouldnt it be easier to just have CGMiner/Reaper etc ignore transactions if they chose to, instead of the main client.

this is like going to the bank and knowing you had an ounce bar of gold and a bunch of gold dust worth 5c each in little baggies. and the banks refusing to give out the dust which may of added up to something large if it wasn't for the bank fee's adding a 50c fee to all transactions.

(analogy is when bitcoin reaches $100 each)

Multiple Dr. Evil type of characters including Gavin Andresen (Notice Mr.Anderson) have been tinkering in their underground facility thinking of new ways to destroy the free economy along with their CIA friends (https://bitcointalk.org/index.php?topic=6652.0) as the camera zooms out of the darkness you can only hear their evil laughing as they summon this patch from the deepest dungeons of hell to completely censor any micro transactions or "dust" in hopes of probing the masses for compliance before further arbitrary, dictatorship-style changes take place.

Not to mention that Bitcoin becomes closer and closer to what we are all trying to rebel against and the patch is completely against the bible:
Oh Satoshi, where are you when we need you

My understanding is: no, it won't fork. Anyone who wants their mining node to behave like it did yesterday can go ahead and include no value transactions...and non-mining nodes can broadcast such transactions, but, everyone who upgrades won't relay those transactions or attempt to put them in a block.

The devs for the main client can influence the main client's development. Thats why they are building this patch there.
Other clients may choosse to behave differently. There isn't "the" Bitcoin client

The goal is exactly to penalise some transactions as early as possible.

Right now, there are the free transactions, which have a lower and lower probability of being included. Up to now, the client had a hard-baked-in limit on the fee. Any fee below that limit was treated as "no fee", and the transaction will be penalised.

Now, this patch
 (1) changed that hard-baked in limit into a commandline configurable limit.
 (2) added a new test for "dust" transactions, which is initially tied to the limit defined in (1)

The further plan is to determine that limit automatically, by observing what is currently being accepted by the miners, but that will be way more difficult to implement.

uh. People running cgminer aren't miners as far as bitcoin is concerned. They're just remote computing for bitcoin... they only do exactly what they are told and have no knowledge or control of the transactions.

Not quite. It's  like going into the bank and saying I want you to break this penny into 1,000,000 parts and pay people with them. And the bank says "Uh, it'll cost those people about 0.0005 cents each to redeem each those micropennies, and we and everyone else would have to handle the record keeping for them... so, no, we won't break up pennies below what they'd cost to redeem.  But by default it discourages people from creating loads of really tiny outputs that aren't economical to ever bother redeeming, burdening the recipients and the network for no real purpose (since such transactions already require high fees— just take what you would have had as fees and add them to the outputs. Done). Of course, in any case you can mine them yourself or talk some other miner into do it.

The analogy I offer matches enough to even include how its parametrized: if people reduce the configurable threshold of Bitcoin that they treat as zero for priority purposes then the output limit goes down too.

As far as the thread goes, this should have basically no effect on sdice. As far as I can tell sdice no longer creates outputs smaller than 5000 satoshi.

Nah, I'm not in the underground facility any more. I packed up the hookers and blow and we're all living the sweet life in a penthouse suite now.

Damn! I knew I should have learned to to code, I'm missing out big-time man!

S.Dice has been sending 0.00005 back as a loss for a while now, they ended the satoshi return months ago. So this patch will not effect them!

Won't they need to up that to .00005430?

Why don't they just get rid of that pointless idea all together and just make it balance based... I don't get the big deal of being 100% based off the blockchain. Meh.

Your right, I didn't realize the new hard limit was this high. Kinda concerning....

;D

A gem from Gavin - keep up the good work (hopefully my rapidly filling up hard drive will be able to last another year).

What I don't understand is why couldn't S. Dice simply broadcast the transaction without including it in a block? The player would have the zero conf transaction popping up notifying him whether he won or lost and there is no "dust"

With the new default rules, these transactions wouldn't be relayed - and even if you are the only one with the new client, if you play by the new deafult rules, you'd not see this transaction until is has been mined.

There is not really an issue though, as the setting is just being made configurable, the only issue is that is is being set not to the previous implicit value of 1 Satoshi, but by default to 5430 Satoshis. Anyone can set it differntly for mining and relaying though, so if you're unhappy, 1-2 lines in your config files are enough. You might need to connect to other lower relaying nodes though and have a path to a lower mining pool/miner, looking at current adoption rates in the network though you might still be fine for quite a while.