There don't seem to be too many technicalities in this proposal, which makes it very readable and easy to understand. I must first commend you for the hard work in putting this proposal together. I am a none developer, but I have understood everything in the best way I can, so do well to correct me if I misunderstood anything.
Final Reflections
While introducing reversible transactions into Bitcoin introduces a paradigm shift, it is a thoughtful response to the ongoing challenges of theft within the cryptocurrency space. By carefully balancing the core principles of Bitcoin with the practical needs of its users, this proposal aims to foster a safer, more resilient network for all participants.
One thing that makes people like Bitcoin is its level of decentralization, security, transparency, and immutability. Bitcoin theft is rampant, but the introduction of this proposal if accepted by the community, will reduce the level of decentralization and trigger centralization.
Bitcoin, as we all know is pseudonymous, which means transactions can be traced, but the real identities of the owners are not revealed. If the reversibility of transactions is added, we would see more influence from the government and agencies, as the power to halt anyone's transaction would be possible.
Transaction reversibility wouldn't be used only for the specified purposes but would be exploited beyond that, trust me.This is unlike banks that can perform reversibility with ease because they are centralized. Filing a complaint about a false transaction would be handled in a centralized way, which would require you to provide lots of details about yourself and prove you didn't initiate the transaction. In most cases, you have to visit the bank in person to clarify your claims. This is why implementing the same on Bitcoin, where there is no central authority, would be very difficult to manage.
I also think that this implementation will cause massive problems for the community, resulting to trust issues between all Bitcoin holders, miners, and developers.
I also think that the implementation might not work for everyone if it were to happen. Only major attacks involving massive amounts would be considered. Just imagine someone stole your 0.1 BTC. Would you expect massive action compared to when an exchange loses 120,000 BTC?
The only solution to solving this is never to introduce it in any way. This will reduce the pressure and opportunity for manipulation from the government or other parties. It is also a clear way of saying NO to centralization.
- Private Key Security: Private keys are the linchpin of user security in the Bitcoin network. They are targets for malicious actors because their compromise grants access to the user's funds.
- Exchange Security: Despite improvements over the years, many exchanges still suffer from security flaws that can be exploited by hackers.
- Phishing and Social Engineering: Users can be deceived into giving away sensitive information, leading to the theft of credentials and funds.
The issue of fund theft through various means has been ongoing for a long time and will likely continue. This theft does not only affect Bitcoin but also other valuable assets like alts, fiats, etc. Addressing Bitcoin theft has mainly been to improve wallet security and educate users on how to protect their keys. But there are still loopholes that attackers exploit due to regular discoveries. We can trace these vulnerabilities to the level of security and human error by those who end up being the victims.
My opinion on an instance where the community wants to consider the proposal.Introducing a Community-Driven Reversible Transaction Mechanism
This proposal seeks to introduce a reversible transaction feature into the Bitcoin network that is activated through community consensus. The mechanism enables a system where transactions identified as potentially fraudulent can be temporarily halted and reviewed by a decentralized body of appointed verifiers, herein referred to as Community Verification Nodes (CVNs). This feature aims to mitigate the risks associated with theft by allowing for corrective action, which is currently impossible due to the irreversible nature of Bitcoin transactions.
Just as I said earlier, I really like Bitcoin for its decentralization, immutability, security, and transparency. If we are considering reversible transactions on Bitcoin, then we should determine
at what level this might be possible. Ideally, when a transaction is initiated (whether by an attacker or the real owner), it must be validated, which means it sits in the mempool and waits for its turn. After the completion of its validation, the transaction ends up sealed in a block, which is aligned with other blocks.
There are two points I can pick from that process:
1. There might be a possible chance for reversal when the attacked transaction is in the mempool waiting to be confirmed. This chance might be possible if the victim flags the transaction before confirmation. If the transaction is flagged on time, the attacked transaction should be set aside for clarification.
2. When the transaction is already placed in the block and attached to the chain, then I don't think we should be talking about any transaction reversal.
Am not a developer, which means I won't be part of those making decisions for the approval. I hope to see this as a BIP on the community GitHub, so I can do my follow up on the decisions taken. You can also share regular update on this thread or board, as I visit here most often .
One thing that makes people like Bitcoin is its level of decentralization, security, transparency, and immutability. Bitcoin theft is rampant, but the introduction of this proposal if accepted by the community, will reduce the level of decentralization and trigger centralization.
The proposal indeed introduces a mechanism that could be seen as a shift towards centralization. However, the design specifically incorporates decentralized decision-making through Community Verification Nodes (CVNs) that are elected by the community and operate under strict guidelines and transparency. The goal is to create a balance where the community can act in cases of clear theft without undermining the decentralized nature of Bitcoin.
If the reversibility of transactions is added, we would see more influence from the government and agencies, as the power to halt anyone's transaction would be possible. Transaction reversibility wouldn't be used only for the specified purposes but would be exploited beyond that, trust me.
This is a critical concern. The structure of the reversible transaction feature is designed to limit the scope of reversibility strictly to cases flagged by users and verified by multiple independent CVNs. This multilayered approach aims to protect against unilateral misuse of power. Furthermore, transparency in the CVN decision-making process and the ability for the community to audit and contest CVN decisions are intended to guard against potential government overreach or other exploitative behavior.
I also think that the implementation might not work for everyone if it were to happen. Only major attacks involving massive amounts would be considered. Just imagine someone stole your 0.1 BTC. Would you expect massive action compared to when an exchange loses 120,000 BTC?
The proposal aims to cover theft of any size, not just large-scale thefts. The community-driven aspect of the mechanism allows for flexibility in addressing various scales of theft, ensuring that even smaller amounts can be contested if deemed significant by the affected parties.
There might be a possible chance for reversal when the attacked transaction is in the mempool waiting to be confirmed. This chance might be possible if the victim flags the transaction before confirmation. If the transaction is flagged on time, the attacked transaction should be set aside for clarification.
Your point about flagging transactions while still in the mempool introduces an interesting layer of prevention. This early intervention could indeed be a critical component of the mechanism, allowing for quicker responses and potentially halting theft before it is cemented into the blockchain. This aspect will require further technical exploration and could be a key feature to enhance the responsiveness of the proposed system.
As you suggested, the next steps would indeed involve drafting a Bitcoin Improvement Proposal (BIP) and submitting it for community review on GitHub. Continuous updates and discussions like this one are crucial, and your active participation, even as a non-developer, is invaluable. The community’s broad range of perspectives strengthens the proposal’s development and ensures that it addresses the concerns of all stakeholders.
IMO there's almost no chance your proposal will be applied on Bitcoin network. Anyway, your proposal is very long and there are many questionable technical detail. Here are few of those,
Transaction Lifecycle Modifications- FlaggedTransaction Creation: When a user detects unauthorized access or theft, they can initiate a FlaggedTransaction via their wallet interface. This transaction includes the transaction ID of the suspicious transaction, a digital signature of the claimant, and a preliminary evidence package.
- Temporary Transaction Freeze: Upon network acceptance of a FlaggedTransaction, the disputed funds are temporarily frozen, preventing any further transfers. This state is maintained until the resolution of the claim.
How many FlaggedTransaction can be created by someone? How does it handle TXID which involve multi-sig address where multiple people may be involved?
Community Verification Nodes (CVNs) Setup- Node Selection: Nodes apply to become CVNs by submitting a proof of stake and a reputation score, derived from their historical activities and peer reviews within the network. The selection process is automated, governed by smart contracts to ensure fairness and transparency.
- Role of CVNs: CVNs are responsible for reviewing all submitted evidence, interacting with claimants, and possibly contacting involved parties for additional information. Their task is to assess the validity of the claim based on the evidence and vote accordingly.
How
exactly reputation score is determine? Is there any minimum Bitcoin amount before someone can submit a proof of stake? What happen if CVN doesn't bother do it's role? What if someone wish to become CVN without any on-chain blockchain history?
Voting and Consensus Mechanism- Voting Protocol: After reviewing the evidence, CVNs submit their votes through a secure blockchain interface. Votes are encrypted and revealed only after all CVNs have voted to prevent influencing decisions.
- Consensus Achievement: A transaction is reversed only if a supermajority (e.g., 75%) of CVNs agree that the evidence substantiates the theft claim. This high threshold ensures that reversal is truly reflective of community consensus.
Does all CVN have same vote weight or the weight determined based on amount of staked Bitcoin?
How many FlaggedTransaction can be created by someone? How does it handle TXID which involve multi-sig address where multiple people may be involved?
The proposal includes a safeguard to prevent abuse through the implementation of a fee structure for initiating FlaggedTransactions. This fee is designed to be significant enough to deter frivolous claims—set at 10% of the transaction value or a minimum fixed amount, whichever is greater. The exact value can be adjusted based on community consensus to ensure it serves as an effective deterrent without being prohibitively expensive for legitimate claims. This fee is non-refundable, which further ensures that only serious cases are brought forward. For multi-sig transactions, all signatures required by the wallet configuration must agree to initiate the FlaggedTransaction, maintaining the decentralized and democratic ethos of the network.
How exactly reputation score is determine? Is there any minimum Bitcoin amount before someone can submit a proof of stake? What happen if CVN doesn't bother do it's role? What if someone wish to become CVN without any on-chain blockchain history?
The reputation score is calculated based on past activities and contributions within the network. A minimum amount of Bitcoin is required to stake to become a CVN, aligning their incentives with the network's health. If a CVN fails to perform their duties, they risk losing their stake and damaging their reputation, which can disqualify them from future participation. New participants can build their reputation through smaller, verifiable actions on the network before applying to become a CVN.
Does all CVN have the same vote weight or the weight determined based on the amount of staked Bitcoin?
All CVNs have equal voting weight, regardless of the amount of Bitcoin they have staked. This is to ensure fairness and prevent wealthier nodes from having disproportionate control over the reversal process.
- FlaggedTransaction Creation: When a user detects unauthorized access or theft, they can initiate a FlaggedTransaction via their wallet interface. This transaction includes the transaction ID of the suspicious transaction, a digital signature of the claimant, and a preliminary evidence package.
how long do they have to create such a transaction because what if alot of time has elapsed such as weeks or months? and the initial transaction utxos have been spent and created a huge chain of utxos are you going to go and cancel all of them starting from the original suspicious transaction? what if the money was sent through bitcoin mixers how are you going to know whose utxos to put a freeze on? you could end up hurting innocent people then. and the bad guys still get away...
i'm not so sure this thing has been thought through well enough if that's the case.
The timeline for initiating a FlaggedTransaction is a critical component of this proposal, and it is designed with several factors in mind to address the concerns you’ve raised:
1.
Time Limit for Flagging: There is a proposed time window during which a FlaggedTransaction can be initiated. This is typically set to a few days or weeks from the original transaction date to ensure that it is practical to trace the subsequent chain of transactions. The community can adjust this period based on consensus to balance responsiveness with practicality.
2.
Handling Long Transaction Chains: The Bitcoin Core protocol tracks UTXOs (Unspent Transaction Outputs) efficiently, and this system does not inherently allow for the reversal of entire chains of transactions once UTXOs are spent. In cases where UTXOs have been transferred multiple times, the reversible transaction mechanism would focus only on the most recent transaction where the original UTXOs were still unspent at the time of flagging. This avoids the complication of unraveling long transaction chains.
3.
Dealing with Mixed Transactions: Bitcoin mixers complicate the traceability of funds. In situations where mixed or shuffled funds are involved, the CVNs (Community Verification Nodes) would employ advanced forensic tools that analyze transaction patterns and mixer outputs. However, reversing transactions involving mixed funds would be approached with extreme caution to avoid affecting innocent users. Decisions in such cases would likely require additional layers of verification and possibly a higher threshold of CVN consensus.
4.
Technical Mechanism in Bitcoin Core: Within the Bitcoin Core software, transactions are validated against the current state of the UTXO set stored in the `chainstate` database. FlaggedTransactions would involve checks against this database to verify the current status of the relevant UTXOs at the time of flagging. If the UTXOs have already been spent, the system would not allow a reversal but would instead focus on recovery or tracing the subsequent transactions, depending on the circumstances.
5.
Protection of Innocent Parties: The proposal includes mechanisms to safeguard non-involved parties, primarily through selective freezing of transactions identified with high confidence as linked to the theft. This would be managed through a judicious review process by the CVNs, who would be required to assess not only the evidence of theft but also the potential impact on third parties.
The technical feasibility and ethical considerations of implementing such a feature in a system as complex and decentralized as Bitcoin require thorough vetting and robust community discussion. The goal of this proposal is not to provide an all-encompassing solution but to open up possibilities for mitigating theft while respecting the fundamental principles of blockchain technology. Your points highlight the need for careful implementation and continuous evaluation of the system's impact, ensuring it serves the community effectively without unintended consequences.
Without going into detail, there is little benefit to encumbering the Bitcoin protocol with these new features because your proposal can already be implemented using the current protocol. The transfers would be done using Bitcoin, and the rest would be implemented outside of Bitcoin.
One possibility might be something like a 2-of-3 multisig Lightning channel.
Without going into detail, there is little benefit to encumbering the Bitcoin protocol with these new features because your proposal can already be implemented using the current protocol. The transfers would be done using Bitcoin, and the rest would be implemented outside of Bitcoin. One possibility might be something like a 2-of-3 multisig Lightning channel.
Thank you for bringing up the potential of using existing Bitcoin technologies such as multisig and the Lightning Network to address issues of unauthorized access and theft. Indeed, these tools offer powerful ways to enhance security and provide mechanisms for dispute resolution without requiring significant changes to Bitcoin's core protocol.
2-of-3 Multisig Approach: Utilizing a 2-of-3 multisig setup could indeed serve as a preventive measure against theft. In this scenario, one key could be held by the user, another by a trusted third party or service, and the third could act as a recovery key in cases of dispute or loss. This setup provides a balance between security and recoverability, allowing transaction reversals under agreed conditions without needing protocol changes.
Lightning Network Channels: The Lightning Network offers another layer of security for transactions that can be reversed within the channel under certain conditions. For instance, a 2-of-3 multisig Lightning channel could facilitate faster dispute resolutions and provide a layer of reversibility for transactions before they are settled on the blockchain.
These solutions, while viable, rely heavily on external enforcement and trust in third parties, which might not align with the decentralized ethos of many Bitcoin users. The proposal aims to integrate a reversible transaction feature directly within the Bitcoin protocol to address these concerns systematically and transparently, ensuring all network participants adhere to the same rules without needing external arbitration.
Moreover, while multisig and Lightning solutions can provide mechanisms for security and dispute resolution, they do not address all cases, especially when transactions are already confirmed on the blockchain. The proposed reversible transaction feature aims to fill this gap, offering a method to contest and potentially reverse confirmed transactions in extreme cases of theft, which are currently irreversible under standard Bitcoin operations.
It's important to weigh the benefits of leveraging existing technologies against the need for new features that might provide a more comprehensive solution tailored specifically for theft recovery. Each approach has its merits and potential drawbacks, and the ongoing community discussion will be crucial in determining the most appropriate path forward.
The decentralized nature of Bitcoin, while providing user autonomy, also excludes the possibility of a centralized authority to intervene in disputes or transaction reversals.
The decentralized and trustless setup of Bitcoin is there to exactly prevent the intervention of some centralized authority for whatever reason. I'll come to apparent problems later.
- Private Key Security: Private keys are the linchpin of user security in the Bitcoin network. They are targets for malicious actors because their compromise grants access to the user's funds.
- Exchange Security: Despite improvements over the years, many exchanges still suffer from security flaws that can be exploited by hackers.
- Phishing and Social Engineering: Users can be deceived into giving away sensitive information, leading to the theft of credentials and funds.
Private keys can be handled securely (hardware or airgapped wallets, multi-sig). User needs security awareness, education and practice.
Software security at exchanges is more difficult as those tend to show off with all sorts of fancy features that may become a security nightmare.
Phishing and social engineering is again related to user's awareness, education and knowledge of secure best practices.
- Voting Protocol: After reviewing the evidence, CVNs submit their votes through a secure blockchain interface. Votes are encrypted and revealed only after all CVNs have voted to prevent influencing decisions.
Denial of Service possible when one CVN refuses to vote. How is that handled?
Execution of Reversal Transactions
How is this supposed to actually happen? Your whole construct seems to be built around the fact that a theft is immediately detected, merely before a transation is confirmed, isn't it? What if coins were moved and confirmed, possibly multiple times, before a theft is detected? How do you expect to reverse transactions that are burried under multiple blocks?
- Flagging Fee: A non-refundable fee, constituting 10% of the disputed transaction value or a minimum threshold (whichever is greater), is required to file a FlaggedTransaction. This fee serves as a deterrent against frivolous or malicious claims.
Assume all coins were stolen, the victim doesn't have any more coins, might be broke. How is the victim supposed to cover the Flagging Fee?
To potentially get back 90% of the stolen coins is certainly better than 100% loss. But still, the victim has to afford another 10% of the stolen mass to initiate the process where it isn't garanteed that he get's the supermajority of votes for the reversal. Worst case for the victim is a 110% loss!
- Strict Verification for CVN Applicants: Implementing rigorous checks on the identity, reputation, and historical activities of CVN applicants to prevent collusion and ensure only the most reliable participants are selected.
So, total KYC for CVNs is a mandatory feature? Good luck with that...
No way!!
I will stop here for now as it's a lot of material.
The decentralized nature of Bitcoin, while providing user autonomy, also excludes the possibility of a centralized authority to intervene in disputes or transaction reversals.
The decentralized and trustless setup of Bitcoin is there to exactly prevent the intervention of some centralized authority for whatever reason. I'll come to apparent problems later.
The foundational principle of Bitcoin's decentralization is indeed to prevent any centralized control over transactions. The proposal for reversible transactions does not aim to undermine this principle but to introduce a mechanism where the community itself, rather than a central authority, can decide on reversing transactions under exceptional circumstances such as theft. This is implemented through a decentralized network of Community Verification Nodes (CVNs), ensuring that no single entity has control over the decision.
Denial of Service possible when one CVN refuses to vote. How is that handled?
To address the possibility of a Denial of Service (DoS) attack or non-cooperation from a CVN, the system can implement a timeout for voting. If a CVN does not vote within the specified time, the vote proceeds without their input. This ensures that the process is not unduly delayed. Furthermore, repeated failure to participate in votes could lead to penalties or removal of the CVN from their role, maintaining the integrity and fluidity of the process.
Execution of Reversal Transactions
How is this supposed to actually happen? Your whole construct seems to be built around the fact that a theft is immediately detected, merely before a transaction is confirmed, isn't it? What if coins were moved and confirmed, possibly multiple times, before a theft is detected? How do you expect to reverse transactions that are buried under multiple blocks?
The execution of reversal transactions is indeed challenging, particularly if the theft is detected after the transactions have been confirmed. The proposed mechanism primarily targets recent transactions where reversal can prevent further propagation of the stolen funds. For transactions deeply embedded in the blockchain, the reversal mechanism may not be feasible due to the irreversible nature of blockchain confirmations. Instead, focus shifts to recovery through other means, such as tracking the stolen funds and collaborating with exchanges and wallets to freeze and recover them where possible.
Flagging Fee: A non-refundable fee, constituting 10% of the disputed transaction value or a minimum threshold (whichever is greater), is required to file a FlaggedTransaction. This fee serves as a deterrent against frivolous or malicious claims.
Assume all coins were stolen, the victim doesn't have any more coins, might be broke. How is the victim supposed to cover the Flagging Fee?
This is a significant concern. The fee model is designed to prevent abuse but should not prevent legitimate claims from being processed. One possible solution could be a community fund or insurance protocol that can cover the flagging fee for verified theft cases where the victim cannot afford the fee. This would require additional community support and governance to manage and distribute such funds responsibly.
Strict Verification for CVN Applicants: Implementing rigorous checks on the identity, reputation, and historical activities of CVN applicants to prevent collusion and ensure only the most reliable participants are selected.
So, total KYC for CVNs is a mandatory feature? Good luck with that...
No way!!
KYC for CVNs could be contentious within the Bitcoin community, known for valuing privacy. An alternative could be a system where CVN candidates are vetted based on their blockchain activity and community reputation, without needing full KYC. This balances the need for reliable participants in the CVN roles while respecting the community's preference for privacy.
Remember this is purely a proposal, and each point you and the other commuting members are raising is crucial for refining the proposal and determining if it is viable.
Mod note: Consecutive posts merged
