Topic: Probing for Community Interest (Read 2161 times)

And how would that work, how would you decide when a automated "landmark" is valid or not ? If you automate and decentralize the "landmark" creation you end up with same problem you started with.

If the attacker and manages to get 51% of the hashing power to setup his chain + his landmarks then what ? If he can't convince other peers he can still pretend by making sure he has 51% of nodes (network communication) as well. The result would fork the whole network and every new client would accept his longer chain ...

Web of Trust ? again you risk forking the chain between web's ...

"Landmarks" sound cool but unless there is a central authority managing them they don't solve anything.


I'm lazy, if you tell people to read at least add a link plz

Edit:
for other lazy people https://bitcointalksearch.org/topic/new-posproof-of-activity-proposal-127314

PoS ? Looks like a interesting and feasible option to me.

To get back on topic you would need to make sure every alt chain on the exchange is secured against double spend and atm I don't trust any of them. (Btc (maybe Ltc) is (are) the only one(s) that has (have) the hashing power to be semi secure.)

You should definitely read the updated PoS wiki. I think my proposed probabilistic system, an elaboration of Colbee's PoA, has very nice properties.
I need input from smart people. I may have made mistakes. Unless you point them out, I may not notice and fix them.

Even if I didn't make mistakes, I still need feedback so I can improve the exposition (I'm bad at that).

Having frequent, automated, temporal checkpoints leads to exactly the same chaos and vulnerabilities that made the blockchain needed in the first place.

Bitcoin has infrequent, hardcoded checkpoints - this works. Checkpoints based on PoS (as in my proof of stake system) might work. I haven't read up the probabilistic PoS discussion yet, but that could work too.

You know, perhaps I overlooked your idea too soon, if there were some way to make bitcoin and all the alt-coins automatically update and write in "landmark" blocks where everything that the chain has followed up to that mark is considered permanent no matter what alt-chain is introduced. It would need to be automatic though because the checkpoints would need to be frequent, maybe every 10-12 blocks. Maybe less for some coins.

I apologize for not considering your idea more deeply the first time around...

The wiki is simply wrong about this (I'll try to edit it sometime). No amount of confirmations is enough to prevent double-spending by someone with more than 50% of the hashrate. 6 confirmations is a completely arbitrary number considered secure enough against an attacker with "typical" hashrate (say, 10%).

The root problem is secret mining. Secret miners can replace the public chain with their own secret attack chain. A simple solution is to prohibit secret mining.

Here is a basic outline:
1) Miners search for tentative blocks. Tentative blocks must meet the PoW difficulty target.
2) The PoW solution in a tentative block maps to a sequence of 5 randomly selected satoshis. (i.e. just hash the solution five times and use these five hashes to select random satoshis)
3) Miners publish their tentative blocks and holders of the 5 random satoshis are invited to sign the blocks using their private key. (there are some omitted steps to minimize bandwidth requirements here)
4) If all 5 satoshi holders sign a tentative block, it becomes a valid block and enters the blockchain. (i.e. the only feasible way to get your block into the chain is by publishing it)
5) If not, the tentative block is ignored. Go back to (1). Some other tentative block will be found and enter the blockchain.

Now think about secret mining. Suppose I own 1% of all coins. In order to mine a block AND keep that secret, I need to find a PoW solution for which I own all five randomly selected satoshis.
The chances of a PoW solution satisfying this criteria is 1 in [1/(0.01)]^5 or 1 in 10 billion. Therefore, mining secret blocks requires 10 billion times the hashing power of mining public blocks.
With these rules, a small chain with say 1 cpu worth of hashing power protecting it (say 3 megahash) requires 30 Terahash of computing power to successfully attack. That is one single CPU would be a sufficient defense against an attacker controlling the entire bitcoin network. One GPU could defend against 100 bitcoin networks simultaneously.

[Another solution is PPCoin. It is nowhere near this robust, but it might be good enough.]

So what's the answer to the problem? 

At proof-of-stake. I wouldn't accept any plausible hash rate as adequately safe. Wait a few years and bitcoin will start getting ravaged too.

I appreciate the support!

I'm sure it will be complicated and I definitely won't be able to do it alone. I will definitely be looking for programmers and security experts if there becomes real enough interest in this concept that people are willing to contribute to bounties for the things we will need.

I would want to set the bounty purse(s) up with a trusted escrow and keep the whole operation completely transparent and if we can do so without compromising the site's security I would like to make it an open-source project as well.

I, like others, am very interested in such a thing should you be able to work out the kinks!

Good luck... it sounds quite complicated.

Hmmm, interesting but doesn't sound practical for the time-frames an exchange would need to work within. I think my strongest defense would be implementing IPSec, .htaccess and a few other tricks to prevent access from proxies and spoofed ip's so that I know exactly who is on my exchange at all times.

I may even manually review all registration forms and block dynamic ip's unless I can find a way to block dynamic ip's via software/hardware configuration.

It will detract from the spirit of anonymity in buying, selling and trading crypto-coins but the people trading there will be able to trust for the most part that if someone DOES "rob" the exchange they will be found, prosecuted and have their assets returned.

I see, that makes a lot of sense... I will have to put some thought into this, but I am confident that I can figure something out.

If there are quite a few nodes running, and they are running updated code that includes a checkpoint that happened since you got your coins, then possibly your coins might be reasonably safe as long as an attacker does not publish a different copy of the node code that contains a different set of checkpoints that feature their fork of the chain instead of the version of the chain in which you got your coins.

Consider for example an Open Transactions server that obtained a bunch of coins many many months ago, and several new versions of the client have come out since then, each one adding another checkpoint which favours the chain in which those coins were obtained.

To reverse those coins would involve going massively far back in time and would be refuted by the last several checkpoints that are already hard-coded into the current batch of nodes that are currently running.

Possibly in that circumstance the tokens the Open Transactions server is backing with those ancient well established coins can be considered to be fairly securely backed by actual coins. Such tokens could even in some ways be considered more secure than any recently mined actual coins.

Still though if a time ever came when there was no more demand/need for the tokens, so that it was time to liquidate, deleting the tokens and sending out the actual coins they represent, an attacker would at that point have an opportunity to try to mess up the actual transfer on the blockchain of those coins. So the liquidation could take a while, involving sending out the coins then waiting a few hardcoded checkpoints before regarding them as having been reasonably securely sent to their new owners.

This is basically why I try to release new versions of node software from time to time with new checkpoints coded in. I hope that over time doing so will eventually make it reasonable to consider the coins backing my tokens as actually fairly secure in their cold wallets so that the tokens are somewhat securely backed by actual coins.

-MarkM-

In theory, the threat of a 51% attack is always present.  At what hash rate would you guys consider the risk pretty well mitigated?  I know it depends on the coin, as they're slightly different.  But just looking for a ballpark number. 

Very nice summary. I particularly liked the part where you threw in opportunity cost, pointing out a vulnerability associated with merged mining.

Here is how an attacker with 51% or more of the hash rate can bankrupt your exchange. For this example I use i0coin:

1) Attacker starts mining a new blockchain fork, starting from the existing block.
2) Attacker deposits i0coin in your exchange.
3) Attackers fork of the chain in (1) does not include this deposit transaction.
4) Attacker sends the same coins as (2) to another address they own and this transaction is included in the blockchain fork in (1).
5) After the required number of confirmations attacker trades for bitcoins and withdraws the bitcoins.
6) When (1) is longer than the existing main chain attacker publishes their fork.
7) repeat from (1)

The result of (6) is that the exchange loses the i0coins due to the transaction no longer being valid. The transaction in (4) has replaced it. The exchange can't reverse the bitcoin withdrawal as the coins are already gone.

The exchange can't detect this offline mining. There's no way to know someone is building the blockchain fork in advance. The exchange can only notice the chain reorg after the fact. By that time all the coins are gone.

It doesn't matter how many confirmations you wait to confirm the deposit in (2). If the attacker has greater than 51% then eventually they will have a longer chain and can force a reorg. It doesn't matter if you process withdrawals manually. The attacker just waits until you've confirmed the btc withdraw and then publishes their fork.

The attacker can even re-use the i0coins they used in the attack to repeat the process since they still own them.

If the alt coin is able to be merge mined then there is no cost to the attacker. They essentially perform the attack for free since they are mining bitcoins at the same time. If it is not a merge mineable coin then the attacker has the opportunity cost of them not mining bitcoins. The amount taken from the exchange can compensate for this however.

In this attack note the attacker started mining the fork before they initiated the fraudulent deposit. This makes it much easier to reverse since they don't need to go back X blocks and mine from there - as the wiki entry you quote notes this could be computationally difficult. Although with >51% they'll eventually get there.

That is true, but keep the following in mind.

1) If they owned the coins at some point in the past, then they can reclaim them from you without your permission.
2) If you ever want to send the coins, you need their permission to do so. This permission could be quite costly to obtain.

Point (2) is kind of functionally equivalent to them stealing the coins directly. Your only recourse is to not give into blackmail and destroy the coins.

Not according to the wiki:


While this is from the Bitcoin wiki, the principles should still be pretty much the same seeing as how all the alt-coins are basically using Bitcoin's code for their underlying infrastructure just with variations on block rewards, re-target times, hashing algorithm, etc...

Unless there is something that I am simply not understanding which is entirely possible being that I've only known about Bitcoin and it's alt-coins for a little over 2 months now...

This holds if they have less than 51%. If they have 51%, your coins are their coins.

From the wiki on the subject of 51% attack: "The risk lessens of this with each confirmation as the computational advantage the attacker needs grows to a mathematically improbable level and six confirmations is widely accepted as being the amount where the transaction is secure from this attack."