Tldr; This is almost a full transcript of the inaugural Bitcoin Cash Network Discussion that was livestreamed on the 1st of October 2020 with presentations by Calin Calianu (Developer for BCHN & Electron Cash ) about "Removing the unconfirmed transaction limit" & Tom Zander (Founder of Flowee) presenting "Double Spend Proofs".

Attendees: Roger Ver (Founder & Executive Chairman of Bitcoin.com),Josh Green (Developer at Bitcoin Verde), Peter Tschipper (Developer at Bitcoin Unlimited), Andrew Stone (Developer at Bitcoin Unlimited), Paul Chandler (CEO & Founder Aptissio), Mark Lamb (CEO at CoinFlex), Peter Ng (Miner & OTC dealer), Mark Lundeberg (Independent Developer),  Fernando Pelliccioni (Developer for Knuth & BCHN) and Eléonore Blanc (Business developer Satoshi’s Angels)

Introduction by John Moriarty:

Hello and welcome to the October 2020 inaugural Bitcoin Cash Network Discussion, these meetings serve as a public forum for presenting initiatives that have an impact on the Bitcoin Cash Network, addressing questions about those initiatives from a diverse set of stakeholders and gaging support for relevant aspects of those initiatives. 

About the meeting format: 

Each item on the agenda will start with a short presentation, that presentation will cover the topic’s relevant problem statement and use case, the properties of a good solution and /or implementation, the status of current solutions and/or implementations and finally the cost of supporting the use case or solving the problem. Once the presentation is finished the floor will be opened up for questions from present stakeholders. After everyone’s questions have been asked, we will gauge the support from present stakeholders for different aspects of the topic as is appropriate. 

Today’s agenda: 

Removing the unconfirmed transaction limit by Calin Calianu and the Double Spend Proofs presented by Tom Zander. 

A couple of points before we start, 

1. The meeting format is a work in progress and can and should change to serve the Bitcoin Cash network to most effectively. Please share feedback, publicly or privately

2. The meetings do not represent the Bitcoin Cash network, Bitcoin Cash is decentralised, so there’s no such thing as an official representation, each participant represents itself as a stakeholder in the network and similarly we do not assume that these meetings will be the only public forum for discussions around the Bitcoin Cash network. Anyone else can hold any meeting, with any participants, with any structure of course. We simply aim to be as effective and productive with these discussions as possible. 

Presentation 1 - Removing the unconfirmed transaction limit by Calin Calianu: 

1. Problem statement / Use case

Currently there is a 50 unconfirmed ancestor limit for mempool transactions. E.g. a limit of 50 on unconfirmed (0-conf) transaction chains.

What is an unconfirmed transaction chain? In its simplest form: It is a chain of mempool transactions, each of which depends on the previous one.  Imagine a situation where A sends a tx to B, the coins from that B tx are then immediately (without waiting for a confirmation) sent to C, C sends the coins it receives on to D, and so on. If all of these transactions are in the mempool and are not yet confirmed, then this is an unconfirmed transaction chain. 

It’s a bit like passing a baton around -- and the limit is the number of times you can pass the baton for unconfirmed transactions (mempool transactions).

The limit in place now is 50, which was recently increased from its long-standing limit of 25.

When the limit is hit, people wishing to “extend” that 0-conf chain must wait for a confirmation (that is, for the transactions to appear in a block), before they can continue to extend that chain.  Thus the limit applies to mempool transactions only.

This limit is not very popular with some businesses and ecosystem members: it inhibits some use-cases and impacts some ecosystem actors negatively., and very strong interest has been repeatedly expressed in raising this limit or removing it.

I believe sites and applications that do lots of transactions very frequently, often with unconfirmed coins, would benefit most. Read.cash, Satoshi Dice, and others come to mind. Bitcoin.com also has expressed a strong desire to raise this limit or remove it altogether.  

2. Properties of a good solution / implementation:

A good solution should allow for significantly more unconfirmed tx chains, say 500 or 1000, or even unlimited unconfirmed ancestors of a mempool tx for mempool entry, without negatively impacting performance, or without introducing DoS vectors (denial of service vectors) in any way.

For example, a simple solution would be to change a constant in a file, from say 50 to 1000 -- however just doing that would negatively impact performance to the point of a possible DoS.  Doing something so simple is not safe -- the limit exists for a reason.

Why does this limit exist?  

Well.. This limit is in place because the mempool accept code is very complex, having algorithmic complexity of O(N^2). It is quadratic -- thus for a 50 tx chain limit, you get 2500 possible comparisons.  For 100, you get 10,000, and so on. The algorithm blows up quickly and thus the solution was to keep the limit low, to keep nodes from DoSing themselves while processing new mempool transactions.

But why is it so complex? 

Mainly due to the “Child Pays For Parent” feature. CPFP.  Every transaction that is an unconfirmed child must be run through all its ancestors to maintain mempool statistics mainly related to fees.  This has all been set-up to allow for the CPFP feature that we inherited from Bitcoin BTC.

I believe in the early days of Bitcoin no such limit existed -- it was added later after they added more complex fee logic to Bitcoin Core.

So -- we want to raise the limit but we don’t want to crash the nodes or have them be DoS’d.  Yet we  must have some (lowish) limit because of CPFP.  So what do we do?

One possible solution: Give up on CPFP or weaken it significantly!

From my inspection of the mempool code in BCHN that we inherited from ABC and from Core, the only thing it would have to “sacrifice” to achieve this would be removing or weakening the “child pays for parent” (CPFP) feature -- which is not even used by anybody on BCH, since we don’t have chronically congested mempools, like BTC does.

The context of the problem: 

Bitcoin BTC wanted to offer the ability for new unconfirmed tx’s to pay extra fees so that the entire tx chain, including its parent tx’s in mempool, could confirm together. Maintaining these CPFP statistics is a costly N^2 operation for new tx’s added to a chain.  

This CPFP feature maximizes profits for miners on a congested chain such as BTC, where block space is limited and fees are high.  For BCH -- this extra calculation adds no benefit for anybody -- and the little benefit it would add in a theoretical scenario is outweighed by the practical drawback of not allowing for long unconfirmed tx chains.

3. Current proposal / implementations:

I believe BU has the capability to handle unconfirmed tx chains of up to 500, mainly due to the parallelization they have implemented.

Other than that, finished implementations that reliably can raise this limit are thin on the ground right now -- but one can be put together. 

Jonathan Toomim is testing code that “weakens” the CPFP guarantee and buys O(N) mempool-add cost for tx’s with unconfirmed parents (as opposed to the current O(N^2)).  This is a huge improvement -- and it weakens the CPFP guarantee (which nobody would miss!).  It means it can allow for, right now, 2500 tx chain limit rather than 50, for similar CPU cost.

I also want to implement a Proof of Concept that does away with the CPFP guarantees in a different way (perhaps by using different indices and a different way of organizing mempool ‘packages’).

More work needs to be done on proof-of-concept implementations to see what the characteristics and practical limits are for unconfirmed tx chains.  Ideally a final implementation would allow for unbounded unconfirmed tx chains with minimal or no performance penalty relative to regular tx’s with confirmed parents.

4. Recognition of costs

Products that would need to be updated: All node implementations such as BCHN, BU, bchd, Knuth, Verde, Flowee, etc would all need to see about updating their code to throw away any O(N^2) CPFP-like features in favor of a simpler O(N) or (ideally) O(1) approach.  Other ecosystem actors outside of full nodes would not need to be updated.  Sites such as read.cash can merely remove their internal checks on tx chain limit when selecting new coins to spend -- but are not required to do so.  The brunt of the cost of this change is on the full nodes themselves, and does not need to be shouldered by anybody else outside the nodes.

Consequences for not updating: this should ideally be rolled out as a synchronized scheduled update to BCH.  If some nodes are not updated but others are, the un-upgraded nodes may end up disconnecting each other.  So, a heterogeneous network with some nodes allowing for this feature and others not allowing for it would not be ideal, but would not be catastrophic. 

For end users, the changes would be largely unnoticed or positive: Perhaps sites like Satoshi Dice would increase BCH usage!  And other sites will pop up that do clever things with transactions that were previously hard or impossible.  Some types of smart contracts come to mind, ones with “baton”-like semantics.

In my opinion the costs (dev time and dev work, removing CPFP) are worth the benefits: unlocking potential BCH use-cases.

5. Suggested stakeholders:

Bitcoin.com, Satoshi Dice, exchanges, Read.cash

Q&A

John M.: Let’s focus on presenting the presenter with questions, if it’s about additional data/content, maybe save it for a future presentation. We will be using the raising hand feature. 

Peter Tschipper: Is the proposal to remove CPFP completely, or to increase the chain limit? 

Calin C. : The proposal about investigating how to change, remove the transaction limit, let’s explore avenues, it might be to remove the CPFP completely, no one really cares about it, and it comes at a huge cost, need to do some extra engineering, but let’s see how we can remove the limit intelligently.  

Peter Tschipper: Well, the mempools aren’t nearly full, will people actually use this feature (CPFP) in the future? 

Calin C.: Indeed, let’s find that out before throwing the baby with the bath water!

Tom Z:  I actually published, “Researching CPFP with on-chain history” a couple months ago, investigating the blockchain to see who was using the CPFP feature, and it actually concerns 10 transactions over an entire year. (or 3 months) It’s basically an extremely low number. Those observed had ridiculous numbers, can’t possibly come from the Bitcoin Cash chain, they paid so much in fees, it sounded like some BTC code that ran on BCH.

John M.: Ideally this is something we would have prepared beforehand. Appreciate the presentation, but before we dig further into the details of whether or not CPFP is worth removing, since that was only barely touched upon, let’s go back with questions for Calin and let’s gauge support for the main point, let’s keep moving on, and not get lost into this, and let’s have an update for next time! This is borderline dev minutia let’s save it for offline conversation. Back to the presentation. Apologies for cutting you off. 

Andrew Stone: Questions in the presentation about if, Bitcoin Unlimited can go over 500, and just to make sure that doesn’t become a future schelling point. We picked that number randomly. We didn’t want to shock the community with an unlimited number but certainly…. 

Calin C.: It seems like you picked a sound limit. 

Andrew Stone: Yes, exactly. 

Josh Green: I’m in favor of removing the transaction chain limit but there is another reason for keeping it, due to the user experience for transactions that are double spent or not mined. If you have a very long chain, and if the first one is not included in a block then the whole chain of them are no longer valid. You can have a really bad user experience. We don’t really have that scenario too much, because if you send a transaction it will be mined into a block, accepted by your peers. But we have the double spend scenario. 

Calin C. : That’s a good point. You can use the Double Spend Proofs which Tom Z will present next. Another thing, you might have to enforce it on the UI. Why should the entire ecosystem suffer, the wallets should put the limit. We need to find an ideal sweet spot. 

Josh Green: Ultimately, let’s remove the chain limit completely, blocks already don’t have that limit.  We do a recursive query to the mempool. 

Tom Z: What do we do with unconfirmed transactions, how do we make it safe for the wallets. Do wallets already take into consideration, this is the child, of a child, of a child… what’s the risk? Wallets currently are very black and white. We might need more engineering on the wallet side.  What about a risk profile for incoming transactions? Something for Bitcoin.com wallet? 

Roger Ver: Anything is possible with the UI on the wallet but ideally, technically, with a long chain of unconfirmed transactions, if one further up the chain gets double spent, it wouldn’t be possible, maybe I’m asking for the impossible, that would be my ideal situation where, once the transaction is broadcasted, even with  some weird ancestors, that that transaction is still good to go, it’s just easier for the end user to not have to worry about anything. 

John M. : Great conversation, but as mentioned before in the future it would be great to have these points even before the meeting, where we know what Bitcoin.com or Satoshi Dice want or are ready to do. 

Josh Green: We need more research on the propagation of these double spends.  If your ancestor is a double spend, then the children won’t be propagated. Need more due diligence. 

Andrew Stone: With a transaction chain of let’s say 500 transactions, and they all show in the wallet. Well if the limit is 50 per block, well the double spender has 10 opportunities to double spend that transaction. Whereas if all those transactions  were confirmed in a single block than the double spender would only have 1 opportunity. There’s an argument that the network ought to confirm every transaction that it sees and wallets should put out the appropriate warning and not allow users to double spend. 

Mark Lundeberg: There’s no 50 limit into the block, only limit into what goes into the mempool. Blocks themselves have unlimited chains, there’s no performance degradation if a block is 32 MB of 1 giant chain it’s the same as if they were all independent transactions. Actually it might be even a bint faster, because of all the utxos. 

Andrew Stone: Right, but if they’re not into the mempool, they can’t get into a block.

Mark Lundeberg: Right, just that the scenario of having 10 blocks in a row … That’s another technical thing. 

Andrew Stone: If BU is holding 500 unconfirmed transactions and we’re trying to push 50 at a time to the rest of the network. An attacker could create a full node that behaves in this exact way  and if it’s able to connect to your wallet it can present that transaction as inside the bitcoin network, when it’s really not. 

Mark Lundeberg: More about the long chain and the UI experience of the wallets, I don’t think 50 VS 50’000 makes a big difference. What tends to happens in the mempool is that you get a lot of unrelated activities, different economic actors doing different things, if an actor is trying to pull off some kind of exploit it’s going to be affecting one part of that network and if it’s 50 long or 50’000 long, or unlimited, I don’t think it becomes any harder or easier. 

Calin C.: So you’re saying the limit is there for no reason? 

Mark Lundeberg: The limit is there to prevent quadratic funding that you were mentioning, fee optimization problem. I think that’s why it was introduced. 

John M. : I see we haven’t  agreed on the most fundamental level, let’s move on to measuring support for the things we can quantify, covered in today’s presentation. In this case, let’s use the “raise hand” feature. Let’s gauge from everybody, feel free to vote or abstain from voting if you’re not a stakeholder. 

Votes 

John M.: Raise your hand if you agree that raising the unconfirmed chain limit in some way is a goal that is worth the costs? 

Hand raised from: Calin C, Mark Lundeberg, Tom Zander, Mark Lamb, Peter Ng, Paul Chandler, Josh Green, Paul Tschipper, Andrew Stone, Roger Ver and Fernando Pelliccioni 

John M.: Raise your hand if you’re a stakeholder that will have to invest costs to implement or to look into the issue? 

Hand raised: Calin C, Mark Lundeberg, Tom Zander, Mark Lamb, Peter Ng, Josh Green, Paul Tschipper, Andrew Stone and Fernando Pelliccioni. 

John M.:  Calin, do you need to gauge more support or all good til next meeting? 

Calin C.: All good. 

Presentation 2 - Double Spend Proofs by Tom Zander:

Presentation available on Vimeo

1. Problem Statement/Use Case

In order for Bitcoin Cash to be useful as Cash, merchants need to be able to accept “zero-conf” transactions, which are transactions that haven’t been added to a block yet. Otherwise, they would have to wait for an average of ten minutes after each payment.

Currently, a thief can create two conflicting transactions (one that pays the merchant and another that sends the same money back to himself), and send both to the network at the same time. 

Some of the time he will walk away with the goods he bought, and then the transaction that sends the money back to himself will be the one that makes it into the next block, instead of the one that sends the money to the merchant.

This is called “double-spending” and, in that case, the thief will have successfully stolen from the merchant. A system that notifies merchants about the existence of a conflicting transaction within several seconds would eliminate that risk, allowing them to react to the situation however they think is appropriate, for example by withholding the goods or alerting law enforcement.

Merchants that are expected to release goods to the customer shortly after payment benefit most from double-spend proofs. Brick and mortar stores and online shops that deliver electronic goods would have their payment experience improved dramatically, and would have their fraud risk almost completely eliminated.

2. Properties of a good solution/implementation

First of all, a solution to double-spend problems should not even try to decide which of the two transactions should be the normal vs the stealing one. This is impossible to do objectively in a decentralized system, and a notification of the double-spend is all that’s needed for the people involved to react.

Currently nodes reject conflicting transactions. A solution should also not involve forwarding all transactions no matter what. While it may seem like that would allow more nodes to detect double-spends and then provide a notification to the involved wallets, it turns out that it also helps the thief to double-spend more often because it helps those conflicting transactions that would otherwise simply be rejected by the nodes to be seen by many more.

Instead, a solution should allow you to prove that a double-spend has occurred without actually forwarding the second transaction, and without providing enough information to reconstruct that 2nd transaction.

A simple notification is not good enough, because then a node could send false double-spend notifications and disrupt the payment process that way. The message should still prove that a double-spend has occurred.

Finally, the solution should notify the wallets that are involved in the double-spend.

3. Current Proposal/Implementation

The double-spend-proof specification I have been working on is, in essence, a message containing two signatures made by the same private key, both signing the same transaction-output, but for different transactions. It fulfils all of the criteria that were just covered:

• It does not try to determine which transaction is the “correct” one and which is the “double-spend”.

• It doesn’t require forwarding the second transaction to anyone else, and it doesn’t require forwarding enough information to reconstruct the second transaction.

• It cryptographically proves a double-spend has occurred, preventing nodes from faking double-spends.

• It notifies the wallets involved in the double-spend transaction.

4. Recognition of costs

A complete implementation of Double Spend Proofs would involve software at every layer of the Bitcoin Cash development stack.

Nodes need to implement creating and forwarding these Double Spend Proof messages. So far Flowee the Hub and BU full nodes have already added my proposed implementation. BCHN and BCHD plan to have it implemented by November. The minimum percentage of the network’s nodes that need to implement DSProofs for them to be reliable is about 40%.

Many “Middle-ware” solutions like REST APIs and block explorers would also need to implement the feature so that the services that depend on them can take advantage of it.

Wallets and point of sale software need to implement listening for these Double Spend messages, and then to also implement a user notification.

Businesses that take advantage of DSProofs will need to train their personnel to react to double spend notifications. The idea of a fraud alert will probably not be an alien concept to point of sale workers, minimizing the extra work required, and the reduced fraud-risk may make it a profitable investment in the long term.

Votes 

John M.: As a stakeholder, please raise your hand if you agree that the use case of adding Double Spend Proofs is worth it for you, considering the investments you’d have to make to implement it. 

Hand raised: Calin C, Tom Zander, Josh Green, Paul Tschipper, Andrew Stone, Roger Ver and Fernando Pelliccioni. 

John M.: Any specific part where you need specific support regarding your proposal?

Tom Z. : The proposal that we have is quite far along, we already have a good amount of support in several full nodes that are creating them, but we would have more companies, stakeholders asking to add this feature, such as wallet makers, Fulcrum, Rest APIs. Today is a good indication that people are interested in this topic. To any party viewing the recording, who can see using Double Spend Proofs, to increase the unconfirmed transactions to be more secure. Anybody, feel free to reach out. 

Discussion

Josh Green:  Unlike the previous proposal, that has non zero risk to an uncoordinated deployment, does this proposal Double Spend Proofs pose any risk to the network for an uncoordinated deployment? Is there a benefit to do it all at the same time?

Tom Z: Good question, well we’re past that situation already. You might depend on it (as a wallet) but we currently have several nodes supporting it, so in the next couple of months that risk should disappear. It goes to the next layer, if a wallet is depending on the Electron X protocol, they have a dozen servers, all of them should be upgraded, ideally at the same time or you can’t promise that you will get the message into the wallet, until a few months later when they upgrade. Basically, it’s 1st the infrastructure then the wallets, otherwise people using the wallet, expecting it, while it’s not sent yet. It’s overall a small risk, it’s going to be built in the right order anyway, it won’t happen in a week,  I think it’s manageable. 

Josh Green: That makes sense, thank you. 

Question from Youtube Chat: 

JT Freeman: Do double spend proofs help outside of POS systems?

Tom Z.: This is for brick and mortar stores, electronic stores that ship their goods immediately, there are the main beneficiaries. What we want to establish it for 0 confirmation transactions to drop in risk to a maintainable risk, to become risk free. Then other use cases, exchanges could lower the amount of confirmation it needs. Wallets, p2p, it’s more personal. We have 99% of the ecosystem then already. 

Question from Youtube Chat:​

Matthew G: I would like to know what the general criticisms of DSproofs were by we all know who - What are the general downsides? 

Tom Z.: When we had a workshop in Italy in 2018,  the main suggestion back then was to forward the entire 2nd transaction, but actually that was bad idea, it made double spending much more easy, that’s not done on the network anymore, that was the main criticism I know of, open to anybody’s feedback. 

Mark Lundeberg: What about denial of service, additional traffic anybody can induce across the whole network, by sending a small message, just send two conflicting messages and send them out, extra activity on the network while you only pay for one translation, is that a concern? As far as I know, no, if it’s programmed correctly. What do you see as the denial of service, that would be the main one. 

Tom Z.: We looked at that early on, the basic design, if you get a double spend transaction, any node will refuse to forward it, unless it also finds one of the other transactions that it’s about, in this mempool. Which basically means that you cannot send more double spend transactions, sorry double spend proofs, than transactions, they all have to match one. Which comes to the question, can you spam, can you DDoS the network with transactions that are actually accepted in the mempool. That’s an open question. We are pretty sure that you can’t, we’re working on that. It doesn’t add any acceleration to the system, it’s 1 to 1, if you have a double spend proof you have to have 1 transaction in the mempool that is already accepted.  In short, there’s no DoS effect. 

John M.: Encouraging any practical input from business representatives? We want to hear from you, dev minutia can, will happen outside of here. 

Question from Youtube: ​

PhilHarris09: Does increase of chain limit help exchanges?

Calin C.: Good question, it may. They  do move money around a lot. Exchanges typically wait for confirmations, don’t want the risk. I would have to find out more. 

Mark Lamb: It helps on the withdrawal side, because on the deposit side, you might wait for confirmations and some businesses don’t, such as Blockchain Poker, but on the withdrawal side, it would definitely help, because exchanges structure the transactions where there’s a change, 100% change on the balance of an address, spending from a single address, and you don’t have to worry about hot wallet management. 

Question from Youtube: or dsproofs (double spend proofs)? Could it make 0conf exchange deposit work?

Calin C.: It goes hand in hand, synergies, they work together. Longer chains, want to know if the whole chain might collapse. With Double Spend Proofs, you can actually find that out, if any transaction will be double spent, collapse the chain. 

Mark Lamb: It’s very useful to be able to confirm transactions in the system even if it’s only for low value things,  the faster a customer gets their money the better. 

Question from Youtube: Does it matter if unconf limit goes to 1000 compared to unlimited?

Roger Ver: We don’t know if it matters or not, who knows which use cases will be put to use if it’s limited, an ideal of 1000 might be just fine, but what if people have unlimited chains of dividends to send across the world, who knows what people want to do. The more useful things you can do with the chain, the better

Question from Youtube:

JT Freeman: What is the chance of miner assisted double spend attack?

Tom Z.: This was originally called the Hal Finey attack ( giving an indication of how old idea is) the miner assisted double spend attack is essentially invisible to the network, because it happens behind the scenes, only when the block comes out do you see that it’s been double spent, the tricky part here, it’s not a technical thing, it’s more about an economical or  market thing. As the mining has become more centralised, people used to mine, you had a lot of CPU miners, now they’re all going to pools. You can’t have 1 guy mining, and then going to a store, and spending it anymore, this miner doesn’t decide what goes in the block anymore. As the system grows, with much more money going into mining,  the chance of this happening goes down, it’s an economic issue at this point. 

There’s another blog by Gavin Andresen, One-Dollar Lulz, explained how cheap it was to make a block back then, now you make so much money out of it, it doesn’t make economical sense. As the economics go, it’s not a risk to the average store keeper. It’s not really something that you want to solve, no cost-benefit, that helps you solve it, it would be too costly. I haven’t seen anybody complain about it. 

Calin C.: For small purchases, you’re not going to be able to get a pool to commit fraud for you, but if you’re buying a car you wait for confirmations. Did I understand that correctly Tom?

Tom Z.: Exactly, the cost of doing a miner-assisted double spend has gone up, because of the amount of money going into mining, if you make several thousands per block, you won’t double spend for the 10$ extra income. At the same time, the amount of transactions are going up, so it wouldn’t make economic sense. 

Mark Lundeberg: Observation, all about risk & rewards. If you wait for 1 or 100 confirmations, there’s still a risk you might get defrauded, you need to look at how big the purchase is, and compare it to the risk of being defrauded for that purchase. 

Josh Green: The max transaction chain limit is something we encountered at (...) Token system they were using. We had 100 people sign up all at once, and we hit reached the limit. The user experience was awful, you broadcast transactions and you don’t get reject messages. You want to chain on top, but that transaction doesn’t exist - from an application developer point of view the user experience sucks. Is 1000 enough? If there’s no limit, cost to development might be less. Make the limit big or actually non existent

Calin C.: It seems possible to not have a limit at all. It could happen. I agree with Josh Green. 

John M.: Thank you everyone for attending, this is a valuable forum for people to understand what is going on.  Find out early on, before the meeting, what businesses will benefit, support proposals before the meeting. Follow up presentations when something is left open ended. Thank you all for watching 

More useful information & links: 

Bitcoin Cash Network Discussion website:

Continue the discussion: https://bitcoincashresearch.org/t/bitcoin-cash-network-discussions/188

Subscribe to the BCH Network Discussion Youtube channel: https://www.youtube.com/channel/UCmyoHmbSsChInLzZ9S5aAAw

More about Double Spend Proofs Roadmap:  https://bitcoincashresearch.org/t/double-spend-proof-roadmap/151/4

PS: This is more a full transcript than a recap article, we want to digest these conversations in a smaller format in the future to help advance the conversation. Thank you for everyone's help and comments in re-transcribing this meeting.