Thanks for your answer, especially the points you mentioned about Electrum server-side limitations.

You all agree on the fact that Electrum is not the best solution in that case so I'm going to stop swimming against the tide from now )

I'm gonna give BTCPayserver a second chance and alongside with that, trying to run a full node!

 

Like I said, currently I can't build a payment process on top of a full node (and going live with it)... i need more experience in Bitcoin/Blockchain architecture to achieve this efficiently.

Although Electrum seems to have issues with large wallets, its interface comply wth most of my actual business requirements.

Except large wallets, could you tell me what, in your opinion, what could possibly go wrong with Electrum ?


Yes BTCPayserver is obviously not centralized. I was basically mentioning that BTCPay is compatible with Bitpay API. Sorry for that confusion.

I tried to run a self-hosted BTCPay instance some weeks ago to test. I gave up because there was a lot of dependencies, options and a complexity which is not required in my case.

Thanks for your answer

In the other hand, if I run a new wallet instance every time "10" addresses have been assigned to a payment request (funded or not), it could become a substantial waste of resource on my side...not to mention managing hundreds or thousands of wallets is probably a funny nightmare.

Another solution would be to not reuse an address for a "very raisonnable" period of time in order to mitigate this risk.


I'm actually trying to estimate that design weakness and finding a creative way to bypass it... even though I don't really know where I'm going at right now but it's getting better)

As far as I know you can run your own Electrum server and make all your wallets connect to that particular server only. However, it could become a single point of failure. Of course you can also run your own Bitcoin node if this is a critical business requirement. But in the end (IMO) we always have to rely on a third-party provider at some point.


I guess this architecture could survive as long as it follows very simple rules and avoid complexity as much as possible (I mean, in terms of wallet management/swap policy)


Yes I already took a (short) look at Bitpay, as well as BTCPay server which is API compliant, as a possible alternative. However at this point I actually need to avoid centralized services as well as third-party payment providers. This is a technical/business requirement.

Thanks again for your answers and point of view!

That's an interesting point of view. I guess JSON is a core design choice made by the developer(s) to avoid dependencies and because they assume that most users won't have to deal with a large wallet. However a database backend would be a merchant requirement for sure. It should be studied more closely.
 

Yes I was wrong, gab limit is not a limitation nor an issue (except when you have to restore a wallet using a seed if I understood well). I assumed gab limit could be used to delimit how many address should be used per wallet instance, but this is not relevant at all. I still need to do some homework)

In my situation I guess I can mitigate this by expiration times and limitating how many pending requests a user can generate at the same time.

On architecture side, one solution would be to look for expired requests and reuse addresses, assuming that reusing an address which has never been funded is an acceptable privacy risk. But again, I may be missing something.



I didn't know about solutions such as getrawmempool thanks!

I'm mainly using Electrum because I guess this wallet provides a "lightweight" additionnal layer as well as some valuable features (secret seed, client-side stored private keys, socks5 proxy support, etc.). At this point, I don't have enough knowledge nor experience to deal with a full node directly.

Hi @ranochigo,

Thanks for your answer.

Maybe I should have started by looking at Bitcoin Core to have a better overview. I will take a look at it asap.

To be more precise, the idea behind this would be to automatically create a new Electrum wallet and run it as a read-only wallet (in a new containerized instance) each time a limitation is reached (e.g gap limit), avoiding as much as possible the limitations you mentioned. This is theory.

Could you give me some details about what is missing (in your opinion) in Electrum RPC interface ?



  




  

Hey,

I've been reading some topics on the message board stating that Electrum wasn't design to handle wallets with a large addresses/transactions history, although there are no hard-coded limitations.

In a merchant situation where a lot of addresses and transactions occur on a daily basis (e.g naivly 100 addresses for 100 transactions a day), does it make sense to "load balance" payments using multiple wallets (e.g naivly 1 wallet for 10 transactions a day = 10 instances of wallets for 100 tansactions a day) ? Does anybody experienced such architecture ?

Thanks

Hey,

I guess I started to read Electrum Protocol section but content was marked as outdated (redirecting to ElectrumX doc) so I may have missed it. Anyways.

Thank you so much for your help !

Hello,

As a developer, I've been testing Electrum command line interface (as well as JSON RPC) for some days to receive payments through my web apps.

I've been trying to use notify (address, [url]) command to get notified every time a wallet's address status changes.

It works quite well, I receive JSON responses but I don't know how to process the status string, which appears to be encoded. I don't know whether this is a binary or encrypted string actually.

Typical JSON response:


I may be missing something obvious but I haven't found specific documentation on this.

I tested this with Electrum 4.0.7 and a read-only Testnet wallet.

Any further information ?

Thanks