Bitcoin Forum
May 25, 2024, 09:55:16 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 »
101  Bitcoin / Development & Technical Discussion / Re: A fully decentralised consensus algorithm on: June 10, 2018, 04:42:38 PM
Firstly, no worries about propagation, I just append the bytes to my statement.

Secondly, The sole fact that 70% of the coins have been destroyed they are automatically re-distributed to remaining coin owners,  in the most 'democratic' way ever.  Fewer coins, more valuable coins. Simple!

Thirdly, 'the rest' of the network is a bit stronger than 15% percent, say 16%, the rest of the 'manpower' is with me. I have poor class in my Anarchistic pocket. Grin

Noways dude, just forget about this idea and go find something else to think about, I'm done here.

The thing you are missing is that all these attack scenarios would apply to <insert PoW coin here> as well as any human based PoW, with the added bonus that they'd be easier to carry out as the hash rate market is much more mature than any human PoW market.
102  Bitcoin / Development & Technical Discussion / Re: A fully decentralised consensus algorithm on: June 10, 2018, 01:08:08 PM
In my statement I explain how good it would be if people just confirm my transactions instantly. I would say:

"Comrades,
This transaction destroys almost 70% of the coins which are in hands of less than 15% of people. Destroying these coins will automatically enrich the rest of the people by a quadratic ratio the poor owner who has just 10 coins in his wallet will find it to be 4 times more valuable now. Unite and confirm my proposed transaction and become 4 times more rich just by spending 10 seconds of your time which is not appreciated enough by capitalists by the way. They won't pay you a single penny for 10 seconds, you know."


What happens next? I know you and your parents are good guys, and have good faith, but dude, don't be naive, most of the people are not that honest, they will just try my proposal and commit my transaction ... please, now don't bring forward  PoS shits, I'm sick of its subjectivity.

Firstly, your transaction is invalid and not accepted by the network for propagation.

Secondly, you will need to pay each one of these people you attempt to bribe more than the block reward they earn for playing by the rules. So this attack is going to be expensive.

Thirdly, your attack has an ongoing cost because you still need to outpace the rest of the honest network.

Your proposition is a simple 51% attack and achieving it is far more difficult than renting hash power because people are the ultimate limited resource.
103  Bitcoin / Development & Technical Discussion / Re: A fully decentralised consensus algorithm on: June 10, 2018, 12:15:32 PM
Sybil attack is not the issue, I'm talking about 50%+1 attack.

As for sybil attack classical PoW again gets the lowest profile unlike what you claim, because it is not about identities but about costs, nobody can forge costs:

To consume or not to consume? This is the question!

Not hard to understand, you decide (being a human or a machine, whatever) based on your analysis of the incentives and costs involved. PoW is the king here, a proven untouchable legit king.

Suppose I give you a problem, solvable only by a human, that a human performing at his best takes 10s to complete. How can you improve this solution time? You can't.

Alternatively, I give you a machine solvable problem, which takes 10s on a the best CPU to solve. How can you improve this solution time? ASIC. You can probably improve it by at least 100x.

That is the difference here. You've getting hung up on PoW being a machine solvable problem.
104  Bitcoin / Development & Technical Discussion / Re: A fully decentralised consensus algorithm on: June 10, 2018, 11:25:36 AM
Huh
People can't vote for my money, it is said to be my asset, to be defended against people not to seize it. So, as long as it is about monetary systems, you better forget about democracy and speak about law.

Consensus, the way PoW deals with it, is achieved by requiring people to consume resources to participate, resources and costs that will be put in risk and be sated if they try something illegal. Otherwise people won't hesitate to take your money. People will participate in any attack if it is just free to join and there is a penny at stake.

You're still not thinking about the problem properly. A PoW solvable only by people would be the ultimate system because you cannot sybil attack it - the best thing you can do is crowd source it, but it would still have the lowest sybil coefficient of any system possible.
105  Bitcoin / Development & Technical Discussion / Re: A fully decentralised consensus algorithm on: June 10, 2018, 11:03:49 AM
In my opinion, PoW is the most reliable consensus paradigm ever. Specially I am strongly about op's obsession with one human, one vote idea.

Such a hypothetical "democratic" algorithm,   won't help monetary systems, on the contrary it would destroy them eventually. People would vote to seize the deposits of top 1% stake holders with a majority of 75% or more  Grin only fools will put their money in such a network.

You're thinking about politics when you should be thinking about consensus. Anything you can apply to politics applies to all possible consensus mechanisms since they're all controlled by people.
106  Bitcoin / Development & Technical Discussion / Re: A fully decentralised consensus algorithm on: June 10, 2018, 10:17:29 AM
A truly decentralised consensus mechanism is one where humans perform the PoW. The trouble is, finding a problem that only a human can solve that is also easily verifiable by a machine is unsolved.

The person who solves this problem will be very rich indeed.
107  Bitcoin / Development & Technical Discussion / Re: Proof-of-Approval: Version 2.0 on: June 09, 2018, 03:13:18 PM
I presume you are referring to the current PoA design and not my proposal because it does not seem to apply anymore in my proposed change.

I was referring to your proposal with the staking keys.... I'm going to stop clogging up this thread with conjecture and wait for Shunsai to add some more details.
108  Bitcoin / Development & Technical Discussion / Re: Limits of POW on: June 09, 2018, 08:04:24 AM
If someone devises a new way to employ Hashcash-like proofs without blocks or something, then we’ll reevaluate. But I have expended 5 years of research, and I haven’t been able to devise any such thing. And I am a very clever, divergent thinker, inventor. And AFAIK, neither has anyone else been able to after so many years since Bitcoin was released.

If you've not read it, I recommend taking a glance at my draft white paper describing Max Kaye's original thinking in this area. You might find it enlightening:

https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf

Remember we had discussed that in 2016 in the Decentralization thread. Anyway it looks similar to thought processes I went through, but the real show stopper appears to be who is doing the validation? That’s why it apparently doesn’t solve the scalability issue. Although I didn’t read the paper carefully again now. No time for that.

What you mean by validation? Transaction are validated by nodes on the network. That's not the show stopper, the show stopper is lite nodes. DAG based systems cannot support them without added centralisation.
109  Bitcoin / Development & Technical Discussion / Re: Limits of POW on: June 08, 2018, 08:45:07 PM
If someone devises a new way to employ Hashcash-like proofs without blocks or something, then we’ll reevaluate. But I have expended 5 years of research, and I haven’t been able to devise any such thing. And I am a very clever, divergent thinker, inventor. And AFAIK, neither has anyone else been able to after so many years since Bitcoin was released.

If you've not read it, I recommend taking a glance at my draft white paper describing Max Kaye's original thinking in this area. You might find it enlightening:

https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf
110  Bitcoin / Development & Technical Discussion / Re: Video Game Proof of Work translated to Proof of Stake blockchain on: June 08, 2018, 08:42:02 PM
If you invest in bitcoin it means you trust the Bitcoin software.  If you invest in Gamecoin then it means you trust the Gamecoin software.  The bitcoin pow algorithm is arbitrarily designed by a human just like the game pow algorithm is arbitrarily designed by a human.  Both can have flaws, both can patch flaws via their dev team.  The consensus is of nodes who are stakehokders verifying signatures just like in Bitcoin.  If bitcoin has hostile devs releasing hostile code then bitcoin is doomed especially if it is closed source.  Same with Gamecoin.

A car has wheels. A plane also has wheels.... yet I do not expect to pilot my car into the air because it shares some of the same functional components.
111  Bitcoin / Development & Technical Discussion / Re: Video Game Proof of Work translated to Proof of Stake blockchain on: June 08, 2018, 03:55:11 PM
One example that I think would work is a Blockchain MMO.  Let's make it simple and say every time you level you broadcast this to all the players, which are also nodes.  They record this in their ledger.  Now depending on your player(s) level you have a stake in the PoS. 

Sorry but this is just nonsense. How are you going to prove that a 'level up' message isn't just fraudulent? You've got the exact same consensus problem here as a blockchain has in the first place.

Because it would be signed by the game software (sort of how some program downloads are signed by the developer so you know there wasn't a man in the middle attack) and signed by the player's node.  Also obviously there is the history in the blockchain that it needs to sync up to as well.  Trusted third parties are a part of bitcoin currently, they are called dev's.  We trust devs to update the software according to bitcoin's core philosophy, and we trust game dev's to do the same in this case.

I agree with nothing you've said. What you're talking about is a consensus of 1, which is no consensus at all.
112  Bitcoin / Development & Technical Discussion / Re: Limits of POW on: June 08, 2018, 09:03:32 AM
Sorry but that’s not correct.

As I explained in my analysis of OmniLedger—a technology which shows how sharding can be adapted to Nakamoto proof-of-work—that proof-of-work is fundamentally incompatible with significant sharding because of the huge variance that individual miners would incur if they didn’t participate in pools. OmniLedger is incompatible with pools because it needs a large set of diverse miners that win blocks in order to populate the shards with independent entities so that it can scale decentralized.

I disagree. You're talking about the existing, block based implementations of consensus built around PoW. PoW itself specifies no such limitations, it is simply a tool to use in building consensus designs which may or may not have the limitation you are describing.
113  Bitcoin / Development & Technical Discussion / Re: Video Game Proof of Work translated to Proof of Stake blockchain on: June 08, 2018, 07:48:44 AM
One example that I think would work is a Blockchain MMO.  Let's make it simple and say every time you level you broadcast this to all the players, which are also nodes.  They record this in their ledger.  Now depending on your player(s) level you have a stake in the PoS. 

Sorry but this is just nonsense. How are you going to prove that a 'level up' message isn't just fraudulent? You've got the exact same consensus problem here as a blockchain has in the first place.
114  Bitcoin / Development & Technical Discussion / Re: Proof-of-Approval: Version 2.0 on: June 08, 2018, 07:43:47 AM
I look forward to what you guys can come up with. Although, I have to say I'm extremely sceptical of any trustless design claiming to have no incentive system.

IMO, the 0% attack is more dangerous than just the not responding attack, because at first glance there should be no reason to expect that sending yourself a transaction could have consequences, so why would someone refuse being paid for doing so?
115  Bitcoin / Development & Technical Discussion / Re: Video Game Proof of Work translated to Proof of Stake blockchain on: June 07, 2018, 07:05:20 PM
'Proof' is the key word here. How are you going to prove any of these achievements actually happened? More to the point, how is the blockchain going to verify them?
116  Bitcoin / Development & Technical Discussion / Re: Proof-of-Approval: Version 2.0 on: June 07, 2018, 10:28:18 AM
1) Bonded stake systems are subject to the 0% attack in which you bribe all the bonded stake in the system to simultaneously send a transaction to themselves (an action with seemingly no consequences). With zero bonded stake remaining in the system, the chain freezes forever.

A bond implies the money is not transferable, so I'm not sure how this attack could work.

That would have to be a necessary condition. You might assume that bonded stake just has to mature for some period before it can start voting, but this is not enough as you say it must also not be transferable.

I think there is still an open question about objectively identifying double signing, though - why can't an attacker just use two different stake public keys to double sign?
117  Bitcoin / Development & Technical Discussion / Re: Proof-of-Approval: Version 2.0 on: June 07, 2018, 09:59:47 AM
@shunsaitakahashi,

Since you expect 50+% of the stake to be stable running on the cloud, my idea for entirely eliminating short-range double spends is to slash not only conflicting approvals but also slash (make ineligible) the stake public key from future slots for an extended remediation period. Also require stake public keys to be stable for extended period before they’re eligible to vote approvals.

Ineligible stake is not counted towards total stake when computing the 50+% quorum threshold. Thus I think you can remove the slow changing stake requirement from your whitepaper and set the threshold to exactly 50+%.

There are a couple of problems with that idea:

1) Bonded stake systems are subject to the 0% attack in which you bribe all the bonded stake in the system to simultaneously send a transaction to themselves (an action with seemingly no consequences). With zero bonded stake remaining in the system, the chain freezes forever.

2) If you remove the stake transfer limit, the above becomes possible and not only that but you also weaken the history attack strength, which was near 99% attack proof due to the slow stake transfer combined with the epocs signatures.
118  Bitcoin / Development & Technical Discussion / Re: Proof-of-Approval: Version 2.0 on: June 06, 2018, 09:51:31 AM
Hi Shunsai,

I have some ideas for you which might help your NaS problem. I developed an aborted Proof of Burn concept ages ago(*) which I've recently revisited and it might have some ideas you can use:

This is a brief summary of how it works:

* Participants compete to win block reward by burning stake
* A block can be proposed when burnt stake >= block reward
* Block reward is divided out between all participants in proportion to their burnt amounts

An attacker attempting to dominate the block generation process by proposing a block containing only his burnt stake will always lose out once his block is published, because other participants can propose a better block containing his burnt stake AND their burnt stake. So, at the limit if he burnt the block reward in his private block, what he gets back is less than his burnt stake once he published his block due to the above possibility, so he will lose money this way.

In order to double spend his only option is create a massive chain of private blocks and then submit that later. But, if we instead adopt your slot mechanism, it would be impossible for this attack to succeed because he cannot propose more than 1 block at a time.

We can also employ your double voting exclusion mechanism so that if he burns on two chains at the same time, he will lose his stake completely.

The only major problem I can see here is that there is no objective way to verify a slot and the boundary(s) thereof, so we have history attack problems.

Anyway, hope that gives you some ideas Smiley

Cheers, Paul.

edit: I still have an open question raised by shelby, if we're discarding double votes inside a slot, why don't we just do that for double spends and scratch the entire voting process completely? This is due to the subsequent invalidation cascade which would make discarded double spends cost free for the attacker

*) https://bitcointalk.org/index.php?topic=1182677.msg12446394#msg12446394
119  Bitcoin / Development & Technical Discussion / Re: Proof of Work: Limit node hashrate to improve decentralisation? on: June 04, 2018, 08:49:14 PM
Maybe for Bitcoin and all other Proof of Work coins: Would it be possible to somehow limit the hashrate the network accepts from a node? Like what if you limit the hashrate per node down to what a normal desktop CPU can do. This would cause all ASICs become irrelevant and/or increase the effort to set up huge mining farms as these, that generate thousand and million times the hashrate of a CPU, would need to run as many nodes as their hashrate is above the abilities of a standard desktop CPU. It would also stop the need to create new algorithms that are ASIC-resistant just to be cracked a few years later.

You need to look up sybil attack. What constitutes a node? A port? So all the mining farms do is to split their existing hash rate over whatever you're defining as the limit so they're achieving the same goal.
120  Bitcoin / Development & Technical Discussion / Re: ECDSA signatures: why not force the reuse for r for spends from the same address on: June 04, 2018, 06:27:41 PM
Thanks for the thought experiment.

I had the feeling that something was off about your approach, but wasn't quite able to put my finger on it until I put a bit more thought into it.

This idea might still have some legs because arguably it would still work if weak subjectivity was an acceptable compromise since no online node would accept a historical double spend as being valid given the latest UTXO DAG. I don't think weak subjectivity should ever be acceptable, however, so I'm going to keep thinking Smiley
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!