My solution to that was to send the hash header of the un-verified branch.

So in your second example perhaps only H would be sent instead of the two lower Ts.

This means that my swarm client can derive the correct root from the transactions it DID get and the hashes of the branches it KNOWS it is skipping (also sent along with the transaction).

Not if you are not sending the entire tree.

If you cut off the maximum number of branches, except ONE transaction, the number of hashes you need to do to verify the transaction you ARE looking at indeed belongs in the block becomes the tree height - log2(n).

Yes, but validating the merkle tree is very easy even for a super light client.

Lets say I have block hash "H"->branch A and branch B.

The header of branch A is "A". There are two transactions in B; "B1" and "B2", THEIR hash is "B".

So my client would verify the transactions B1 and B2 and then check that the resulting B along with A gives H.

This tells my swarm client the following:
1. There are transactions I have NOT verified, but ONLY those in branch A.
2. I have verified everything in branch B.
3. What I have verified belongs to the block with hash H.

Now I don't know exactly how this works, but I am assuming that the branch tip headers of the merkle tree are transactions themselves* and all subsequent headers are derived from them up until the block header itself?

If so it would be impossible to hide a transaction because swarm clients watching a specific branch (say "the left one") would report the block as invalid if there was a branch header with no transaction as root.

(Remember that faking a hash is harder than the 51% by a million times at least)

* If I am wrong about this assumption then that is a massive security whole in the official client right there.

Yes, but if your computer device cannot do that, it cannot run even a light client:

If there is 100.000 transactions in ONE block, then that is ~17 hashes your light/swarm client needs to do with a binary tree. That would cut off everything, but one or a few transactions that could then be verified by a swarm client.

17 operations for verifying something quite close to VISA levels of activity!

Well if the BTC economy was like the real one MtGox would have been shut down and bitcoinica bailed out.

The utter lack of such ludicrous inefficiencies alone will help grow the real BTC economy.


Then there is the whole circle of "credit being printed by government -> banks -> government -> banks*2" disappearing and leading to the rise of real investments not in garbage bonds and gambling, but factories and renewable energy.

I don't think any of us get how huge an effect that would have on market efficiency - that vicious cycle has many times the fund flow used by the ENTIRE world on thorium, renewable and fusion energy research/deployment combined .


Yeah I think BTC will do just fine minus small local dips. On a 3-5 year time frame I don't think you will see bitcoin going down.

I was assuming that there was no attacker at first. That means the first public keys you got would not be fake ones from an attacker, but real ones the attacker would be unable to communicate by.

That would require vast computing power or your block would not be the longest chain and thus ignored.

Remember a block is only accepted if its hash fits the hash of the last block on the longest blockchain.

Unless you have 51% you can't do the attack you mention and even if you do have 51% people will soon start to block you out of the system if you keep reversing the chain or any BTC you hold will become worthless.

In my solution you would get one or a few branch roots while cutting the others. (search "pruning merkle tree")

This means you can tell that the transactions you verify indeed belong to the block hash even without having all the transactions of that block.

You cannot. For all you know your BTC client is the only one in the world doing any verification and by chance everyone else is honest.

The longest valid chain is what is being worked on.

You could theoretically do my solution, but without a reporting system; the invalid chain would loose more and more computing power as individual swarm clients got an invalid block branch.

The wasted computing power would lead to the development of a reporting system rather quickly though.

The normal client already splits up the transactions into branches and branch headers.

All you need to do to create a swarm client is to modify the code to ignore some of those branches while keeping the branch header(s) you need to re-create the block hash.

An individual swarm client will ignore the longest chain if it contains an invalid transaction and start to mine on a different chain (longest valid one).

Each invalid block will make more swarm clients break away (or ALL with a simple reporting system) and eventually the longest, but invalid, chain will become shorter again.

This will lead to a minimum of transaction reversals as all valid transactions will have been carried out on the new valid chain as well.

I am myself procrastinating somewhat

Not in person; I just have to ask someone online or otherwise what public key their client is running with and then putting it into my local clients "check always"-list.

I could also just make a list of all my first couple of peers while assuming they are honest - rather unlikely to get attacked RIGHT after installing BTC.

It could be entirely automatic completely safely.

You can pick my words if you want and be obtuse, but I DO understand how it works.

What I am trying to tell you is that if I sign that some outputs should be moved to your address, you cannot verify whether I have ALREADY done this with another address without keeping a record of all transactions in/out of an address.

A->ME
A->ME->B
A->ME->YOU
Merchandise->YOU->ME

That is the standard doublespend.

Only way for a verifying node to do its job in this instance is to have FULL knowledge about ME.

This is achieved in then normal client by storing A, B, ME, YOU and all others.

In my client it is achieved by storing the transactions pertaining perhaps just ME. THOSE transactions (like A->ME) would have been verified when they were added to the main blockchain.

That is not something I "trust" it is something that I can look up at blockchain.info or similar to check or even block by only accepting blocks from accepted IPs  while banning all others.

The real threat of a 50% attack is quite small even should it occur.

Indeed and its the only vulnerability anyone has been able to spot in my idea and then it was fixed with PKC - like the normal client should.

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.

Transaction fees are already ~2.5$/trans to the miners. That's already too high in my view.

And yes I am including the block reward as that IS essentially a fee all BTC holders pay to miners.

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.

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.

What surprised me the MOST is that ANYONE actually looked at "the official interest rates" and went by that.

Why would any sane investor do that?

"Well gollyjee this bank looks like it's about to go under, but I GUESS if these other guys say I should only get 0,00001% on my loans to them everything should be FINE!" - Only idiots

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.

You're crazy.

Inflation simply to avoid changing a soft-coded fee?

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.

Any transaction or script will ultimately affect two or more addresses (out/in). The swarm client would save any transaction data affecting an address it was watching including scripts.

Hence scripts might be saved by clients watching the sending address at first and at completion (escrow/mult sig style?) also the clients watching the receiving address.

Am I missing something even more exotic than that?

I am usually pretty good at coming up with algorithms.

I had a vague yet decently defined idea 6+ months ago and now everything is as envisioned in my bachelors project. That was pretty advanced too.


BTC is moved if a block containing the movement is accepted by most clients. This means that as long as the swarm clients can tell by ONE fraudulent tx that a block is false they can all reject the block.

The data proving a block is invalid can be propagated by the swarm client that watched the (empty) sending address by just sending the txs/block branches pertaining to that movement.

The only way to trick a swarm client would be to keep it isolated from the reports from all the other clients that already know it's a fake block.
However this can only be achieved by cutting said clients internet connection - which would also prevent any benefit from the "attack".

Since signed TXs and block hashes cannot be faked the swarm client could operate in a SEA of attackers just fine without double spend attacks occurring as long as just ONE attacker doesn't know what txs the other attackers don't want sent.

Once the swarm client has information about a tx you can't force it to forget it or "unsend" it. Specifically I am here talking about the tx that says you already spent your money.
Same here. Electrum and medium nodes should be just fine for the BTC economy for now.

I am in fact in the process of understanding BTC tech better, but for a different project.

If there are any specific points I will elaborate.

The basic idea is:
Each client only actively watches a few addresses while blindly accepting the others in the block.
This allows only parts of the block branches to be sent/stored while every client doing verification.

Each client would decide how many addresses to watch from one to all in the blockchain (as the normal client).
Security is maintained as clients A communicate via secure non-hijackable channels (PKC) and B clients can report invalid transactions so that the entire network drops a bad block.

Clients can request/send info on specific addresses to avoid sending entire blocks.


For now I suggest people use electrum or something.

No and it would not be enough by itself soon anyway due to bandwidth and CPU usage also rising.

You can search "swarm client" on this forum to find a possible solution to BTCs algorithmic problem.

Until that is developed I suggest using electrum or some online wallet for new users.

The article said that ANOTHER organization set up the new system/fund FOR them.

Even if they had it's their choice and not necessarily a bad investment given their lack of funds.

The thing to take away here is that BTC managed to give a pretty decent chunk... unless it was all moneygram of course...

Dollars and euros already have crypto/numeric representations (inside banks)... just slapping that label on a currency doesn't do much.

This right here.

Basically bitcoinica was a ponzi of sorts, now they have just plain run off with your money.

The lack of security is so vast the only explanation is that one, more or all of the operators just stole everything while using "hacks" as an excuse.


I would suggest filing police reports against everyone involved whose name is known. Bank fraud is bank fraud and with USD involved the police should AT LEAST inconvenience them with a few questions.

Even if it was a hack there might be such a thing as criminal negligence which could also give them trouble.

I liked the green one by psy better than the more asymmetrical yellow ones.