DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?) - page 51.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

Quote from: Fuserleer on January 11, 2016, 04:05:29 PM

Quote from: TPTB_need_war on January 11, 2016, 04:00:05 PM

Quote from: Fuserleer on January 11, 2016, 03:58:41 PM

If you actually read the posts instead of making these self pitying comments you might actually learn why it might.

Wow you live in a deep delusion don't you.

No. I'm just suggesting you might learn something, which funnily enough was the purpose of this thread according to you.

But you repeatedly come back with that attitude of yours and quite frankly I've allocated about as much patience to you and your insults aimed and me and everyone else trying to further themselves as I'm going to.

Plenty of people are skeptical, and that's fine, I can accept that and respect it....but you're just a bit too much on the God complex side of the line to tolerate.

I can't learn anything until you provide all the details. And given my knowledge set, I know there about a million-to-one chance you can achieve consensus without blocks that consume a resource.

I don't like wasting my time on the Lotto. You disrespect odds and people's time.

I was prepared to talk about my design which is actually sound and can probably change the world, but instead we are going on and on with this.

And now it is time for me signoff. My deadline has been hit. Oh well.

Priorities matter. Resources matter. You all made your choice.

monsterer

legendary

Activity: 1008

Merit: 1007

Quote from: Fuserleer on January 11, 2016, 03:55:55 PM

Of course they do, they cost energy! What else would it cost?

I explained this in brief up thread, if you didn't read it, do so, if you need more detail, post back after.

What energy? I can't find where you describe how it works.

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: TPTB_need_war on January 11, 2016, 04:00:05 PM

Quote from: Fuserleer on January 11, 2016, 03:58:41 PM

If you actually read the posts instead of making these self pitying comments you might actually learn why it might.

Wow you live in a deep delusion don't you.

No. I'm just suggesting you might learn something, which funnily enough was the purpose of this thread according to you.

But you repeatedly come back with that attitude of yours and quite frankly I've allocated about as much patience to you and your insults aimed and me and everyone else trying to further themselves as I'm going to.

Plenty of people are skeptical, and that's fine, I can accept that and respect it....but you're just a bit too much on the God complex side of the line to tolerate.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

Quote from: Fuserleer on January 11, 2016, 03:58:41 PM

If you actually read the posts instead of making these self pitying comments you might actually learn why it might.

Wow you live in a deep delusion.

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: TPTB_need_war on January 11, 2016, 03:56:48 PM

I am so dumb. Really dumb.

Quote from: TPTB_need_war on January 11, 2016, 03:55:23 PM

Quote from: monsterer on January 11, 2016, 03:52:52 PM

Quote from: TPTB_need_war on January 11, 2016, 03:46:43 PM

2. DSPEND <- GOODA <- GOODB. How do you modify GOODA or GOODB to not point to DSPEND when you do not have the private key. And if you allow anyone to change the references, then you have chaos.

I might be missing something very obvious here, but why do you need to do that? Nodes won't apply a transaction that is invalid, so the double spend just doesn't get applied - the other transactions which are chained can still get applied without issue as long as they are unrelated to the double spend?

You continue to do this mistake.

Double-spends are not unambiguous. Who decides? That is why we have LCR.

If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.

This is also why eMunie can't work without blocks. Period.

If you actually read the posts instead of making these self pitying comments you might actually learn why it might.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

I am so dumb. Really dumb.

Quote from: TPTB_need_war on January 11, 2016, 03:55:23 PM

Quote from: monsterer on January 11, 2016, 03:52:52 PM

Quote from: TPTB_need_war on January 11, 2016, 03:46:43 PM

2. DSPEND <- GOODA <- GOODB. How do you modify GOODA or GOODB to not point to DSPEND when you do not have the private key. And if you allow anyone to change the references, then you have chaos.

I might be missing something very obvious here, but why do you need to do that? Nodes won't apply a transaction that is invalid, so the double spend just doesn't get applied - the other transactions which are chained can still get applied without issue as long as they are unrelated to the double spend?

You continue to do this mistake.

Double-spends are not unambiguous. Who decides which double-spend is reversed? That is why we have LCR.

If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.

This is also why eMunie can't work without blocks. Period.

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: monsterer on January 11, 2016, 03:54:19 PM

Quote from: Fuserleer on January 11, 2016, 03:50:38 PM

Im pretty sure that the challenges can be considered POW. They are a proof that you have done some work which can be verified.

So while they are not the mechanism that votes on the transactions, they are the mechanism that allows you to gain eligibility to vote on transactions.

Which is essentially the same thing, therefore its not broken.

Do the challenges cost anything to solve, though? How do they work, exactly?

Of course they do, they cost energy! What else would it cost?

I explained this in brief up thread, if you didn't read it, do so, if you need more detail, post back after.

monsterer

legendary

Activity: 1008

Merit: 1007

Quote from: Fuserleer on January 11, 2016, 03:50:38 PM

Im pretty sure that the challenges can be considered POW. They are a proof that you have done some work which can be verified.

So while they are not the mechanism that votes on the transactions, they are the mechanism that allows you to gain eligibility to vote on transactions.

Which is essentially the same thing, therefore its not broken.

Do the challenges cost anything to solve, though? How do they work, exactly?

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: monsterer on January 11, 2016, 03:45:23 PM

Quote from: Fuserleer on January 11, 2016, 03:38:50 PM

Plus we are forgetting one critical component in this scenario of yours which has been overlooked here repeatedly. The challenges. You'll be getting 10,000+ of them about every minute, 166 of them a second, and none of them will be the same and they are significant work. You'll have to hit the DB and do the work because you can't cache all the data, plus then the processing and creating the solution proof.

And you still havent acknowledged the pipe cost.

That's like a busy website, but it isn't going to break the bank. This is a major flaw with this design, I'm sorry to say.

You can fix it, though - and I've mentioned this before, throw away the trust model and use POW for voting on transactions.

Hold on.

Im pretty sure that the challenges can be considered POW. They are a proof that you have done some work which can be verified.

So while they are not the mechanism that votes on the transactions, they are the mechanism that allows you to gain eligibility to vote on transactions.

Which is essentially the same thing, therefore its not broken.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

Data structures don't matter when analyzing designs:

Quote from: TPTB_need_war on January 11, 2016, 03:46:43 PM

Quote from: monsterer on January 11, 2016, 03:40:54 PM

Quote from: TPTB_need_war on January 11, 2016, 03:35:41 PM

1. But it may not always be unambiguous or other reasons that they can't do what you think they are incentivized to do. MUST is not the same as incentive. Be very careful in analyzing the details of consensus designs.

2. The transactions that follow the double-spend must be because they include the double-spend by referencing it. You need to study more closely the concept of the DAG. The transactions reference prior transactions. I thought you know that. So if there is a double-spend, but isn't known to be a double-spend until later, then all the transactions that referenced it will be potentially reversed. But again which set? It is ambiguous.

1. Maybe, I'm no expert on Iota, I just see parallels between the LCR and longest stream of POW.

2. I know transactions reference prior transactions, I'm just trying to understand why you must invalidate transactions which chain from a double spend, when you could also just not apply the double spend and carry on?

2. DSPEND <- GOODA <- GOODB. How do you modify GOODA or GOODB to not point to DSPEND when you do not have the private key. And if you allow anyone to change the references, then you have chaos.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

Quote from: monsterer on January 11, 2016, 03:45:23 PM

You can fix it, though - and I've mentioned this before, throw away the trust model and use POW for voting on transactions.

Nope that won't fix it for similar reasons to Iota.

monsterer

legendary

Activity: 1008

Merit: 1007

Quote from: Fuserleer on January 11, 2016, 03:38:50 PM

Plus we are forgetting one critical component in this scenario of yours which has been overlooked here repeatedly. The challenges. You'll be getting 10,000+ of them about every minute, 166 of them a second, and none of them will be the same and they are significant work. You'll have to hit the DB and do the work because you can't cache all the data, plus then the processing and creating the solution proof.

And you still havent acknowledged the pipe cost.

That's like a busy website, but it isn't going to break the bank. This is a major flaw with this design, I'm sorry to say.

You can fix it, though - and I've mentioned this before, throw away the trust model and use POW for voting on transactions.

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: TPTB_need_war on January 11, 2016, 03:30:08 PM

It costs at most half of 39.85 terawatt-hours of electricity per year to attack Bitcoin and you guys are arguing about the costs of 10,000 servers only.

Which is IMO a ridiculous amount of power to waste securing $4B of market cap.

Isn't this constructive arguments? Monsterer posted an example, and we are discussing it to discover if this particular problem holds up.

Whats wrong with that?

Eventually we'll either find one that doesn't, or we won't. Instead of just accepting your hypothesis that it doesn't work without any concrete reasoning behind it other than "I know best!"

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: monsterer on January 11, 2016, 03:27:10 PM

Quote from: Fuserleer on January 11, 2016, 03:22:32 PM

Hmm Im not convinced you'd be able to get the performance required to the DB even with the most exotic of caching/read and write tricks. You could maybe memdb it, but then you need a hefty amount of RAM, which again costs.

Has anyone actually tried to benchmark 10000 "nodes" reading and writing to a single DB on decent commodity hardware, let alone the high end stuff? I don't think it would be very pretty.

Plus, what about the pipe, thats a hefty pipe you'd need to serve up 10000 nodes.

In this scenario, you don't actually have 10000 x the DB load, you don't need 10000 DB writes to commit one transaction, you just need one. So, the load on the DB is equivalent to having 1 node. Reads can be cached and then served and farmed out to the 10000 ports.

In memory traffic is fast, a lot faster than DB traffic, so the load on the server would be high, but not untenable. It would just be like a busy website.

No, you're right that is my bad, you don't need 10000 writes per transaction. Essentially in this instance the 10k ports are the same as accepting 10k connections on the same port, but I still maintain that you would need one hell of a machine to manage, maintain those 10000 connections, ports, whatever.

Plus we are forgetting one critical component in this scenario of yours which has been overlooked here repeatedly. The challenges. You'll be getting 10,000+ of them about every minute, 166 of them a second, and none of them will be the same and they are significant work. You'll have to hit the DB and do the work because you can't cache all the data, plus then the processing and creating the solution proof.

And you still havent acknowledged the pipe cost.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

Yeah I am dumb and details don't matter:

Quote from: TPTB_need_war on January 11, 2016, 03:35:41 PM

Quote from: monsterer on January 11, 2016, 03:33:23 PM

Quote from: TPTB_need_war on January 11, 2016, 03:25:43 PM

1. I didn't ask what their incentive is. I asked why MUST they? In block chain design, they MUST reference the longest chain. The distinction may be important in scenarios, e.g. #2 below or others.

2. It can't reference two chains with double-spends in the history. That is invalid.

1. No one forces them to do anything, but if they chose the shortest stream of work, they won't get confirmed in a timely manor.

2. Is the entire branch with the double-spend discarded in Iota? I would have thought not, because that would mean clients would need to resubmit all their transactions, since there are no miners to place them in the longer chain for them. It ought to be possible to keep the double spend branch, but just not apply the double spend transaction, since it spends an already spent output?

1. But it may not always be unambiguous or other reasons that they can't do what you think they are incentivized to do. MUST is not the same as incentive. Be very careful in analyzing the details of consensus designs.

2. The transactions that follow the double-spend must be because they include the double-spend by referencing it. You need to study more closely the concept of the DAG. The transactions reference prior transactions. I thought you know that. So if there is a double-spend, but isn't known to be a double-spend until later, then all the transactions that referenced it will be potentially reversed. But again which set? It is ambiguous. Thus chaos of forks.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

It costs at most half of 39.85 terawatt-hours of electricity per year to attack Bitcoin and you guys are arguing about the costs of 10,000 servers only.

Besides I am confident there is a simpler fundamental flaw. That is the proof of history isn't provable. But I will need all the details in order to show it.

monsterer

legendary

Activity: 1008

Merit: 1007

Quote from: Fuserleer on January 11, 2016, 03:22:32 PM

Hmm Im not convinced you'd be able to get the performance required to the DB even with the most exotic of caching/read and write tricks. You could maybe memdb it, but then you need a hefty amount of RAM, which again costs.

Has anyone actually tried to benchmark 10000 "nodes" reading and writing to a single DB on decent commodity hardware, let alone the high end stuff? I don't think it would be very pretty.

Plus, what about the pipe, thats a hefty pipe you'd need to serve up 10000 nodes.

In this scenario, you don't actually have 10000 x the DB load, you don't need 10000 DB writes to commit one transaction, you just need one. So, the load on the DB is equivalent to having 1 node. Reads can be cached and then served and farmed out to the 10000 ports.

In memory traffic is fast, a lot faster than DB traffic, so the load on the server would be high, but not untenable. It would just be like a busy website.

Fuserleer

legendary

Activity: 1050

Merit: 1016

Quote from: monsterer on January 11, 2016, 03:12:21 PM

Quote from: Fuserleer on January 11, 2016, 03:08:42 PM

Even if you could do it, 10000 ports would be 10000 connections lets say.

You'll be getting transactions, tx requests and sync status updates from 10000 nodes, to which you HAVE to reply or you lose you connection (and thus possibly an endorsement). Aside from thrashing the crap out of the DB you'll need a big fat pipe.

In our tests a node connected to 8 others at 100+ tx/s load is processing about 250KB/s downstream and about 120KB/s up. Divide that by 8 and multiply by 10000 = 150,000KB/s or 1.2Gbits upstream.

So you need a machine that can handle potentially millions of DB requests per second, and a pipe that can handle over 1.2Gbits upstream and at least double downstream. Or are those things trivially cheap too?

Not really - I'd just have one grunt process for all the DB reads/writes and then pipe/queue/cache all the external network requests from the other processes, because having multiple databases is totally redundant in this case... after all it's just one machine.

Hmm Im not convinced you'd be able to get the performance required to the DB even with the most exotic of caching/read and write tricks. You could maybe memdb it, but then you need a hefty amount of RAM, which again costs.

Has anyone actually tried to benchmark 10000 "nodes" reading and writing to a single DB on decent commodity hardware, let alone the high end stuff? I don't think it would be very pretty.

Plus, what about the pipe, thats a hefty pipe you'd need to serve up 10000 nodes.

TPTB_need_war

sr. member

Activity: 420

Merit: 262

Quote from: illodin on January 11, 2016, 03:16:41 PM

Quote from: monsterer on January 11, 2016, 02:30:39 PM

Quote from: patmast3r on January 11, 2016, 02:17:47 PM

But is it really that easy to own the majority of nodes ? You don't just need the majority of nodes but the majority of nodes that are voting in any given round and to be eligible to vote in the first place also costs, stake or PoW (I think zerotime is PoW/Pos right ?).

That's what I'm trying to establish. As far as I can tell, there isn't any real cost (neither coins or electricity) to obtaining a majority of nodes, but I'll wait for fusilier's reply.

If getting majority of nodes is easy, then the incentive to get the majority and gain financially from the attack is high. And if the incentive is high, then there will be many who want to profit from that and try to get majority of the nodes. But from this follows that getting the majority is not easy anymore.

So if the incentive is to short the coin, then they are all competing to help each other. So the cost will be low because they can see the attack working before they get the majority individually.

illodin

hero member

Activity: 966

Merit: 1003

Quote from: monsterer on January 11, 2016, 02:30:39 PM

Quote from: patmast3r on January 11, 2016, 02:17:47 PM

But is it really that easy to own the majority of nodes ? You don't just need the majority of nodes but the majority of nodes that are voting in any given round and to be eligible to vote in the first place also costs, stake or PoW (I think zerotime is PoW/Pos right ?).

That's what I'm trying to establish. As far as I can tell, there isn't any real cost (neither coins or electricity) to obtaining a majority of nodes, but I'll wait for fusilier's reply.

If getting majority of nodes is easy, then the incentive to get the majority and gain financially from the attack is high. And if the incentive is high, then there will be many who want to profit from that and try to get majority of the nodes. But from this follows that getting the majority is not easy anymore.

Topic: DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?) - page 51. (Read 91144 times)