Bitcoin Forum
April 16, 2014, 04:13:41 AM *
News: ♦♦ A bug in OpenSSL, used by Bitcoin-Qt/Bitcoin Core, could allow your bitcoins to be stolen. Immediately updating Bitcoin Core to 0.9.1 is required in some cases, especially if you're using 0.9.0. Download. More info.
The same bug also affected the forum. Changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 [All]
  Print  
Author Topic: Proposal: Pre-emptive measures against 51% attacks  (Read 3721 times)
casascius
Mike Caldwell
VIP
Hero Member
*
Offline Offline

Activity: 1204


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW

Ignore
December 25, 2011, 07:35:08 AM
 #1

Was thinking a bit... about what would happen in the event of a 51% attack.

Imagine a 51% attack against Bitcoin that was begun in secret, to create a large alternate chain that simply reversed a very large number of blocks, and persistently prevented any transactions from confirming.  The chain would be published all at once as a surprise and would propagate across the network faster than any worm.

Even if many of us could deal with that, the news would say "BITCOIN HACKED", that would be the end of Bitcoin as we know it, at least for a short while, until we all scattered around and figured out what to do about it.  

The problem with a 51% attack done this way is its effects would be sudden and instant.  The repair would be several days while the developers figure out what to do, and several more while the bugs get fixed, and plenty more time while people download it, repair their block chains, backport the patch to their customized clients, get back in business... meanwhile, we'd have lots of angry miners whose mining work on the fake chain got reversed, etc...

I would like to propose a couple simple things now relating to checkpointing so that the solution is known and the disaster preventable all the way in advance.

Basically, what I am proposing is that a) trusted entities put signed checkpoints in the block chain - which are nothing more than assertions that "I have seen the block with hash x", and b) that the client have some sort of list of trusted public keys (modifiable by power users, but otherwise pre-seeded by client authors) so that trusted parties can be recognized but also removed if needed.

Signatures would appear periodically in blocks, which would be part of real or dummy transactions.  MtGox, for example, may occasionally initiate a transaction to itself (or embed in one of its payout transactions) a signature referencing the hash of a prior block, simply to say "I saw this".  MtGox need not sign every single block - since each signature acknowledges all blocks before it, there will be other signers participating, and the scheme is mainly targeted at attacks on 6+ blocks, the signatures could be done three or ten or any other reasonable number of blocks apart.

Mining pools would do the same except would likely use the coinbase transaction as the location for their signature.

Very simply - if I as a client have block X, which I know has been seen by MtGox, TradeHill, and a dozen mining pools and trusted parties... I can quickly and confidently reject block Y which purports to replace block X with a higher proof of work.

To implement this proposal, all that would need to happen is:
  • client gets a mini database to track trusted public keys, possibly kept in wallet.dat, but pre-seeded from hardcoded values in the client
  • client gets an RPC call to modify this database for power users
  • definition of "standard transaction" amended to include one that packs an OP_DROPped signature so that trusted parties can count on their stamps of approval being relayed
  • the logic for handling chain reorgs more than 3 blocks deep is revised such that blocks known to have been seen by a majority of the trusted crowd are impervious to being preempted by blocks that have not.

The vast majority of client users would be using the default list of trusted public keys and would be unlikely to modify it, so the onus would be on the authors of clients to appropriately judge who belongs to be on the list.  The idea of allowing the client author to update the list remotely isn't out of the question - a suggestion probably not appropriate for the reference client - but entirely plausible for smaller-time clients whose users could just quit using if the authors were up to shenanigans.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
1397621621
Hero Member
*
Offline Offline

Posts: 1397621621

View Profile Personal Message (Offline)

Ignore
1397621621
Reply with quote  #2

1397621621
Report to moderator
1397621621
Hero Member
*
Offline Offline

Posts: 1397621621

View Profile Personal Message (Offline)

Ignore
1397621621
Reply with quote  #2

1397621621
Report to moderator
1397621621
Hero Member
*
Offline Offline

Posts: 1397621621

View Profile Personal Message (Offline)

Ignore
1397621621
Reply with quote  #2

1397621621
Report to moderator
Remember that Bitcoin is still beta software. Don't put all of your money into BTC!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1397621621
Hero Member
*
Offline Offline

Posts: 1397621621

View Profile Personal Message (Offline)

Ignore
1397621621
Reply with quote  #2

1397621621
Report to moderator
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 413


View Profile

Ignore
December 25, 2011, 08:08:36 AM
 #2

Very simply - if I as a client have block X, which I know has been seen by MtGox, TradeHill, and a dozen mining pools and trusted parties... I can quickly and confidently reject block Y which purports to replace block X with a higher proof of work.
As long as the blocks contain adequate proof of work, they are all eligible to be accepted. It's not a beauty contest where the one with the highest proof of work wins. The reasoning works if we replace "block" with "blockchain" on the basis that longer blockchains are preferred.

Suppose the bitcoin network divides into two roughly equal portions in terms of hashing power and trusted parties but without any attack. Life goes on for a while at roughly half the block rate and with half the trusted signatures missing. When the network reconnects what happens to the losing chain and the trusted parties' signatures of the losing chain's block hashes?

ByteCoin
casascius
Mike Caldwell
VIP
Hero Member
*
Offline Offline

Activity: 1204


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW

Ignore
December 25, 2011, 09:46:48 AM
 #3

The signatures only mean "I saw block X".  If block X is unknown or ends up being rejected, the signature then means nothing. the signature doesn't sign the block it is in, it simply acknowledges receipt of some other (earlier) block and is still a valid transaction in any block it gets put in.

In the event of a bona fide net split, where exactly half the trusted parties get separated from the other half, neither chain will meet the threshold of having a sufficient majority if the threshold is set any higher than half - so the longest proof of work would win as it does now.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
iddo
Sr. Member
****
Offline Offline

Activity: 343


View Profile

Ignore
December 25, 2011, 11:08:45 AM
 #4

So if those few "trusted parties" are malicious then they can carry out a double-spending attack even though they have a tiny proportion of the total hash power, by preparing their own fork and signing it? I think that this is a bad idea, both in a technical sense, and from a PR standpoint.

For example it could take those malicious parties one day to prepare a secret fork of 6 blocks, while the rest of the network generated 144 blocks during that time, and still the malicious fork of 6 blocks will win?

You didn't describe which threshold of trusted parties would be needed? If all the parties are required then a single malicious party could cancel the entire scheme, and if a majority of the trusted party is required then a malicous majority can double-spend, etc.

And equating mining pools with trusted parties is a step in the wrong direction imho, it would be better to think of ways to enhance security of the overall bitcoin network by decentralizing the power of mining pools, rather than giving them more power. This was discussed at https://bitcointalk.org/index.php?topic=9137.0 , as well as p2pool, and there's also the idea of preventing mining pools at protocol level by requiring that if you have (privkey,pubkey)=(sk,pk) and block reward address corresponds to pk then you try to generate the block by: hash(txns,nonce,sign_sk(txns,nonce))

Edit: on a more basic level, if we officially condone having an easily modifiable list of trusted nodes as being a correct behavior of honest clients, then in the scenario where the mining power is truly decentralized it means that it becomes easier to have clients who don't follow the same rules, i.e. more possibilities for forking the chain.
casascius
Mike Caldwell
VIP
Hero Member
*
Offline Offline

Activity: 1204


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW

Ignore
December 26, 2011, 05:02:00 AM
 #5

So if those few "trusted parties" are malicious then they can carry out a double-spending attack even though they have a tiny proportion of the total hash power, by preparing their own fork and signing it? I think that this is a bad idea, both in a technical sense, and from a PR standpoint.

Most of those trusted parties aren't mining, so they wouldn't really have the means to carry out the attack.  Remember, they'd already have to have 51% of the mining power, and in my proposal, they'd have to have 51% of the "trust" (however that is allocated).  This ups the ante even more.  A lot of other trusted people simply won't sign a new chain of replacement blocks that just show up out of nowhere, as a matter of policy.

Someone with a policy of "I sign the first thing I see right away as I see it, and I am trusted only so long as I continue to do so" will have self-prohibited himself from signing an alternate chain that replaces blocks, because by doing so he would have met the conditions to delete himself as a trusted person.  Decentralization doesn't mean "trust nobody"...could you see MtGox or Gavin trying to do a double spending attack?

For example it could take those malicious parties one day to prepare a secret fork of 6 blocks, while the rest of the network generated 144 blocks during that time, and still the malicious fork of 6 blocks will win?

I expect there should be far more trusted parties than to make this feasible.  But let's suppose that happened.  We would know exactly who those parties were, we'd dump them from the trust list, and then they would never have a second opportunity.  Sure, Bitcoin might get some bad press, but it would also prove that the contingency plan worked.  They wouldn't gain anything in the process.

You didn't describe which threshold of trusted parties would be needed? If all the parties are required then a single malicious party could cancel the entire scheme, and if a majority of the trusted party is required then a malicous majority can double-spend, etc.

I left it vague on purpose.  A majority, sure.  But remember there's more factors that a client can use to weigh two competing chains of blocks - Gavin enumerated a few on another thread.  A flexible algorithm would be desirable over a hard and fast rule.  If I have chain A and chain B competing with one another, and chain B is longer, doesn't contain any double spends against A, and contains everything from chain A, I (as an algorithm) probably should just consider choosing chain B without worrying much about majorities.  On the other hand, if 6 blocks come along and purport to be better than 144 they want to replace, they may merit needing a much higher percentage of the trust than even 51% to be acceptable.

And equating mining pools with trusted parties is a step in the wrong direction imho, it would be better to think of ways to enhance security of the overall bitcoin network by decentralizing the power of mining pools, rather than giving them more power. This was discussed at https://bitcointalk.org/index.php?topic=9137.0 , as well as p2pool, and there's also the idea of preventing mining pools at protocol level by requiring that if you have (privkey,pubkey)=(sk,pk) and block reward address corresponds to pk then you try to generate the block by: hash(txns,nonce,sign_sk(txns,nonce))

Trust doesn't mean a block is assumed valid just because it was signed by someone special (unlike SSL for example, which does work this way, much to our demise).  In this sense, a signature only means "I saw this block".  I as a client should prefer a chain that I know has been seen by a lot of stakeholders, over one that has been seen by none.  Having mining pools sign blocks helps everyone confirm that the mining pools are still in contact with one another and that there isn't a "net split".


Edit: on a more basic level, if we officially condone having an easily modifiable list of trusted nodes as being a correct behavior of honest clients, then in the scenario where the mining power is truly decentralized it means that it becomes easier to have clients who don't follow the same rules, i.e. more possibilities for forking the chain.

I don't see how it follows.  This proposal doesn't create forks, it simply provides an element of human control over how to deal with forks if and when they happen.  They have to happen first on their own, either deliberately as part of an attack, or unintentionally if there are disconnects in the network.


Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
fastandfurious
Full Member
***
Offline Offline

Activity: 224


View Profile

Ignore
March 18, 2012, 09:52:14 AM
 #6

Was thinking a bit... about what would happen in the event of a 51% attack.

Imagine a 51% attack against Bitcoin that was begun in secret, to create a large alternate chain that simply reversed a very large number of blocks, and persistently prevented any transactions from confirming.  The chain would be published all at once as a surprise and would propagate across the network faster than any worm.

Even if many of us could deal with that, the news would say "BITCOIN HACKED", that would be the end of Bitcoin as we know it, at least for a short while, until we all scattered around and figured out what to do about it.  

The problem with a 51% attack done this way is its effects would be sudden and instant.  The repair would be several days while the developers figure out what to do, and several more while the bugs get fixed, and plenty more time while people download it, repair their block chains, backport the patch to their customized clients, get back in business... meanwhile, we'd have lots of angry miners whose mining work on the fake chain got reversed, etc...

I would like to propose a couple simple things now relating to checkpointing so that the solution is known and the disaster preventable all the way in advance.

Basically, what I am proposing is that a) trusted entities put signed checkpoints in the block chain - which are nothing more than assertions that "I have seen the block with hash x", and b) that the client have some sort of list of trusted public keys (modifiable by power users, but otherwise pre-seeded by client authors) so that trusted parties can be recognized but also removed if needed.

Signatures would appear periodically in blocks, which would be part of real or dummy transactions.  MtGox, for example, may occasionally initiate a transaction to itself (or embed in one of its payout transactions) a signature referencing the hash of a prior block, simply to say "I saw this".  MtGox need not sign every single block - since each signature acknowledges all blocks before it, there will be other signers participating, and the scheme is mainly targeted at attacks on 6+ blocks, the signatures could be done three or ten or any other reasonable number of blocks apart.

Mining pools would do the same except would likely use the coinbase transaction as the location for their signature.

Very simply - if I as a client have block X, which I know has been seen by MtGox, TradeHill, and a dozen mining pools and trusted parties... I can quickly and confidently reject block Y which purports to replace block X with a higher proof of work.

To implement this proposal, all that would need to happen is:
  • client gets a mini database to track trusted public keys, possibly kept in wallet.dat, but pre-seeded from hardcoded values in the client
  • client gets an RPC call to modify this database for power users
  • definition of "standard transaction" amended to include one that packs an OP_DROPped signature so that trusted parties can count on their stamps of approval being relayed
  • the logic for handling chain reorgs more than 3 blocks deep is revised such that blocks known to have been seen by a majority of the trusted crowd are impervious to being preempted by blocks that have not.

The vast majority of client users would be using the default list of trusted public keys and would be unlikely to modify it, so the onus would be on the authors of clients to appropriately judge who belongs to be on the list.  The idea of allowing the client author to update the list remotely isn't out of the question - a suggestion probably not appropriate for the reference client - but entirely plausible for smaller-time clients whose users could just quit using if the authors were up to shenanigans.

Casascius, I really don't think people understand how important it is to understand what your proposal is saying. For me when thinking about it, it says exactly what will be the doom of Bitcoin it this in some way wont get implemented in the future.

I am sure that your proposal of checkpoints of trusted entities is pretty much unnecessary when the total market cap of Bitcoin is $100M or even as much as $1 Billion, but the question is what this does if and when the market cap is nearing $10 Billion? Bitcoin is going head to head against central banks, politicians, all fiat money and the status quo of everything that the average joe knows and accepts about rules of finance and economics in the world. When something like Bitcoin comes in and changes this, trust me, let me repeal that, TRUST ME the establishment will do anything to prevent Bitcoin to get to higher adoption. And one way of doing this is a 51 % attack, it is very effective and for them probably not that expensive way of destroying the hole Bitcoin project.

Just some thoughts. The trusted entities that you choose is probably good ones, but I think they are very few in number. Maybe it should be as much as 349 trusted entities /persons (we have to see BTC as a global phenomenon and because of that 349 or even more trusted entities are necessary) and there should be a voting system that chooses these persons, like once every year or two like a parliament. Everyone should have the opportunity to get elected, and the election can take place on the Bitcoin.org site. You vote with your BTC, Every BTC in the wallet that it is sent from is one vote, and you send one satoshi as a way of showing the person/entities you want to vote for. All entities tells the Bitcoin community who they are and what they stand for.

Also one more big point is that this checkpoints of this trusted entities is not something that is hard coded in the client, the way it works right now will be enough with hard coding with every new client the development team releases, BUT when and if there is a 51 % attack then we should have this emergency checkpoint system come in in to work and only then when there is a 51 % attack that he Bitcoin community didn't know about and recognize as a 51 % attack this parliament will get activated and the checkpoints of this parliament will be the ones that will get hard coded in to the client. This is a way of telling any government that any attack will not get Bitcoin on the knees.

Any thoughts?  
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
March 18, 2012, 10:09:12 AM
 #7

Trusted parties should be people who have an ownership stake in the system. If you want to identify who truly wants bitcoin to succeed, ask who is willing to bet money on its success. The trustworthy people will plunk their money down. Proof-of-stake. Ownership and control in the same hands, not separated. It's that simple. Anything else can and will be gamed.

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 18, 2012, 10:53:48 AM
 #8

Having the pools include a signture within the blocks they produce is a very good starting point.

It dosn't harm the network in any-way... However makes the post 51% attack 'cleanup' much easier.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 18, 2012, 12:05:31 PM
 #9

This has been a problem that has been on the back of my mind for a very long time also.

The core component is that this will provide a 2nd line of security against attacks based upon a web-of-trust style of security model, rather than the absolute ‘who hashes the most’ security model.

From the start-out the web-of-trust and computational problem security models have different ‘qualities of truth statements.’
The quality of the security that a cryptographic problem provides is a provable solution, which is non-relative.  All parties in the system will come to the same exact solution.  It can be summarised as the quality statement:  “This is absolutely true for everyone”
In legal terms it may be said as:  “This is true without any doubt”
This can be dramatically contrasted with the quality of the security that a web-of-trust provides.  A web-of-trust gives a relative prospective for the solution.   Each party may or may not come to the exact same conclusion, based upon whom they trust.  It can be summarised as: “This is good enough for me”
In legal terms it may be said as:  “This is true enough for my purposes”

Now…  Having such a strong truth statement comes at a much higher cost that a ‘less rigorous’ truth statement.   The cost in the case for bitcoin is that there is no ‘human’ element in deciding what chain is valid or not…. Instead it is entirely left up to ‘whoever can gather the most hashing power.’
Economically, such a high level of truth statement is affordable to protect bitcoin against internal attacks, (people within the bitcoin community).  Namely those whom want to seal through double spending bitcoins.
However, the economics doesn’t provide any natural protection against an externally motivated attacker.  The attacker whom gains the finance through taxation, or the protection of established systems that bitcoin competes with.

Much higher levels of security can be gained far more cheaply by lowering the required truth statement.
Think?  Is the precise order of the transactions important; if the network is being attacked by an attacker who stops all the transactions?Huh

This is where casascius gets his idea of a ‘trust’ based system to protect against the 51% attack…  It is more important that we gain an “Extremely High” level of security against a motivated 51% attack, than maintain our “Extremely Strong” level of truth statement.

PS.  For a long time, I have been conceptually designing a ‘web-of-trust’ coin… However I’ve never came up with a good way to ‘issue’ the new coins… However It could work as a low-cost security backend for a pre-allocated *coin.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 18, 2012, 12:13:22 PM
 #10

My proposal:

1.   Miners release signatures of their blocks by-default.  If they want to remain anon, either don’t release one… or use a new identity for every block.
2.   Bitcoin will display a warning if the current chain contains a very unexpectedly long time without any blocks from its ‘favourite’ miners.
3.   Bitcoin also displays warning when ‘favourite miner’ blocks consistently get orphaned.
4.   Upon detecting an active alternative fork, that contains many blocks made by the nodes ‘favourite’ miners, an option will be given to the user to move to the forked chain.


Edit:  By ‘Favourite’ I mean, whoever the developer of the particular client decides are trusted.
The user should be provided with a clear and simple way to change the ‘default’ favourite miners.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
CIYAM
Hero Member
*****
Online Online

Activity: 896


Ian Knowles - CIYAM Lead Developer


View Profile WWW

Ignore
March 18, 2012, 12:17:10 PM
 #11

I'm not sure if anything like this is feasible or not but is there perhaps a way that some sort of voting by standard clients (rather than miners) could be used in order to decide about checkpoints (perhaps by unique IP addresses)?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 18, 2012, 12:25:46 PM
 #12

I'm not sure if anything like this is feasible or not but is there perhaps a way that some sort of voting by standard clients (rather than miners) could be used in order to decide about checkpoints (perhaps by unique IP addresses)?

A web-of-trust based system will never work without two main features:

1.   Active Human Thinking Trusted Parties.
2.   Cryptographically Secure Announcement of Trust Relationships

You cannot have a secure web-of-trust without active human maintenance… figuratively you are trading computational security through the proof-of-work.  With trust gained by human interactions.

AKA... You cannot have your cake and eat it.

Edit: I suggest that using Unique IP address would be a poor security model against a motivated 51% attack.  As it would tend to lead to many different solutions, as the attacker would also flood the network with malicious nodes.  (Remember that a 51% attacker must be externally motivated to the bitcoin network)… Therefor it is likely that the attacker would have many times the financial resources disposable than the entire bitcoin network can use to defend against it.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 18, 2012, 12:52:16 PM
 #13

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 18, 2012, 12:56:16 PM
 #14

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?


Nothing... the attacker will just use bounces, many IP addresses, connect to different nodes block, or mines over TOR.  The latency for release of the attacking chain that has been mined with 51% hashing power isn't important in the long run.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 18, 2012, 01:03:21 PM
 #15

What if they couldn't change their IP, would that rule solve the problem?

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 18, 2012, 01:14:27 PM
 #16

What if they couldn't change their IP, would that rule solve the problem?

I think you have a large misunderstanding on how bitcoin operates.  How would you enforce this, when you want the network to remain opon for new miners?

2nd IP addresses are very very poor at identifying a node. IP black lists will never work.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
March 18, 2012, 01:21:52 PM
 #17

I'm not sure if anything like this is feasible or not but is there perhaps a way that some sort of voting by standard clients (rather than miners) could be used in order to decide about checkpoints (perhaps by unique IP addresses)?

A web-of-trust based system will never work without two main features:

1.   Active Human Thinking Trusted Parties.
2.   Cryptographically Secure Announcement of Trust Relationships

You cannot have a secure web-of-trust without active human maintenance… figuratively you are trading computational security through the proof-of-work.  With trust gained by human interactions.

AKA... You cannot have your cake and eat it.

Edit: I suggest that using Unique IP address would be a poor security model against a motivated 51% attack.  As it would tend to lead to many different solutions, as the attacker would also flood the network with malicious nodes.  (Remember that a 51% attacker must be externally motivated to the bitcoin network)… Therefor it is likely that the attacker would have many times the financial resources disposable than the entire bitcoin network can use to defend against it.
A human coalition of trust is a good idea. However, it must also be able to recognise when a friendly ally comes online with additional hashing power that is enough to offset the 51% attack. OTOH how would you know if there even was an attack until after the damage was done? You wouldn't be able to just roll back the transactions. It might be best to stop worrying about it and let Bitcoin trust the competetive nature of man to maintain a balance of power.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 18, 2012, 01:28:25 PM
 #18

If there is a way to recognize blocks by their owners and we can determine that a certain owners is finding a lot of blocks, we can simply put in place a rule that once you find a certain amount of blocks out of all the blocks found in a certain time period you get a forced break from getting your blocks accepted by the rest.

The blockchain exists as a copy in every single client. Meaning that because of our decentralization, just because someone has over 51% of hashing power, there's nothing that forces the 49% to accept their blocks into their copy of the blockchain, they do it voluntarily.

What I'm suggesting is to solve this problem with ostracism. Simply ignore blocks found by someone having too much hashing power. Yes, this would create a fork, but the owner of the over 51% of hashing power will find himself all alone in his fork while the rest of us carry on as if nothing happened.

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
TT
Member
**
Offline Offline

Activity: 77



View Profile

Ignore
March 18, 2012, 02:15:26 PM
 #19

If it is possible for any single player to manage to amass that much computing power relative to the rest of the network, it seems to me that the whole proof-of-work concept is invalidated, fundamentally. We're just back to human webs of trust relations. Those who then claim that bitcoin has been hacked would be right to do so...and perhaps it would be best to abandon the block chain concept altogether.

Having said that, I believe it is possible to modify the proof-of-work algorithm to make it less likely to favor people with a particular type of specialized hardware.
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
March 18, 2012, 02:40:15 PM
 #20

If it is possible for any single player to manage to amass that much computing power relative to the rest of the network, it seems to me that the whole proof-of-work concept is invalidated, fundamentally. We're just back to human webs of trust relations. Those who then claim that bitcoin has been hacked would be right to do so...and perhaps it would be best to abandon the block chain concept altogether.

Having said that, I believe it is possible to modify the proof-of-work algorithm to make it less likely to favor people with a particular type of specialized hardware.

Umm yes, proof-of-work might lose all credibility, but there would still be proof-of-stake standing untarnished. No need to get rid of blockchains altogether, that is throwing the baby out with the bath water.

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
March 18, 2012, 03:43:31 PM
 #21

If it is possible for any single player to manage to amass that much computing power relative to the rest of the network, it seems to me that the whole proof-of-work concept is invalidated, fundamentally. We're just back to human webs of trust relations. Those who then claim that bitcoin has been hacked would be right to do so...and perhaps it would be best to abandon the block chain concept altogether.

Having said that, I believe it is possible to modify the proof-of-work algorithm to make it less likely to favor people with a particular type of specialized hardware.

Huh? You make it sound so easy. I suppose that just because The USA got the most medals in the last Olympics that we should just stop having them. Oh, and because the USA has enough nuclear bombs to blow up the world, everyone else should stop building nuclear weapons. Are you afraid of a little competition?

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
TT
Member
**
Offline Offline

Activity: 77



View Profile

Ignore
March 18, 2012, 03:45:26 PM
 #22

cunicula, you're right. I should clarify.

I didn't mean to say that the concept of a public transaction history with a trusted timestamp mechanism should be tossed away. I just meant that proof-of-work as the mechanism for establishing trust would be rendered effectively useless.

You could still have a mechanism based on web-of-trust and reputation.
TT
Member
**
Offline Offline

Activity: 77



View Profile

Ignore
March 18, 2012, 03:49:43 PM
 #23

Quote
Huh? You make it sound so easy. I suppose that just because The USA got the most medals in the last Olympics that we should just stop having them. Oh, and because the USA has enough nuclear bombs to blow up the world, everyone else should stop building nuclear weapons. Are you afraid of a little competition?

No, but thanks for throwing in a nice strawman.

I'm suggesting something along the lines of what people like Dan Kaminsky have suggested: that it would be possible to have proof-of-work that cannot be massively accelerated with GPUs or ASICs...but that has high memory and serialization dependencies or other resource requirements, too.

http://www.slideshare.net/dakami/bitcoin-8776098
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
March 18, 2012, 03:59:26 PM
 #24

cunicula, you're right. I should clarify.

I didn't mean to say that the concept of a public transaction history with a trusted timestamp mechanism should be tossed away. I just meant that proof-of-work as the mechanism for establishing trust would be rendered effectively useless.

You could still have a mechanism based on web-of-trust and reputation.
I agree that a web-of-trust and reputation is a solid mechanism for organizing exchange and decision-making, but I made a different point than this...

Another time tested mechanism is to allow voting based on proof-of-ownership. That is how corporations work. They seem to do all right in terms of serving the interests of their shareholders.
I am recommending that bitcoin or an altchain work in the same way. I describe how this voting mechanism could be used to organize a blockchain in the proof-of-stake wiki.

https://en.bitcoin.it/wiki/Proof_of_Stake

You should consider checking it out. It is a really simple design.

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
TT
Member
**
Offline Offline

Activity: 77



View Profile

Ignore
March 18, 2012, 04:06:25 PM
 #25

Quote
You seem to have missed the first part of my statement. You might consider checking out the proof-of-stake wiki.

https://en.bitcoin.it/wiki/Proof_of_Stake

Ah, interesting. Yes, you're right...I apologize. I'll take a look at this idea.
Gavin Andresen
Hero Member
*****
qt
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
March 18, 2012, 04:12:07 PM
 #26

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
March 18, 2012, 04:40:05 PM
 #27

cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  

Haha. I'm an academic economist. I can't code anything beyond 'Matlab code'. Thus, I hope you can understand why I must be all talk and no do.
Someone else has to take my idea and run with it, or it will never happen.

Of course, I'm happy to help in anyway I can, but my help is intrinsically limited.

If you're looking for something that is basically bitcoin compatible and someone who can make it happen, Meni might be the appropriate person to encourage.

My idea is fundamentally incompatible with the current bitcoin reward system. It has to exist as either a hard fork or an altchain.

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
March 18, 2012, 04:48:03 PM
 #28

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.
This. Math gives us tools to create complex and useful games, but there is no Unified Theory of Finance. Managing the integrity of the blockchain will require whatever-works-at-the-time schemes to check and balance real world complications. Multiple schemes in combination and moderation can be used to adapt the Bitcoin Network if there is a sudden threat to the balance of power. The important thing is that the network propogates fluidly and globally.

Quote
Huh? You make it sound so easy. I suppose that just because The USA got the most medals in the last Olympics that we should just stop having them. Oh, and because the USA has enough nuclear bombs to blow up the world, everyone else should stop building nuclear weapons. Are you afraid of a little competition?

No, but thanks for throwing in a nice strawman.

I'm suggesting something along the lines of what people like Dan Kaminsky have suggested: that it would be possible to have proof-of-work that cannot be massively accelerated with GPUs or ASICs...but that has high memory and serialization dependencies or other resource requirements, too.

http://www.slideshare.net/dakami/bitcoin-8776098
My point is that I'm really not afraid of a massive 51% attack because having such a weapon doesn't justify actually using it. It is more likely that someone will have the means of stopping the attack and restoring the game back to a healthy competition. Inventing new technologies that take extreme advantage of anything are the hardest secrets to keep.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
markm
Hero Member
*****
Offline Offline

Activity: 1148



View Profile WWW

Ignore
March 18, 2012, 05:18:55 PM
 #29

My idea is fundamentally incompatible with the current bitcoin reward system. It has to exist as either a hard fork or an altchain.

I was thinking an alt chain would be a good place to implement proof of stake, but a hard fork would be interesting since I already have stake in the current block chain.

Maybe you should start a bounty, as that seems to be an effective way to get your ideas coded (several mining projects have been completed in this fashion). Like minded individuals would be able to contribute as well. It would certainly be a giant step towards "do" instead of only "talk".

You mean, like, maybe if he himself had a stake in it people might take the idea more seriously? By his theories that might make sense, afterall if he has no stake maybe he is just gaming us?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
casascius
Mike Caldwell
VIP
Hero Member
*
Offline Offline

Activity: 1204


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW

Ignore
March 18, 2012, 06:39:21 PM
 #30

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

If you did something like this, my pet preferred default setting for the majority would be to just auto-checkpoint anything 6 blocks deep as long as the client believes it has had a good streak of good connectivity (e.g. it has been online for at least 24 hours and has received blocks at a rate consistent with their expected creation rate).  And for the client to simply shut down if it receives an attempt to rewrite more than 6 blocks - that is, a shutdown until it is issued an explicit checkpoint command to lock in what the user believes is the correct block chain.

A GUI interface to respond to the shutdown could offer the user two options: 1) a "phone home" option that allows the user to explicitly trust the dev team on a one-time basis to resolve the conflict (it would hit a predetermined URL and look for a signed message), or 2) a textbox in which the user can paste the RPC command supporting the view of his choice (which presumably would be clipped from a forum or whatever news source the user trusts) or a URL leading to a message containing the same.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
March 18, 2012, 08:03:25 PM
 #31

My idea is fundamentally incompatible with the current bitcoin reward system. It has to exist as either a hard fork or an altchain.

I was thinking an alt chain would be a good place to implement proof of stake, but a hard fork would be interesting since I already have stake in the current block chain.

Maybe you should start a bounty, as that seems to be an effective way to get your ideas coded (several mining projects have been completed in this fashion). Like minded individuals would be able to contribute as well. It would certainly be a giant step towards "do" instead of only "talk".

You mean, like, maybe if he himself had a stake in it people might take the idea more seriously? By his theories that might make sense, afterall if he has no stake maybe he is just gaming us?

-MarkM-


I would think that if a true PoS was viable, then a VC would have created and monopolized it already. They might call it Google Cash or something like that.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Steve
Hero Member
*****
Offline Offline

Activity: 840



View Profile WWW

Ignore
March 19, 2012, 01:09:25 AM
 #32

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

If you did something like this, my pet preferred default setting for the majority would be to just auto-checkpoint anything 6 blocks deep as long as the client believes it has had a good streak of good connectivity (e.g. it has been online for at least 24 hours and has received blocks at a rate consistent with their expected creation rate).  And for the client to simply shut down if it receives an attempt to rewrite more than 6 blocks - that is, a shutdown until it is issued an explicit checkpoint command to lock in what the user believes is the correct block chain.

A GUI interface to respond to the shutdown could offer the user two options: 1) a "phone home" option that allows the user to explicitly trust the dev team on a one-time basis to resolve the conflict (it would hit a predetermined URL and look for a signed message), or 2) a textbox in which the user can paste the RPC command supporting the view of his choice (which presumably would be clipped from a forum or whatever news source the user trusts) or a URL leading to a message containing the same.
+1

I suggested the same a while back…basically, stated another way, you don't allow reorgs deeper than 6 blocks.  I think plenty of testing would be in order before making such a change, but it seems like a good solution on the surface.  Such a change would force any would-be attackers out into the open with their hashing power.  And 6 seems like plenty of time to allow miners to get their blocks distributed.  Any subnets cutoff from the main network would have to operate under an assumption that a) their blocks may be invalidated and b) they may have to take manual action to rejoin the main network.  The subnet could continue to mine to ensure the integrity of their own transactions while separated from the main net, but they would have to expect that their block rewards may eventually be rendered invalid.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
jago25_98
Hero Member
*****
Offline Offline

Activity: 850


http://moneybutnofixedabode.blogspot.com


View Profile WWW

Ignore
March 19, 2012, 02:15:55 AM
 #33

I think it would be easier to disrupt development

This hasn´t happened so I think bitcoin has the nod to continue from the man

Explaination of Gox mess up here. They are running custom wallets and a bug allowed double payments: http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac
casascius
Mike Caldwell
VIP
Hero Member
*
Offline Offline

Activity: 1204


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW

Ignore
March 19, 2012, 03:41:34 AM
 #34

Any subnets cutoff from the main network would have to operate under an assumption that a) their blocks may be invalidated and b) they may have to take manual action to rejoin the main network.  The subnet could continue to mine to ensure the integrity of their own transactions while separated from the main net, but they would have to expect that their block rewards may eventually be rendered invalid.

If the 6 block auto-checkpoint were contingent on being connected for 24 hours with a normal incoming stream of blocks at a normal-looking rate, someone separated from the main net would be spared the need to do anything manually to rejoin.  This would be because while they were separated, there would be a big gap between the difficulty and the rate they were seeing blocks, and this would disable their checkpointing.

Above all, it would make us look much better to the media: "Bitcoin Attacked, Contingency Plan Activated, Disruption Minimal, Just Click Button" versus "Bitcoin Hacked, Nobody Saw It Coming, Developers Racing Around Clock, (Untested) Patch Expected Soon, Maybe Bitcoin Was A Bad Idea From the Beginning After All"

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 19, 2012, 04:18:13 AM
 #35

The problem with proof-of-stake is:

1.   As proposed require a fundamental change in how bitcoin operates.
2.   The security of Bitcoin should be up to those who 'trade' bitcoin, not those who own lots of it... Holding bitcoin is always going to be safe, even under a 51% attack.  The problem lies with trading it.
3.   Why not publicly signing something saying that you own a particular bitcoin address that holds many bitcoins is not enough of evidence that you own bitcoin?

The key point should be that we build the infrastructure that doesn’t change how bitcoin works, that allows us to respond much more effectively to a 51% attack.

The two key things to do are:

1.   A standard way to produce cryptographic signatures showing who made the block.

This will allow website such as blockchain.info to check tell whom is the owner of the block in a much more secure way than just looking at the coin-bases and the IP address that the block was announced from.

2.   The hooks for user-defined checkpoint, so this later on can be used by the user to choose a chain based on any criteria they wish.

Both of these things do-not change how bitcoin operates at all (possibly the mining signature within the block will need some modification to the block format… however I’m not an expert in _how_ one would make cryptographically secure block-signatures, however, I do believe that it is useful and doesn’t change the fundamentals of bitcoin).

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
March 19, 2012, 04:24:11 AM
 #36

The problem with proof-of-stake is:

1.   As proposed require a fundamental change in how bitcoin operates.


This is true, but that can be applies to any disruptive technological improvement. If we want to make the world a better place, then we have to be willing to change how it operates.

2.   The security of Bitcoin should be up to those who 'trade' bitcoin, not those who own lots of it... Holding bitcoin is always going to be safe, even under a 51% attack.  The problem lies with trading it.

I'll leave this one as an exercise for the reader.

3.   Why not publicly signing something saying that you own a particular bitcoin address that holds many bitcoins is not enough of evidence that you own bitcoin?

Once you make proof-of-stake the main determinant of blockchain validity, then what is proof-of-work for? True, it taxes the user base to transfer money to AMD/FGPA/ASICs manufacturers and oil companies. I wasn't aware that this was a key objective or source of competitive advantage. Is there some other goal besides this that I haven't cottoned on to?

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 19, 2012, 04:44:35 AM
 #37

If it is possible for any single player to manage to amass that much computing power relative to the rest of the network, it seems to me that the whole proof-of-work concept is invalidated, fundamentally. We're just back to human webs of trust relations. Those who then claim that bitcoin has been hacked would be right to do so...and perhaps it would be best to abandon the block chain concept altogether.

Having said that, I believe it is possible to modify the proof-of-work algorithm to make it less likely to favor people with a particular type of specialized hardware.

The proof-of-work is very good for stopping internal attacks... It however provides no natural defence against attacks that are externally financially motivated.

It is completely reasonable that the internal bitcoin community can decided what miners they trust, and weigh their blocks more than of blocks from unknown miners.   Such a defence is called a ‘web-of-trust,’ and it provides a different quality of security to a proof-of-work.

Since the proof of work is to defend against internal attackers anyway… there is no problem in using a different type of defence to defend against externally motivated attackers.

So a proof-of-work is already secure enough to secure against internaly motivated double spends, why would an external 51% attack completely dis-credit it?
That is akin to saying “Something getting defeated by an attack that it wasn’t designed to defend against, means that the original design was faulty?”  - No it just means that the attack was out of specification.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
March 19, 2012, 04:49:51 AM
 #38



So a proof-of-work is already secure enough to secure against internaly motivated double spends, why would an external 51% attack completely dis-credit it?

Because the mechanism against external attacks as you call them also works as a defense against internal attacks. Proof-of-work would be costly and redundant (read uselss).

Useless and costly -> completely discredited

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 19, 2012, 09:18:06 AM
 #39

Because the mechanism against external attacks as you call them also works as a defense against internal attacks. Proof-of-work would be costly and redundant (read uselss).

You are complexly mixing up the different concepts of 'quantity of security' and 'quality of security'

If is like having a huge poorly trained army (that may be able to defend a country from external war)...
However you need special elite forces to defend against internal and sensitive disputes (such as dealing with spy's).

By your logic, because the special forces cannot defend an entire country against an invasion, they are:

Useless and costly -> completely discredited

I’m arguing that more than one type of security is required…. and for defending against internal attacks, the extremely high ‘quality’ of the security that we have is a good thing.

The problem the proof-of-stake is that it requires TRUST.  You must trust the people who have large numbers of bitcoin, to be both active, and not malicious with their investment.  With the current proof-of-work… being stakeholder counts for nill… as you don’t need defence, if you are not transacting your bitcoins.


A web-of-trust, (or even a proof-of-stake, a type of web-of-trust), that provides a lower grade of security, but at a much lower cost (so we can afford a very large quantity), is good for the 2nd line of defence, that we use against 51% attacks…

However I do not agree that the proof-of-work is made irrelevant by the proof-of-stake idea.  Rather I think that they provide solutions to different problems.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
gmaxwell
Moderator
Hero Member
*
qt
Offline Offline

Activity: 1078


View Profile

Ignore
March 19, 2012, 01:37:11 PM
 #40

a type of web-of-trust), that provides a lower grade of security, but at a much lower cost (so we can afford a very large quantity), is good for the 2nd line of defence, that we use against 51% attacks…

However I do not agree that the proof-of-work is made irrelevant by the proof-of-stake idea.  Rather I think that they provide solutions to different problems.

The fundamental problem here is that these things are not generally additive:  An action which causes different nodes to follow different chains is a forking attack which may be fatal to Bitcoin.

Say you have two distinct perfect security measures: A and B.  They both do a nearly perfect job of selecting the best chain.  But they are distinct and can select different chains.  Some users use A and some use B (or some A, some B some A&B) then an attacker just has to do something to make them differ— that something may even hardly be an attack and then Bitcoin is forked in a way which is irreparably without manual intervention. Rapidly people will double spend on each of the forks and within a dozen blocks or two any repair will be a difficult selection of which of two enormous groups of people gets robbed more.

Even the cases where the node just shuts down in response to reorgs— which is much better than the above— still is no help.   In a sane attack the reorg you see is the reorg moving you back onto the real chain— by the time you get any evidence that something is wrong it's too late.  You can't ignore that reorg without forever losing the ability to trade with everyone else.  The shutdown just helps you avoid getting exploited again shortly thereafter.   But even that isn't much help— because at the same time you've exposed yourself to a nice DOS that you were immune to before.    If miners adopt software that shuts down on reorgs then all sorts of great force multiplying attacks happen where you get >50% active hash power when you really have much less, just by first getting luck enough to trigger a big enough reorg to knock miners offline.

hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 19, 2012, 04:11:01 PM
 #41

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?

I thought about this a bit more and I came up with a revised rule:

Coupled with the above rule we add another rule. If more than half the new blocks in a time period are created by IP addresses that didn't appear in a certain already elapsed time period, for the next x blocks only blocks from IPs that have found blocks in that same time period but didn't find more than half are valid.

So even if someone amasses over 51% and is switching IPs he'll get ignored by the legitimate part of the network because a) he is finding too many blocks from his IP and b) he is finding too many blocks from previously unknown IPs

This way the proof of work stays valid as a mechanism to limit the supply of bitcoins and also gets protected from malicious intent by someone with more than 51% hashing power.


Comments?

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
wogaut
Donator
Sr. Member
*
Offline Offline

Activity: 448



View Profile

Ignore
March 19, 2012, 04:23:26 PM
 #42

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?

So? All someone mining more than 50% needs to do then is implement two IP addresses, certainly less difficult for the miner than the validation through the network. I see no benefit in that idea.

hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 19, 2012, 04:29:19 PM
 #43

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?

So? All someone mining more than 50% needs to do then is implement two IP addresses, certainly less difficult for the miner than the validation through the network. I see no benefit in that idea.


Right after I wrote my post I thought of that too but then I wasn't sure if it is actually the same if you have two clients with 26% of hashing power running the same malicious rules as having 1 with 52%?

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
Explodicle
Hero Member
*****
Offline Offline

Activity: 940


View Profile

Ignore
March 19, 2012, 04:34:52 PM
 #44

I was thinking about this last night and I was wondering, what would happen if we added another stricter block-validity rule that says if more than half of blocks of all the blocks created within a day are created by 1 IP, the IP get's ignored by the rest for the next 24h?

I thought about this a bit more and I came up with a revised rule:

Coupled with the above rule we add another rule. If more than half the new blocks in a time period are created by IP addresses that didn't appear in a certain already elapsed time period, for the next x blocks only blocks from IPs that have found blocks in that same time period but didn't find more than half are valid.

So even if someone amasses over 51% and is switching IPs he'll get ignored by the legitimate part of the network because a) he is finding too many blocks from his IP and b) he is finding too many blocks from previously unknown IPs

This way the proof of work stays valid as a mechanism to limit the supply of bitcoins and also gets protected from malicious intent by someone with more than 51% hashing power.


Comments?

Could a potential 51% attacker start out at half power to be recognized as legit, and then switch to full power?

Could an attacker DDOS the major pools, forcing more than 51% of the hashing power to get new IP's at once and granting a temporary oligopoly to the remaining pools?

I'd be most worried about both at once, a "set, spike" attack where even everyone honest mining at a loss (for network defense) isn't enough to stop a 26% attack.
hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 19, 2012, 04:37:00 PM
 #45

As soon as he reaches 51% he'd start breaking my first rule and get ignored. DDoSing pools does nothing since miners connecting to pools still have the option to solo mine.

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
Explodicle
Hero Member
*****
Offline Offline

Activity: 940


View Profile

Ignore
March 19, 2012, 05:20:14 PM
 #46

As soon as he reaches 51% he'd start breaking my first rule and get ignored. DDoSing pools does nothing since miners connecting to pools still have the option to solo mine.

Sorry, I didn't answer your previous question: running two nodes with 26% is the same as one with 52%. The important part is that they're controlled by the same malicious party - an organized group could still coordinate a 51% attack.

Suddenly solo miners would constitute previously unknown IP's, so their blocks would be ignored.
hazek
Staff
Hero Member
*****
Offline Offline

Activity: 980



View Profile

Ignore
March 19, 2012, 05:31:39 PM
 #47

Yeah you are right, nvm then Tongue  Embarrassed

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
wabber
Member
**
Offline Offline

Activity: 85


View Profile

Ignore
March 20, 2012, 02:27:04 PM
 #48

What if they couldn't change their IP, would that rule solve the problem?

As already mentioned you can relay your block through a proxy but that's actually not necessary because every node is a proxy already. Let's say I create lots of blocks. They probably don't go directly to you because it's pretty unlikely that we have a connection to each other. I send the blocks to the nodes im connected to and they send them further until they reach you. So you will only know the IP of the node you got the block from and not the IP of the creator of the block (me).
fastandfurious
Full Member
***
Offline Offline

Activity: 224


View Profile

Ignore
March 23, 2012, 10:52:44 AM
 #49

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

Any update on this, will this get implemented in the near future (less than a couple of months)?
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
March 23, 2012, 03:27:15 PM
 #50

I started experimenting with user-defined checkpoints (-checkpoint=height,hash multiarg, and 'addcheckpoint <height> <hash>' RPC call) but stopped when higher priority issues came up.

It seems to me that type of low-level mechanism is the right way to go; checkpointing is a good low-level way of identifying which chain you think is "the" chain. And making it command-line/RPC configurable means we don't all have to agree on One True Way of deciding what the right blockchain aught to be; cunicula can write some code that implements proof-of-stake and then tie it into bitcoin/bitcoind using -blocknotify.  etotheipi can write some code that scans the blockchain for well-known miner signatures (or asks miners directly if they produced a new block), etc.

If your argument is "But Gavin, if core Bitcoin doesn't support One True Way of doing I'll never be able to convince miners to do it my way!" then I'd say you need to better express to them how the benefits of your proposal outweigh the costs.

Any update on this, will this get implemented in the near future (less than a couple of months)?
Is there a BIP or wiki to describe this? I think I misunderstood this post from Gavin, but it looks to me like a reconciliation for forks?

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
coretechs
Donator
Sr. Member
*
Offline Offline

Activity: 349



View Profile

Ignore
March 24, 2012, 01:31:25 PM
 #51

Would it be possible to shift the entire mining process to a system similar to p2pool that would include a signature based on it's own tree?  Then just accept blocks that are also signed by THE decentralized mining pool so everyone has to use it.  I guess it's a "one true way" approach.

I'm loosely thinking about something like what p2pmining.com is attempting to do.  Perhaps existing pools would submit blocks through the main p2p pool where they would be signed, maybe paying a small fee that is distributed to miners in the process.  Basically all miners/the masses would work together in a single p2p mining pool as gatekeepers to the actual blockchain.  External pools could still exist but would need to still submit blocks through the main p2p mining pool and pay a small fee of each blockreward to be signed and accepted.  I know there would be a lot of complexities to work out, I'm just thinking out loud and wondering if it would even be possible and what the potential problems would be.
fastandfurious
Full Member
***
Offline Offline

Activity: 224


View Profile

Ignore
March 24, 2012, 06:08:54 PM
 #52

Would it be possible to shift the entire mining process to a system similar to p2pool that would include a signature based on it's own tree?  Then just accept blocks that are also signed by THE decentralized mining pool so everyone has to use it.  I guess it's a "one true way" approach.

I'm loosely thinking about something like what p2pmining.com is attempting to do.  Perhaps existing pools would submit blocks through the main p2p pool where they would be signed, maybe paying a small fee that is distributed to miners in the process.  Basically all miners/the masses would work together in a single p2p mining pool as gatekeepers to the actual blockchain.  External pools could still exist but would need to still submit blocks through the main p2p mining pool and pay a small fee of each blockreward to be signed and accepted.  I know there would be a lot of complexities to work out, I'm just thinking out loud and wondering if it would even be possible and what the potential problems would be.

Very interesting.
Haplo
Full Member
***
Offline Offline

Activity: 168



View Profile

Ignore
March 24, 2012, 11:24:23 PM
 #53

a type of web-of-trust), that provides a lower grade of security, but at a much lower cost (so we can afford a very large quantity), is good for the 2nd line of defence, that we use against 51% attacks…

However I do not agree that the proof-of-work is made irrelevant by the proof-of-stake idea.  Rather I think that they provide solutions to different problems.

The fundamental problem here is that these things are not generally additive:  An action which causes different nodes to follow different chains is a forking attack which may be fatal to Bitcoin.

Say you have two distinct perfect security measures: A and B.  They both do a nearly perfect job of selecting the best chain.  But they are distinct and can select different chains.  Some users use A and some use B (or some A, some B some A&B) then an attacker just has to do something to make them differ— that something may even hardly be an attack and then Bitcoin is forked in a way which is irreparably without manual intervention. Rapidly people will double spend on each of the forks and within a dozen blocks or two any repair will be a difficult selection of which of two enormous groups of people gets robbed more.

Even the cases where the node just shuts down in response to reorgs— which is much better than the above— still is no help.   In a sane attack the reorg you see is the reorg moving you back onto the real chain— by the time you get any evidence that something is wrong it's too late.  You can't ignore that reorg without forever losing the ability to trade with everyone else.  The shutdown just helps you avoid getting exploited again shortly thereafter.   But even that isn't much help— because at the same time you've exposed yourself to a nice DOS that you were immune to before.    If miners adopt software that shuts down on reorgs then all sorts of great force multiplying attacks happen where you get >50% active hash power when you really have much less, just by first getting luck enough to trigger a big enough reorg to knock miners offline.

Both of the proposed implementations of PoS (Cunicula's and Meni's) are combined with PoW. In Cunicula's system, difficulty is adjusted by stake, such that a miner with a higher stake gets to use a lower difficulty for PoW. Meni's system uses straight PoW, but PoS is used independently to verify certain checkpoint blocks that the whole network can fall back on in case of a dispute.

The main disadvantage of Cunicula's system is that only a single miner signs each block, which makes it hard/impossible for decentralized pools to contribute. Also, the way his system weighs stake doesn't allow for the "trustworthiness" of signatures to be gauged based on how many blocks they have contributed or any other relevant figures. It also has the unintended side effect that having a larger stake leads to a higher chance of generating a block (and thus collecting the coins from it).

The main disadvantage of Meni's system is that signature blocks can be signed by anyone with a stake, so each checkpoint block might end up with millions of signatures. This also makes it hard to provide any incentive for signing.

I had the idea to have the contributors of each pool sign the blocks it creates, and then only signatures that appear on previous blocks can be used on checkpoint blocks, each weighted by, say, the number of blocks the sig appears on and the amount of BTC in the signing account. That would prevent a 51% attack unless the attacker both had 51% of the computing power and a huge stake, and it would take a considerable amount of time for their signatures to gain the weight needed to overthrow the main blockchain. The main problem is figuring out how to keep the size of signatures down as in Meni's system.

Another thing that occurs to me is that, in the thread on tx replacement, it was briefly mentioned that a new protocol rule could be included that would invalidate any block containing a double spend attempt. If there is any conceivable way that a 51% or other forking attack could be used to effect a (very large) double spend, then a protocol rule would invalidate that chain automatically even if it does happen to be longer. They would be limited to DoS, or they would have to put most of the other miners out of business before the network would accept their attack (if at all). In that case, the network (and bitcoin) would probably be destroyed (if the clients still throw flags) before a double spend would succeed. As long as there's some contingency for a major DoS attack, it shouldn't be a major issue, however.

I'm So Meta, Even This Acronym
fastandfurious
Full Member
***
Offline Offline

Activity: 224


View Profile

Ignore
April 04, 2012, 03:56:41 PM
 #54

Any progress on this proposal?
fastandfurious
Full Member
***
Offline Offline

Activity: 224


View Profile

Ignore
May 17, 2012, 06:59:27 AM
 #55

Asking again because I think this is very important, especially because of the 25 BTC change at the end of the year, many legit miners will leave and the bots will remain, thus making Bitcoin vulnerable to a 51 % attack.  Gavin and others, any progress or information on this?
Realpra
Hero Member
*****
Offline Offline

Activity: 687


View Profile

Ignore
May 17, 2012, 07:58:24 AM
 #56

Trusted parties should be people who have an ownership stake in the system. If you want to identify who truly wants bitcoin to succeed, ask who is willing to bet money on its success. The trustworthy people will plunk their money down. Proof-of-stake. Ownership and control in the same hands, not separated. It's that simple. Anything else can and will be gamed.
So if I bet 49 BTC on my block it should win? Wink

Proof of stake can be gamed as well - the block hashing ITSELF is proof of stake; you need to stake your computer.


Casacious idea would protect the chain against sudden reversal, but NOT transaction blocking.


The ONLY defense against 51% attack is blocking certain IPs - ALL of them except a few trusted parties if necessary.

If you want to be preemptive about it, build it into the client, a block/allow list simply. Let the wallet owners decide who is spewing crap chains.

Bitcoin card in the spirit of Bitcoin itself.
Open source, usable globally, no bank involvement, perfect security and near-zero fees:
https://bitcointalk.org/index.php?topic=7539.140
cunicula
Hero Member
*****
Offline Offline

Activity: 700



View Profile

Ignore
May 17, 2012, 08:33:13 AM
 #57


Proof of stake can be gamed as well - the block hashing ITSELF is proof of stake; you need to stake your computer.
No

In a Society in which there is no law, and in theory no compulsion, the only arbiter of behaviour is public opinion. But public opinion, because of the tremendous urge to conformity in gregarious animals, is less tolerant than any system of law. When human beings are governed by "thou shalt not", the individual can practise a certain amount of eccentricity: when they are supposedly governed by "love" or "reason", he is under continuous pressure to make him behave and think in exactly the same way as everyone else. - George Orwell
HostFat
Staff
Hero Member
*****
Offline Offline

Activity: 1330



View Profile WWW

Ignore
May 17, 2012, 08:57:48 AM
 #58

If you want to be preemptive about it, build it into the client, a block/allow list simply. Let the wallet owners decide who is spewing crap chains.
This is a good idea Smiley

Tip / Mancia / Donazione: Click! to Show
Bitmessage: BM-oqEkfpH9HA4vNYMdNmfyjR5zSMJ7pnU3Y
Bitcoin Foundation Italia
iain
Jr. Member
*
Offline Offline

Activity: 30



View Profile WWW

Ignore
May 25, 2012, 06:59:41 AM
 #59

I have some thoughts on the 51% (even >>50%) attack problem which may be of interest to those following this thread. Rather than duplicate them here I'll just give an intra-forum link: Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether! https://bitcointalk.org/index.php?topic=68213.msg920853#msg920853

(Note that it's not, yet, a specific technically detailed proposal. It's more the launching of a new paradigm for how to design proposal(s) for standing up to attacks that go over the 50% mark. I hope it's of some interest to someone!)

Bitcoin - changing the world one transaction at a time.
cbeast
Donator
Hero Member
*
Offline Offline

Activity: 1064

Bitcoin, Decorporated stockholder since 2011.


View Profile

Ignore
May 25, 2012, 01:11:31 PM
 #60


Proof of stake can be gamed as well - the block hashing ITSELF is proof of stake; you need to stake your computer.
No
He doesn't see that. The proof of stake idea is no more secure than the proof of work system. This has boiled down to a philosophical argument about *who* should be responsible for the integrity of the Bitcoin Network. Should it be the elitist technocrats or the the unwashed masses?

It's like the employer that sees his employees as assets that are worthless without his money. In fact, employees are actually talented contractors willing to take less pay for not having to deal with capital management. This analogy applies to Bitcoin, because we the people must take responsibility for managing not only our own bank, but the banking system itself. Satoshi gave us an easy way to do this and we should recognise the significance of this. We are all bankers, with better hours.

Furthermore, if we give up our responsibility to run this easy-peas network for a little extra security, then we don't deserve Bitcoin.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
DeathAndTaxes
Donator
Hero Member
*
Online Online

Activity: 952



View Profile WWW

Ignore
May 25, 2012, 01:34:25 PM
 #61

Asking again because I think this is very important, especially because of the 25 BTC change at the end of the year, many legit miners will leave and the bots will remain, thus making Bitcoin vulnerable to a 51 % attack.  Gavin and others, any progress or information on this?

Why would the network be more vulnerable to a 51% attack by botnets then "legit miners"?  Hashing power is hashing power.  Botnet operators profit (unethical or not) be keeping the network secure.

Gerald Davis  CEO, Tangible Cryptography Inc.
BitSimple. A simpler way to buy and sell bitcoins
Pages: 1 2 3 4 [All]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!