use a bitcoind hot wallet instead of lnd #272
Comments
|
@nicolasburtey From what I have been able to study since yesterday, I think that if there are plans to keep adding Bitcoin wallet features, then bdk is a good choice. It uses miniscript + descriptors (both which I am now learning about), which allow building many kinds of transactions. But the project is still early, like in here it still says that only testnet and regtest are supported. And I also found this, which is a way to do proof of reserves with bitcoind https://github.com/ElementsProject/reserves. |
|
@bodymindarts do you want to chime in? maybe @moneyball would have some insights for the readiness of bdk for production use? I think if we don't have a strong conviction we should go with bitcoin-core wallet. bitcoin core will eventually also have descriptors (if they don't already). for miniscript I'm not sure yet, but for what we're doing I don't think miniscript will be useful anytime soon. |
|
It would be great to find an early adopter of BDK! As @jotapea mentioned, it is particularly attractive if you're looking to utilize output descriptors, miniscript, multi-sig, PSBT, coin selection, and fee estimation, as it does all of that for you. Even if you use BDK, you'll still need to use Bitcoin Core (or some form of block data such as Electrum or BIP 157/158), as BDK is not a full node or source of block data. BDK supports Rust, Java, and Swift right now. It would need language bindings support work to support TypeScript, if that is what your wallet needs. As for mainnet/production readiness, we'd need to check with the developers on the project, in particular Alekos and Steve Myers. But whatever tasks remain I'm sure they'd prioritize as there is a desire for BDK to be adopted for real usage. Let me know how I can help. |
I'm also in the camp of staying with bitcoin-core. Its the safest option and we currently have no need for any of the above mentioned features. |
|
Again to be clear, even if you were to adopt BDK, you aren't moving to a new node solution - you'd still need to use Bitcoin Core (or some mechanism to get block data). BDK works with Core, Electrum, and BIP 157/158 block data sources. |
|
But it would be adding a new runtime dependency and change the communication protocol between app and on chain wallet right?
…Sent from my iPhone
On 9. Jul 2021, at 07:29, Steve Lee ***@***.***> wrote:
Again to be clear, even if you were to adopt BDK, you aren't moving to a new node solution - you'd still need to use Bitcoin Core (or some mechanism to get block data). BDK works with Core, Electrum, and BIP 157/158 block data sources.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Also we’d have to develop our own language bindings cause we are using typescript
…Sent from my iPhone
On 9. Jul 2021, at 07:52, Justin Carter ***@***.***> wrote:
But it would be adding a new runtime dependency and change the communication protocol between app and on chain wallet right?
Sent from my iPhone
>> On 9. Jul 2021, at 07:29, Steve Lee ***@***.***> wrote:
>>
>
> Again to be clear, even if you were to adopt BDK, you aren't moving to a new node solution - you'd still need to use Bitcoin Core (or some mechanism to get block data). BDK works with Core, Electrum, and BIP 157/158 block data sources.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@bodymindarts yes to both. With BDK (and LDK), they are true libraries, that you call into and link to as opposed to running a separate process and using RPC to interface (like with Core or LND). If someone is building a wallet from scratch, BDK and LDK help immensely so you don't have to reinvent the wheel, yet you still get as much flexibility as you need. However, if you've already developed your wallet application, then it might be less clear. My main point is that BDK is not a replacement for a full node like Core. BDK is a dev kit that makes building a wallet easier. |
|
I see. Thanks for the clarification. I’ve looked at ldk before but not bdk. I think they are really cool projects and see their value.
But for us at this point, especially with the lack of typescript support, I don’t see enough benefit. We have many other more pressing priorities.
…Sent from my iPhone
On 9. Jul 2021, at 07:57, Steve Lee ***@***.***> wrote:
@bodymindarts yes to both. With BDK (and LDK), they are true libraries, that you call into and link to as opposed to running a separate process and using RPC to interface (like with Core or LND). If someone is building a wallet from scratch, BDK and LDK help immensely so you don't have to reinvent the wheel, yet you still get as much flexibility as you need. However, if you've already developed your wallet application, then it might be less clear.
My main point is that BDK is not a replacement for a full node like Core. BDK is a dev kit that makes building a wallet easier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi, regarding the above comment this is just for the As for the Typescript support, BDK can be built into a WebAssembly package with a thin wrapper (primarily to convert inputs/outputs to JSON). You can see a live demo of this working in a browser on the "Playground" page @afilini created. If that's something your team would consider we can work on a NodeJS demo. |
|
this is done with bria. |
the current hot onchain wallet is based on lnd. we want to move the onchain hot wallet to bitcoind (or maybe bdk could be an alternative, haven't dive into it, but there is an initiative for proof of reserve which is something we want to get into) for the following reasons:
disposable lnd
the lnd nodes are currently being considered disposable. there is no state in lnd that are not being duplicated into mongodb in regards to balances/transactions. so deleting a lnd instance would not create any data loss for the uses perspective.
the reason we want to be able to do that is because nodes can have issues and eventually die (like an irreparable corrupt database).
if lnd dies, then it's possible to recover the funds using a recovery procedure and starts anoter another lnd. (our architecture will allow multi lnd also).
aftter lnd is offline, no more payment can be received on the disposed lnd: even if there were some invoices issued by the disposed lnd that another party tried to pay, the payment would not go through because of the liveness requirement to receive a payment.
all the above logic of payment doesn't apply for the onchain wallet. a user could have shared an onchain address, and received a payment later. if the fees are high (and moving higher) maybe a user will be waiting for its transaction to confirm on chain for weeks/months.
the current issue is that the onchain addresses of the users are tied to a particular lnd. so if this lnd is being disposed, the pending/future onchain payment send to this node would still be eventually received, but unless the node is being restarted, those payment would never be credited to the associated user.
so the best way to mitigate this is create a separate the hot onchain wallet that doesn't have as much state to maintain as a lnd node. a hot bitcoin wallet could be restored easily with an xpriv to another bitcoind node.
this is the key reason as to why moving from the current hot onchain wallet relying on lnd to something that require less state and would likely never need to be recycled.
not focus on onchain
lightning labs doesn't focus on onchain wallet as much as lightning (which is understandable). some example of issues that have been pending:
I would expect bitcoind to not have such issues
The text was updated successfully, but these errors were encountered: