Topic: [ANN][SIM] Simcoin - A Simple Coin - page 5. (Read 157678 times)

UPDATE:

The last transaction on 7th was at 22:50:53, so their window should be at least an hour longer.

Seems that about 3 BTC went to the Good Samaritan, who then returned it to blockchain.info: https://bitcointalksearch.org/topic/reused-r-values-again-581411

Anyone who deposited after 7th got their deposits stolen immediately.

All this time blockchain.info showed me completely different view of things and a valid balance, so I was unaware that somebody was stealing all new deposits.

Users #96, #387, #500, #1176 had their deposits stolen for the total amount of 4.72614335 BTC.

It looks like blockchain info was on a fork or used their own database instead of the real blockchain, so it showed that everything is Ok, but in reality every incoming transaction after 8th got stolen?

https://www.blocktrail.com/BTC/address/12E1nuxThKRSNLSUHAYKcXis3KPpS9834X/transactions

Weird things are happening at blockchain.info - a few hours ago everything looked normal, now the balance is 0 and there are some crazy transactions on 8th, which are not recorded in my database.

Can anyone check this address 12E1nuxThKRSNLSUHAYKcXis3KPpS9834X in the native bitcoin client?

Particularly the balance and all transactions on 8th.

This is weird: https://www.biteasy.com/blockchain/addresses/12E1nuxThKRSNLSUHAYKcXis3KPpS9834X

There was some sort of security incident at blockchain.info and now the main exchange wallet stopped working.

Your money is safe, but no withdrawals are possible at the moment.

Also please don't deposit anything, just in case.

I've contacted blockchain.info to resolve this.

Maybe Stellar's new consensus which Prof. Mazières is working on is taking a similar approach as Simcoin.   That would be big.

Thought about it a bit more, their claim that

"The majority of the network was on ledger chain A. At some point, the network decided to switch to ledger chain B."

means that the system split, and for a few hours each part operated independently, happily reporting that everything is Ok and building a separate transaction history.

This is weird. I can't imagine under what conditions that would be possible in Simcoin - it is designed in such a way that it wouldn't build 2 separate histories. If some catastrophic failure splits the network it will just stop working almost instantly, because I believe that not being able to send money is not as bad as losing it.

In that regard, Simcoin sacrifices some resilience for speed and reliability. Ripple's solution is almost centralized, it's strange they didn't take the same route...

Wow, another one bites the dust, and a big one!

Well, can't say this is a big shock, because when I've read their full paper I was surprised at how bad their system actually was - it made so many assumptions about the state of the network in order to function correctly.


Just wow.

This also shows how difficult the distributed consensus is. Although I hope to do better, every such failure makes me suspect that I am deluded (Sell, sell, sell! )

Also, I can't fall back to Ripple's consensus now if Simcoin's consensus fails, at least not until they invent something better.

Well, let's hope it will work.

Stellar revealed a flaw in Ripple/Stellar consensus. It seems there are still lots of room for better consensus.

https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/

Progress report

Slow week, had to take care of some real life stuff.

So, as you know, I finalized bootstrapper this week, plus reorg. The whole architecture starts to look very simple and elegant.

There are 3 major parts: Transaction Gobbler, Bootstrapper (which now also handles reorg) and the Heart, which handles transaction consensus.

All of them are practically done, yet my to-do list still has a gazillion of small tasks This is the proverbial last 10%, which take another 90% of the time Anyway, we will get there one day.

Also rewrote this piece of garbage: https://github.com/ghedipunk/PHP-Websockets and now I have a nice, simple, non-blocking websockets server in PHP, which can be used for various dynamic web pages: exchange, explorer, web wallet, you name it. Even games

And what does a good little minion or Wayne's World fan say to that? We're not worthy! We're not worthy!

cross fingers

For that, I will reward them generously.

your minions are well behaved 

Me three. 

Same here, I am waiting patiently, quality comes first. Keep up the great work.

Thanks, guys

FWIW, I'm happy to wait.

This is one of the few projects currently in crypto that I don't doubt is going to come through in the long run and I would rather you don't feel pressured to rush out solutions to problems.

Thanks, but this project is behind schedule and a lot of people want to see some tangible results already

So I have to cut a few corners to try and deliver sooner. Mostly things that can be improved later, when we need to handle higher volume.

For reorg I will probably use a combination of two schemes: flush everything, but try to re-download only the relevant section of the history and thus cut the download size about 10 times. Half-assed approach

Besides, this should never happen anyway, it's only for very rare cases.

Please don't take the lazy approach. I mean since you dedicated so much work and currently SIM seems to me that is the only cryptocurrency that we can rely for building something totally new, innovative and stable. Every minute dedicated to research before implementation is of utmost importance, since we avoid future impediments.  

I thought I also give you an update on what I am working on right now.

A big area, which is not yet finished, is reorg. Although the consensus mechanism should be very reliable, there might still be situations, particularly in catastrophic scenarios, where some nodes will have a different view of transaction history and need to reorganize it.

The Reorg Boundary is a point in time beyond which no reorg is possible. Nodes will insist on their view of the history no matter what. It should be some reasonable value and I think 4 hours is a good point.

Now, the lazy solution to deal with reorg would be to just flush everything from the point of fracture and re-download it again. The problem, though, is that at 100 TPS 4 hours can amount to about 200 Mb and at 1,000 TPS it can be 2 Gb!

Granted, this should be extremely rare, and we will probably be at 10 TPS, not 100, for quite some time, so it's more like 20 Mb of transactions, tops.

So here's my current dilemma – be lazy or try to invent some complicated scheme to figure out what changed and then rollback/re-download/apply the differences.

It's quite stupid to re-download everything just because one transaction might be different, but detecting what exactly is different over a hostile and unreliable network, and then merging the changes into main "branch" of history, is also far from trivial, actually bordering on "insanely complicated"

Still thinking about this...