Fabrice Drouin [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-07 📝 Original message: Hi Chris, What we've ...
📅 Original date posted:2019-01-07
📝 Original message:
Hi Chris,
What we've learned building a lite bitcoin/LN wallet is that there are
different things it must implement:
- a bitcoin wallet. We started with bitcoinj, but there are known
issues with Bloom Filters, which is one of the reasons why we ended up
building our own wallet that connect to Electrum Servers (and it seems
we're not the only ones). I'm not sure that a "better" implementation
of BIP37 is actually needed, if that's what you mean by "traditional
SPV". Client-side filters is a nice improvement, and we have a basic
Neutrino prototype that is up to date with the BIPs but not used in
our mobile app. We could collaborate on this ?
- monitoring your channels" part: detect that your peer is trying to
cheat and published an old commit tx, and publish a penalty tx. This
is fairly easy (the "detecting" part at least :))
- validating channels: you receive gossip message, and check that
channels actually exist, detect when they've been closed and remove
them from your routing table. This is much harder. Electrum servers
now have a method for retrieving a tx from its coordinates (height +
position), but as the number of channels grows it may become
impractical to watch every channel. With Bloom Filters and client-side
filters you probably end up having to download all blocks (but not
necessarily store them all).
I also think that it's very important the lite wallet support mobile
platforms, android in your case, and since it's basically stuck at
Java 7 you may wan to consider using plain Java (or Kotlin) instead of
Scala as much as possible.
Cheers,
Fabrice
On Sun, 6 Jan 2019 at 15:58, Chris Stewart <chris at suredbits.com> wrote:
>
> Hi all,
>
> Hope your 2019 is off to a fantastic start. I'm really excited for Lightning in 2019.
>
> We are currently reviving a lite client project in bitcoin-s (https://github.com/bitcoin-s/bitcoin-s-core/pull/280). The goal is to have a modern replacement for bitcoinj that also can be used for L2 applications like lightning. We also are planning on supporting multiple coins, hsms etc.
>
> The current plan is to implement traditional SPV, and then implement neutrino when development is picking back up on that in bitcoin core. If that takes too long, we will consider implementing neutrino against btcd.
>
> What I wanted to ask of the mailing list is to give us "things to consider" when developing this lite client from a usability perspective for lightning devs. How can we make your lives easier?
>
> One thing that seems logical is to adhere to the bitcoin core api when possible, this means you can use bitcoin-s as a drop in lite client replacement for bitcoin core.
>
> Thoughts?
>
> -Chris
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Hi Chris,
What we've learned building a lite bitcoin/LN wallet is that there are
different things it must implement:
- a bitcoin wallet. We started with bitcoinj, but there are known
issues with Bloom Filters, which is one of the reasons why we ended up
building our own wallet that connect to Electrum Servers (and it seems
we're not the only ones). I'm not sure that a "better" implementation
of BIP37 is actually needed, if that's what you mean by "traditional
SPV". Client-side filters is a nice improvement, and we have a basic
Neutrino prototype that is up to date with the BIPs but not used in
our mobile app. We could collaborate on this ?
- monitoring your channels" part: detect that your peer is trying to
cheat and published an old commit tx, and publish a penalty tx. This
is fairly easy (the "detecting" part at least :))
- validating channels: you receive gossip message, and check that
channels actually exist, detect when they've been closed and remove
them from your routing table. This is much harder. Electrum servers
now have a method for retrieving a tx from its coordinates (height +
position), but as the number of channels grows it may become
impractical to watch every channel. With Bloom Filters and client-side
filters you probably end up having to download all blocks (but not
necessarily store them all).
I also think that it's very important the lite wallet support mobile
platforms, android in your case, and since it's basically stuck at
Java 7 you may wan to consider using plain Java (or Kotlin) instead of
Scala as much as possible.
Cheers,
Fabrice
On Sun, 6 Jan 2019 at 15:58, Chris Stewart <chris at suredbits.com> wrote:
>
> Hi all,
>
> Hope your 2019 is off to a fantastic start. I'm really excited for Lightning in 2019.
>
> We are currently reviving a lite client project in bitcoin-s (https://github.com/bitcoin-s/bitcoin-s-core/pull/280). The goal is to have a modern replacement for bitcoinj that also can be used for L2 applications like lightning. We also are planning on supporting multiple coins, hsms etc.
>
> The current plan is to implement traditional SPV, and then implement neutrino when development is picking back up on that in bitcoin core. If that takes too long, we will consider implementing neutrino against btcd.
>
> What I wanted to ask of the mailing list is to give us "things to consider" when developing this lite client from a usability perspective for lightning devs. How can we make your lives easier?
>
> One thing that seems logical is to adhere to the bitcoin core api when possible, this means you can use bitcoin-s as a drop in lite client replacement for bitcoin core.
>
> Thoughts?
>
> -Chris
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev