FYI, I just rebased the segwit branch on current master.
On 08/12/2017 05:40 PM, Andreas Schildbach wrote:
> 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.
