Many thanks for your offer! See my comments inline.
On 08/10/2017 06:29 PM, fdr...@gmail.com wrote:
> I've been working on modifying bitcoinj to use segwit, I've seen that
> other people are also working on bitcoinj+SW, and would like to share
> where I am and ask a few questions:
>
> The changes so far are:
>
> * modify the protobuf definitions and serialization code to include
> witness data (I think that it should fix issue #1418)
This sounds like it can be merged right away. Yes, please submit a PR
(preferably with unit tests, but if not then don't worry).
> * a few sw-related minor changes (like not using the payload hash that
> comes with tx messages for sw txs)
If this is more correct, yes please submit a PR. We'll happily take a
look at your improvements.
> * a "segwit" mode (more info below)
This ties in with the "HD wallet format for Segwit" thread I started on
July 21. I think neither an environent variable nor a context variable
is a good fit for this.
I think it should be a variable in DeterministicKeyChain.
MarriedKeyChain is a DeterministicKeyChain too, so it could probably
benefit from segwit at the same time. The idea would be that all
addresses in a chain have the same type, so from my mailing list post
option B. Different chains can have different types.
Migration:
I would suggest up to three phases:
Phase 1) Only new wallets create a P2SH-of-P2WPKH chain and only use
that. Old wallets stay with whatever chain they already got.
Phase 2) Old wallets will be retrofitted with a P2SH-of-P2WPKH chain and
use that chain for receiving coins and change. UTXOs on the old chain
will be spent first, but only as they are needed (an actual payment
being made).
Phase 3) A wallet maintenance will be requested, sending all coins from
the old chains to the new. The infrastrucure for wallet maintenance is
already in place and used for deterministic wallet upgrades and
replacing compromised seeds ("key rotation").
I'm not sure if phase 3 actually makes sense, but it is good to know the
possibility exists. Obviously I would start with phase 1 only for now.
> I believe that the first 2 sets of changes could make their way into
> bicoinj (segwit branch) as-is.
> The "segwit mode" is a mode where all receive and change addresses are
> P2SH-of-P2WPKH instead of P2PKH. My understanding is that it is the
> recommended way of migrating a wallet to segwit.
>
> We've used this modified version of bitcoinj in our work on Lighting and
> it fit our requirements, but I would like to have your opinion before I
> submit a PR:
>
> * the segwit mode is triggered by an environment variable, but I was
> wondering if there might be a better option (maybe the Context
> object but I'm not too sure) ?
> * Also, it is a "binary" mode i.e either all UTXOs managed by the
> wallet are segwit outputs, or none of them are. I don't see how to
> mix both modes since to get the benefit of SW then all outputs that
> you spend must be SW outputs.
> * Likewise, the only migration strategy for an existing wallet that I
> see is "send everything to a new SW output" ? It's not clear to me
> yet whether bitcoinj can manage several different wallets at the
> same time ?
> * I'm not sure how segwit is supposed to work with "married" wallets
>
> Best regards,
>
> Fabrice
--
You received this message because you are subscribed to the Google Groups
"bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to bitcoinj+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
