Topic: The swarm client proposal - Reminder: 15 BTC pledged so far, now worth 3255$! - page 2. (Read 12127 times)

PKI is a nonsolution to the connection hijacking problem since they can also spoof the certificate authority.

No:
1. Each node would generate a new public key after installation.
2. The node publicizes it for future communications.
3. It is not changed later on.

Hence an attacker cannot generate a new one as mtgox, your brother and friend for instance would always be using the same public keys.
The attacker would have to steal each of these along with your upstream connection to pull off his attack.

That is not enough.

How do you even know whether or not you have "valid previous inputs"? You don't.

You ALWAYS have to know about ALL of them, both in and out to know the real balance of an address. If you don't you can't "verify" a transaction because you don't know if prior inputs have been spent or not.

However by only looking at only some of the addresses on the block chain you can both verify blocks (the parts you are watching anyway) AND avoid having to download, process and store the entire block.

I beg to differ.

A client that breaks protocol is simply ignored in bitcoin.

The rest is hard as nails cryptography.

I don't know all the details, but if you have ONE router connecting to the internet through ONE phone/fiber cable then "all" I need is to cut it and splice it into my fake internet-portal-hack-machine.

No matter what IP you queried I would answer.

That's right the normal BTC client may well be unsafe. (dunno if they fixed it already)

I suppose you are building a light client like electrum or you shouldn't have to rely on trust.

I was wrong/inaccurate when I mentioned DNS. The TLS itself is more generic; but is typically used as a way to double-check the results of the DNS resolution.

I think both TLS and IPsec have some merits. In my mind the most important thing for TLS is that it can be used over Tor. This would allow Dead Pirate Roberts to publich the certificates for his cottonpath.onion family of sites and operate as a super-trusted Bitcoin peer node.

IPsec would shine in WLAN peer-to-peer situations because the IPsec protocol stack has less interdependency with name resolution. It could be a great way to authenticate mobile but non-anonymous peers.

I'm not sure if the existing Bitcoin protocol can be transparently extended to support the STARTTLS behavior. But for sure Bitcoin could be modified to support HTTP/HTTPS dichotomy of two different port numbers 80/443.

So you have to use DNS with TLS? I know TLS is used for domain name authentication (With HTTPS) but I didn't think it was tied to DNS. I thought it was lower level than that. I thought the domain name or organisation authentication was taken by the subject details in the PKI certificate by the web browser?

Except that TLS is geared towards client-server model and has explicit tie-ins with DNS service. Since Bitcoin is fundamentally peer-to-peer I think the better approach would be to popularize use of IPsec for securing the Bitcoin traffic.

IPsec can use PKI certificates and has the additional benefits that no source code modification would be necessary. One can secure the p2p transfer by just configuring the IPsec at the OS level or router level. The eventual modifications to the source code would be just to make it more user friendly. Understanding the intricacies of oakley.log is a very advanced pursuit.

Hence another reason to use trusted nodes and issue scary security warnings when valid connections to these nodes cannot be established.

I definitely think TLS should be adopted so that PKI features can be used, if not now, in the future. For now, simple public key matches can be used but if the concept of bitcoin certificate authorities ever comes around the PKI is there.

The definition of "their own internet connection" varies. Throughout most of the Western world this typically means "household" or "office".

But say in Brazil or in Eastern Europe it could mean "our block", "our building", etc. The shared Intenet is way more popular. Thus the popularity of attack programs that spoof DHCP, poison ARP caches and flood the switches. Such trojans/viruses don't even have English versions, they are already written in their local language. Most importantly the Western antivirus tools are oblivious to them.

So you mean the connection from your computer network, to the next machine upstream to the internet? Well I mentioned the problem of someone having control over your entire internet connection. This would be fatal for the current bitcoin software as you can be isolated from the main network. A solution would be using trusted public keys. Using public keys themselves with no form of identification would not be suitable.

Imagine you are connected through someone else's wifi network. The attacker could intercept all traffic from your computer. The attacker would form a TCP connection to every connection your computer makes. The attacker would then forward all non-bitcoin traffic to the internet and it would take control over all the bitcoin traffic. The attacker can just generate their own public keys for each node you try to connect to. The only way to identify that you are not making a legitimate connection is to compare a public key against trusted keys or to use some sort of system such as PKI (via certificates you use a third party to verify keys) to find trusted keys.

I seem to remember reading other discussions about this, it would be unlikely that your entire connection is compromised but there are risks. Cancer nodes are a way in which an attacker tries to connect someone to many bad nodes by flooding the network with these bad nodes. That could be an issue. It is one reason why relying on specifically trusted nodes could be a good idea.


That's what I'm talking about.


I don't know what you are talking about. In the case of validating transactions you will need valid previous outputs. If you do not have them, then you'd need to query other nodes for them. This could perhaps be helped if miners added the position of previous outputs in the inputs of transactions with OP_DROP to help you query particular nodes for the information (This would be in the case where nodes look at specific regions of blocks).


Well bitcoin actually requires trust. True that if you have connection to one good node and that node has connections to good nodes that cover the entire block, problems in blocks can be discovered and shared. That's pretty much as safe as bitcoin is now, which is very (Providing not all of your connections are bad which is what I mentioned at the start of this post). Though you do have to assume that the entire blocks are being covered by good nodes. I don't think that would be a bad assumption to make, if this is implemented correctly. Ensuring you are connected to trusted nodes that cover all the block regions would increase confidence in the fact.


Not so fast, you would need to intercept all the connections. Is this a problem for people using their own internet connections? Are ADSL lines secure? I doubt there is a problem except perhaps when using someone else's internet connection, as I said.

The security model of the client I'm building will make use of a trusted node alongside the usual network. If you cannot connect to the trusted node, then my client will issue some type of security warning.

No just YOUR upstream connection, then I can simply tell you that I am IP XYZ and that there are no new updates to my addresses.

You don't need a web of trust or anything like that, just PKC; each client randomly selects a PK and publishes it.

Each client would then have its own list of Pub.Ks or "client addresses". For instance I might add MtGox, my brother and some others.

This doesn't mean I trust these guys it just means I find it near impossible that they would ALL know what the attacker wanted left out AND either have been hacked or colluding with him.

If I cannot connect to them because the attacker cannot fake them without their Pri.Ks I will know my connection has been hijacked.


This would not be possible, you cannot tell if a transaction is valid unless you know ALL movements to/from that address prior to the new move.


Wrong. My solution does not require trust, hence its awesomeness.


A swarm client would query thousands of nodes for updates to the same address.

Only ONE of those thousand would have to be honest and the swarm node would know your addresses true balance.


Actually when thinking about it the vulnerabilities of the swarm client and the normal client are the same:
"Hijack attack"
1. I hijack your connection.
2. I pretend I am your 8 peers.
3. Instead of the real blocks I start to relay blocks I made.
4. Your client will simply think the computing power of the miners dropped or something (and eventually lower its difficulty level).
5. I spend my bitcoins on the real chain.
6. I "buy" something physical from you on the fake chain I am feeding you.

If the official client doesn't have PKC you could execute this attack right now. The swarm client is just as strong as the normal client.

You'd need to hijack many nodes. There is the problem of cancer nodes and man-in-the-middle attacks, regardless. A PKI system or web of trust could help the problem of bad nodes. If someone can take control of your internet connection because you may rely upon their connection (Like public wifi) then you could easily isolate people from the internet and into a fake bitcoin network. This is not an issue if the client relies upon trusted nodes. The client could generate a security warning to users if it cannot connect to enough trustworthy nodes (via PKI, web of trust or hardcoded keys for specific nodes) like "Warning: This client has detected a potential security issue with your internet connection. It is highly recommended you do not use this software. Please restart your internet connection and try again. If you are using someone else's internet connection, it is advised you consult the owner of the connection or use another connection.".


I don't know why. It would probably be better to validate a certain manageable amount of transactions per block at random offsets (done to try and ensure even spacing of the validation across the transactions).

A distributed validation system will always require trust in other nodes. The key would be to try and ensure enough nodes are relied upon to prevent the risk of all the nodes being untrustworthy (relying on one node is obviously not good for instance). And indeed a broadcasting system to share bad information across the well behaved nodes is important so that you should be safe with a connection to only one trustworthy node (provided that node has connections amongst the rest of the network). I do think the problem of cancer nodes will be much greater for this type of system, so PKI (Special bitcoin certificate authorities that try to validate trusted nodes) or a web of trust (More decentralised solution), as I've said, could be one way to battle this.

Needs a lot of thought. The security implications are a serious consideration.

Bitcoin was originally designed to eliminate trust but running full nodes is not possible for everyone. Simplified payment verification, server models, and perhaps this potential solution (It's not a working solution yet, too many problems) will be important. All lightweight solutions require a level of trust.

Well okay then.

Normal clients request blocks from their peers which can then be sent or not sent.

However swarm clients request information pertaining to certain addresses (or what ever the information is organized by).

This means that if I hijack the upstream connection of a client I can leave out just the transaction where I spent my coins and then pretend I can spend them again.

My fake upstream client would pretend to be mtgox and a thousand other clients all NOT sending that one critical piece of information.

However with PKG implemented I would be unable to fake being the mtgox client or any other and the double spend attack would fail.

The clients watching the first sending normal address would then store the chain of scripts until the BTC landed on a normal address again - which could then be watched by other clients.

This is only true if the obfsproxy software is used, and it's very new, immature and rarely used so far. For most purposes, Tor is completely unavailable for use in China.

Why? What makes you think the destination address, the Tor exit node and the machines between them will be safe from censorship?

The only complete solution is to use encryption in the bitcoin protocol.


Using TLS may be simpler (Though I've never used it with OpenSSL or any other library) and offers a well tested and accepted security protocol. It can also lead on to the additions I talked about (PKI and web of trust).


I cannot find this post. Maybe I am blind. Why is connection hijacking a problem for a distributed solution to block chain validation, is it isn't already for bitcoin?


And the person sending bitcoins redeemed from an IP transaction, is not. There is no address in the previous output.

If you're born there you should be more worried about suicide bombs, starvation and the mood swings of the local warlord 

Right and wrong:
The last step might be un-encrypted true, but that would usually be safe on the other side of the government firewall.

However between TOR proxys the data is in fact made to look like facebook/email/youtube traffic. Otherwise TOR would have been shut down long time ago in China.

Since BTC data is not sensitive the only reason to use public key cryptography for communication would be to prevent connection hijacking.



All you need is for clients to publish their public key, then only that client can read the data and no-one can fake being an IP they are not.

This WILL be needed to make swarm clients safe as argued originally by casascious?.

(connection hijacking)



If you are sending to an IP you are sending FROM an address, so some swarm client would be storing that OUT-transaction/script until it was redeemed.

Same if you send to a script that is redeemed with a double sig.

The block constructors would be trusted members and the hash finders all the other strangers. Constructing a block will always be much easier than finding the hash so you would not need that many trusted.

If you want to avoid trust; multiple clients could be checking each included transaction. If a bad transaction is reported it is removed from the construction process.

Finding 10-100 trusted members would probably be simpler though.

The swarm client just saves the pool operators from writing their own parallelized local client/super node.

Tor hides your IP address, it does not hide unencrypted data. The final connection to the destination address is not encrypted. Tor is simply a routing protocol (It's onion routing which means there is multiple layers of encryption to hide the path from everyone) which hides the source address of a connection.

See this: https://www.torproject.org/about/overview.html.en

See that the last link is unencrypted:




Internet censorship is becoming a widespread reality now. If people want SSL/TLS for bitcoin, I suggest that people discuss this further and if anyone has a good solution for implementation, they could submit a BIP. Bitcoin-qt already uses OpenSSL so it can use OpenSSL for added TLS connections to the bitcoin protocol. Bitcoin can use self-signed certificates for establishing secure connections. Perhaps bitcoin could implement the PKI system (Certificate authorities for verifying "trusted" nodes) or some sort of decentralised web of trust system.


Incorrect. Your proposal depends on that transactions use an address system. They do not, they use a scripting system. Bitcoin addresses are just an abstraction on the script. There are many other types of transactions that you could have. Look at IP transactions for instance.

The output (when sending to IP) and input for redeeming the bitcoins:


Note: I do not like the terms "scriptPubKey" and "scriptSig", as it doesn't describe the exact nature of the script system.

No bitcoin address is used. The sender of the coins simply queries the IP to send to for a public key. This is used to make the transaction and then the owner of the public key simply provides the signature. IP transactions were never secure. IP connections were never encrypted and even if they were there was no identity validation so it was always going to be prone to man-in-the-middle attacks.


Which is worthless if you are making algorithms for a protocol you do not fully understand.

Also your distributed mining solution was flawed in that individual mining nodes cannot be trusted by the other nodes in the pool. Someone may wish to purposefully add bad transactions into the block.

One solution may be to have pool officials that carry out the policing of pools. The pool management can state that an individual miner needs to send xyz amount of bitcoins to a script hash (P2SH). Then the only way to redeem the bitcoins is for the miner and the pool officials to sign an input. The pool officials will allow the miner to redeem the bitcoins when the miner wishes to exit the pool. If the miner misbehaves then their bitcoins are lost forever as the pool will refuse to redeem the bitcoins back to the miner. Thus it is a way to make bad behaviour expensive but not impossible. See this for the scripts: