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

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.

One second you dont have enough information to make a decision or comment, the next you know for sure it can't work.

Which is it?

Plus you started this thread to talk about all options, not just yours!

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?

You don't seriously think you can fix a design like that do you. I guess I am much more pessimistic than you because I know it can't work in any form. I don't like million-to-1 odds. I have don't have infinite time.

I just want to help; there is always a way to fix obvious flaws, but in order to fix them, they must be exposed and understood first

monsterer it appears to me you are basing your understanding on some past discussions with Fuserleer that I did not read. For example, I don't even know what is this "long con" you two are referring to. I am basing only on what he just wrote today because I did not memorize the details from his primer and I did not participate fully in the prior discussions where you and he went on and on in discussions. So feel free to carry on without me. I don't have enough contextual understanding to analyze his design at this point and I don't feel like doing all the sleuthing you did already. You are really determined to extract the flaw in his design before he formally discloses. Why? Intellectual challenge? Sport?

I am here to be efficient. I was hoping to discuss my design and get some feedback because I told my gf I would have  decision by morning about my future. It is 4am. I am running out of time.

I can just open 10000 ports on one server running the same code, sharing the transaction database and any other overheads between them. This is the essence of the sybil attack.

edit: think about it like this: what *is* a node in your system, a port? A private key? These things are trivially cheap.

If you don't spam and endorse your own nodes, then the the only option is to run a large number of nodes that collect endorsements naturally.

To have any real voting power you would need to be endorsed for 30%+ of all transactions in the network.  Which means that you need to be connected to 30%+ of all transaction producing nodes at all times AND to be the node selected to receive the endorsement by that transaction producing node from all of its connections.  If that node has 4 connections you have a 25% chance of being selected.

Furthermore as transactions are generally made in reaction to some other event, usually outside of the system, you'll never know when any particular node in the system might produce a transaction, so there is no way to target who you need to be connected to and when.  The only way to be sure is to be connected to everyone, at all times.

In the 100 tx/s example I presented above, there will likely be 10000s of transaction producing nodes live in the network, and you need to be connected to them all.  There will also likely be a few 1000 nodes vying for the endorsements, so even if you could handle 1000+ connections per node you control, and you might get a high number of endorsements to that node, you'll only get one vote.  If the selection set for the next vote is just 10 voters (it'll likely be a few 100 at these loads), you only have one vote.....wasted effort.

So lets recap, at 100tx/s network load without spamming, you need 1000s of nodes, connected to everyone, at all times.

People have many times said to me "Well I can just make 1M nodes on Amazon and take over your network" and these people live in lala land with no consideration at all for the cost of operating 1M nodes in the real world.

As per Amazon here http://calculator.s3.amazonaws.com/index.html

1000 Linux t1.micro nodes is $14640 per month - these wouldn't even be able to handle a load of 100 tx/s with 1 connection
1000 Linux m3.medium nodes is $38070 per month - would struggle to keep up
1000 Linux m3.medium nodes is $49050 per month - more like it, HD IO would cope, CPU would struggle with too many connections
1000 Linux m3.large nodes is $97360 per month - would handle up to 300 tx/s and many connections reliably

So you see, 1000 nodes, let alone 1M has a significant cost still attached to it.

Is it my turn now to discuss my design? Just let me know when you are done and I will come back.

I did not force your hand. I told you I would wait for when you want to disclose. You let monsterer pressure you. Stop blaming me.

Can you remind me why I need to spam the network in order to become a validating node?

edit: it seems to me the long con still, applies - or at least the simple sybil majority; if it doesn't cost me anything to become a validating node, it is trivial for my one server to pretend to be 10,000 or more nodes and just sit there acquiring reputation until I have a majority whereupon I can wreak havok.

They don't understand. They are shooting in the dark, and not even factoring in all potential issues because they can't. Lack of information.

Are seriously going to analyze a design when you don't even know the data structures? Do you even know how the consensus is formed on chosing the set B, C, D? And many other details he hasn't stated. This is ridiculous.

There are so many aspects that can be hidden in vague specifications.

So $9000 in fees at 100tx/s load as stated in my post up thread is no real cost?  What planet are you on?

Or it could be this as per https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect


The fact is that others understand at least what I'm trying to convey, and you do not.

You claim that there is ambiguity in my statements, but I don't believe that there is.  Plus, I did state a few times that compressing all the theory into a few forum posts would be difficult.  I did never state that it would be a technical document, and only to highlight some of the under-pinnings.

If you want a more detailed representation of it, then don't force my hand to post information then whine and cry that its not complete, or that it doesn't make sense.

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.

That you don't even understand how you have been ambiguous is evidence of Dunning-Kruger trait. So go on boasting.

Now I am 99.999% sure you can be ignored. You are of inferior intellect. That is why you can't even write a technical document properly. End.

When you release the clear specification, I will cut you down to size. I'm patient. End of this discussion about eMunie from my side (pending the future time I will get the final laugh). You all carry on.

Sure go for it, some here need as much help as we can get 

What a surprise.

Is anybody else having such a hard time as TPTB?

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 ?).

So it's not that easy is it ?

I hope you guys don't mind me chiming in here from time to time