"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 157678 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...
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: