|
I support OP_CAT, but Bitcoin L2s need more decentralized bridges now. We'll develop BitVMX with optional support of OP_CAT, so that we can make use of OP_CAT if/when it is activated.
|
|
|
|
Martin from FairgateLabs created a Blake3 implementation in Bitcoin script. This is the shortest hash function ever implemented in script (only 45K bytes or 11.2K vbytes in a Taproot script). Why implement a hash function when we have OP_HASH and OP_HASH256 and other opcodes ? Because Bitcoin script currently does not allow the manipulation of individual bytes of the hash digests produced by OP_HASH, so we cannot implement Lamport or Winternitz signatures based on existing opcodes. Having signatures for arbitrary messages (not only the transaction) is essential for proving systems like BitVMX.org. The shortest the code, the cheaper the onchain disputes. (BitVMX is a optimistic proving system for arbitrary programs, based on a virtual CPU. It does not require any hard-fork or soft-fork to Bitcoin.) Specs
The new implementation is compared with the previous one that existed in BitVM. These are the numbers: Bytes Hashed Number of blocks Original Size New Implementation Size Improvement from original 64 1 103k 45k 55.60% 80 2 206k 91k 55.72% Comparing the max stack height usage: Bytes Blocks Original New New stack-optimized Size 64 1 384 671 550 47K 80 2 448 779 678 95K You can take a look at the PR here: https://github.com/BitVM/BitVM/pull/67Also you can learn more about BitVMX from its paper: https://bitvmx.org/files/bitvmx-whitepaper.pdf. Or you can comment in this thread: https://bitcointalk.org/index.php?topic=5494208.0 |
|
|
|
FYI the BitVMX paper is available at https://bitvmx.org There is a Telegram channel for devs and a twitter account for updates. |
|
|
|
Martin Jonas (BitVMX team) created a SHA-256 code in Bitcoin script that hashes 64 bytes, and the code fits into a standard taproot script. The limiting factor is the maximum script stack (1000 elements). With a larger stack, it could probably be shrank to ~100 Kb. This was a contribution to the BitVM2 implementation in Rust. https://github.com/BitVM/BitVM/pull/65It's interesting the use of nibbles (4-bit words) instead of 32-bit words to operate. That's perfect for tables involving two 4-bit operands (AND, OR, XOR, SHIFT, etc.). Why create a SHA-256 implementation in script if there is a OP_SHA256 opcode? Because Bitcoin script cannot expand the OP_SHA256 output value (32 bytes) into individual bytes in the stack. Therefore, OP_SHA256 cannot be used to check properties of the input and output inside the script. This prevents the use of OP_SHA256 to verify Lamport/Winternitz signatures. (Note: Martin works @ https://fairgate.io and he is a contributor to the https://BitVMX.org project) |
|
|
|
|
The key differences between BitVM1 and BitVMX are the amount of pre-computation required, the transaction space consumed, and more importantly, the complexity of the solution.
Regarding pre-computation, BitVM1 requires computing large Merkle trees (2^32 elements in size). BitVMX does not require to compute any Merkle tree.
Regarding onchain footprint, in the optimistic case, both BitVM1 and BitVMX require just one multi-signed transaction. But in the pessimistic case, if one of the parties is malicious, then BitVM1 may require more than 250K of virtual bytes (in total between both parties). This is my estimation, not a precise number, because BitVM1 was never finished. In contrast, BitVMX consumes less than 160K of virtual bytes.
Also BitVMX can be parametrized to require half the number of interaction rounds compared to BitVM1, at the expense of higher space consumed.
Finally, BitVMX is much simpler. I think anyone will understand it in 10 minutes.
While the bitvmx.org site has some information, the first paper will be published just before BTC++ (May 1, '24).
|
|
|
|
|
Hi OroroMunroe, first congratulations for the launch!
I'm a Bitcoiner since 2012 and I waited many years to this to happen. I worked my last 5 years to for the adoption of Bitcoin sidechains, not only RSK (a.k.a Rootstock) but ALL sidechains, so that Bitcoiners are prepared to take advantage of cryptocurrency innovations without interference with the base layer which guarantees the hard money properties of Bitcoin.
So I'm not only excited, but also emotionally moved when I see that DeFi on Bitcoin already happening. The early RSK team worked hard to integrate sidechains into Bitcoin when we showed in 2016 the first BIP and working code for a drivechain. But since then, the RSK community has been working to create the best possible sidechain technology within the current limitations, and I think we managed to do it. Now RSK has stablecoins, DEXes, and soon margin trading too.
I think open finance and stablecoins are key for mass adoption of Bitcoin, because stablecoins and decentralized exchanges are the lubricant required to frictionless interface with the billions of people that could benefit from it. But building infrastructure takes time, and margin trading is the spark that ignites the rapid development of an open finance ecosystem.
My only remark is that you keep your security to the highest standards possible. We must lead the DeFi movement by showing an example of responsibility towards our users.
|
|
|
|
Ah yes, I've heard of that before. But if that happens, you can still make your Merkle tree larger and most likely not have collisions anymore, right? So this is clearly a bug in the original implementation, but no deal stopper. (And in theory this could be fixed by using a different way to assign slots.)
I agree. You can always use a higher number of slots, with little space wasted for the merge-mining proofs.
With Armadillo, you will never be able to put an arbitrary number of merge-mined chains into a fixed amount of coinbase space.
(Note that I'm not saying Armadillo is a bad idea, I just previously had the impression when talking to miners that coinbase space is a concern for them or for some of them.)
Yes. The space could be a concern, but the monetary incentive to merge-mine is higher than the cost of the extra bytes. I think the major problem for miners to add new merge-mined sidechains is not the space, but the one-time integration cost with a new full node. And the periodic maintenance cost to upgrade it. |
|
|
|
While this is not exactly on topic, I'm curious. Why do you think that the Namecoin scheme does not work and that no other coins would adhere to that scheme? I'm at least aware of three other chains (Namecoin, Huntercoin and Xaya) that all follow that scheme and at least one pool (F2pool) that mines more than one together.
Check it yourself from the algorithm given in the wiki. Also the wiki states this. If merkle_size is a power of 2, when there is a slot collision of slots for some chain ids, then the collision will persist no matter what merkle_nonce you use. I can sent you a code function that checks this by scanning but it's clear from the equations this is true. So I don't know how f2pool is doing it, it will work if it's merging 3 chains, but not for merging 4. |
|
|
|
One thing I wonder about is this: With Armadillo, you need to place the commit-to-parents vector directly in the Bitcoin coinbase input, right? That means that unlike classical merge mining where you have a Merkle tree of mined chains, you can only merge-mine so many (a rather small number) of coins with Armadillo.
About "classical" merge mining: namecoin defined a scheme which AFAIK did not work well for more than one merge-mined chain. No other project simultaneously adhered to this scheme. "specs" here: https://en.bitcoin.it/wiki/Merged_mining_specificationBecause of these flaws, RSK used a single independent tag for its sidechain, not part of a tree of hashes. One of the reasons was the early idea of putting more info in the tag to be seen by the whole network. If it was buried in a tree, the it was obscured. Therefore each merge-mined sidechain would need to consume 12 additional bytes (or more) to save its own armadillo tag. We could define a new standard for merge-mining that enables publishing these additional bytes for each chain Armadillo needs. Given a good standard and enough community feedback, I think RSK community would hardfork to adhere to it. I also think that miners were concerned about coinbase size in the past. Do you think that could be a problem?
I don't think this is a problem now. Currently most coinbase transactions have several outputs containing OP_RETURN data that serves different purposes. The amount of space consumed is negligible. Anyway, miners are paying for it. |
|
|
|
Recently RSK (the first merge-mined Bitcoin sidechain) hard-forked to add a feature to increase the security of merge-mining. The new security protection, called Armadillo, is quite simple to understand. The idea is to add to the RSK merge-mining tags additional information that enable the reconstruction of the RSK fork graph even if the actual RSK blocks are hidden from the RSK network. Then, any node can monitor the Bitcoin blockchain and, in case of detecting a malicious hidden fork, emit alerts that flood the RSK network. These alerts are decentralized and Sybil-attack protected. Nodes can choose to enter a temporary "Safe Safe Mode" (to differentiate it from Bitcoin's old Safe Mode  ). In this mode they do not confirm transactions, so high-stake economic nodes, such as Exchanges, won't accept deposits. I wrote an article about how it works and the security it brings here: https://bitslog.com/2019/08/01/armadillo-more-consensus-security-for-rsk/Happy to receive feedback and hear other ideas. |
|
|
|
|
RSK (a.k.a Rootstock) is very active, with more than 20 core contributors, more than 40% of Bitcoin miners engaged in merge-mining and a HSM-protected federation with 15 members around the globe.
Liquid also is quite active.
|
|
|
|
Rootstock (now RSK) seems to offer what you need. It's a merge-mined federated Bitcoin sidechain, compatible to Ethereum. Check www.rsk.co |
|
|
|
Hi! Rootstock was renamed RSK a couple of years ago. The RSK sidechain mainnet has been active since January 2018. The Beta testnet was active for two years without problems. The currency in the sidechain is not called Rootcoin anymore (because some other alt-coin took that name). The coin is called Smart Bitcoin (SBTC) (but don't confuse with a new alt-coin self-called SuperBTC  that an exchange listed also as SBTC). The RSK sidechain has a federated 1:1 peg with Bitcoin. In the future we would like it to become a drivechain. More info in the RSK website https://www.rsk.co/ |
|
|
|
|
Blocks 73 to 77 seems to be mined by Satoshi.
Block 78 was mined by HAL.
My hypothesis is that Satoshi was looking at the debug log on real-time. When he saw that a block had been mined by another person he decided to restart his node (blocks 79 to 125 are his).
|
|
|
|
During 2013..2015, the times different scaling proposals were analyzed, I proposed reducing the block time to 1 minute. I did some research that ended with the DECOR+ PoW consensus algorithm as an alternative to Nakamoto Consensus. Some more info here: https://bitslog.wordpress.com/2014/05/02/decor/The DECOR+ protocol is what powers the RSK Bitcoin Sidechain (check rsk.co). There has been a lot more research about this since 2014. My current understanding is that shorter block intervals down to 1 minute for Bitcoin are ok because block propagation has improved (however the blocks would need to be 1/10th of the current size). For even shorter intervals, more cooperative consensus protocols are required to prevent the generation of stale blocks to be a significant disadvantage. |
|
|
|
RSK brings smart contracts to Bitcoins as a sidechain. Check rsk.co RSK code has been open sourced long ago. You can check its github repo: https://github.com/RSKSmartThe test network has been alive for more than a year! working as a sidechain to the Bitcoin Testnet. Production launch will be close to the end of the year. |
|
|
|
|
Generally most smart contracts created now are ICOs, and are not based on Bitcoin scripting system but on Ethereum. So your question may not belong here.
However I can recommend several companies that do smart contract audits:
- Coinspect.com (mine)
- zeppelin.solutions
- Coinfabrik.com
|
|
|
|
|
After some firmcoin prototypes were created, a new company was built to create firmcoins en masse at low costs. The new design was called Digibill and the company behind it was called Doosra.
Sadly, due to different conflicting visions on how the project should grow, the founding team split and the project was abandoned.
It will someday make a comeback, because it's super cool.
The most similar project is Opendime (opendime.com).
|
|
|
|
|
Show Posts
