Flowee revamp, check it out!

Hello!

DSProofs are designed and are now shared between full nodes, this was a large amount of work (and is still ongoing) because a lot of full nodes want to coordinate and forward each others DSProofs. The next stage is to make them available in APIs. This is described here: https://bitcoincashresearch.org/t/double-spend-proof-roadmap/151

There are some designs going on already, I was hoping that the owners of the APIs would take the lead and come up with a good design.

Please consider giving a bit of a push to get this done in places like: Protocol implications of double spend proofs

Thanks for the links Tom!

I see the current discussion is on integrating DSProofs into existing data services (eg. ElectrumX and Fulcrum). However, I'm interested in providing a REST-based API query for DSProofs. The advantage is ease of implementation.

What I'm looking for is a hub-cli query request that i can make on a txid that will give me a yes/no result. developers could then make a request https://dsproof.devops.cash/<txid>. what do you think?

existing data services (eg. ElectrumX and Fulcrum). However, I'm interested in providing a REST-based API query for DSProofs.

As far as I know, ElectrumX does exactly that. It is a REST based service producing JSON.

See more for it here: Flowee Fulcrum

is ElectrumX (Fulcrum) accessible from an http request? afaik it's only accessible via tcp. (websockets are available too)

is what I'm asking for possible with Flowee the Hub? i know BU is working on DSProofs too, but i can't get their node to sync when using the DSProof branch i was referred to.

all I'm looking for is a way to query Flowee for a DSProof from the cli, then i can package that into an API request.

again, a REST-based solution would compliment "direct" implementations by functioning as an "add-on". eg, a dapp developer could continue using current solutions (as-is) and simply add an extra request for the DSProof. imo this will greatly speed up adoption of DSProofs and encourage more "direct" implementations.

lemmeno, thanks!

is what I'm asking for possible with Flowee the Hub?

Flowee the Hub has had DSProofs for more than a year, the design in the full node is to put the in the P2P protocol. It does that.

i know BU is working on DSProofs too,

Yes, I made a merge request with the same code from Flowee on BU and they integrated it into their node based on this. The code is operational on mainnet today.

but i can't get their node to sync when using the DSProof branch i was referred to.

That may be the RPC code you talked about, is my guess.

again, a REST-based solution would compliment "direct" implementations by functioning as an "add-on". eg, a dapp developer could continue using current solutions (as-is) and simply add an extra request for the DSProof.

The REST based solutions are in things like electrum, the rest (http://rest.flowee.org) server and similar.

It is indeed highly wanted to integrate it with these known products. I would apreciate if you work with these products in order to integrate it in their offering. I personally am against starting yet another rest server to do something on the side, on a different URL. Instead focus on working together with other players in order to make the existing servers support double spend proofs: that will have to happen anyway, not working with them and doing your own thing won't make stuff go faster.

I didn't see any new comments on the linked electrumx task. Working together on this will be appreciated.

personally am against starting yet another rest server to do something on the side, on a different URL.

that's fine but you're now restricting the options of app builders (sigh) imho BCH is hardly in a position to be restricting anything.. the 2 solutions are hardly mutually exclusive.. may i ask what the argument is for you NOT providing a DSProof field in http://rest.flowee.org?

i would apreciate if you work with these products in order to integrate it in their offering

i can certainly respect that request.

unfortunately, I'm not well versed in any of those languages (C, C++, Go), so i personally cannot contribute to the product's code; which then makes me 100% dependant on the product's roadmap, priorities and timeline. given my experience this past year, I'm not at all comfortable with being at the mercy of any 3rd-party development.. but maybe that's just me 😒

basically, i have multiple "production" use-cases ready to implement your DSProofs TODAY (and promote its value to other builders), so i ask that you please reconsider your position on a REST-based solution..

anyway, thanks for your time and support 🙏

what the argument is for you NOT providing a DSProof field

Hmm, my suggestion was to do it in the rest service or any of the other existing ones. So, if that is what you want then we agree.

so i ask that you please reconsider your position on a REST-based solution..

It is absolutely something that should happen, and I'm sorry if that was not how it sounded before.

My task list is pretty long, but I'll try to move it up a bit.

okay, great! I'm sooo tired of merchants sticking to that 1 conf requirement.. i know it will take time but providers like BitPay and exchanges like Sideshift really need to feel confident in the protocol before they'll even consider it..

Yeah no worries! Enjoy the holidays, and we'll sort something out in the new year! 💪

Our products are meant to be the infrastructure for Bitcoin Cash. We build the roads mapping out the wilderness so makers can reach all the exciting destinations with much less fuss.

Just a week ago we had someone successfully run scalenet (the one with 250MB blocks) on a raspberry pi. Not exactly server hardware ;)

I think I still have a lot to learn 😉