...
All transactions should be going to new addresses! If anything, we should penalize address reuse.
...
Nonsense. Address reuse is perfectly valid. When I spend from a paper wallet I send the change back to the same place. I sign the transaction on an offline computer using electrum, then publish it on another. I would have to constantly be printing out change wallets if I did not send the change back. How exactly is address reuse an issue to anyone? It compromises the network's privacy (not just your own!). Basic privacy is pretty important when it comes to finances. Additionally, when we upgrade to post-quantum cryptography, reusing an address will likely allow people to compromise your wallet - possibly even other addresses in it (though I'm not so sure on this last bit). Bitcoin is a set of rules and as long as your follow the rules, no one should be allowed to pass judgement on how others use it. Unless the rules are changed to combat perceived problems, such as the micro-transactions that SD brings up, everyone is complaining about the problem and not offering up any solutions and thus will never solve the perceived problem. There is no such thing as a technical solution to a social problem.  Flooding is a social problem, and that is why Bitcoin uses a social solution (miners who are supposed to filter it). Nobody is "passing judgement" on SD (or maybe someone is, but it's unrelated to this) for being gambling or anything like that. Enabling flooding is simply not possible. |
|
|
|
fee must be smaller than the transacted amount, and be at least of 0.1%? You can't know how much was transacted unless you're the sender. additionally, add a certain penalty amount, if you send it to a new address… All transactions should be going to new addresses! If anything, we should penalize address reuse. also, the fee should weight in how old are the past tx out and the general size of the TX. Already does. |
|
|
|
Are we really going to go down the road of deciding who can and cannot use bitcoin?
Any solution should be agnostic of specific vendors. The problem is not SD, how the hell is bitcoin going to scale to meet massive use if we can't handle a single company?
A vendor-specific solution is better than no solution at all. It buys us time to figure out a better solution. And worst case scenario, this problem is short-term anyway - the risk goes away when bitcoin adoption is sufficient to handle it. |
|
|
|
People on IRC also claim that SD gambles against themselves to build their Most Popular Bitcoin Gambling Website brand, which would also bloat the blockchain, but there is no way of proving or disproving that rumor. Well, if you ask around, there is surprisingly few people who actually play SD... |
|
|
|
My miners are just doing their job filtering out spam, like they're supposed to as part of the Bitcoin system.
My understanding is that SD no longer creates 1 satoshi transactions. The minimum it now sends is 5000 satoshis, which should help with the unspendable bit dust problem. Does that change your position on SD transactions? Not at all. Those are still dust spam, and even if they never sent anything on losses, their "bet" and "win" transactions are still spam. |
|
|
|
If it gets big enough, it could cause a soft-fork. But that's a much different/smaller problem than a hardfork, and unlikely to occur (since miners would presumably get their act together before it got to this point). If half the network decides that blocks containing SD transactions are valid, and the other half decide they are invalid it would indeed be a hard fork. Notice I never suggested to consider them invalid. Just not relay them. There's no guarantee that it would go your way either. The majority of the network might just continue processing those transactions and ignore your blocks until you get your act together. You mean Bitcoin's way. My miners are just doing their job filtering out spam, like they're supposed to as part of the Bitcoin system. And if you start trying to force miners to accept transactions, you're breaking Bitcoin. In this particular case, you'd in effect be creating a SD tax on miners. |
|
|
|
If miners refuse to do their job in filtering, there's no reason to leave it up to miners.
Regular participating nodes can refuse to relay blocks with (eg) more than 50% Dice spam. Let me get this straight: a blockchain fork caused by the fixing of an unknown bug should be fixed ASAP. On the other hand the blockchain should be deliberately forked because not all miners agree with you? This topic has nothing to do with blockchain forking, period. One faction in the network refusing to relay valid blocks has no potential to cause a fork? If it gets big enough, it could cause a soft-fork. But that's a much different/smaller problem than a hardfork, and unlikely to occur (since miners would presumably get their act together before it got to this point). Edit: The real problem with this idea, is how to coordinate undoing it when/if SD cleans up their service so that it stops flooding. |
|
|
|
If miners refuse to do their job in filtering, there's no reason to leave it up to miners.
Regular participating nodes can refuse to relay blocks with (eg) more than 50% Dice spam. Let me get this straight: a blockchain fork caused by the fixing of an unknown bug should be fixed ASAP. On the other hand the blockchain should be deliberately forked because not all miners agree with you? This topic has nothing to do with blockchain forking, period. So wait, the Psy theory is the following:
Major bug in network. Don't actually fix it, simply expect the company taking advantage of it to stop taking advantage of it out of the kindness of their hearts. Then, proceed to exercise monumental amounts of naivety by assuming that no other website will come along and start to do the same exact thing. When they do, instead of fixing the bug, simply come on bitcointalk.org and whine and whine about it instead of fixing the bug. The (by then 100+) websites doing the exact same thing should simply stop doing it out of the kindness of their hearts. Rinse repeat. Never actually solve problem, just expect that it will solve itself if I whine about it enough. Don't fix flaws, just expect people not to aBTCuse them.
Psy, ...wtf? I can't even begin to wrap my mind around that.
That's like the Canadian people expecting the operators of the Exxon-Valdez vessel to pay for the environmental damage of the spill out of the kindness of their hearts, after passing a law specifically limiting the company's financial liability in case of a spill. It's nice, if you're in kindergarten, to expect the world to be all fluffy and happy and companies will simply not profit from loopholes and exemptions and little flaws that allow them to make more money.
This is not kindergarten. Expect that any flaw will be fully taken advantage of and abused, and must be taken care of like the SRS BSNS that it is. The flaw is that miners aren't doing their job filtering spam. That's how the Bitcoin protocol deals with it. |
|
|
|
If anything, we should be banning miners who refuse to do reasonable filtering like this.
Banning is such a strong word, though. If a majority of miners would in fact refuse such transactions other smaller miners would start getting a lot of orphans and would be forced to either reduce their blocksize drastically or starts filtering out what goes in to their mined blocks. But that's only if the majority of miners sees that as a good thing for the network and their bottom line, no? If miners refuse to do their job in filtering, there's no reason to leave it up to miners. Regular participating nodes can refuse to relay blocks with (eg) more than 50% Dice spam. |
|
|
|
|
If anything, we should be banning miners who refuse to do reasonable filtering like this.
|
|
|
|
is this speed ok or are there only 2 mining: Status MHS5s MinerCount AsicCount
Alive 45621.57 24 10
This may be Avalon's broken GBT. If so, you have two options: - Use stratum
 - Try out the BFGMiner firmware
|
|
|
|
At this moment our pool created a wrong branch of the blockchain, but not because of being 0.8+.
I'm working on the fix now.
Tycho, this should be really easy to fix. Ping me on IRC if you need any help. |
|
|
|
FWIW, Eligius was the only pool that survived yesterday's hardfork incident not-by-coincidence  Since it work from both 0.6.0 and 0.8.0, it actually detected the problem. |
|
|
|
The only question is when does it happen and who will lose out because of it. The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork? The longer one would have won. No. A majority of miners cannot effect a change in protocol rules. A hard fork like this would require the intentional support of a majority of merchants. Short of an emergency, that means everyone will be given at least 2 years to upgrade. |
|
|
|
|
bitcoind 0.8.0.eligius shares the bug with normal 0.8.0.
Eloipool should work fine with 0.6/0.7.
|
|
|
|
|
Eligius is unaffected. (0.6.0)
|
|
|
|
why the hell is Deepbit only on 0.3.21 Tycho has been very resistent to any change. ... and Luke on 0.6.0? Eligius is actually running both 0.6.0 and 0.8.0 concurrently, but has 0.6.0 prioritized so it trumps 0.8.0 when there's a conflict. It noticed and began reporting the problem immediately, but I guess wizkid057 was busy with something at the time. |
|
|
|
Let no one say that pooled mining is bad for bitcoin now, given how quickly the pool operators corrected this potential disaster and coordinated its recovery... It would have taken a lot longer for thousands of solo miners to have corrected it.
It's not that simple. If everyone was solo mining about equivalent, it wouldn't have been as troublesome! Side note: p2pool is broken by this. Keep up with forrestv's updates if you use it. |
|
|
|
Any idea what version eligius is on? 0.6.0 Deepbit is 0.3.21 IIRC |
|
|
|
|
Show Posts
