New Cryptocurrency written using 'Rust', looking for another programmer

[mczarnek]

Hello,

I am in the process of writing a new cryptocurrency, because of the uniqueness of the mining algorithm, it needs to be re-written from scratch.  I've started the program using 'Rust' to do this.  I went with Rust because it means it means the transactions processing will be able to be parallelized easier and also because it forces you to write secure code that doesn't have the potential memory risks of C++ but in theory runs as fast as C++ (C++ has had lots of time to optimize itself.. Rust is still newish).

Any chance any developers are out there and interested?  I'd be happy to further explain the idea behind this new coin which I think will grab some attention.. the project just still happens to be in 'Stealth Mode'.


If you want to learn more about Rust developed by Mozilla, I recommend reading this post. It was the eye opener for me:
http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

Or check out rust-lang.org

[Come-from-Beyond]

I went with Rust because it means it means the transactions processing will be able to be parallelized easier...

This is an interesting part. How do you parallelize manipulations on a single ledger?

[mczarnek]

I don't see any reason you can't parallelize transaction processing, which seems to be the majority of the work miners are doing.

I intend to keep basically a running total going for the most frequently used accounts, and as you process a transaction, you check to see if that account had enough money, assets, etc at that moment.  Even if they are out of order, the miner who initially mines them can mine them in either order.

I don't know that I would use it here would have to think through security implications further, but hashing these blocks together to make sure they have the correct hash could be done this way too, you just could keep an accumulator which is basically the 'sum' of all the byte values of transactions so order isn't important, appended to the header info, then at the end you put it through the hashing function.  And when it comes to verifying transactions, similarly it doesn't matter if they are out of order or not, either the block is valid or it isn't.  You can process all transactions in parallel into a buffer that is sorted by changes to individual account ids, then go through and check those all at once, then finally apply them. Each of those steps could be done in parallel.

Granted you would have to verify and manipulate all transactions in the block you are checking before you starting building the new one, but building a new block or verifying a block someone else mined could be done in parallel.

This probably would not be in version one as it is indeed a little trickier, but somewhere does the line, it would be nice to have this easy to add.  You could hope for 3 times speed up of block processing on a 4 core CPU.  Which may someday be significant.

[Come-from-Beyond]

I don't see any reason you can't parallelize transaction processing, which seems to be the majority of the work miners are doing.

Alice has $10, Bob has $0.
Block contains "Alice pays Bob $5" and "Bob pays Alice $5".
One node will accept this block, another node will reject it because thread scheduler will change the order of transaction processing.
More interesting effects will happen during order matching if you have something like Asset Exchange.

[bcdev]

I don't see any reason you can't parallelize transaction processing, which seems to be the majority of the work miners are doing.

Alice has $10, Bob has $0.
Block contains "Alice pays Bob $5" and "Bob pays Alice $5".
One node will accept this block, another node will reject it because thread scheduler will change the order of transaction processing.
More interesting effects will happen during order matching if you have something like Asset Exchange.

Not every transaction depends on the transaction before it. You can parallelize 99.9% of transaction processing and keep 0.01% serial [if one transaction depends on the one before it in the same block].

[Come-from-Beyond]

Not every transaction depends on the transaction before it. You can parallelize 99.9% of transaction processing and keep 0.01% serial [if one transaction depends on the one before it in the same block].

What is the source of your numbers?

[mczarnek]

I don't see any reason you can't parallelize transaction processing, which seems to be the majority of the work miners are doing.

Alice has $10, Bob has $0.
Block contains "Alice pays Bob $5" and "Bob pays Alice $5".
One node will accept this block, another node will reject it because thread scheduler will lead to the opposite order of transactions.

Good point. One fix is to allow account balances to dip into negative, keeping track of which accounts currently have negative  balances. And when finished processing, accept the block only if no such account balances exist.

Again, two steps, each of which can be done in parallel.. or maybe the second step can even just be, "Is list empty?"

[bcdev]

Not every transaction depends on the transaction before it. You can parallelize 99.9% of transaction processing and keep 0.01% serial [if one transaction depends on the one before it in the same block].

What is the source of your numbers?

I don't have a source. I don't think it's needed in this case.
Look at this block for example: https://blockchain.info/block/000000000000000000c0e693dd6c552e8ba40ac63d978f7cef1b49cce03f8c7d
While there are some chains of transactions [I can see even one chain of 10tx!] they are exception. Most of transactions are using transactions from previous blocks. These can be easily parallelized.

Besides, even if you had 4 long chains of 300tx in one block, it'd max out 4 core cpu to 100% allowing for about the same time.

[mczarnek]

Not every transaction depends on the transaction before it. You can parallelize 99.9% of transaction processing and keep 0.01% serial [if one transaction depends on the one before it in the same block].

What is the source of your numbers?

I don't have a source. I don't think it's needed in this case.
Look at this block for example: https://blockchain.info/block/000000000000000000c0e693dd6c552e8ba40ac63d978f7cef1b49cce03f8c7d
While there are some chains of transactions [I can see even one chain of 10tx!] they are exception. Most of transactions are using transactions from previous blocks. These can be easily parallelized.

Even if there were many chains in the block which would make parallel processing difficult [lots of waiting for chain to complete], it'd be quite easy to fix on miner side. [Make chains spread out all over the block, don't keep chain together when you forge a block.]

Something like this could also help where you link transactions back to the ones they rely on seeing first though my initial thought is that dipping into negative balances may be easier to implement and enforce.

[bcdev]

@mczarnek: Do you have in mind a tx-based currency [like Bitcoin] or account-balance-based one [like NXT]?

[Come-from-Beyond]

Got it, guys. What is the name of the currency, so I could spot it when it's released and check how parallelization works?

[bcdev]

Good point. One fix is to allow account balances to dip into negative, keeping track of which accounts currently have negative  balances. And when finished processing, accept the block only if no such account balances exist.

This method is applicable only to payments. It won't work on advanced features like asset exchange.

[mczarnek]

Got it, guys. What is the name of the currency, so I could spot it when it's released and check how parallelization works?

It's going to be a little bit, least 2 months, probably 3ish.

Coin is going to be named 'Fractal', happy to ping you and let you know. Feel free to do the same when you release your new project.

And like I said, parallel processing probably won't be in version 1.

@mczarnek: Do you have in mind a tx-based currency [like Bitcoin] or account-balance-based one [like NXT]?

I'm planning account based, makes blockchain trimming much more compact.

Good point. One fix is to allow account balances to dip into negative, keeping track of which accounts currently have negative  balances. And when finished processing, accept the block only if no such account balances exist.

This method is applicable only to payments. It won't work on advanced features like asset exchange.

Nah, same idea, just treat every asset balance like a seperate account balance for that account.

[bcdev]

Good point. One fix is to allow account balances to dip into negative, keeping track of which accounts currently have negative  balances. And when finished processing, accept the block only if no such account balances exist.

This method is applicable only to payments. It won't work on advanced features like asset exchange.

Nah, same idea, just treat every asset balance like a seperate account balance for that account.

You still have to have some canonical order for market orders.

[mczarnek]

Good point. One fix is to allow account balances to dip into negative, keeping track of which accounts currently have negative  balances. And when finished processing, accept the block only if no such account balances exist.

This method is applicable only to payments. It won't work on advanced features like asset exchange.

Nah, same idea, just treat every asset balance like a seperate account balance for that account.

You still have to have some canonical order for market orders.

True, maybe a little trickier but I don't see it being impossible. Perhaps something like your chaining idea could be involved or the block creator could simply include a numbering for all trades on same asset in same block.  And again, right now I'm focused on version one, assets probably won't be till version 3, and parallelizing their processing until later still.. or perhaps parallelize first, then assets. Either way, I'm still in the early stages of the initial product, eventual parallelization was just meant as one more reason for choosing Rust.

CfB based on the previous conv, sounds like you are too busy for something like this. Bcdev,would you be interested?

[runpaint]

Coin is going to be named 'Fractal'

Would you be interested in doing a coin burn/swap from the original Fractalcoin and making it a relaunch for existing users?  It launched over a year ago, it's already listed on Cryptsy, and it would bring over a small but established base of users.

[mczarnek]

Coin is going to be named 'Fractal'

Would you be interested in doing a coin burn/swap from the original Fractalcoin and making it a relaunch for existing users?  It launched over a year ago, it's already listed on Cryptsy, and it would bring over a small but established base of users.

Yeah, we choose the name first, then we did realize there was a coin with that name. It seemed like the coin died.. market cap of < $6000? Dead site, etc.

Fractal just so perfectly describes one of the key concepts of what is unique about this coin.


We could talk to them, my first inclination is I want to start from scratch but would be willing to talk to them, maybe some very small piece of the coin. Feel free to put some of them in touch with me.

[runpaint]

You're talking to them now.  The dev abandoned the coin and recently offered to release a new wallet if we paid him.  I told him to get lost.

I have a shiny new website, Fractalcoin.us which hosts a blockchain bootstrap, source code, wallet downloads, detailed instructions for beginners who want to mine, and all kinds of links.  But I haven't ever shared that url before now because I'm waiting to get Fractalcoin added at CoinPayments.net, and waiting to get my online store running so I can offer a 25% discount for Fractalcoin.  

I also just donated 15,000FRAC to the faucet at MultiFaucet.tk, which is hosting our block explorer.

The coin supply stands at less than 800,000, and there will never be any more because PoW block rewards are over.  The mining now runs only on transaction fees.  

The DNS seeder is offline, it's hard to find connections, so I'm running multiple nodes and giving people my peers.dat.  Not many people are mining because of the small rewards.  We could use a change.

So if you need an initial distribution, you could accomplish that and absorb the other Fractalcoin at the same time.  

What kind of coin supply and block rewards are you looking at?  Fractal block reward reduction?

[mczarnek]

The coin I am making is pretty unique and different from any other coin I've seen out there.

Let me talk to you via private message, I suspect we could work something out though, particularly if you guys have any developers or marketers that I could hire, such as you.. mostly paying stock options for now but I could probably pay one developer in cash to help with a few of the smaller features required for the initial release. At that point we can get investors and have enough money to hire others.

[50cent_rapper]

The coin I am making is pretty unique and different from any other coin I've seen out there.

Let me talk to you via private message, I suspect we could work something out though, particularly if you guys have any developers or marketers that I could hire, such as you.. mostly paying stock options for now but I could probably pay one developer in cash to help with a few of the smaller features required for the initial release. At that point we can get investors and have enough money to hire others.

Will there be an IPO/ICO