Bitcoin Forum

Stratising is where you connect to multiple chain-services and only accept the common shared history that they give your client (Electrum .etc).

Assume that you connect to n chain-services controlled by different organisations/individuals. There is an average expected risk r per service that they are compromised by a single attacker. Not that each service gives false info, malfunctions, but that they are compromised by the /same/ attacker. We assume this to be an independent probability.

The chance of being cheated, p

p = r^n

The more services you connect to, p drops exponentially very fast because r < 1

I suspect users would choose the services or they are bundled with the client.

Show me why that is a valid assumption in a hostile environment, please.

Isnt that the dns system ?

A very tall assumption on the internet when identities are fairly cheap.  The question of interest is for a given definition of "organizations" how much does it cost me to make your P as low as I like?  If your definition would let you include individuals the answer is very low.

These sorts of assumptions can also fall down if the attacker has the ability to influence your routing unless you have a good way to validate the identities— and most ways of having good authentication and good ability to distinguish control work against having a lot of peers.

Bitcoin could have been created as 'one peer one vote' system under the logic given here but it would have been trivially exploited if it did.

[Edit: Oh, maaku said this all pretty succinctly, so succinctly that I missed it]

Assume that you connect via the namecoin dot-bit dns to n chain-services controlled by different organisations/individuals .

(fixed)

How does namecoin help you know that they're distinct?   How does namecoin— as it's used today— help you defend against an attacker who has control of your router?  How do you resolve namecoin without having a namecoin full node without trusting someone (resulting in the same problem you're trying to solve here)?

Well obviously you would have to run a full node .... I thought you would know that?

The rest of the questions are based on the straw man of not running your own node ....

It seems kind of odd to me that you'd invoke running a full namecoin node as a means to avoid running a full bitcoin node— and only a partial means, since it doesn't do anything to tell you if the parties you're communicating with are actually distinct.

Wouldnt that also mean that with enough faked nodes you could "just" outnumber the correct ones?

Not odd at all ... have you compared the overhead lately on the bitcoin network vs. namecoin network? E.g. there is no satoshi dice running on namecoin .. yet anyway.

Basically if you want to trust a server to do the heavy lifting for a lightweight bitcoin client (the topic of thread), which it is increasingly likely most people will have to do, then you want the best security possible to authenticate with that bitcoin node server .... with the merged-mining hash power of the bitcoin network behind it namecoin offers similar security of authentication as a full bitcoin node (which is basically the best going right now) without the overhead.

So it is a trade-off where you give up the absolute security of bitcoin, for a reduced overhead but piggy-back onto bitcoin hashpower to authenticate with a known good node on the bitcoin network .... I'd take that, it is the next best thing to a full bitcoin node.



Don't understand this part of your comment, before we go any further it maybe instructive to know how much you studied the namecoin system?

This is a very strong assumption which I don't think is warranted.

I agree, that was the bit I had trouble with also ... bit of a "who knows" though, i.e. unquantifiable.

As pointed out by others, you're just redesigning Bitcoin by doing this. Your next problem is that it's hard to know you are really connecting to independent nodes. Eg, if you have some kind of random node selection algorithm, you can't know that you're really talking to different nodes if your connection is compromised. For example, if you are at a Bitcoin conference and using the free wifi.

To solve that you can push the burden onto the user, by asking them to provide the public keys of servers that they "trust". However, this has a poor user experience (users start out by trusting nobody, why should they?) and that trust can be undermined by hacking a few of the nodes. As most users would never set up their own node relationships, operators would have a giant set of cross-hairs on their backs.

Given that "stratum servers" make a big deal out of advertising that they're secure because they don't hold your private keys, and they're all run by volunteers today, if reliance on them became common I'm sure hacking would start. Not to mention possible scaling issues.

So you can say, hey, why don't we define the common shared history by proof of work, which is harder to fake using sock puppets especially as the transition to specialized hardware and professional miners kicks off.

Now you have a client that downloads and verifies the shared proof of work, which is called an SPV client.

This is why I haven't put any effort into Stratum/Electrum type services. I think it's only somewhat more work to just use the block chain directly and the end result has better security and scalability properties.

Relative to the number of users namecoin is currently much more expensive to maintain. Or do you really think that namecoin has as many as 18% of the users as Bitcoin.


I understand the namecoin system very well.

"Relative to the number of users" huh?... and why would that be a relevant metric for anybody?

To the end user, using namecoin to ensure a secure connection to a full bitcoin node is way cheaper than running a full bitcoin node ... or are you disputing that point?

Obviously namecoin doesn't have as many users as the proportion of the hash power it commands, this is precisely the piggy-backing onto the bitcoin hashpower merged-mining allows ...  this is the second time you have thrown up an irrelevant arguments without pointing out exactly where the problem is you are complaining about. Third strike and I'll assume you are just trolling.

Because if namecoin was widely used the cost of running a full node would increase. It has _far_ less usage than bitcoin and already it's about 18% of the blockchain size.  Namecoin's design, unfortunately, doesn't enable lite resolvers (there can be no equivalent of a SPV node, like bitcoinj, for namecoin with its current design) of any kind which I think will probably doom its adoption.  I posted a sketch of a design to solve this last year, but other than the addition of merged mining namecoin development appears to be more or less completely dead.

I consider this to be fatal flaw which will ultimately prevent the adoption of namecoin unless it is resolved.


That makes no sense at all and doesn't follow from the technology.  Namecoin is fundamentally more computationally costly to maintain because you _must_ have multiple unspent outputs pending in order to have multiple registered names (whereas any amount of bitcoin can be represented by a single txout), and you must carry additional indexes on them in order to perform lookups. (bitcoin txn only require lookups by txid).

These aren't any terrible flaws, but they're reasons why a full namecoin node— if as widely adopted as bitcoin— shouldn't be expected to be less expensive to run.

A fully validating bitcoin node can actually be operated with less than 100 mbytes storage, though the code for this is not mainline yet.


Can someone please decode this for me— because I don't have an idea what you're talking about.  I can assure you that I'm not trolling.
 
To the contrary, you've still made no suggestion about how namecoin could do anything to address the fundamentally hard problem of this thread: Demonstrating the independence of weakly trusted central servers, as required for the exponential security model given in the OP to hold.