A non-profit, but not a charity, and I think a lot of people think of the two as synonymous— the tax advantage of their structure mostly exists to prevent double taxation on monies that would otherwise be spent directly by the members if the orginization didn't exist. I hadn't really paid much attention to (c)(6)'s previously, it's interesting to see that some have been under fire, and thats probably another argument for maintaining a good delineation between Bitcoin and Bitcoin Foundation:  no one wants uncle sam arguing that Bitcoin Foundation is really the controlling corporation for Bitcoin— in independent business— operating under (c)(6) as a tax dodge.

Responses in that thread (I've whitelisted the poster and would move the thread here, but I can't) as thats better than splitting it across two places.

"Make the best chain selection not a pure function of the chain" is a perennial proposal, and can be answered to as a class:

Chain-external statefulness can result in fatal consistency failures. Not all nodes will have observed identical past prior states— consider newly started nodes, or an attack where the attacker intentionally simultaneously announces conflicting chain segments to distinct groups of nodes in order to intentional create incoherent state.

For example, some of the most common proposals in this space is simply to refuse to make reorganizations over some size X. But this means an attacker who can produce X+1 blocks can do a simultaneous announce to half the network of one fork while giving the other half one more block. Everyone locks in and the network is forever split.  If you assume that an attacker couldn't make an X block reorg, then the "protection" was pointless in the first place.

Likewise the all the soft versions I've seen proposed have the same kind of problem, though potentially less fatal— while closing one pattern of reorg it acts as a reorg size multiplier for a different attack pattern using an attack optimized for it.

I don't expect this general line of research to be promising, simply because — above all Bitcoin is a consensus system and using node local data to make decisions gets in the way of achieving the fastest possible consensus.

Height isn't visible to the asics. The network difficulty and current time are.

If someone would like to pay the 50 BTC cost, I'll gladly solo mine an invalid block on an avalon with 2x the current difficulty and a timestamp set far in the future.

It's a 501(c)(6)— a professional league, not a 501(c)(3) charity.

A 501(c)(3) engages in religious, scientific, educational charitable purposes and are obligated to act in the public interest. They're prohibited from certain political activities (they can lobby for their interests but cannot support candidates and lobbying must be limited to some minority part of their expenditure) and must meet various tests for their funding coming from the public (or other charities and government) sources. The IRS has been clamping down on charity applications now and seems to be demanding more justification that an organization's purpose is in fact charitable.   The plus side of all this trouble is that donations are tax deductible, and there is a certain degree of public legitimacy created due to both the charitable mission as well as the public support requirements demonstrating that the org isn't just acting in one parties interest.

501(c)(6) organizations are professional interest organizations such as chambers of commerce, sports leagues, etc. Rather than acting in the public interest they act in the business interest of their members. (And their income is not taxed, because it's assumed to already be taxed— and only replacing activity that the members could have done directly, but it is not tax deductible).

The lobbying and political limitations as well as the general hoop-jumping to get the classification are reasons that if I were creating a Bitcoin Foundation I might consider making it a (c)(6) instead of a (c)(3). On the other hand, the lack of a requirement to serve the public interests will likely always feed accusations of the organization being a pawn for its primary funders, and along with the lack of deductability are arguments against (6) and in favor of (3) most obvious to me.  IIRC there are also fewer rules about the disposition of assets which can make it easier for a large sponsor fund a (c)(6), because IIRC a (c)(6) can return assets to people where a (c)(3) can only dispose of assets by transferring them to another charity.

I think that even if we had a 501(c)(3) Bitcoin org, the Bitcoin ecosystem would still probably need a 501(c)(6) one to optimally enable collaboration of the large commercial interests.

I think this is a fantastic idea.

I look forward to owning all of the resulting coins. (as I will mine blocks that makes the next POW require factoring a large near-prime composite specified in this block...)

 

More seriously, there have been LUA pow proposals before. No one knows how to make them secure against that kind of obvious gamesmanship much less more subtle kinds.

Amusingly, the US's track record for technology and internet freedom is actually quite excellent— far more so than much of the developed world (e.g. the UK). Part of the reason it's so good is that there are a great many people who speak out about any threat, so you hear more about it. Even our bad-and-often-complained-about laws like the DMCA are also tremendously protective (E.g. DMCA creates an absolute immunity for service providers, removing them from having to be in the business of playing copyright nanny).

Mining over Tor works okay generally... more so as a solo miner than a pooled one, since a solo miner can have multiple connections and will still hear new blocks even if one link is lagged out. Of course, if many people are mining behind delays then it won't be a disadvantage at all.

There are also parties solo-mining without themselves accepting incoming connections, and instead just making sure they are connecting out to other well connected nodes. This creates a bit more privacy.

I saw the FinCEN stuff as generally positive. There were many other negative things they could have said and didn't, in particular I consider their delineation between decentralized systems and not as quite positive.

Exactly.

My general view is that Bitcoin is strongly supportive of the interests of the public and no equitable democratic nation should have reason to take adverse legal action against it.  There may be some authoritarian dinosaurs who might try— but I hope and expect that they'll continue to be asleep at the wheel until long after Bitcoin is far too widely adopted by boring and normal people for them to successfully suppress it.

Trying to dodge policy with technology is something of a losing game here. It can be fun to think about, and there are many things you can do to try to keep Bitcoin more robust against powerful attacks... the most potent of which would be to constantly adapt. But mining is certainly a soft spot: the conspicuous usage of energy is a bit hard to hide, though not impossible.

But I don't think it's very relevant in any case: Sometimes people will compare a war on Bitcoin to a copyright-war or drug-war... but I don't think the comparison is apt.  Illicit drugs still make the user high, unlawfully copies movies still make their audiences laugh— both of these things still work even if none of your friends are willing to partake.  A money-like good is another matter— it gains value from people's willingness to accept it— and so even outlaws don't have much use for outlaw currency.

What protects Bitcoin is that its fundamentally a very just and wholesome technology, and not that different in terms of abuse-risk from cash which is still a norm even in highly authoritarian places. No government is a monolith, and some of the aspects of Bitcoin helpfully cut through a lot of gnarly public policy issues:  It's really hard to resist inflating your currency when you are technically able— when resisting it means accepting some obvious negative outcome at the expense of some fuzzy long term principle.  Sometimes to achieve freedom it's essential to take some options off the table.

I don't share many of the concerns in this thread—  I think it's natural, expected, and a welcome thing that businesses and other interested parties should come together to collaborate to advance the cause of Bitcoin.

I'm also confident that Gavin can behave responsibly relative to his dual roles, and at the same time— nothing he does with the codebase is a secret, all changes are cross reviewed by other developers (and anyone else who is interested!). If the review process works then there is little to worry about even if you do not trust Gavin, and if it doesn't work then you have worse things to worry about than the foundation being a boogieman.

You can help out by following changes to the reference codebase and asking questions. This would probably be a lot more productive than the fear-mongering on the forum— which does nothing to prevent badness, and is pretty demotivating to people who (in all likelihood) are completely honestly motivated.  If you have a concern the best thing to do is step up and eliminate it by guarding the system— if your concerns were misplaced, no harm done, you might still stop a failure from a direction you didn't expect— if they weren't misplaced you'll help stop a bad outcome ... and doing that avoids offending people with false accusations in the times your concerns were misplaced.  Complaining on the forum like this, smearing peoples motivations and such— makes people write off the forum as a bunch of poorly socialized chicken-littles.

I do think that it's kind of odd to see one thread of people complaining that the bitcoin foundation is some ominous force, while other people from the forum complain that they're not grabbing enough!

Making it clear that the Bitcoin Foundation is a professional promotion organization like a chamber of commerce and doesn't own or control Bitcoin— any more than a chamber of commerce controls or represents all business— is a good thing but it can be done without accusations or conspiracy theories that make it sounds like the claiming person has other motivations.

If you use the browser extension I believe you are relatively safe from arbitrary code changes like the one we witnessed at StrongCoin.[/quote]
That is not correct to the best of my understanding. The extension only makes sure the JS matches the JS on github and does not prevent additional pre-loaded JS from manipulating the execution environment.

The makes a nice example of why security is hard: This isn't secure either— if you're using a single point of trust webwallet the wallet can still lie to you about having confirmed payments that aren't real or cause you to sign away the bulk of your coins to fees.

Log out, read the instructions on the log in page.

There are things that can be done, but they depend on the specifics of the attacker and the attack... and if the attacker knows about them they will be less effective. You can be confident that Bitcoin wouldn't go down without a fight.

But fundamentally: The security assumption of Bitcoin is that the honest users control the majority.  If it could be stronger, it would be— but at least so far as I've seen the proposals to strengthen it within the algorithm end up trading off one weakness for a worse one. If you break the majority assumption then no algorithm can protect you— but people, acting externally to the system adapting it with the consent of the honest users— still can.  People can make value judgements "this chain is good, that chain is an attack" which are very hard for an algorithm to make especially when the attacker can see the algorithm.  Those value judgements are a liability— they're part of why traditional monies are untrustworthy— but if Bitcoin's security assumptions get broken by an overt attack I expect there would easily be universal consensus for some kind manual intervention.

They have the same access that all JS webwallets have. People have been telling all of you that their "private key on the client" model isn't comparable in security to a normal Bitcoin client and you've just continued blabbering on about 'BUT PRIVATE KEY ONLY ON MY COMPUTER' ...  Even here you seem to be speculating that maybe it wasn't really on your computer. IT WAS and thats _not sufficient_.

People have been telling everyone since these JS wallets have come into existence that they have an inferior security model compared to SPV nodes which have an inferior security model compared to full nodes. If people insist on ignoring the experts who are looking out for their interests because they think they know better ... well. Expected result is expected.

As an aside I ran into a nice quote from Jacob Appelbaum on system security, an I thought it nicely repeated some of the points I made above.

ECDSA is not a hash function. At attacker with the pubic key isn't confined to use the dumbest possible brute-force attack.

Pollard's lambda algorithm takes sqrt() operations— so roughly 2^128 security.

If you make the longest chain decision stateful and not a pure function of the universe equally visible to all nodes then you replace a consensus change with an even more devastating consensus _failure_.

As an example, an oft-repeated suggestion is "just refuse to make any reorg greater than 50 blocks". Great, so now an attacker who can outpace the network can produce a fork 49 blocks back  and then mine two more blocks— one on the real branch one on the fork— and concurrently announce them each to half of the network ... and from one currency you have two: nodes are forever split and will never converge.  ... Or more simply, he makes his longer chain and all new nodes will accept it, all old nodes reject it.

Of course, if you make the fork far back enough then "okay, it'll never happen"— indeed, but if it'll never happen, what value is it?

I'm not seeing your third choice.  I see: do nothing, do nothing, return the stolen funds.  I mean, if you're willing to distinguish choices that make no functional difference then there is an infinitude of options... he could ... return the funds... while wearing a funny hat.

I disagree that it's about the consequence. Consequences are one time things.  Today a thief is stopped and the stolen funds are returned to their rightful owners, tomorrow guys with guns ransack the operators home and 15% of the wallets get stolen… or maybe it doesn't happen. Perhaps it just gets hacked and the operator plays no role in the redirection of funds. Or maybe something else… Remove the trust and you remove the vulnerability.  You might demand that an operator be built out of stuff immune to human suffering— I don't agree— but do you also ask him to be immune from bullets? From court orders? From his own conscience?  Wheres the limit?  I argue that the answer isn't that interesting because no answer will be very good and because Bitcoin was invented so that we wouldn't have to ask that question very often to begin with.

Certainly there can be cases where you can debate the rightfulness or wrongfulness of a decision— but this isn't a good one for that:  This isn't a place where trust is unavoidable (like a BTC/USD exchange), and it isn't over a particularly grey decision...

The 256-bit ECDSA is really only 128 bit strong. The hash is not the limiting factor.

Not many options.

"none of the above"

This is a false dichotomy. "Inaction" is a choice too, to say otherwise is maddness: we can often orchestrate things so that great evil require us to only sit by "inactive". ... and the laws of many societies also frequently endorse the view that at least in some cases a duty to act is created— even though creating such a duty carries many risks and costs.

Ultimately, the question here was only about power. The site had the power and opportunity to stop the theft.  Failing to act on it would be a difficult choice, one that would open them up to adverse legal and moral judgements by others and one that many people— sympathetic to the thief's victims and not the thief— might have a hard time sleeping with. As I elaborated in my message— for some other operator the threshold might be different— higher or lower, depending more or less on the specifics or the pressure placed on them— but that there is a threshold is a fact which can only be changed by reducing the amount that we grant trust.

Someone asked me why I'm bothering to blather on about this... I think this is important because I hope people think deeply about trust and change their behaviors. It would make me sad if only thieves— who should know in advance that they can't depend on anything as thin as trust— get the benefits of reduced trust.

I think people who are hating on strongcoin are taking away the wrong thing from this.  This is the reasonable and expected outcome.

I suggest meditating on some words from Satoshi:

Used correctly Bitcoin is secure no matter how good the "excuse" is and in this case the excuse is exceptionally good:  Someone who ripped off infrastructure important to many of our community members, screwing both the users and a the operator (a rightfully well respected member of our community)— is utter scum. It would be wrong of us to expect anyone to protect him, he didn't protect Bitcoin— he didn't protect Ozcoin's users— he didn't look out for anyone but himself.  I agree that this can begin slippery slope of "excuses"— but Bitcoin has an answer to that that slippery slope: Build systems that don't depend on trust. But Bitcoin's trustlessness can't protect you if you go around delegating the actual use of Bitcoin to third parties.

When you use a webwallet you're trusting that the JS is not replaced out from under you— you're trusting that any 'validator' tool validates against something useful (and not just some copy the same operator can replace), and that no additional JS is being inserted which e.g. rebinds half the JS language and keeps the validated code the same while changing its operation, that the web browser environment— which wasn't designed for this kind of security at all and lacks basic features like mlocking data to keep it out of swap— is secure. You're trusting that the operator doesn't phish your passphrase— as they trivially can— or brute force it. You're trusting that the site gives you faithful information about the blockchain as none of the webclients have even SPV security. You're trusting that the site operators description of their service as secure is truthful and that there aren't subtle weaknesses that you don't personally understand. You're trusting a lot of things ... and especially if you're a disreputable thieving source there can be no basis for that trust.  It would have been wrong of us to demand that the operator of a service turn down a well substantiated request in a case like this, it would make them a villain to the kind and honest people their decision harmed. We shouldn't create a world where people have to make choices like that.

The webwallet wasn't the only problem here: For example, the address reuse made identifying the wallet vendor trivial.  These aren't new security issues, but a lot of people won't believe them without concrete examples.

Ultimately the problem here is one of introducing trust needlessly. Expecting this not to fail for a villain would be to expect inhuman behavior from the site's operators... and even a wallet service operated by the least human most profit oriented sort would have some "excuse" that was sufficient: Perhaps for some it's a crime that ought to be solved, for others it an attractive bribe, someone else might be motivated by a court order— or by a literal gun held to their head. Whatever the exact contours of the breaking point is— it exists.  Bitcoin was designed to liberate us from so much dependance on trust, but it can only do that if we use it— and not thin-clients that kinda-sorta-approximate it.

I'm glad that the example here is one where a really obvious thief gets screwed over and not someone less deserving. Hopefully the honest folks will learn and change their behaviors faster than the thieves do.


[I'm sure this is going to get discussed in a dozen different places— I'm not going to bother trying to track them all down. If you see it discussed elsewhere and you thought my comments were interesting, please feel free to drop a link back to here]