"Dark days for Sia =/. But filecoin is also broken, permacoin is not efficient, maidsafe is opaque and very difficult to audit, and storj is underspecified"
https://bitcointalksearch.org/topic/m.9105286
Topic: [ANN][SIM] Simcoin - A Simple Coin - page 9. (Read 157763 times)
Decentralized systems are hard. Now it seems Sia hit a dead end:
https://bitcointalksearch.org/topic/m.9105286
https://bitcointalksearch.org/topic/m.9105286
Progress report
Not much to report, because I am currently mostly working on many small things, instead of adding major features.
--
Replaced the ugly "busy" screen in the client with a nice, embeddable progress bar:
--
Spent two and a half days (!) trying to track down the cause of a weird random crash in the client.
The crash happened only occasionally when 2 exposed API functions were called from 2 JavaScript timers and only when they returned strings of significantly different lengths
Couldn't use the debugger because it crashed as well – seems like using IE as an OLE object from one DLL inside another DLL, linked from main EXE, while exposing DLL's API functions to JavaScript timers via another OLE object, utterly confused it
Anyway, as usual with memory corruption, had to follow several wrong trails before finally stumbling upon what seems to be the main problem: for some reason IE doesn't like when the arguments he passes to my Invoke() are converted in place with VariantChangeType(args->rgvarg, args->rgvarg, 0, VT_BSTR).
At this point I envy Java and Node.js coin developers...
Not much to report, because I am currently mostly working on many small things, instead of adding major features.
--
Replaced the ugly "busy" screen in the client with a nice, embeddable progress bar:
--
Spent two and a half days (!) trying to track down the cause of a weird random crash in the client.
The crash happened only occasionally when 2 exposed API functions were called from 2 JavaScript timers and only when they returned strings of significantly different lengths
Couldn't use the debugger because it crashed as well – seems like using IE as an OLE object from one DLL inside another DLL, linked from main EXE, while exposing DLL's API functions to JavaScript timers via another OLE object, utterly confused it
Anyway, as usual with memory corruption, had to follow several wrong trails before finally stumbling upon what seems to be the main problem: for some reason IE doesn't like when the arguments he passes to my Invoke() are converted in place with VariantChangeType(args->rgvarg, args->rgvarg, 0, VT_BSTR).
At this point I envy Java and Node.js coin developers...
Not to bash the Crypti team, but as I understand the main network is offline for 4-5 days already? Was it worth it to rush things?
These guys couldn't do it in 60 seconds, I am trying to do it in under one. Now you can appreciate the difficulty of the task a bit better.
Also, seems like I am right putting a lot of thoughts into DDoS mitigation, possible attack vectors, general reliability, etc. This is no joke.
By the way, what a lame excuse: "What? Internet connections can be slow? Uh, we didn't know..."
Anyway, I like Crypti and wish them well. Hopefully they will fix it soon.
The issue is, you can't test for everyones varying hardware setups, network connections, or delays in requests and that makes getting all of the requests and consensus difficult to map out. Our system worked perfectly when scaled on 50 nodes running on different hosting platforms and our scaling projections appeared as though it would work up to 10s of thousands of nodes with no problem.
And then we launched. The system actually worked quite well at first but once the nodes started to climb and we started to see people running them in very different locations and sometimes improperly setup on different hardware and connection speeds which caused unforeseen bugs to pop up. We also saw several attacks on the network in just the short time it has been around. We saw malformed packets, DDoS attacks on nodes, as well as people sending fake requests, or at least, what to the network looked like fake requests. These various aspects were hitting the fork processing so often that the network was starting to skip blocks and hit 2 minute, sometimes 3 minute block times. Over time, it was causing the network to stop. This is unacceptable so changes needed to be made.
Bottom line is, you can't prepare for every possible occurrence and these are growing pains that Bitcoin and NXT both saw in the early days. They saw multiple attacks and even rolled back their block chains multiple times throughout their early days.
Keep in mind, we have posted an entire write-up on how the system is meant to work. You are more than welcome to try to "restart" and come up with a solution. We are always open to input from the community. The problem is that in order to use node-uptime as a property in our system, all nodes must send out requests saying they are alive with specific information and those requests must all get accepted and confirmed through the network with consensus and must do it in a 60 second timeframe. If you have any idea what that means, it's not an easy task, especially when you start incorporating slow connections, systems with different time settings (which we saw when we added windows), and attacks on nodes disrupting the entire system.
And then we launched. The system actually worked quite well at first but once the nodes started to climb and we started to see people running them in very different locations and sometimes improperly setup on different hardware and connection speeds which caused unforeseen bugs to pop up. We also saw several attacks on the network in just the short time it has been around. We saw malformed packets, DDoS attacks on nodes, as well as people sending fake requests, or at least, what to the network looked like fake requests. These various aspects were hitting the fork processing so often that the network was starting to skip blocks and hit 2 minute, sometimes 3 minute block times. Over time, it was causing the network to stop. This is unacceptable so changes needed to be made.
Bottom line is, you can't prepare for every possible occurrence and these are growing pains that Bitcoin and NXT both saw in the early days. They saw multiple attacks and even rolled back their block chains multiple times throughout their early days.
Keep in mind, we have posted an entire write-up on how the system is meant to work. You are more than welcome to try to "restart" and come up with a solution. We are always open to input from the community. The problem is that in order to use node-uptime as a property in our system, all nodes must send out requests saying they are alive with specific information and those requests must all get accepted and confirmed through the network with consensus and must do it in a 60 second timeframe. If you have any idea what that means, it's not an easy task, especially when you start incorporating slow connections, systems with different time settings (which we saw when we added windows), and attacks on nodes disrupting the entire system.
These guys couldn't do it in 60 seconds, I am trying to do it in under one. Now you can appreciate the difficulty of the task a bit better.
Also, seems like I am right putting a lot of thoughts into DDoS mitigation, possible attack vectors, general reliability, etc. This is no joke.
By the way, what a lame excuse: "What? Internet connections can be slow? Uh, we didn't know..."
Anyway, I like Crypti and wish them well. Hopefully they will fix it soon.
Progress report
This week I was working on refactoring the bootstrapping protocol and unifying node and client bootstrapping.
Since I lost about 2 weeks in September and also did some client refactoring, which wasn't planned, the core release is moved to somewhere in October. Hopefully
This week I was working on refactoring the bootstrapping protocol and unifying node and client bootstrapping.
Since I lost about 2 weeks in September and also did some client refactoring, which wasn't planned, the core release is moved to somewhere in October. Hopefully
Nevermind! Thanks for the update!
Do what you have to do you know the best!
Progress report
This week I was working on refactoring the bootstrapping protocol and unifying node and client bootstrapping.
Since I lost about 2 weeks in September and also did some client refactoring, which wasn't planned, the core release is moved to somewhere in October. Hopefully
This week I was working on refactoring the bootstrapping protocol and unifying node and client bootstrapping.
Since I lost about 2 weeks in September and also did some client refactoring, which wasn't planned, the core release is moved to somewhere in October. Hopefully
DPOS is bullshit.
Why? The problem with PoS systems is that not enough stake is securing the system, which makes attacks easier.
When you switch from flat to hierarchical model, i.e. from "everyone is a node" to "a bunch of master nodes", the problem becomes more severe. In case of btsx they have a fixed number of nodes, 101, right?
Delegated PoS allows you to increase the stake of nodes.
Now, I am not convinced yet, because when you lend your money with almost no consequences for you, there's no guarantee that an attacker won't be able to trick you to lend him your stake. So attacks might actually become easier in DPoS.
You can probably verify that all of the nodes are honest when you have 101 of them, and that's the road btsx took. But small number of master nodes makes you extremely vulnerable to DDoS (which are quite cheap nowadays).
I've considered DPoS several times. Maybe we can find some better solution to increase the size of node's stake.
use DPOS as btsx?
Please do not do this. DPOS is bullshit.
use DPOS as btsx?
Progress report
So the voting system design is basically finished. I will probably have no time to code it before the core release, but I needed to design it to make sure no major changes are required to implement it.
The rest of the week spent refactoring the client – I didn't plan to do it, but this test client became so messy that it's hard to change anything.
Also updated client's design to match the rest of Simcoin sites, which will probably be good for the price because people judge things by how they look, not what's under the hood, and the old client was ugly. Need to take care of my investors, eh?
So the voting system design is basically finished. I will probably have no time to code it before the core release, but I needed to design it to make sure no major changes are required to implement it.
The rest of the week spent refactoring the client – I didn't plan to do it, but this test client became so messy that it's hard to change anything.
Also updated client's design to match the rest of Simcoin sites, which will probably be good for the price because people judge things by how they look, not what's under the hood, and the old client was ugly. Need to take care of my investors, eh?
how will voting be done/managed ?
in ones' qt/wallet ?
can there be reminders in built that one has set up a vote?
in ones' qt/wallet ?
can there be reminders in built that one has set up a vote?
There will be a special page "Voting" where you can see all the polls in the system, from fresh to old. New polls will be marked in bold, same as unread messages. Each poll has a description, so again, similar to messages.
And yes, you will see notifications about new polls. Someone can even develop a service to send notifications via email, text messages, etc. upon various events in Sim. I can allocate a bounty for it if it's open-source.
Users can vote several times, in case they change their mind, and only the last vote will count.
I am thinking that there should be only one type of voting - by stake, because voting with accounts promotes spam accounts and voting with real money promotes scam polls.
There will probably be a limited number of options per poll - 9.
Not sure yet about poll duration, whether it should be fixed, say, 3 days or the poll creator can specify 1-7 days length.
Ok, I'm an idiot. Just realized I can simply pause the Transaction Gobbler as soon as it detects that a poll has expired and do the calculation.
Gobbler is already working on a separate thread because of my previous DB performance tests, so counting can be done without any hurry.
This means no separate voting account and no locking are required. The system can also do complicated delegation tracing if needed.
The only problem is that some users will forget they voted and move money before the poll is closed, we will need to do something about it.
Gobbler is already working on a separate thread because of my previous DB performance tests, so counting can be done without any hurry.
This means no separate voting account and no locking are required. The system can also do complicated delegation tracing if needed.
The only problem is that some users will forget they voted and move money before the poll is closed, we will need to do something about it.
how will voting be done/managed ?
in ones' qt/wallet ?
can there be reminders in built that one has set up a vote?
Glad I helped you sort out your mind
That's my voodoo ! 
That's my voodoo !
Yeah, thanks to you I realized I can do it at a different point in time
Ok, I'm an idiot. Just realized I can simply pause the Transaction Gobbler as soon as it detects that a poll has expired and do the calculation.
Gobbler is already working on a separate thread because of my previous DB performance tests, so counting can be done without any hurry.
This means no separate voting account and no locking are required. The system can also do complicated delegation tracing if needed.
The only problem is that some users will forget they voted and move money before the poll is closed, we will need to do something about it.
Gobbler is already working on a separate thread because of my previous DB performance tests, so counting can be done without any hurry.
This means no separate voting account and no locking are required. The system can also do complicated delegation tracing if needed.
The only problem is that some users will forget they voted and move money before the poll is closed, we will need to do something about it.
Glad I helped you sort out your mind
That's my voodoo !
Ok, I'm an idiot. Just realized I can simply pause the Transaction Gobbler as soon as it detects that a poll has expired and do the calculation.
Gobbler is already working on a separate thread because of my previous DB performance tests, so counting can be done without any hurry.
This means no separate voting account and no locking are required. The system can also do complicated delegation tracing if needed.
The only problem is that some users will forget they voted and move money before the poll is closed, we will need to do something about it.
Gobbler is already working on a separate thread because of my previous DB performance tests, so counting can be done without any hurry.
This means no separate voting account and no locking are required. The system can also do complicated delegation tracing if needed.
The only problem is that some users will forget they voted and move money before the poll is closed, we will need to do something about it.
You just have to publish the result of the vote few block after the snapshot, this give the nodes time to calculate the vote in parallel of doing the normal transaction process.
So let's say you decide the vote end at block 5000, then it's decided the miners should publish the result on block 5100, then you have 100 block time to do the calculation. You can even give this 5100 block a slightly larger reward so that miners have more incentive to calculate it.
So let's say you decide the vote end at block 5000, then it's decided the miners should publish the result on block 5100, then you have 100 block time to do the calculation. You can even give this 5100 block a slightly larger reward so that miners have more incentive to calculate it.
There are no blocks in simcoin
And the problem is that during the calculation, funds in all accounts must be frozen, so no transactions are possible until the calculation is finished.
--
My current working idea is an explicit locking mechanism, but with only one lock for simplicity.
It works like this:
- you create another account with which you will vote in the system
- you send whatever amount you can afford to freeze at the moment to that account
- when you send a voting transaction, a time lock is set for this account, and the system increments the stake vote counter in the poll
- you can vote in another poll, this will just keep the account locked longer
Polls will expire, after that no more voting transactions will be accepted and the voting is considered closed. For simplicity I am thinking that all polls must have the same length, but this might be a problem if people need to vote on something urgent, so not sure yet.
This seems like the best solution. Can't figure vote delegation and there are some tactical issues too, but other than that, this is how I plan to do it.
is it not plausible to either handle multiple chains? or at least have multiple data types within the single chain.
so voting could be on a more relaxed chain than transactions, or at least a more relaxed time frame.
also different data types could have different arbitrary durations in the chain.
so voting could be on a more relaxed chain than transactions, or at least a more relaxed time frame.
also different data types could have different arbitrary durations in the chain.
I thought about doing some sort of voting tokens, but this has its own problems.
People need to be able to vote with their stake. This means that at the time the poll closes the system has to calculate stakes for everybody who voted and this can take time if 100,000 people voted, for example. During this time balances must be frozen and transactions can't be processed.
What I would like is to have some sort of additional "voting" balance, which is incremented with each voting transaction. But then people can move their stake to another account and vote again.
Another approach would be to charge a fee to convert your account into a voting account, for example 10,000 SIM, and then just count votes. This way people can still vote with their stake by creating lots of dummy accounts, but this is bad for database size.
Last option is to vote with real money, but this is also not a perfect solution and would be a bad choice for many polls.
You just have to publish the result of the vote few block after the snapshot, this give the nodes time to calculate the vote in parallel of doing the normal transaction process.
So let's say you decide the vote end at block 5000, then it's decided the miners should publish the result on block 5100, then you have 100 block time to do the calculation. You can even give this 5100 block a slightly larger reward so that miners have more incentive to calculate it.
SlyWax.
TF design has a "built-in" race condition (which in my opinion is a consequence of its inherent fragility) and this race condition can lead to double spends.
Could you elaborate on this?
Some algorithms are more robust than others.
It's hard to tell anything specific, precisely because some algorithms are more difficult to analyze and figure out all the possible issues, attacks, things like race conditions, etc.
I believe that TF is that sort of algorithm, and this race condition attack seems to prove me right.
Let me elaborate a bit, why this seems like a problem.
TF design has a "built-in" race condition (which in my opinion is a consequence of its inherent fragility) and this race condition can lead to double spends.
It's one thing when you need 51% of stake or PoW to double spend and quite another when it's a race condition in your forging algorithm.
Which you don't even intend to fix, but instead tell people "oh, just wait 10+ confirmations, you'll be alright".
If we give up 51% requirement so easily then anyone can do "instant transactions". They just won't be worth much.
Could you elaborate on this?TF design has a "built-in" race condition (which in my opinion is a consequence of its inherent fragility) and this race condition can lead to double spends.
It's one thing when you need 51% of stake or PoW to double spend and quite another when it's a race condition in your forging algorithm.
Which you don't even intend to fix, but instead tell people "oh, just wait 10+ confirmations, you'll be alright".
If we give up 51% requirement so easily then anyone can do "instant transactions". They just won't be worth much.
DISCLAIMER: I own <500K NXT
Let me elaborate a bit, why this seems like a problem.
TF design has a "built-in" race condition (which in my opinion is a consequence of its inherent fragility) and this race condition can lead to double spends.
It's one thing when you need 51% of stake or PoW to double spend and quite another when it's a race condition in your forging algorithm.
Which you don't even intend to fix, but instead tell people "oh, just wait 10+ confirmations, you'll be alright".
If we give up 51% requirement so easily then anyone can do "instant transactions". They just won't be worth much.
TF design has a "built-in" race condition (which in my opinion is a consequence of its inherent fragility) and this race condition can lead to double spends.
It's one thing when you need 51% of stake or PoW to double spend and quite another when it's a race condition in your forging algorithm.
Which you don't even intend to fix, but instead tell people "oh, just wait 10+ confirmations, you'll be alright".
If we give up 51% requirement so easily then anyone can do "instant transactions". They just won't be worth much.
yes, after <1 second you will be able to spend the funds again and will have a confirmation that it was indeed sent.
Again, I will believe it when I see it.
And how is that different from Bitcoin's unconfirmed transactions?
Still this doesn't make it 100% safe from manipulation.
Seems to me like reliability of this is far below 100%, at the point where everybody will still wait 10+ confirmations just to be sure, nobody wants to lose money.
And there go your instant transactions.
and than comes Simcoin
Jump to: