ghost
commented
4 years ago "In my examples I'll assume the parent is 4x faster than the child." Doesn't this assumption render references to BTC as impractical and inappropriate?.
Open zawy12 opened 4 years ago
ghost
commented
4 years ago "In my examples I'll assume the parent is 4x faster than the child." Doesn't this assumption render references to BTC as impractical and inappropriate?.
zawy12
commented
4 years ago I am guilty of rhetoric in the sense I want people to feel it can immediately give BTC security but then I switch to thinking in terms of LTC to get the advantage of it working better. It can work with BTC, but it increases the delay to security.
This describes how an alt coin can use a double-notarization scheme to import BTC or any other coin's chain work directly onto the alt chain to get BTC security directly on the alt chain. It does not need permission from the parent coin or for future alt nodes to have access to the parent chain. Miners, exchanges, and other coin recipients who want confirmation that a double spend is not possible (unless a double spend is occurring on the parent chain) need to have access to the parent coin's node data at the time of transactions and mining.
It forces double-spending attacks to publicize their existence on the parent chain.
The parent coin could be used by up to 1,000 alt coins using this scheme. They would send most of their collected fees (via their miners) to the parent by paying for the parent chain transactions. This allows all the coins to get a level of security that is financed by their combined fees. If BTC is the parent coin, this may enable it to survive state-sponsored attacks as the reward is cut in half every four years and it is trying to survive on fees. It is well-known and even acknowledged by BTC maximalists like Adam Back and Nick Szabo that BTC has a serious security problem as the reward gets smaller and older mining equipment goes dark and could be used for double spending attacks.
Alt coin fees are paid to miners so that they can pay for their expenses and the parent coin txs to approximately break even To send the parent coin txs, miners will buy the parent coin on exchanges on their own with the alt coin or anything else. They will therefore be holders of the alt coin instead of indifferent mercenaries because there is no profit in it. This blocks for-profit miners from having an interest in doing 51% attacks that do not necessarily want to do a double spending attack.
Self-hashing txs will be used to generate coin, separate from the above consensus mining which has fees but no reward. This helps prevent 51% attacks and can enable an alt to have a "true" peg to BTC without coordination from BTC. By "true" I mean the alt's difficulty could be programmed to track BTC's difficulty in a way that the alt coin will not be generated unless a miner has paid the same hashes per reward as BTC miners were paying at the time of his mining.
General Process Alt chain miners look on the BTC chain (or another "parent" or "peer" chain or chains) for a block that contains a special tx called "Note A" that includes the full header of a previous block in the alt chain (that has not been previously cited) and he cites it. "Citing Note A" means "Notarizing the Notarization". It means he creates a special tx called "Note B" (to be placed in the alt chain's block he is mining) that has the full header of the parent block that contains Note A and enough Merkle tree data from that parent block to prove Note A is in that parent block. If he wins the block, he may choose to create a Note A for his block to send to the parent coin for a subsequent alt coin block winner to cite. Anyone else like a foundation can do it, but the miner probably needs to do it. He is motivated to pay the fees to do Note A to prevent his block from being orphaned because chain work is primarily the parent coin's difficulty as will be included on the chain by a future miner's Note B citing his Note A. Notice that Note A is unfortunately not immediately public so the next block's miner can't typically cite it unless the parent coin has a faster block time.
Validators only need to be able to do the POW hash of the parent coin to prove the work in Note B without needing to look at the parent coin's chain or consult its nodes. Note B timestamps the alt coin's header that is in Note A with a high level of security. Note B can reference orphaned parent blocks because the proof of work is directly in the header that Note B contains. To get chain work, validators add the work in Note B to the alt coin's chain work. There may be more than one Note B (for different Note A's not previously cited) in a block or none. Security primarily comes from the enormous work in Note B that validates Note A's timestamp.
Preventing Double Spending Damage An immediate use of this is that it requires a selfish mining attacker to notify "everyone" via the parent coin's chain of his existence if he wants to get the parent coin's work to win a race. This means exchanges and other interested parties can stop confirmations until the attacker makes public his alt coin blocks or until the public alt chain has more parent coin work. This is Mental Nomad's idea that he proposed in 2018 for BTG that eventually resulted in this draft. I thought of Note B as a way to get the parent coin's work directly on the alt coin's chain so that future validators do not need to look at the parent coin and as a way to keep strict chain work rules to determine chain tip winners.
Notes A & B must be issued quickly Note A must be included in the parent coin "soon" after the block with that header is found or it must not get extra chain work. This is because a selfish miner could delay sending many note A's (publication of his existence) and still get the chain work (suddenly) when he makes his existence known on both parent & child chains. The "soon after" requirement means it works a lot better if the parent coin has faster blocks than the child coin. I'll assume parent blocks are 4x faster than the child's. The following is an example rule to prevent this attack (to enforce this "no late Note A's" requirement) while maintaining the requirement that all notes are optional.
Terminology: The timestamp of Note B is the parent block it cites, not the timestamp of the child block that contains it. Similarly for Note A's "timestamp": it's of the child block it cites not the parent block that contains it.
In shorthand:
Since 2% of blocks take longer than 4xT, 2% of Note A's and 2% of Note B's (4% of alt chain blocks) will not allow a parent chain work contribution. This is an intuitive balance between allowing a 4% hole in chain work security (that I can't think of a way to exploit) and getting fast confirmation that there is no attack in progress. This assumes both child & parent do not frequently have long delays from a sudden drop in hashrate.
Importantly, this allows some notes to be out of sequence, does not prevent multiple Note B's in the same child block, and keeps both both A and B note optional. The 4x limit means sometimes an honest attempt to include the notes will not be successful, but an attacker should not be able to exploit this because he does not know ahead of time if that will occur.
Need to Tighten Timestamp Limits for Accurate Time It is important that both coins have timestamps that have less error than the target solvetimes. This can be easily assured by requiring timestamps to be sequential and requiring a future timestamp limit of 1/4 (or even less) the target time (Tp & Tc). Node peer time should not be used, only local time. If BTC or LTC are the parent coin, it seems apparent they will keep timestamps accurate enough despite not meeting these conditions.
Full Header in Note A Prevents Spam Attacks The full header of the child coin in Note A might be included instead of just the hash so that a malicious attacker can't send fake Note A's to delay confirmations. The fees to get Note A's may be (and possibly should be) expensive enough to make this unlikely so that just the hash can be used.
Preventing 51% Attacks By outsourcing and purchasing security (chain work) from a parent, miners being elected for block creation theoretically do not need any reward or fees beyond what is needed to purchase the txs from the parent coin. In this scheme, the child coin only awards fees to miners participating in consensus. Self-hashing txs (see below) are used to generate coin. No profit for consensus mining removes the motivation for 51% attacks that seek 100% of the block rewards and fees (which usually occur without attempting a double spend).
To make attacks more expensive, an advanced (complicated) solution could be that txs specify and require a specific tip block to be in the very recent history of the chain it's going to be included in. It would be invalid if a selfish mining attack tried to include it (the tx did not "see" the private chain when it was sent).
Child Coin Consensus Uses Typical Difficulty Algorithm Difficulty for the child coin is adjusted with a good difficulty algorithm like EMA, ASERT, or LWMA as long as the previous block is the most recent timestamp used (no delay by the use of median timestamps or CN/XMR coins using time when mining begins without updating the timestamp during hashing). Unlike CN coins (and XMR coins?), the block difficulty must be in each of the parent's block headers (there must be something like nBits).
Orphaning Bad Actors Who Do Not Pay for Parent Work Honest miners should actively orphan blocks that are not issuing Note A's. Bad actors will attempt to do this in order to get the child coin fees without paying the parent coin fees. It is easy for honest miners to orphan them because chain work is determined mostly by the parent coin's difficulty.
A problem in orphaning bad actors is that miners will not immediately know if Note A has been issued. If the parent coin is 4x faster, something like 25% of the alt blocks could be solved before it's known if the prior block issued a Note A. A solution is for honest miners to stop mining until Note A is seen, or has had a "fair" chance of being seen. "Fair" might mean 2 parent blocks after the child block, or it could have a flexible definition that miners define outside the coin's protocol, even violating a 2-block suggestion. If seen, miners begin mining on top of the block in question. If not, they begin mining again on the prior block. Not mining is not a problem because they are not mining for profit. Not paying mercenaries to achieve consensus has large benefits. We are only paying for the parent work to secure timestamps on the child consensus decisions.
Fees Flow Up to Parent, increasing timestamp security The parent(s) primarily function as a timestamp server for the children. Fees flow up from the children to the parent in exchange for the timestamps. There could be 1000 children per parent and fees are effectively 0.5% of value transferred, the parent receives 100% the fees, the parent would receive 5x the value transferred in the average child coin. A thousand grandchildren on each of the children could support 1,000,000 coins totaling 5,000,000 tx/s. Fees may increase first linearly and then exponentially as blocks get full. If a parent starts getting full, miners would naturally migrate from children to grandchildren to reduce their fees and therefore the load on the parent. This comes at a cost of being an extra "note-cycle" behind the grandparent's timestamp.
Calculating Chain Work It may be that only the parent coin's difficulty is needed for the alt coin to calculate chain work. The child coin's work may also be added. The fees paid to the parent might also be used in some manner, allowing a more charitable miner to beat a more stingy one.
Fee Problems There are issues involving fees that I not yet thought out. This section is for a future edit. For example, if there are not enough fees to reimburse the child miner for the parent coin fees for Note A, do block delays cause a problem due to the < 4xTc requirement that prevents chain work from being counted? Will miners need to agree on how to delay txs in order to evenly distribute fees so that difficulty is and solve times are relatively constant? Should the < 4xTc limit be increased as delays are observed?
Self-Hashing Transactions to Generate Coin Rewards (coin generation & distribution) could be done with Self-Hashing Transactions that could prevent the need for pools.
Stable Value Without a Fiat Peg This does not discuss transferring coin like sidechains but that is a possibility. A child coin could peg its value to the parent coin if the parent coin states the reward+fee in its headers (not including any dev fees) in order for the child to see the reward+fees per difficulty in Note B. That would determine the difficulty necessary for self-hashing txs to get coin. In particular so the self-hashing tx would select his difficulty (Dc) and the protocol would use this equation to calculate his reward Rc based on information in Note B and the equation Dc/Rc = Dp/(Rp+Fp). If merchants began to accept the child coin in place of the parent coin (merchants or auction websites should create child coins to greatly reduce BTC fees), then demand for the parent coin remains stable as child coin supply increases. This would motivate stable value in both parent and child coins, even as security in the parent is increased, eliminating the feeling of BTC being a kind of Ponzi scheme, chain letter, or MLM that results from hodlers profiting without creating societal value. Merchants could accept a variety of similar or identical reputable child coins that all have the inherent "value" (cost to create coin at a given point in time). The parent coin could be identical to the child coins except for an understanding that it's the parent. Even if child coins are identical, they would compete to have the lowest fees which could come at a cost of lower security from creating fewer Note A's or a lower child coin consensus difficulty. But lower fees also means the most txs which means it would be a reputable child coin with a longer history. If a reputable coin like this starts getting blocks that are too full, the fees/byte could go up, or its security would be reduced from block size. In either case, a new child coin is motivated into existence, keeping the stable value & competition features. It's exchange price would be lower despite costing the same to acquire (in self-hashing txs) so the people seeking it are really interested in exchange (their motivation is lower fees).
An alternative to a direct peg could be "stable value" achieved by tx fees voting in proportion to their fees to adjust a difficulty per coin setting in the headers. A consensus miner refusing a tx fee that is voting to change the difficulty per coin in a direction he does not want can't block an honest miner from including it. Hodlers and coin-generation miners (as opposed to consensus miners) could send txs with fees to affect the vote in a desired direction. If they can afford to do that then the coin is not yet being used for many real purchases. It would only work if a large community of buyers and sellers are actually using it for txs and thereby need stable value.
Using different POWs: User-adjustable coin parameters If a different POW is used for the child and parent coins, or there are multiple parents that a child uses who have different POWs, there is a problem with how to calculate their relative chain work. The relative work per hash (cost per hash) in POWs can change substantially over time as the algos or hardware improve, so a hard-coded conversion constant in the code is not acceptable.
To address this, coin senders can vote in proportion to their fees to change coin parameters in block headers such as the the conversion factors between POWs, block time, max block size, and even coin emission. This follows a tenant of governing, "representation via taxation". It takes power away from developers. If the choices being voted on are (for some unforeseen reason) not to the miners' liking, they can pick and choose txs, rejecting "unfriendly" votes. A child miner might prefer larger blocks or a specific parent POW. But refusing txs reduces their income relative to honest miners who accept all txs.