Most coins promise so many features and breakthroughs and shills try to hype them.
I have invested in some of them too but when SIM will ROI like BTC and NXT I will be again the one who saw it again.
The rest can go follow stupid pump & dumpers at twitter and NXT AE..
Topic: [ANN][SIM] Simcoin - A Simple Coin - page 13. (Read 157678 times)
At least NxtChg is still work and i trust this guy coz he is really have balls. 
2014/08/24 Monero Blockchain Spam Attack - Post Mortem
On 2014/08/24 a spam attack was launched against the Monero blockchain. Up to that point, Monero had a relatively low fixed fee per transaction of 0.005 XMR (under 1 US cent per transaction). This allowed the attacker to broadcast extremely large transactions every 5 seconds.
For the most part, the network worked as expected. The dynamic block size limit allowed the max block size to grow, and transactions were broadcast without incident. However, the (relatively) slow expansion in the median block size, among other things, lead to some transactions taking some time to confirm. This is not the usual turn of events - normally an increase in usage occurs over a couple of days in a best case scenario (Monero is featured on Dr Phil and Oprah, and every Monero user gets a whale once they check under their seat). At its worst, there were ~400 transactions in the memory pool that were waiting to be confirmed. The sudden, sharp, drastic increase means that the network needed to adjust, and in the interim some transactions took anything from a few extra minutes to an hour longer than usual.
On 2014/08/24 a spam attack was launched against the Monero blockchain. Up to that point, Monero had a relatively low fixed fee per transaction of 0.005 XMR (under 1 US cent per transaction). This allowed the attacker to broadcast extremely large transactions every 5 seconds.
For the most part, the network worked as expected. The dynamic block size limit allowed the max block size to grow, and transactions were broadcast without incident. However, the (relatively) slow expansion in the median block size, among other things, lead to some transactions taking some time to confirm. This is not the usual turn of events - normally an increase in usage occurs over a couple of days in a best case scenario (Monero is featured on Dr Phil and Oprah, and every Monero user gets a whale once they check under their seat). At its worst, there were ~400 transactions in the memory pool that were waiting to be confirmed. The sudden, sharp, drastic increase means that the network needed to adjust, and in the interim some transactions took anything from a few extra minutes to an hour longer than usual.
Let me get this right, an unusually large transaction every 5 seconds brought Monero to a halt and required an urgent fork to hike up the fees.
See, what I am talking about?
Almost every coin out there now is a toy coin. The fact that they seem working is just a consequence of the fact that nobody bothered to seriously rattle them.
-Carl Friedrich Gauss
2014/08/24 Monero Blockchain Spam Attack - Post Mortem
On 2014/08/24 a spam attack was launched against the Monero blockchain. Up to that point, Monero had a relatively low fixed fee per transaction of 0.005 XMR (under 1 US cent per transaction). This allowed the attacker to broadcast extremely large transactions every 5 seconds.
For the most part, the network worked as expected. The dynamic block size limit allowed the max block size to grow, and transactions were broadcast without incident. However, the (relatively) slow expansion in the median block size, among other things, lead to some transactions taking some time to confirm. This is not the usual turn of events - normally an increase in usage occurs over a couple of days in a best case scenario (Monero is featured on Dr Phil and Oprah, and every Monero user gets a whale once they check under their seat). At its worst, there were ~400 transactions in the memory pool that were waiting to be confirmed. The sudden, sharp, drastic increase means that the network needed to adjust, and in the interim some transactions took anything from a few extra minutes to an hour longer than usual.
On 2014/08/24 a spam attack was launched against the Monero blockchain. Up to that point, Monero had a relatively low fixed fee per transaction of 0.005 XMR (under 1 US cent per transaction). This allowed the attacker to broadcast extremely large transactions every 5 seconds.
For the most part, the network worked as expected. The dynamic block size limit allowed the max block size to grow, and transactions were broadcast without incident. However, the (relatively) slow expansion in the median block size, among other things, lead to some transactions taking some time to confirm. This is not the usual turn of events - normally an increase in usage occurs over a couple of days in a best case scenario (Monero is featured on Dr Phil and Oprah, and every Monero user gets a whale once they check under their seat). At its worst, there were ~400 transactions in the memory pool that were waiting to be confirmed. The sudden, sharp, drastic increase means that the network needed to adjust, and in the interim some transactions took anything from a few extra minutes to an hour longer than usual.
Let me get this right, an unusually large transaction every 5 seconds brought Monero to a halt and required an urgent fork to hike up the fees.
See, what I am talking about?
Almost every coin out there now is a toy coin. The fact that they seem working is just a consequence of the fact that nobody bothered to seriously rattle them.
Progress report
Wow...it sounds almost like you could write a textbook on DB programming.
(So stop complaining that this project is taking too long – go invest in toy coins that don't pay attention to this kind of stuff).
Not complaining at all...in fact, I'm sitting here regretting that I'm fiat-broke and BTC-locked. If only I had a few thousand to spare, I'd be bothering you with another deposit to SimXchg.
One thing that maybe you could do is to use memory tables to save transactions in memory and periodically dump them in 1 second timeframe onto the disk.
Transactions are already queued in memory as C++ objects, so no need for memory tables.
Yes, my current approach is to accumulate them in a separate thread for some time, then group into a single DB transaction and write.
If checkpointing gets triggered it will not stall the system, because writing is now done in a separate thread and checkpointing doesn't block readers, at least not for any significant time.
Thanks
Hello.
funny image you have put there it made my laugh
--
I also discovered that SQLite doesn't free shared locks unless you explicitly call finalize() or reset() and this makes working with prepared statements a bit of a hassle. Had to write additional code to manage automatic destruction of these statements too...
Databases are hard!
Yes they can be very hard sometimes depending on the complexity of the workflow that you need to implement.
One thing that maybe you could do is to use memory tables to save transactions
in memory and periodically dump them in 1 second timeframe onto the disk.
In MySQL (i think SQLite too ) when you create a table you can specify the database engine that you want to be used with this table. Using memory tables can improve performance but then you get other limitation
because if you need transaction and rollbacks this features are not supported in memory tables.
funny image you have put there it made my laugh
--
I also discovered that SQLite doesn't free shared locks unless you explicitly call finalize() or reset() and this makes working with prepared statements a bit of a hassle. Had to write additional code to manage automatic destruction of these statements too...
Databases are hard!
Yes they can be very hard sometimes depending on the complexity of the workflow that you need to implement.
One thing that maybe you could do is to use memory tables to save transactions
in memory and periodically dump them in 1 second timeframe onto the disk.
In MySQL (i think SQLite too ) when you create a table you can specify the database engine that you want to be used with this table. Using memory tables can improve performance but then you get other limitation
because if you need transaction and rollbacks this features are not supported in memory tables.
thank you, always nice to read the weekly progress report...
Progress report
Tentacles are not always helpful... this is why it's taking so long...
--
Two days spent developing Sim Explorer, including PHP code to parse transaction blobs from the database. The fact that PHP doesn't have 64-bit integers makes things a bit more complicated.
Also converted my NxtAddress PHP classes into Simcoin format and tested.
Did some tests to make sure transaction ID doesn't cause significant collisions.
--
Working on finalizing the design and coding transaction pipeline and client protocol. Drew a detailed diagram of node's transaction pipeline.
--
The rest of the week was spent battling with SQLite performance: turns out that after I've replaced my old HDD with WD's Red, the transaction speed dropped to just 4 per second!
This makes my blood boil. Can you believe that a modern HDD can safely write only 4 things per second?! What the...
I guess, this is mostly because of WD's "intelliPower" marketing BS, which in reality probably means "5400 RPM or slower". Barracuda with 7200 RPM is about 4 times faster and SSD is about 7 times. Still, ridiculously slow.
OK, to be honest, these numbers are not yet catastrophic, they don't mean 4 TPS, because inside one database transaction I can write thousands of Simcoin transactions.
But when this transaction finally gets committed, the system will freeze for the same 500 M ticks (250 ms) and during that time I cannot do anything with the database, can't even read it, so the whole system is stalled.
If you are aiming for <1 sec confirmations, this is unacceptable. I can't just put everything on hold for 250 ms. Even 50 M ticks is too much.
The only solution seems to be switching SQLite to WAL mode and doing all writes in a separate thread. So I recompiled SQLite again, now with multi-threading turned on. I hate to do it, but using threads seems like the lesser of two evils.
Now the code needs to be reorganized to separate writes from reads and probably also to add queues to handle writing stalls.
It's annoying when libraries don't work out of the box and require a lot of reading and testing to figure out how to make them work the way you need. That's why I am a big fan of the NIH syndrome.
Anyway, I did a hell of a lot of tests with various combinations of settings, locking modes, journaling modes, multi-threading modes, checkpointing modes, page sizes, auto-checkpointing intervals, same/different database connections, tried manual checkpoints in a separate thread, all this while measuring average/peak performance of concurrent writes and reads on both WD and SSD drives. (So stop complaining that this project is taking too long – go invest in toy coins that don't pay attention to this kind of stuff).
The end result is documented in my local wiki and I am now confident that after the changes the system will be able to handle at least 100 TPS even on consumer-grade hardware or VPS.
--
I also discovered that SQLite doesn't free shared locks unless you explicitly call finalize() or reset() and this makes working with prepared statements a bit of a hassle. Had to write additional code to manage automatic destruction of these statements too...
Databases are hard!
Tentacles are not always helpful... this is why it's taking so long...
--
Two days spent developing Sim Explorer, including PHP code to parse transaction blobs from the database. The fact that PHP doesn't have 64-bit integers makes things a bit more complicated.
Also converted my NxtAddress PHP classes into Simcoin format and tested.
Did some tests to make sure transaction ID doesn't cause significant collisions.
--
Working on finalizing the design and coding transaction pipeline and client protocol. Drew a detailed diagram of node's transaction pipeline.
--
The rest of the week was spent battling with SQLite performance: turns out that after I've replaced my old HDD with WD's Red, the transaction speed dropped to just 4 per second!
This makes my blood boil. Can you believe that a modern HDD can safely write only 4 things per second?! What the...
I guess, this is mostly because of WD's "intelliPower" marketing BS, which in reality probably means "5400 RPM or slower". Barracuda with 7200 RPM is about 4 times faster and SSD is about 7 times. Still, ridiculously slow.
OK, to be honest, these numbers are not yet catastrophic, they don't mean 4 TPS, because inside one database transaction I can write thousands of Simcoin transactions.
But when this transaction finally gets committed, the system will freeze for the same 500 M ticks (250 ms) and during that time I cannot do anything with the database, can't even read it, so the whole system is stalled.
If you are aiming for <1 sec confirmations, this is unacceptable. I can't just put everything on hold for 250 ms. Even 50 M ticks is too much.
The only solution seems to be switching SQLite to WAL mode and doing all writes in a separate thread. So I recompiled SQLite again, now with multi-threading turned on. I hate to do it, but using threads seems like the lesser of two evils.
Now the code needs to be reorganized to separate writes from reads and probably also to add queues to handle writing stalls.
It's annoying when libraries don't work out of the box and require a lot of reading and testing to figure out how to make them work the way you need. That's why I am a big fan of the NIH syndrome.
Anyway, I did a hell of a lot of tests with various combinations of settings, locking modes, journaling modes, multi-threading modes, checkpointing modes, page sizes, auto-checkpointing intervals, same/different database connections, tried manual checkpoints in a separate thread, all this while measuring average/peak performance of concurrent writes and reads on both WD and SSD drives. (So stop complaining that this project is taking too long – go invest in toy coins that don't pay attention to this kind of stuff).
The end result is documented in my local wiki and I am now confident that after the changes the system will be able to handle at least 100 TPS even on consumer-grade hardware or VPS.
--
I also discovered that SQLite doesn't free shared locks unless you explicitly call finalize() or reset() and this makes working with prepared statements a bit of a hassle. Had to write additional code to manage automatic destruction of these statements too...
Databases are hard!
Progress is good news
As estimated, it took me less than 2 days to build a basic version of Sim Explorer:
https://simcoin.info/explorer/
This is all I need for development right now. It will grow along with the rest of the system.
Nice https://simcoin.info/explorer/
This is all I need for development right now. It will grow along with the rest of the system.
As estimated, it took me less than 2 days to build a basic version of Sim Explorer:
https://simcoin.info/explorer/
This is all I need for development right now. It will grow along with the rest of the system.
https://simcoin.info/explorer/
This is all I need for development right now. It will grow along with the rest of the system.
Complete this great coin, be rich!
Love the updates. I enjoy reading your updates and Skycoin's updates, usually on a week to week basis.
I also spend the last two days completely occupied by the nxt debacle and was ready to go into damage control but the crisis is for the most part avoided.
I also spend the last two days completely occupied by the nxt debacle and was ready to go into damage control but the crisis is for the most part avoided.
Progress report
Improved consensus is finished and seems working, I also had a couple more ideas how to improve it further and implemented them.
--
Most of the time was spent on finalizing bootstrapping design and coding it. It's about 70% complete.
--
Spent a day trying to get rid of signatures. Guy Fawkes scheme was a big inspiration, unfortunately it means more than doubling confirmation time, so it's not an option.
It's certainly possible to at least not store signatures in the database and not verify them on bootstrapping, but I feel that relaxing security is too much of a risk at this point.
Distributed consensus is hard enough as it is, it's impossible to foresee all kinds of attacks, so for now the signatures stay. Storage is cheap, plus transaction history can be easily truncated at any point.
--
Spent some time solving a problem with one of the exchange deposit transactions.
--
Spent a day following the NXT's 50 M debacle, but it was well worth it.
(I had some NXT on Bter, so my smile was a bit fainter)
There are a few people in NXT community whose opinions I enjoy reading and I learned a lot from this incident.
At first, I was thinking that maybe Simcoin should have a built-in rollback capability, activated by the voting system, but now it seems that policing the blockchain is a bad idea.
Mature industry, account control, insurance and decentralized exchanges/services is the way to go.
--
Was thinking about micropayments (see the previous post). Seems like it will be possible with my account control.
It's actually a very nice feature to have, because such transactions are even faster, have no fee and don't bloat the database at all!
--
Started working on Sim Explorer ("blockchain explorer" in other coins).
I considered posting a bounty, but then realized that, since PHP scripts will just read SQLite database and that Simcoin doesn't have a blockchain and in general is very simple, I could write it in a day or two myself – much faster than finding somebody and then explaining to him how Simcoin works.
So hopefully you will see it in the next few days.
And somebody, please, tilt the Earth already!
Improved consensus is finished and seems working, I also had a couple more ideas how to improve it further and implemented them.
--
Most of the time was spent on finalizing bootstrapping design and coding it. It's about 70% complete.
--
Spent a day trying to get rid of signatures. Guy Fawkes scheme was a big inspiration, unfortunately it means more than doubling confirmation time, so it's not an option.
It's certainly possible to at least not store signatures in the database and not verify them on bootstrapping, but I feel that relaxing security is too much of a risk at this point.
Distributed consensus is hard enough as it is, it's impossible to foresee all kinds of attacks, so for now the signatures stay. Storage is cheap, plus transaction history can be easily truncated at any point.
--
Spent some time solving a problem with one of the exchange deposit transactions.
--
Spent a day following the NXT's 50 M debacle, but it was well worth it.
(I had some NXT on Bter, so my smile was a bit fainter)
There are a few people in NXT community whose opinions I enjoy reading and I learned a lot from this incident.
At first, I was thinking that maybe Simcoin should have a built-in rollback capability, activated by the voting system, but now it seems that policing the blockchain is a bad idea.
Mature industry, account control, insurance and decentralized exchanges/services is the way to go.
--
Was thinking about micropayments (see the previous post). Seems like it will be possible with my account control.
It's actually a very nice feature to have, because such transactions are even faster, have no fee and don't bloat the database at all!
--
Started working on Sim Explorer ("blockchain explorer" in other coins).
I considered posting a bounty, but then realized that, since PHP scripts will just read SQLite database and that Simcoin doesn't have a blockchain and in general is very simple, I could write it in a day or two myself – much faster than finding somebody and then explaining to him how Simcoin works.
So hopefully you will see it in the next few days.
And somebody, please, tilt the Earth already!
One reason to implement flexible account control is that it will allow things like micropayments.
This makes it possible to execute tiny transactions off-chain.
So this is how it would work: you time-lock an account, allow only 1 outgoing transaction and then require 2 signatures to send this transaction.
The buyer sends account's passphrase to the seller.
He then keeps re-signing his part, increasing the value (same as in bitcoin), and then before the lock expires, the seller can redeem the money.
After that the buyer gains full control of his account (only 1 signature is now required), so he can take all the unspent money back.
This makes it possible to execute tiny transactions off-chain.
So this is how it would work: you time-lock an account, allow only 1 outgoing transaction and then require 2 signatures to send this transaction.
The buyer sends account's passphrase to the seller.
He then keeps re-signing his part, increasing the value (same as in bitcoin), and then before the lock expires, the seller can redeem the money.
After that the buyer gains full control of his account (only 1 signature is now required), so he can take all the unspent money back.
Go ahead NxtChg, these things take their time.
I think this is the first coin, that is fast enough to be used in point of sale situations.
So the future might be really bright
I think this is the first coin, that is fast enough to be used in point of sale situations.
So the future might be really bright
Spent most of the time today trying to get rid of signatures, at least in some places, because out of 96 bytes in SIM transactions 64 is the signature.
This is very tempting. Removing signatures would allow to cut bootstrapping/history traffic by 2/3 and make database about 50% smaller!
Also verifying signatures is very expensive and puts an upper limit on TPS and bootstrapping speed.
Unfortunately, not much progress, though I managed to come up with some interesting ideas...
That's one example of why this project is a bit slow - research is a big part of it, i.e. trying to solve problems and thinking how to do something better.
This takes time and often leads to multiple dead ends, and there is no guarantee that you'll ever find a solution
This is very tempting. Removing signatures would allow to cut bootstrapping/history traffic by 2/3 and make database about 50% smaller!
Also verifying signatures is very expensive and puts an upper limit on TPS and bootstrapping speed.
Unfortunately, not much progress, though I managed to come up with some interesting ideas...
That's one example of why this project is a bit slow - research is a big part of it, i.e. trying to solve problems and thinking how to do something better.
This takes time and often leads to multiple dead ends, and there is no guarantee that you'll ever find a solution
@Pentamon
Sim-Ipo is over, Ora "IPO" is over. Let me here your schedule to bring them in one boat. But a lovely dream indeed
Sim-Ipo is over, Ora "IPO" is over. Let me here your schedule to bring them in one boat. But a lovely dream indeed
Yes, I know. I am happy to say I am in Sim for long term. And in Ora.
Interesting how we get split up in these different projects.
"Come together, now!"
Pentamon
Jump to: