DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)

[Fuserleer]

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.

[1714925473]

1714925473

[monsterer]

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.

[TPTB_need_war]

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.

[TPTB_need_war]

Yeah I am dumb and details don't matter:

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.

[Fuserleer]

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.

[Fuserleer]

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!"

[monsterer]

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.

[TPTB_need_war]

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.

[TPTB_need_war]

Data structures don't matter when analyzing designs:

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.

[Fuserleer]

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.

[monsterer]

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]

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.

[TPTB_need_war]

I am so dumb. Really dumb.

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]

I am so dumb. Really dumb.

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]

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]

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.

[monsterer]

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.

[TPTB_need_war]

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.

[Fuserleer]

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.

You had plenty of time to present it, you didn't, your choice

Have a good evening.

[TPTB_need_war]

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.

You had plenty of time to present it, you didn't, your choice

Why should I compete with your noise? What is my incentive to reveal my secrets any way? Like you or anyone is really going to help me code it.  

I have already demonstrated that I can analyze the flaws better than anyone else who is commenting here.