I had thought that there would already be an easy to use module to spawn a p2p network that would synchronize any sort of data that was fast, efficient and mostly in sync.
However, there didnt seem to be any such thing as the concept of “mostly in sync” seems to be at odds with what most decentralized projects are doing. …
It has taken many years to finally be able to put together a fully decentralized system for one of the most demanding usecases, realtime poker. The final piece is a decentralized cashier, which utilizes cryptographic proofs to deposit coins, issue coins, redeem coins. While the cashier is being created specifically for poker, it can actually be used by any game that has balances tied to a player on a “table”.
First, let us start with a bit of background. I have written about CHIPS using lightening network for instant payments, that enables realtime betting. Of course, we are all familiar…
First a brief review of what a Finite State Machine (FSM) is https://medium.com/@mlbors/what-is-a-finite-state-machine-6d8dec727e2c
There are many other resources on what a FSM is and what they can do as it is a well established field. The important thing to note is that FSM can be mapped into a transactionalized CC. What that means is that with a single CC, unlimited numbers of different FSM instances can be defined and used.
I will try to show a very simplistic example to illustrate what a blockchain FSM CC would be like. Since the “events” that can happen can be an arbitrary…
I have written about multichain clusters where they are all setup to be 1:1 fungible with each other. The way it is implemented is so that to issue coins from a cross chain transfer, you need to get proof of the burn of the matching amount. Additionally, you need to make sure the same burn isnt allowed to issue twice, ie. prevent double spends.
Using komodo runtime forks, this cross chain burn/import is a matter of specifying the same clusterid and notarizing it. All the support to do it is built into komodod.
Let us now explore a special case…
after my post last week, the acknowledged expert in the DAA (difficulty adjustment algorithms) zawy https://github.com/zawy12/difficulty-algorithms/issues was kind enough to not only provide feedback, but we ended up working together to fix the problems of my initial solution.
i am a generalist and am always keen on the feedback from specialists in whatever area, but when i am able to work together and we can evaluate my sometimes extreme ideas, with years of specialist experience, then the result is usually quite good.
First, the N*N decay in difficulty that i used in the original implementation was offchain, so it didnt…
First let me describe the problem that is often encountered by small PoW blockchains, which in this context is any blockchain that uses a hashing algorithm and isnt the highest hashrate coin that uses the same hashing.
It is not uncommon for a coin to have less than 1% the hashrate of a specific algo. That means if some miner decides to mine at 100x normal hashrate for a few minutes (this will find many blocks very quickly) he can get a lot of blocks in a very short amount of time. Then jump to the next coin that is…
A few weeks ago while reading the flyclient paper, i came up with the idea for nSPV. Rapidly, i modified komodod to have a -nSPV=1 mode to implement the superlite functionality.
since then i got most of the CC transactions being able to be created from the nSPV=1 client and the fullnode side protocol seems to be getting pretty stable. probably, i should add a protocol versioning to allow seamless updating of the p2p messages for future additions.
last week, i discovered a very cool library called libbtc. it implement all the things needed for a headers only SPV client…
Above is the first ever transaction created by nSPV! nSPV went from idea to initial implementation during this last week. With the rest of the komodo team handling all the day to day aspects of things, i was free to code a simple cli reference client with the following rpc calls:
nspv_hdrsproof prevheight nextheight
nspv_txproof txid height
nspv_spentinfo txid vout
nspv_spend destaddr amount
For each of these rpc calls, there is a corresponding p2p message that is sent to a fullnode and the response is waited for. The reference implementation just…
SPV clients are very useful for wallets that dont want the entire blockchain locally, however as the blockchains grow in length, the number of headers required grows linearly. With equihash coins, the header size is 2kb, so this effect becomes quite a large overhead, ie. 2GB per million blocks. Just for the headers!
If we are willing to use the notarizations as a verified blockhash, we can reduce the number of headers required to just the headers that are in the blocks near the utxo in a specific wallet. …
Back in 2014 when NXT added support for tokens, it was brand new and unexplored territory. The ability to issue tokens and then assign whatever arbitrary value was quite a new functionality, but all of the initial usages were fully centralized around the token issuer. Generally speaking, this is a problem with most tokens as if it is a centralized token, then the failure of the issuer to honor the commitments made for the token and, well, the token would become worthless.
Its not like the token is running a consensus algorithm and protected by hashrate or stake directly. In…