dip-0074 - doginal channels in consideration of BOLTS #9
Conversation
|
an alternative path may be to implement LIP 003 MW-EB as suggested by LTC community https://github.com/litecoin-project/lips/blob/master/lip-0003/MW-EB.png |
| Title: Doginal Channels (Dogecoin | DRC-20) | ||
| Author: George Artem <[email protected]> | ||
| Status: Draft Abstract | ||
| Type: Informational - Collaboration Request |
There was a problem hiding this comment.
From the README of this repository:
This repository contains three types of files:
BIPs: Bitcoin Improvement Proposals
DIPs: Dogecoin-specific variations to existing BIPs
Standards documents: Draft standards for submission as RFCs (Request For Comments)
If you have good arguments for why it is needed, I can create a separate discussion forum here for protocol discussions, but to be honest, I think that using the one over at dogecoin/dogecoin reaches many more people, and can perfectly serve as a starting point for writing DIPs, imho. Let me know your thoughts.
|
|
||
| ==Abstract== | ||
|
|
||
| This DIP describes introduction and changes proposed in BOLTS #0 #1 #2 #3 and #5 to adapt them to be suitable for use with dogecoin-node. |
There was a problem hiding this comment.
BOLTS are a layer 2 protocol specification. Specifying a layer 2 protocol inside the layer 1 protocol specification will complicate things and create a tight coupling that will slow down any evolution on the layer 2 and add pressure to L1 developers. I would strongly recommend keeping ANY layer 2 specifications and implementations separate from L1. Note that there can be many L2s.
| Decisions made in BOLTS are Bitcoin-Lightning-specific, and changes and collaboration will be required to understand existing vs desired | ||
| future state. This brief should be read in combination with BOLTS summary <a href="https://github.com/lightning/bolts/" target"_blank">here.</a> |
There was a problem hiding this comment.
changes [..] will be required
To what?
collaboration will be required
With whom?
This brief should be read in combination with BOLTS summary
See above - keeping loose coupling is recommended. Let layer 2 refer to layer 1, but not vice versa. What we can do on L1 is support generic use-cases, to enable an as wide as possible array of solutions for consuming services.
For example: having non-malleable multi-party transactions is not just beneficial for Lightning, but this is also a wish multiple bridge developers have expressed.
|
|
||
| ==Motivation== | ||
|
|
||
| DRC-20 deploy, mint, transfer and other inscription functions create a risk to the primary function of dogecoin as a medium of exchange. The community has |
There was a problem hiding this comment.
create a risk to the primary function of dogecoin as a medium of exchange
Please provide arguments how that is so and what the impact is.
|
|
||
| DRC-20 deploy, mint, transfer and other inscription functions create a risk to the primary function of dogecoin as a medium of exchange. The community has | ||
| the right to express their thoughts on this issue by creating a DIP in order to urge creation of a more friendly ecosystem for node operators and consumers while attempting to | ||
| address the issues associated with the limited function of DRC-20 marketplaces without implementing a complete re-write to PoS. |
There was a problem hiding this comment.
without implementing a complete re-write to PoS
PoS is not a solution to prevent inscriptions. People inscribe on Ethereum too.
| the right to express their thoughts on this issue by creating a DIP in order to urge creation of a more friendly ecosystem for node operators and consumers while attempting to | ||
| address the issues associated with the limited function of DRC-20 marketplaces without implementing a complete re-write to PoS. | ||
|
|
||
| This DIP is meant to (re)introduce the concepts in the BOLTS above and to provide a mechanism for off-chain transfer of deployed DRC-20, dogemap and doge-dns inscriptions |
There was a problem hiding this comment.
to provide a mechanism for off-chain transfer of deployed DRC-20, dogemap and doge-dns inscriptions
This is where I expect a "how". Please explain how this DIP's solution (what is the solution?) mitigates the risk mentioned on line 18.
| address the issues associated with the limited function of DRC-20 marketplaces without implementing a complete re-write to PoS. | ||
|
|
||
| This DIP is meant to (re)introduce the concepts in the BOLTS above and to provide a mechanism for off-chain transfer of deployed DRC-20, dogemap and doge-dns inscriptions | ||
| in order to support at minimum 33X growth in daily transactions prior to next run on crypto and achieve goals outlined in the "10/10/100X problem". |
There was a problem hiding this comment.
achieve goals outlined in the "10/10/100X problem".
Do you have a link where these goals are outlined? Whose goals are these?
|
|
||
| == Speculative Impacts == | ||
|
|
||
| To address the issues associated with transaction time and transaction cost presented by DRC-20 and avoid future impacts of potential "spikes" associated with DRC-20. |
There was a problem hiding this comment.
issues associated with transaction time
Transaction time is a combined function of luck (block is found) and policy of whomever found that block. Policy is up to each individual miner (or pool), and luck is up to the universe. The DigiShield function retargets difficulty based on past results, but past results are no guarantee for the future.
the issues associated with [..] transaction cost
Transaction costs are a function of supply (of blocks) and demand (of transactions requiring space). No guarantees can be given regarding the costs of a transaction, because the network decides the fees, not the protocol.
| == Speculative Impacts == | ||
|
|
||
| To address the issues associated with transaction time and transaction cost presented by DRC-20 and avoid future impacts of potential "spikes" associated with DRC-20. | ||
| To avoid necessity to consider PoS and face potential negative impacts to community sentiment and economic market disruption. To avoid the risks associated with a "lift and shift" migration |
There was a problem hiding this comment.
To avoid necessity to consider PoS
What necessity is there to consider PoS if this DIP is not accepted?
face potential negative impacts to community sentiment
The protocol is agnostic to its users and does not care about sentiment. Changing a protocol to manipulate sentiment is what the Federal Reserve, politicians and crypto scammers do.
economic market disruption
Markets are fully external to the Dogecoin protocol, because the Dogecoin protocol only knows DOGE. Same remark from above re: manipulation can be applied to markets.
|
|
||
| == Security Impacts == | ||
|
|
||
| DRC-20 security is presently secured from counterfeiting via DRC-20 marketplace indexing and data sharing. |
There was a problem hiding this comment.
DRC-20 is a second layer on top of Dogecoin. The protocol is not aware of it, and shouldn't, per L2 coupling rationale above.
The Dogecoin protocol must NEVER play cat and mouse games with L2s. If specific functionality is needed for operators to make better decisions on their own sovereign nodes, then I am 100% open to discuss these, as long as they are generic.
"Doginal Channel" - Risk Mitigation Proposal