Join 100,766 users already on

New Flipstarter campaign: Implementing Double-Spend Proofs on Knuth node and libraries

4 284 exc
Avatar for kth
Written by   135
1 year ago

The Knuth engineering team will begin implementing Double-spend proofs on the node's code.

The motivation to implement this double spend detection mechanism is very well described in the specification:

The chance of defrauding a merchant by double spending the transaction that is being paid to him is real and the main problem we have today is the fact that without significant infrastructure the merchant won't find out until the block is confirmed. The low risk of getting caught will make this a problem as Bitcoin Cash becomes more mainstream. The double-spend-proof is a means with which network participants that have the infrastructure to detect double spends can share that fact so merchants can receive information on their payment app (typically SPV based) in short enough time that the merchant can refuse to provide service or goods to their customer.

In a normal merchant-customer exchange, the customer creates a transaction which he then gives to the merchant. Either directly or through the Bitcoin Cash network. Upon receipt of that transaction, the merchant will be able to recognize and store it, allowing the customer to leave.

This means that the merchant relies on a zero confirmation setup in which the merchant saves a copy of the transaction and will continue to send it to the network until it is confirmed. This works well in the vast majority of cases.

However, the customer may have set up some custom software and immediately after submitting the appropriate transaction to the network, they submit another transaction to a friendly miner. This transaction spends twice the money you initially sent to the merchant.

With Double-spend proofs, any node, and specifically wallet software, can use the information exchanged as a way to alert the network of an attempt to double spend.

While the wallet software is required to implement this protocol as well, the nodes need to implement a series of specific messages and also an API to provide this information to the wallet software.

Requested Funding

The estimated time for implementing DS-Proofs on Knuth core library is 320 hours.


At a rate of 0.2 BCH/hr the total requested funding for this phase of development is 64 BCH.

At a rate of 150USD/hr, the total requested funding for this phase of development is 48 BCH (using BCH price at the time of writing this).

Flipstarter Campaing

You can access our Flipstarter campaign with this link

Knuth's 2020 in numbers

If you want to know what we have been working on for the past year, check out the following article:

Plan for 2021

  • Development of the Knuth Javascript Library (done).

  • Implement Double-Spend proofs (this Flipstarter campaign).

  • Create our own block explorer on top of the JS library.

  • Improve the performance of the node so that it can adapt to the times that come in Bitcoin Cash: 256 MB blocks. For this we have determined that we will need to (1) rewrite the IDB code from scratch and (2) implement a better concurrency scheme.

  • Maintain and improve our existing APIs: C++, C, C#, Javascript, ...

  • Implement UTXO Commitments.

  • Development of the Knuth Rust Library.

  • Development of the Knuth Python Library.

  • Development of the Knuth Java Library.

  • Development of the Knuth Go-lang Library.

  • Development of the Knuth Eiffel Library.

The listing above is our entire backlog. Instead of doing a big campaign with all that, we prefer to go on feature-by-feature campaigns basis. Once we finish the current one, we will move on to the next one. In this way, it allows us to do shorter tasks and since the Bitcoin Cash ecosystem is very dynamic, we can adapt to the demands of the moment.

Thank you!

Knuth is open source software that needs community support to continue its development. Therefore we would like to thank the generosity of our supporters and that of the entire Bitcoin Cash ecosystem. You are the ones that allow us to move forward with our goal, which is everyone's goal at Bitcoin Cash, which is to be the Peer-to-Peer Electronic Cash System for the entire world.

$ 90.36
$ 32.00 from @Ellie
$ 23.24 from @TheRandomRewarder
$ 16.42 from @zatarra
+ 8
Sponsors of kth
Avatar for kth
Written by   135
1 year ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.


The estimated time for implementing DS-Proofs on Knuth core library is 320 hours. At a rate of 0.2 BCH/hr the total requested funding for this phase of development is 64 BCH.

Dude, check your numbers. Nobody I know makes $200 an hour doing open source development.

also, you can just copy the code from me (as seen in Flowee, BCHN and BU) which made the integration time for those teams much less than 320 hours.

$ 10.00
1 year ago

Knuth's code is not descended from Satoshi's code (like BCHN, BU and Flowee) so copying the code is not an option for us. Knuth's code is as different from Flowee's as BCHD's or Bitcoin Verde's. But we will use the Flowee code as a reference in case we find any ambiguity in the specification.

As for the hourly rate, you are right, the campaign was written almost a week ago, when the price of BCH was close to 700 and kept falling. We will adjust the rate to one more appropriate to the current price ​​of BCH.

Thanks for your suggestions.

$ 5.00
User's avatar kth
1 year ago

Knuth's code is not descended from Satoshi's code (like BCHN, BU and Flowee) so copying the code is not an option for us.

Hmm, when I look at your CTransaction and the one from Flowee, they look very much alike, I would argue that you definitely did take relevant parts from Bitcoin Core.


Just being able to get access to this class and the ones in the script subdir means you can have about 80% of the functionality up and running by simply copying the code from one of the above mentioned clients.

The idea and the code really isn't that big, there is some confusion somewhere if you calculate the cost of support as high as you have.

$ 0.00
1 year ago


The Knuth node has 2 ways to interpret the Bitcoin script (idea inherited from Libbitcoin).

  1. The mode compatible with Satoshi code (the code you are pointing to) which is a copy in this case of the BCHN code and,

  2. The mode that uses Knuth's own code.

This dual mode is to give miners more confidence that the code will be as compatible as possible with those derived from the Satoshi client (if they chose option 1).

CTransaction is not used anywhere in the Knuth code, only the primitives/transaction.h file had to be copied due to the spaghetti code of the Satoshi Client and derivatives. (I would never call a class CTransaction, more than 30 years of the 90s have passed ;) ).

The code related to the node's domain (blocks, transactions, etc.) can be found here:

Thanks for you effort trying to help!

$ 0.00
User's avatar kth
1 year ago