Topic: Boycott 0.8.2 - page 2. (Read 18974 times)

If you want more security use 0.8.2 or higher.  The issue you linked to only affects older clients.  Yes it comes from diffrent handling on non-standard transaction in 0.8.2 (and 0.8.3) but the only one negatively affected is older clients.

Good point, thank you for the correction.

People tend to look at things a X is secure, Y is insecure.  The truth is more subtle than that.  There's always just a confidence interval.  Even with 1 confirm there's risk.

Developers will come from the angle of: "zeroconf is insecure, dont do it, and since its insecure anyway, more risk is acceptable" ie buyer beware

Merchants will come from "I understand there's risk with zeroconf, but I am willing to accept some level of risk"

The goal should be to try and increase security where possible.  Perhaps marker coins is one way to do this.

Thanks!  Forum inserted http ... im not sure why ...

If you read the paper, you can see they are talking about a change introduced in version 0.8.2, not 0.8.3.

Further, it is a zero-confirmation transaction attack, which is already known to be insecure.

No, however from passively paying attention to what clients are being used, it seems to always be a slow process unless its a fork issue or security issue. With all the fuss about this update i would imagine it to take longer then normal, but the list of users for the different clients show a steadily increasing adoption rate  towards 0.8.2 atm. Perhaps most users arnt paying attention to the forums and just update when they notice the change or when they get to it. With the new client coming out i imagine people will stop going to 0.8.2 and start going to 0.8.3 instead. hard to say much about the adoption rate and im not an expert lol.

As it stands the ratio is about 1:5(if nobody is running two clients) or 1:4 (if everyone is running both) But who can say whether some people are running both clients or not. I have both installed but am currently only running 0.8.2 on a daily basis.

The page ive been watching daily is http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html

Nice to see that number steadily increasing.


----

@melvster Ouch, dead link too. Though depending on what it is, Maybe you shouldnt be posting that?

Looks like 0.8.3 introduced a double spend attack

http://ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf

So I am guessing most upgraded their clients to the new version?

Regarding colored coins. In my own personal view i dont see them as "bitcoin" they are a system built upon bitcoin that seeks to use it for its own purposes that are not strictly aligned with the concept of *this amount of bitcoins is worth this*. As a result i dont think its the devs responsibility to cater to a system that uses bitcoin for its own purposes at the expense of bitcoin itself. Regardless, there is no reason why colored coins cant continue to exist and function with a higher value and a larger amount of bitcoins.


The people that understand the issue regarding dust, know why this change is needed. The people that are against it, I dont think they understand the issue and as a result are not in a good position to judge whether or not its a good choice even if they think they may understand it.

But let me try to clarify some stuff.

Divisibility as far as bitcoin is concerned means how many decimal places to the right you can go. This aspect of bitcoin has not been altered in any way. the definition of what makes a non standard transaction has been expanded, to cover what is referred to now as 'dust' outputs. Dust outputs, are not able to be spent as inputs for the recipient, without significant fees AND/OR wait time due to how the fee structure works, and has always worked(1), this is why we want to block 'dust outputs'. Fees have changed over time but have never been configurable client side. now with this update its lower then ever before and is configurable client side, with the value of dust being a percent of whatever you set the fee to. If by divisibility you mean 'its unfair i cant send half a penny, or 1/10th of a penny or 1/1000th of a penny.' Then you should be informed that you can if you connect to a node that mines them. But the recipient will still be saddled with large fees AND/OR large wait times, Regardless of whether this change happens or not.(1)

(1) this is partially negated by a pool ignoring certain rules for what is considered spam on the network, Which would allow anyone to simply flood blocks with garbage if they want unless they implement their own set of rules as to what they think doesnt belong in the blockchain.

The bottom line, bitcoin is a complex system that as we all knows requires a great deal of understanding to fully grasp. This change is needed.

0.83 is out, you may want to start boycotting 0.83 as well

exactly the reason. DUST

Change one line here:
main.cpp:55:
int64 CTransaction::nMinRelayTxFee = 10000;

Build binaries.  Make said binaries publicly available.  Accept the market's decision.  Anything else is just pointless bitching.  In open source software, disagreements are resolved through action, not words.

No.  The recent dust change did not target SatoshiDICE.  They increased their payout on losing bets immediately, demonstrating this.

The recent dust change addressed the people who were dumping megabytes worth of data, such as the full contents of wikileaks cables, into the blockchain.

I think you under estimate the power of defaults.  Nobody changes the default, and no one was ever going to change the default. 

This is a consequential change, because one of the key qualities of bitcoin is divisibility.   This change shatters divisibility.  Colored coin people also suffered, but they are a minority.

The gain was that all the spam from satoshi dice, which is considerable, was lessened.

It's all about pros and cons.

In my view this was satoshi's project, and now it's gavins.  Huge shoes to fill, but he's done a great job so far. 

We should however be vigilant over future changes, in a reasoned way, and I think that's exactly what the core dev team want to happen.

Your missing the point of 0.8.2 boycott, ofc 0.8.3 contains the changes made in 0.8.2, the same changes he wanted to boycott in first place ...

0.8.3 is available.
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.3/

So where is my 8.1. patch ? I'm all for boycott but plz provide me the tools to support your boycott .... 

Miners are simply a node that also happens to create and publish blocks.  In the earliest client all nodes were mining by default as the client itself had a built in miner module which ran in the background. Miners in the context is the entity designing the block.  So called "pool miners" are merely hashpower suppliers.  Miners learn about new transactions the same way any other node does, they receive a message from a peer node.

Oh thank you for your correction. Just a question, do miners pull transactions from nodes to put them in solved blocks? Or are miners essentially nodes themselves. Never really got around to understanding that.

Corrected your post it is 0.1mBTC.  If a node still relays it (either because it has set a lower min fee or it is running different code) and a miner includes it in a block the transaction and block will still be accepted by the network.

So true. Sadly, most people can't comprehend that. If bitcoin suddenly traded at $200, the dust threshold could be reduced by half, because the minimum fee drops by half. It's just about balances.

You have your minimum fee for accepting a transaction (1 mBTC default).
The dust threshold is just 54.3% of that. Basically anything under 0.5 mBTC won't be verified.