Bitcoin Forum
May 03, 2024, 12:46:58 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 64 »
  Print  
Author Topic: DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)  (Read 91075 times)
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 10, 2016, 08:02:14 PM
 #161

However, I want to make you aware that quantum computers are unlikely to speed up anything[1] on a cost/performance basis.

Cost/performance is a good protection... until you meet an irrational attacker (e.g. the state).
1714740418
Hero Member
*
Offline Offline

Posts: 1714740418

View Profile Personal Message (Offline)

Ignore
1714740418
Reply with quote  #2

1714740418
Report to moderator
1714740418
Hero Member
*
Offline Offline

Posts: 1714740418

View Profile Personal Message (Offline)

Ignore
1714740418
Reply with quote  #2

1714740418
Report to moderator
1714740418
Hero Member
*
Offline Offline

Posts: 1714740418

View Profile Personal Message (Offline)

Ignore
1714740418
Reply with quote  #2

1714740418
Report to moderator
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714740418
Hero Member
*
Offline Offline

Posts: 1714740418

View Profile Personal Message (Offline)

Ignore
1714740418
Reply with quote  #2

1714740418
Report to moderator
1714740418
Hero Member
*
Offline Offline

Posts: 1714740418

View Profile Personal Message (Offline)

Ignore
1714740418
Reply with quote  #2

1714740418
Report to moderator
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 08:03:21 PM
 #162

However, I want to make you aware that quantum computers are unlikely to speed up anything[1] on a cost/performance basis.

Cost/performance is a good protection... until you meet an irrational attacker.

N(icholas) S(anta/atan) A(sshole)

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 10, 2016, 08:06:00 PM
 #163

It seems to me I derailed the convo. Continue, please, gentlemen.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 08:11:53 PM
Last edit: January 10, 2016, 08:49:39 PM by TPTB_need_war
 #164

It seems to me I derailed the convo. Continue, please, gentlemen.

Well kudos. You did demonstrate that the state might be able to win all block solutions due to building a very expensive computer, but which is (perhaps) exponentially less costly than building that many copies of mining equipment. Per the Berstein paper, apparently they can do it with parallel memory tables, no need to wait for a quantum computer (but I need to study that more closely).

And the defense is as in your Iota/Tangle paper to keep the difficulty of each confirmation step of the chain (each submitted PoW share) as low as possible to minimize the exponent of speedup.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 08:21:11 PM
 #165

Your 4.3 section makes the point that the lower the difficulty, the lower the threat. Interesting. Thanks. Edit: I think I perhaps know how to incorporate this into my design...

That defense would already be in my design (before I even became aware of that in yours) because every transaction carries a PoW share, thus this share references a prior block hash. The cumulative difficulty could include all the shares.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 08:29:18 PM
 #166

The LCR insures no double-spend exist. There is no fix for the idea of taking the conjunction of chains. The idea is flawed that is why I abandoned it. Also note I had added to my prior post.

That's why you'd need a new chain selection rule... what happens if you were to use to greatest set of all new transactions as the rule?

The greatest set of all new transactions would have the largest cumulative POW weight (in a system with a constant POW cost per transaction), such that any double spend by the attacker within this set would become the canonical spend, not the double spend.

Yes I remember now that was my next line of thinking too. If the rule is that the union is the canonical set, then the attacker's latter double-spend is the invalid transaction. Remember I wrote that in my vaporcoin thread last month.

But the flaw remains that there is no way to prove what the union is. At any given time the honest chain has all the transactions from the attackers chain plus censored transactions, but then the attackers chain releases a new block with more new transactions. How do we prove which was first? That is the entire point of a longest chain rule is we have no way to prove relative order otherwise. This is what I wrote several posts before. You will just chase your tail in circles. It violates the CAP theorem.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
January 10, 2016, 08:32:52 PM
 #167

But the flaw remains that there is no way to prove what the union is. At any given time the honest chain has all the transactions from the attackers chain plus censored transactions, but then the attackers chain releases a new block with more new transactions. How do we prove which was first? That is the entire point of a longest chain rule is we have no way to prove relative order otherwise. This is what I wrote several posts before. You will just chase your tail in circles. It violates CAP.

First doesn't matter. Cumulative POW matters - if the attacker extends his chain by another block, thereby increasing his weight, if he is still censoring transactions, the minority can easily extend their own chain by including all the transactions he has, plus the ones he leaves out?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 08:44:42 PM
Last edit: January 10, 2016, 08:54:46 PM by TPTB_need_war
 #168

But the flaw remains that there is no way to prove what the union is. At any given time the honest chain has all the transactions from the attackers chain plus censored transactions, but then the attackers chain releases a new block with more new transactions. How do we prove which was first? That is the entire point of a longest chain rule is we have no way to prove relative order otherwise. This is what I wrote several posts before. You will just chase your tail in circles. It violates CAP.

First doesn't matter. Cumulative POW matters - if the attacker extends his chain by another block, thereby increasing his weight, if he is still censoring transactions, the minority can easily extend their own chain by including all the transactions he has, plus the ones he leaves out?

We can't prove when those chains were created relative to each other. That was the point in my very first post on this.

Someone could 100 years later create a chain and claim it existed at the time and was part of the union.

The only proof we have for the union is what the chains record. This is the entire reason we need LCR.

You envision a union, but you have no way to prove what the union is. Propagation is not proof. I made this point several times now.

The flaws require very deep thinking.

Edit: this is example of what I mean by it is easy to be fooled into thinking one has a solution. So many times I thought I was close to a solution then banged my head against CAP over and over.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
January 10, 2016, 08:59:50 PM
 #169

We can't prove when those chains were created relative to each other. That was the point in my very first post on this.

Someone could 100 years later create a chain and claim it existed at the time and was part of the union.

The only proof we have for the union is what the chains record. This is the entire reason we need LCR.

You envision a union, but you have no way to prove what the union is. Propagation is not proof. I made this point several times now.

The flaws require very deep thinking.

Ahhhh, right of course - because the minority doesn't expend much energy by bundling the larger set of transactions, we have a sybil problem similar to long range attack in POS. And if they did expend energy linearly in the number of transactions they bundle, the majority always wins are we're back to the same old LCR.

edit: this is actually a really nice example of why you have to expend sufficient energy when you're creating blocks, and why POS is not tenable for a world currency.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 09:02:47 PM
 #170

Thank you for helping me remember all the thought process I went through and helping me to write it down. That should be very instructive to readers on how elusive flaws can be and why they should be very skeptical of claims of solving CAP without a LCR.

So now back to current and last attempt...searching for the flaw...

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
January 10, 2016, 09:06:20 PM
 #171

Thank you for helping me remember all the thought process I went through and helping me to write it down. That should be very instructive to readers on how elusive flaws can be and why they should be very skeptical of claims of solving CAP without a LCR.

So now back to current and last attempt...searching for the flaw...

I can't remember if you're still holding the key details of this close to your chest? If you'd like help enumerating the potential problems, I'd be happy to assist Smiley
Fuserleer
Legendary
*
Offline Offline

Activity: 1050
Merit: 1016



View Profile WWW
January 10, 2016, 09:12:20 PM
 #172

Byzantine tolerance can not exceed 50% of failures.

Isn't it 33%?

You can achieve 50% in some circumstances by making sacrifices in the system.

If you have the inclination, I suspect readers would appreciate a layman's example.

Just punch "byzantine 2f+1" into Google

Plenty of papers on the subject, some sacrifice asynchronous comms, others adopt semi-trusted authorities etc etc

I didn't say it was pretty, or that it could be used here, but 2f+1 (or 50% near as damn it) is the best you can do.

Radix - DLT x.0

Web - http://radix.global  Forums - http://forum.radix.global Twitter - @radixdlt
Fuserleer
Legendary
*
Offline Offline

Activity: 1050
Merit: 1016



View Profile WWW
January 10, 2016, 09:20:52 PM
 #173

The LCR insures no double-spend exist.

Once quantum computers hit the market everyone will be able to rewrite complete Bitcoin blockchain from the genesis. So I would add something to emphasize temporal nature of your statement.

This is also the benefit of an append only ledger and an issue with POW.

Even a quantum computer cant rewrite history in a ledger that is append only.  Sure it might be able to disrupt future transactions if sufficient algorithms are not in place to account for quantum computing resources, but the fact still holds that the past data prior to any quantum influence is sound and can be trusted.

Also, I haven't looked into how a QC would do this, but how would it get around the Bitcoin checkpoints?  Surely it can only rewrite from the last checkpoint issued?

Radix - DLT x.0

Web - http://radix.global  Forums - http://forum.radix.global Twitter - @radixdlt
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
January 10, 2016, 09:25:29 PM
 #174

This is also the benefit of an append only ledger and an issue with POW.

Even a quantum computer cant rewrite history in a ledger that is append only. 

I'm gonna go out on a limb here and state that having an append only ledger is impossible in trustless crypto.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 10, 2016, 09:38:52 PM
 #175

Also, I haven't looked into how a QC would do this, but how would it get around the Bitcoin checkpoints?  Surely it can only rewrite from the last checkpoint issued?

Yes, these checkpoints realize append-only subchain.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 10:27:14 PM
 #176

I clarified how bad the security is in PoS (readers still weren't grasping the gravity of the point):

  • even 0.1% stake can attack the coin because block solutions are exclusive to some stake holder so the stake holder can delay transactions[1]

[1]Another scenario is DDoS attack other stake holders when their turn to mine a block, then jack up your transaction fees sky high when its your turn to mine a block. Note this has many variants as follows:

I do not think the following is possible in dPoS (I'm not sure about other forms of PoS), because delegates cannot change or set transaction fees by themselves. Transaction fees can only be changed by committee members which are elected by stakeholder vote. Not including a transaction because it doesn't have a certain amount in transaction fees seems silly, because the next honest delegate will do so and the honest delegate will get whatever fees are associated with the transaction. They would basically be giving up free money, putting a big red flag on their witness campaign, and it would be very likely that would get them voted out. Part of the incentive for delegates to stay honest is the future income of blocks produced in the future, although as I stated earlier... even if they are dishonest there is not much they can do other than withhold transactions from blocks (and the transaction would be included in the next block produce by an honest delegate.) The way I understand it, DPoS' main weakness is that all consensus algorithms suffer from.. a 51% attack.
Quote
[1] Another scenario is DDoS attack other stake holders when their turn to mine a block, then jack up your transaction fees sky high when its your turn to mine a block.

You forgot my point that the attacker can short the coin. And that delaying transactions is an attack that could cause the share price to crater. Or DDoS attack all the others and then force all transactions on to your block. This is the problem with PoS and DPOS, because the ordering of who will mine is known before the transactions are sent. That is a major flaw compared to PoW.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 10, 2016, 11:38:52 PM
 #177

My illness is flaring up, so I will need to hit the bed for now. Be back next day or when ever I feel okay.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1000


View Profile
January 11, 2016, 10:29:22 AM
 #178

@TPTB_need_war, what are the broad key features you're targeting in your new design?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 257


View Profile
January 11, 2016, 11:11:23 AM
 #179

monsterer I think the answer will be incorporated into my next post which I am composing now. Trying to determine what I will disclosure and how I will elucidate what I think I have so far.

I will go jog first. Fighting well.

wingspan
Newbie
*
Offline Offline

Activity: 54
Merit: 0


View Profile
January 11, 2016, 01:15:27 PM
 #180

This is also the benefit of an append only ledger and an issue with POW.

Even a quantum computer cant rewrite history in a ledger that is append only.

I'm gonna go out on a limb here and state that having an append only ledger is impossible in trustless crypto.

One way to think of the difference between an "append-only" ledger and one that isn't (e.g. LCR without checkpoints) is the difference between a strict teacher that allows no late work and a soft teacher that allows late work just the same.  Half way through the semester, a clever student in the soft teacher's class who hasn't done any work can still pull off a perfect total score in the class just by cramming at the end, turning in all homework, and getting all previous zeroes turned to perfect scores.  It's a function of what rule the system uses - does it allow previously confirmed ledger entries to change or not? Trustless or not.  Right?

I guess it is assumed that you are watching for rule violations constantly.  Always block such violations, and your copy of the ledger remains append-only.
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 64 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!