[ANN][SIM] Simcoin - A Simple Coin

[ownerbest]

I think jl777 is megalomaniac now, I don't think supernet will succeed, maybe jl777 will make big money for himselft, you know.

[1714625911]

1714625911

[1714625911]

1714625911

[1714625911]

1714625911

[1714625911]

1714625911

[1714625911]

1714625911

[NxtChg]

I think jl777 is megalomaniac now, I don't think supernet will succeed, maybe jl777 will make big money for himselft, you know.

Oh yeah, that's probably the best word to describe him right now. Thanks, I forgot such a nice word exists

[NxtChg]

Progress report

I think I should stop writing "another slow week", it's becoming a cliché

The client subscription system basically works. Tested it with quarter of a million subscribed addresses - it's very fast.

--

Now I plan to focus on the voting system, because I clearly underestimated it.

At first I thought: well, I will just add it later, how difficult could that be? Turns out, pretty difficult

To allow voting with stake we can either:

1. "color" coins
2. or lock them

1. Color coins

"Coloring" coins is a bad idea: if somebody buys a large amount of coins to increase his voting power, the last thing he wants is to find out that those coins have already been used in this poll and he now can't vote with them. Also tracking what money participated in what polls is complicated.

2.1. Explicit locking

This puts a burden on the user to decide what part of his money to use (and lock) in each poll, and on the system to track these locks. Many people will also wait till the last moment to lock their funds, and this can cause abrupt spikes of activity on the last day of voting, hurting system performance.

2.2. Implicit locking

We could lock the money implicitly by trying to count votes at poll closing time. This is very bad for performance to the point of being infeasible if we want scalability. Plus, you just know that many users will forget that they voted, move or spend money, and then complain that not all their votes counted.

Coin days

We could try to use coin days for voting, but it's a bad idea too: you can only spend them on one poll at a time. This means you can simply "run out" of your voting power.

It also encourages hoarding and adds another dimension to the problem (time), which complicates things - for example exchanges and other services that hold your money will gain excessive power.

Vote delegation

It would be nice to have the ability to delegate your voting power to representatives, but this opens a whole new can of worms...

--

So you see, it's not that trivial.




http://www.youtube.com/watch?v=IoWJkrlptNs

[NxtChg]

Hm, so apparently there is a race condition with TF in NXT, which requires waiting for 10+ confirmations to fix.

https://nxtforum.org/transparent-forging/race-condition-attack/

So much for "TF will solve everything and make transactions instant".

Told ya that TF is fragile.

[TwinWinNerD]

Hm, so apparently there is a race condition with TF in NXT, which requires waiting for 10+ confirmations to fix.

https://nxtforum.org/transparent-forging/race-condition-attack/

So much for "TF will solve everything and make transactions instant".

Told ya that TF is fragile.

This is an elaborate attack, and only worthwhile for bigger amounts, everyone should anyway wait for 10 confirmations with NXT to reach bitcoins security of 1 conf.

This was common knowledge.

[NxtChg]

This is an elaborate attack, and only worthwhile for bigger amounts, everyone should anyway wait for 10 confirmations with NXT to reach bitcoins security of 1 conf.

This was common knowledge.

Is this supposed to be a refutation? Because you just stated the same thing: TF still requires 10+ confirmations.

This shatters all the overexcited posts about how it will make everything instant and take NXT to VISA level. Whether something was "common knowledge" or not has no relevance whatsoever.

How many times have I heard this:

Not to rain on your parade, but NXT TF will allow speeds like this as well.

Right. I'll believe it when I see it.

So far it looks like a very fragile and artificial construct (not to rain on your parade too )

Anyway, with block time = 1 minute, you cannot achieve 1 sec transactions. TPS is not equal to confirmation speed.

TF will enable instant transactions (<1 second confirms), but I am definitely interested if you have a working model right now.

[TwinWinNerD]

This is an elaborate attack, and only worthwhile for bigger amounts, everyone should anyway wait for 10 confirmations with NXT to reach bitcoins security of 1 conf.

This was common knowledge.

Is this supposed to be a refutation? Because you just stated the same thing: TF still requires 10+ confirmations.

This shatters all the overexcited posts about how it will make everything instant and take NXT to VISA level. Whether something was "common knowledge" or not has no relevance whatsoever.

How many times have I heard this:

Not to rain on your parade, but NXT TF will allow speeds like this as well.

Right. I'll believe it when I see it.

So far it looks like a very fragile and artificial construct (not to rain on your parade too )

Anyway, with block time = 1 minute, you cannot achieve 1 sec transactions. TPS is not equal to confirmation speed.

TF will enable instant transactions (<1 second confirms), but I am definitely interested if you have a working model right now.

yes, after <1 second you will be able to spend the funds again and will have a confirmation that it was indeed sent.

Still this doesn't make it 100% safe from manipulation.

[NxtChg]

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.

[peled1986]

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 

[NxtChg]

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.

[klee]

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?

DISCLAIMER: I own <500K NXT

[NxtChg]

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.

[SlyWax]

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.

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.

[NxtChg]

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.

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.

[NxtChg]

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.

[SlyWax]

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.

Glad I helped you sort out your mind

That's my voodoo ! 

[NxtChg]

Glad I helped you sort out your mind

That's my voodoo ! 

Yeah, thanks to you I realized I can do it at a different point in time

[pineapples]

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.

how will voting be done/managed ?
in ones' qt/wallet ?

can there be reminders in built that one has set up a vote?

[NxtChg]

how will voting be done/managed ?
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.

[NxtChg]

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?