Except it already has occurred. Anyone who hacks BTCGuild's systems or coerces its operator can happily reverse transactions that have reached six confirmations with a 21% success rate. 2 confirmations with a 53% success rate.

This is a direct result of the consolidation of hashpower which wouldn't exist absent it. It violates the security assumptions of the system.

We don't iterate MD5 more when its security assumptions were broken, we replace it.

See above.

We also have only about ~3000 stable inbound connection listening full nodes on the network according to the DNS seed crawlers.

We agree here (amazing) and I've had a similar experience to you. I am currently mining on P2Pool and I am a substantial fraction of its hashrate, not because I care for the variance reduction, but because I support P2pool and want miners who do not want the high variance of solo mining to have options which don't require delegating their mining authority over to centralized pools.

I have talked to easily a thousand people about Bitcoin. Hundreds of miners. I am a moderator in the mining subforum here.  It is my experience that your views are highly unrepresentative— not unique, but I could basically count the number of similar views I've heard on one hand if I exclude the developers who only have a few GH/s of toy mining.  If I thought your views were common I wouldn't be concerned.

Funny, responding to a pool behaving maliciously is not among those "modes". Luke's bfgminer stuff actually will detect a number of cases of bad pool behavior (like attempting to fork a chain it had previously mined on) and switch away. Con is completely uninterested in merging that or any comparable feature.

I'm curious what poolserver daemon you run.


I cannot think of a single feature in cgminer which is associated more with network health than short term hasher income.

The failover functionality also unfortunately means that if you compromise one large pool you can DDOS the others in order to drive the hashrate up on your compromised pool.

This is objectively false. For example, when P2SH went active on the network, 50BTC was asleep at the switch and for over a month almost every block they mined was orphaned. They lost no hashrate during this time and today are the second largest public pool.

BTCguild, before they went PPS, went through a months long period of "bad luck" which had one in a zillion chance of actually occurring based on chance. The cause was never explained. Today its the largest pool.

Some popular "gui" mining software botches its failover and has hundreds of gigahash of wrong usernames and passwords show up on other pools when their primary fails. It goes unfixed for months/years.  When a major pool goes down there is an observable loss in network hashrate, in spite of the really fantastic failover abilities in miner software— as you note, the pools are unreliable, and the miner software has great failover, and people don't avail themselves of it.

Pirate (and friends) ran an operation which was paying people to run their mining through them while concurrently running his ponzi operation and paid astronomic PPS rates as high as 150% PPS at times. He gave conflicting explanations of how the hashpower was being used, none of which could possibly have paid for those PPS rates.  He claimed to have a near majority of hashpower flowing through his systems at one point, the SEC reports over 23,000 BTC mined by his operation. Several other parties have also run large pay to hash operations and received large amounts of hashpower.

If a pool starts doing something evil will miners switch away from it — on the timescale of days, sure. Hours? No.  I don't believe anyone can say with confidence that a day-scale malicious reorg event would be survivable.


What am I wrong about?   BTCguild— months of 40% returns. #1 public pool.  50BTC, ~1 month of mostly orphaned blocks due to misconfiguration, second largest public pool.  Slush, hacked multiple times thousands of btc stolen, third largest public pool. Together they are a simple majority of the hashpower.

P2Pool plus solo mining (assuming we exclude the large mining corporations like asicminer) are _no more_ than about 4.3% of the total hashpower, and probably less.  The position you are expressing is, sadly, a demonstrably minority one.

As someone who was deeply involved in the recovery of that event I can't say I agree with your characterization of the situation at all.  A tiny minority of nodes had rapidly deployed new Bitcoin software, if not for the tremendous consolidation in hashpower— making that tiny minority have a large supermajority hashpower, the fork would have resolved naturally.  The miners who's blocks were orphaned in the change were paid for their loss.

You keep saying things that make me wish I could duplicate you, which is a very odd feeling because I have fairly low respect for you outside of your support for the network.  Still, I don't think that we can dispute that your experiences are unrepresentative: Solo mining is a tiny fraction of the hashpower.

At one point we had something like 20,000 stable reachable full nodes. At one point I knew a dozen people who solo mined. You are not talking to some newbie here who is repeating the same old uninformed concerns, I never complained that gpus or asics themselves were a centralization problem.

BC.i webwallet users out number all time downloads of the reference software by a significant multiple.  There are so many different ways that the Bitcoin economy and network has more single-point-of-failure risk than it did in the past now— and only a few ways that it appears to have less (more working client software, and viable exchanges are things I'd call out as having improved).

I am not saying that Bitcoin is doomed or that things will not improved. If I believed that I wouldn't waste my time working on it or discussing it with you here.  But I think we need to frank and clear about the risks and concerns we have with the system if any correction is to happen prior to a devastating event which we may or may not survive.

Evidence in the altcoins and in other security systems suggests its not. One alternative, indeed, is to "correct",  but correcting has great expense— one which is borne exclusively by the correctors but which confers benefits primarily to the general public, a failure to support decentralization is largely an externality.  Additionally, the need for correction is not obvious to most users of the system until there is a massive failure— this kind of security is brittle—, I could argue that this thread is evidence that people are not completely unaware of these concerns, but here you deny them. There are low/no cost changes participants in the system could make (move off of centralized mining pools to P2Pool, run full nodes for wallets if you can, SPV instead of webwallet where you can't, run additional full nodes for the network even where you don't run a wallet, refuse to provide funding to centralized mining datacenters) which few people appear to be taking. The massive failures required to trigger correction would underscore that the core security premises of the system are not currently or automatically true, eroding confidence.  Without confidence Bitcoin has no value.  And everyone has another alternative: don't use Bitcoin.

Some of the most popular mining pools have been hacked over and over and over again, three and four times. Their reputation is fine. A large portion of hashers do not know or care.  Someone attacking the system would be interested in shutting it down completely and/or profiting off shorting it. They don't necessarily have to be those "trusted" parties, they may instead be someone who has hacked or coerced them.    Your argument with respect to reputation could just as easily apply to the FED or Paypal, and yet they continue to stay in operation and continue to behave in ways which people find to be unethical or untrustworthy.

Bitcoin is supposed to be based on stronger stuff than that.

This also ignores that a sufficiently large reorg is unfixable without leaving some people robbed. You can end up with two chains with loads of mutually exclusive transactions and absolutely no way to determine who are the honest owners and who are the thieves: it's one persons word against another.  The actual miners causing the reorg don't even need to be parties to all the theft, it can simply be opportunistic theft that happens during the consensus failure.

The majority of the users are not participating in the Bitcoin protocol, they use thin clients and hosted wallet services which do not enforce the rules.  As usage grows it is a distinct possibility that operating a rule enforcing node will become very expensive— requiring multiple gigabits per second of bandwidth in the "scales to visa" examples given by some— so it's not at all clear that they even could respond to such a threat by changing their behavior due to economic constraints.

steal your coins. Because creating counter-party risk where none is required is absolutely what Bitcoin is about.

Wrong subforum. I tolerate the latest gambling schemes talk when they have some intersection with the actual Bitcoin protocol, software, or technology.  But when you respond telling people not to use technology and to just send you coin, I say— go try the service discussions subforum.

Do not confuse delta-t with the amount of waste heat. Ability to operate at high delta-t is limited by semiconductor technology.  Indeed, if we really did have high speed logic that worked with high delta-t then your options for making productive use of the waste heat would be broadened beyond low level heating applications, and the argument that hashing is more efficient decentralized wouldn't fly, but we don't currently (and this is something which is very much desired even outside of bitcoin mining).

Depending on how you define "Bitcoin"— if you mean the thing that most Bitcoin users use, ... most Bitcoin users use a couple webwallets and SPV clients. SPV clients cannot prevent inflation in our current blockchain protocol, and webwallets may not— at their own preference and whim. I believe that most Bitcoin users are trusting the behavior of a half dozen people or so to prevent inflation.  No _one_ perhaps, but six people? That is another question.

There is currently such an option, but with mining under the control of just a couple entities it could go away. They could happily only mine transactions created a certain way or obeying whatever new rules they wish to impose.

I think the thing we try to achieve with decentralization is not just freedom in practice but freedom which is infeasible to remove. It might not look likely that these freedoms will be removed in the short term, but I think we cannot say that it is currently infeasible.

Decentralization is not a binary state, it is a continuum.

Change is a fact of reality. Early on all the users of Bitcoin were equal. They (almost) all mined, all ran the same software. None had any real power over another, which I think is really the main purpose of decentralization.  That couldn't last forever, eventually some participants would be tremendously more important than some others.

Bitcoin has lost more decentralization faster than I expected it would, and I am unhappy with the current state of affairs, especially with the level of centeralization occurring in mining and in "trust based" hosted wallet services.  These levels of consolidation undermine the security assumptions that justify our system. The future is unclear.

But "not decentralized"?  Well, can you suggest an alternative?

Would it be really awful to regexp filter posts for something like^\w*[Ww]atching\.?\w*$ and deny the post and tell the user about the watchlist feature?

This is all really quite in the spirit of this thread.  ... Delicious flirtations with ideas on the boundary of really useful and horrible train-wreaks.

As long as the charge-back covenant doesn't run with the coin forever it would become safe to accept these coins once it was free of the covenant.

> It seems that one party always has to assume some risk

If you discount the cost of wasting your time and tinkering with technology, true zero risk exchanges of some digital "assets" are at least theoretically possible. E.g. I can easily buy a SHA256 pre-image from you today using Bitcoin. The math tells us this capability should, in fact, be fully general... and that any digital good who's acceptance you can codify into a program can be sold risklessly with Bitcoin (using the contingent payment protocol I invented) once the right tools are made.

Clunky pieces of metal, indeed, no such luck.

Nope, disabled and re-enabling it would require a hardfork. (though it could be replaced with a soft fork and a v2 p2sh)
The best I think you can do now is hash the two secrets and compare to half way through the possible output space.

I see.

This isn't a great assumption— http://blockorigin.pfoe.be/top.php —, but it's also not your problem. If that assumption fails hard enough the Bitcoins being bet lose their value anyways.

Ah, I only saw the first three steps and accidentally scrolled past the rest. I went on to propose a spirituality similar protocol. I think thats fine (upto practical details, such as not being able to read the LSB in script; that it falls down if the transactions take longer to confirm than your timeouts, etc).

Congrats!

FWIW, there are john the ripper patches for wallet.dat passphrases (which can attempt about 8 tries per second) ... also support for bc.i passphrases, with speeds more like 10 million per second.

As you note, the later to release could hold up if they see that they would lose.

I can see ways of compensating for this where disclosures happen one bit at a time so that one party never has more than 1 bit of knoweldge advantage, but those don't result in compact release scripts due to the need to structure the proof as a bit commitment list to prevent unfaithful execution during the reveal.

e.g. your commitment would need to be  H(...H(bit||H(bit||H(bit||nonce)))...)

Though even then it means that a party with a substantial computational advantage could still bias the outcome.


One possibility would be to bond the bet thusly (warning: this protocol is a freeking mess)

Alice and bob one to do a no-renig coinflip.

First alice and bob commit to secrets by sharing hashes of their secrets.

Alice writes a transaction which pays to multisig alice and bob
.. but before announcing, writes two refund transactions:
  One is lock-timed 100 blocks from now, and pays alice's coin to bob.
  The other is not lock-timed, but requires both alice's signature and the preimage to redeem.
After bob signs both of these alice announces the payment into the escrow.

Likewise, bob does the same with the roles reversed.

Now alice and bob do your coinflip transaction, with it's own refund, but the refund is locktimed 300 blocks from now.

If they do not release their secret in time to beat the refund they lose their starting bond.

You do realize that multibit cannot run at all without thousands of people running full nodes, right? And that if the network consisted entirely of multibit like clients it would have no security at all...

It's fine that users with limited resources use thin clients, but— they're just thin clients— someone has to run the servers for those thin clients, and if its only a few people then they can tell you whatever they want and the house of cards comes tumbling down.

The word dominate very strongly suggests the race misunderstanding. If I have 1% and you have 20% you will mine 20x the amount of coin I do, you will also consume 20x more power and pay 20x more for hardware (assuming we are buying the same hardware). There is no "dominate", it's all linear.

I'm not sure that I'd want to promote mined transactions as a jamming resistant communications channel. Especially since, you know, it's not actually jamming resistant, and it's not hard to imagine examples where the miners would actually be interested in jamming NAKs on an update.

An idea I find attractive is to have the ability to have signers who can only give "negative karma"— these keys could be issued pretty liberally, since the only risk is that they delay an update. This models what we already believe to be the primary existing source of assurance: "if something bad is done, someone somewhere will sound an alarm". Coupled with suitable delays this could be pretty powerful.

The tricky part is having a jamming resistant way to get their negative views out to people.

Yes/No.  It does support two factor authentication: Thats what wallet encryption is, you're protected by knowledge of the password and possession of the wallet file.

But no, because control over your computer moots security provided only by your computer.

There are a number of hardware wallet devices coming out which outsource possession of private keys to USB dongles that require a button press to authorize a transaction... those will keep you safe even if your computer is compromised.

It's also a peeve of mine, and it very much is ontopic. The people just fitting random formulas to the hashrate and making predictions are producing BS numbers that obscure better analysis (e.g. ones factoring in published shipping schedules or profitability over power costs) and make everyone dumber.


All living men are mortal.
Socrates is mortal.
Therefore, Socrates is alive!

Sorry, you can't just wave some hands and some things that have some vague commonality. Good reasoning requires at least arguing for a causal relationship. I can argue how increases in hashpower encourage decreases in the rate of increase— higher hashpower makes every bit of marginal increase in hashpower less profitable— but not the opposite.

This is missing, at a minimum, the core developer and technical expert flags.

Some of the participants here are pretending to be women specifically because they believe it manipulates how others respond to them.