The swarm client proposal - Reminder: 15 BTC pledged so far, now worth 3255$!

[Etlase2]

There are ways.  Adding Nonce data to randomize size, interval, etc.  But you are also assuming that some one (a person) is sitting there sifting thru your packets. 

Uhh, I am not. This will certainly be automated. Nonce data won't accomplish anything, there is enough randomness to each tx or block to already cover that. The bitcoin patterns will be obvious to pattern-recognition, so the alternative is to pad with lots and lots of useless data. It is not a pleasant way out, but it is a possibility if there is legislative action to block bitcoin or whatever else.

[1714836852]

1714836852

[doobadoo]

Whatever the challenge i'm sure our wonderful dev team will be on it!  0.7 will include most awesomest support for Tor.  I personally disagree that our only defense should be simply to be able to click a button and route via tor.  Pattern recognition will require the nimrods trying to block it to write some specialized stuff to go after bitcoin.  right now you don't need much.  That why i say, if you can encrypt all the data and obfuscate the patterns a little you've just greatly enlarged the 'security task' for the opposition.  Its going to become a cat and mouse game, we should not get caught flat footed.

[Realpra]

You are pretty off topic, but hiding traffic and avoiding package detection has already been pretty much accomplished by TOR so there should be no reason to reinvent the wheel.

Additionally this would mostly be an issue with China, the other countries with firewalls are a few third rate nations hardly worth notice.

+ They won't catch on to BTC until like 5-10 years from now.

[notme]

You are pretty off topic, but hiding traffic and avoiding package detection has already been pretty much accomplished by TOR so there should be no reason to reinvent the wheel.

Additionally this would mostly be an issue with China, the other countries with firewalls are a few third rate nations hardly worth notice.

+ They won't catch on to BTC until like 5-10 years from now.

Hardly worth notice... Unless you happen to be born there.

[MatthewLM]

You are pretty off topic, but hiding traffic and avoiding package detection has already been pretty much accomplished by TOR so there should be no reason to reinvent the wheel.

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:

Additionally this would mostly be an issue with China, the other countries with firewalls are a few third rate nations hardly worth notice.

+ They won't catch on to BTC until like 5-10 years from now.

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.

Any transaction or script will ultimately affect two or more addresses (out/in)

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:

Code:

output: <public key> OP_CHECKSIG
input: <signature>

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.

I am usually pretty good at coming up with algorithms.

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:

Code:

output: OP_HASH160 <script hash> OP_EQUAL
input: <official 1 sig><official 2 sig><official 3 sig><official 4 sig><miner sig> {OP_5 <official 1 key><official 2 key><official 3 key><official 4 key><miner key> OP_5 OP_CHECKMULTISIG}

The problem is, this means individual miners will have to put up money for the length of time that they mine. This was just an idea, perhaps others have better ideas.

[Realpra]

Hardly worth notice... Unless you happen to be born there.

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

Tor hides your IP address, it does not hide unencrypted data. The final connection to the destination address is not encrypted.

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.

Bitcoin can use self-signed certificates for establishing secure connections.

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)

Incorrect. Your proposal depends on that transactions use an address system.

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.

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.

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.

[MatthewLM]

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

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.

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.

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).

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

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?

If you are sending to an IP you are sending FROM an address

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

[capsqrl]

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.

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.

[Realpra]

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

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.

Well okay then.

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?

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.

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

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.

[MatthewLM]

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.

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.".

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.

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.

[Realpra]

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.

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.

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.

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).

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.

A distributed validation system will always require trust in other nodes.

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

The key would be to try and ensure enough nodes are relied upon to prevent the risk of all the nodes being untrustworthy

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.

[MatthewLM]

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.

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.

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.

That's what I'm talking about.

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.

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).

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

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.

If the official client doesn't have PKC you could execute this attack right now

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.

[2112]

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 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.

[MatthewLM]

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.

[2112]

I definitely think TLS should be adopted so that PKI features can be used, if not now, in the future.

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.

[MatthewLM]

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?

[2112]

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?

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.

[Realpra]

The attacker can just generate their own public keys for each node you try to connect to.

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.

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.

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.

Well bitcoin actually requires trust.

I beg to differ.

A client that breaks protocol is simply ignored in bitcoin.

The rest is hard as nails cryptography.

Not so fast, you would need to intercept all the connections.

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)

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.

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

[notme]

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

[MatthewLM]

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.

But that is as I have been saying. Trusting any public key would not do, you would need to trust the particular public keys. i.e. You need to trade public keys with your brother in person. Not something you should expect ordinary people to do. This is where hard coded node keys, and maybe PKI comes in.

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

This is the sort of thing Merkle trees were used for. I'm sure you meant to say output. What is needed to validate a transaction is a previous output of another transaction.

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.

You can't spend inputs. The money "available to a bitcoin address" (Which is not a very accurate picture) is the unspent outputs that can be redeemed by the private key related to the address. You simply add up all the unspent transaction outputs that the private key can spend. Clients will form the balance by adding up all outputs spendable by the keys in the wallet. Simple stuff then really.

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 think you have a fundamental misunderstanding of the bitcoin protocol. Transaction inputs are not parts of a transaction that say "put xyz into this address" and outputs are not the opposite. Inputs link previous outputs to a transaction so you can spend those outputs. The outputs define who can spend the money next. The next people will need the correct inputs to spend those outputs and so on. It's all very simple. The money spendable by you, are all the unspent outputs that you recognise can be spent by you. You just need to provide the correct input (The usual case is a signature followed by a public key). The bitcoin client looks for standard transactions and finds the outputs that have any of your bitcoin addresses in them.

In the standard bitcoin address transactions the previous output script will be like:

Code:

OP_DUP OP_HASH160 <your address> OP_EQUALVERIFY OP_CHECKSIG

This output describes how to spend the bitcoins. All outputs have a value to them, so they apply to a certain amount of bitcoins.

This can be spent with the input script:

Code:

<your signature for the spend><your public key>

Inputs simply prove you can spend an output. Transactions are signed so that only you can spend money owned to you. The input is run first, pushing the signature and public key onto the stack:

Code:

stack: <your signature for the spend><your public key>

The output is run, to verify the public key is what the previous spender wanted in the output by comparing hashes. The signature is then checked to verify that the spender owns the public key and the transaction contents cannot be changed without invalidating the signature.

Code:

program pointer: OP_DUP OP_HASH160 <your address> OP_EQUALVERIFY OP_CHECKSIG
stack: <your signature for the spend><your public key>

Duplicate top stack item.

program pointer: OP_HASH160 <your address> OP_EQUALVERIFY OP_CHECKSIG
stack: <your signature for the spend><your public key><your public key>

Hash top stack item with SHA-256 and then RIPEMD-160

program pointer: <your address> OP_EQUALVERIFY OP_CHECKSIG
stack: <your signature for the spend><your public key><your address (hash of public key)>

Push <your address> onto stack.

program pointer: OP_EQUALVERIFY OP_CHECKSIG
stack: <your signature for the spend><your public key><your_address><your_address>

Verify that the top two stack items are equal. If not, exit with failure.

program pointer: OP_CHECKSIG
stack: <your signature for the spend><your public key>

Take off the top item from the stack as the public key and the next as the signature and check the signature for the public key. If OK, push OP_TRUE onto the stack, else push OP_FALSE.

program pointer: 
stack: OP_TRUE

The stack is left with true and had no failures, hence the input correctly spends the output.

I beg to differ.

A client that breaks protocol is simply ignored in bitcoin.

The rest is hard as nails cryptography.

Imagine that over 50% of the mining power is owned by people who are willing to collude to reverse transactions? Unlikely, but we trust that will not happen. A very easy thing to trust. And you need to trust your connection is safe. Saying bitcoin needs trust most of the time is quite pedantic.

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.

Not likely to happen though, is it?

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

My client will place trust in difficulty using the SPV model. The server will be used as a trusted node but also to offer special (and currently secret) bitcoin services.

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

So in other words, the security of the entire internet is doomed?... How does an attacker spoof a CA? They'd need the private keys of the CA....?