Re: [ANN] BitcoinDark (BTCD)--Sha-256/PoW-PoS hybrid/Bounty Opportunities

Hello!

I am part of BTCD community now and I happen to be developing a cryptonote fork to add anon features to NXT. It turns out that my methods should apply to BTCD also. I will be working on integrating cryptonote tech into BTCD, but it is more than "just" cryptonote anon tech as I am also making my solution include a near realtime exchange (InstantDEX) so people can directly trade just by running the coin.

How will all this work you ask?
https://github.com/jl777/pNXT has the current source code and it is rapidly being developed.

Once InstantDEX is done, I will be adding Privatebet (peer to peer sportsbook) to the pNXT framework, plus the way it is implemented there is no reason any other number of useful services cant be added.

My efforts are in parallel with all the other BTCD coders and I try to design a clever way to integrate to require minimal changes to the BTCD codebase. So, if I succeed, then all the peoples selling at current prices will not be so happy.
There is no reason that other anon tech in BTCD can't combine with the cryptonote tech, in fact pushing tx through two independent anon algos would only help if it is done properly. So, I bring very good news to BTCD and now I expect a massive in increase in the FUD level

James

P.S. I am not so active on BTT, but you can find out more about me on NXT forums and jl777.org

Will the cryptonote tech lead to any issues with blockchain bloat?

yes,blockchain bloat is an issue for all cryptonote coins, however I chose the boolberry fork to base my work on as it was the most advanced as far as blockchain pruning and just being more efficient. However, I have a plan to use a blockchain FIFO to deal with whatever bloat issues we get. There is no reason to store the entire blockchain, but you do have to process it once. A FIFO is perfect for that, just set the FIFO size to the max lookback window into the blockchain dataset you need (of course you need to store all the keyimages, but that is smaller than the full blockchain). Then after loading the blockchain the first time, all that is left in memory is the FIFO. So as long as you have HDD space you are fine, not limited by system RAM

James

P.S. I am also toying with the idea of using the cryptonote blockchain as a sidechain and maintaining a decentralized ledger. Then we can simply toss the blockchain as soon as there is consensus. However, this is pretty tricky, so most likely not for the first version.

It hasn't been done yet because you if you ever need to revert the blockchain because of a fork, or if an exchange is hacked, then you cannot.

This just encourages hackers to infiltrate exchanges, or even exchanges themselves to take the coins because they know they have them permanently.

Cool idea though.

Not sure what you mean by "it hasnt been done yet"
I happen to specialize in doing stuff that "hasnt been done yet"
So, if you are talking about the blockchain FIFO, just set the FIFO depth to longer than the longest fork, say 3 days. Then functionally the blockchain FIFO will be identical to the full blockchain. The one issue is that it cannot provide historical blockchains for other nodes, so there would need to be reference nodes with the full blockchain. Hmm, maybe something like hubs in a hub and spoke network? Say within the privacyServer?

As far as InstantDEX, yes it is quite an "impossible" problem to solve. That is why it has taken me 3 months to get a workable design that incorporates atomic exchanges. To cover additional cases, I also did a subatomic exchange, that's where you have overlapped and synchronized micropayment channels setup directly between two wallets. No exchange at all. Just direct peer to peer trading. The problems are that it is cumbersome and not so fast to do subatomic trades, but if you want to be able to swap 100 BTC for 1000 BTCD directly, there would be no alternative method.

Now as long as both nodes are on the same fork, then any trades between them will either be nullified or accepted when the fork resolves. If it is nullified, then the protocol would be for both sides to resubmit their tx. Now it is possible that one of the nodes wont be around to do so and the other node is compromised and does only the half of the trade advantageous to do so, but I think the requirement is that if you are trading and it happens that there was a major fork then you need to do some cleanup, if not, then you will lose out, so my guess is that most people will resubmit their tx.

James