Re: Recover ECKey from Hex

[vbarna]

I think that I have answered my own question. I guess that it can be done 
like this:

ECKey ecKeyFromHex = 
aWalletKitApp.wallet().findKeyFromPubKey(Utils.HEX.decode(hexPubKey));

However, I'm still wondering if the reason why there is not a method to do 
this directly 
(which to me, getting an ECKey from a public key hex seems something very 
common to require) is
some conceptual mistake that I have. 


 

On Wednesday, August 9, 2017 at 4:21:58 PM UTC+2, vba...@gmail.com wrote:
>
> Dear all,
>
> Is there a way that I can recover an ECKey from the hex? Kind of an 
> inverse of ECKey.getPublicKeyAsHex. 
> There is something similar with 
> DeterministicKey.deserializeB58(base58,params). However, just base58 is 
> accepted.
>
> Or may be there is an explanation why I should not be doing that?
>
> Regards.
>
>
>

-- 
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.

Re: Recover ECKey from Hex

[vbarna]

Actually, to compliment my last answer, I would like to add the way to 
recover they ECKey if it is a public only key: 

ECKey.fromPublicOnly(Utils.HEX.decode(hexPubKey)


On Thursday, August 10, 2017 at 12:52:00 PM UTC+2, vba...@gmail.com wrote:
>
> I think that I have answered my own question. I guess that it can be done 
> like this:
>
> ECKey ecKeyFromHex = 
> aWalletKitApp.wallet().findKeyFromPubKey(Utils.HEX.decode(hexPubKey));
>
> However, I'm still wondering if the reason why there is not a method to do 
> this directly 
> (which to me, getting an ECKey from a public key hex seems something very 
> common to require) is
> some conceptual mistake that I have. 
>
>
>  
>
> On Wednesday, August 9, 2017 at 4:21:58 PM UTC+2, vba...@gmail.com wrote:
>>
>> Dear all,
>>
>> Is there a way that I can recover an ECKey from the hex? Kind of an 
>> inverse of ECKey.getPublicKeyAsHex. 
>> There is something similar with 
>> DeterministicKey.deserializeB58(base58,params). However, just base58 is 
>> accepted.
>>
>> Or may be there is an explanation why I should not be doing that?
>>
>> Regards.
>>
>>
>>

-- 
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.

Re: BIP34, BIP65, BIP66 enforcement

[Andreas Schildbach]

On 08/03/2017 12:48 PM, 'Jean-Pierre Rupp' via bitcoinj wrote:
> Perhaps I am missing some code, but I can't seem to find any code that 
> enforces the BIP34, BIP65 and BIP66 block versions at specific blockchain 
> heights. Am I right? Will bitcoinJ allow older block version numbers to be 
> used in new blocks as long as they have enough PoW?

VersionTally keeps track of BIP activations in the above cases. However,
this only works if you sync the chain from genesis; in the more common
case of syncing from a checkpoint the first x blocks are not enforced.

Enforcing BIP9-based activiations will be even harder as version bits
don't keep their state after activation.

In the end, we will need to depend on hardcoded block heights, but those
we only know after the fact. So basically it's the PoW that counts.



-- 
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.

Re: bitcoinj for BCH

[Andreas Schildbach]

On 08/08/2017 09:25 PM, Wei Hsu wrote:
> Is anyone working on a bitcoin cash splitter, or a BCH version of bitcoinj? 
> What would a project like that entail, if I wanted to look into it?

There is an open PR for signing BCH transactions:

https://github.com/bitcoinj/bitcoinj/pull/1422

-- 
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.

Re: Is it possible to create wallet without DAT file

[Andreas Schildbach]

On 08/07/2017 07:13 AM, Ajit Soman wrote:
> I want to create wallet without saving it as .dat file. 
> 

You can use

new Wallet(params)

There is no need to save it to disk if you don't want to.

-- 
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.

Re: Recover ECKey from Hex

[Andreas Schildbach]

There is ECKey.fromPublicOnly() and ECKey.fromPrivate(). Yes, you need
to convert your hex to a byte array yourself, or by using Utils.HEX like
you did.


On 08/10/2017 01:27 PM, vba...@gmail.com wrote:
> Actually, to compliment my last answer, I would like to add the way to
> recover they ECKey if it is a public only key:
> 
> ECKey.fromPublicOnly(Utils.HEX.decode(hexPubKey)
> 
> 
> On Thursday, August 10, 2017 at 12:52:00 PM UTC+2, vba...@gmail.com wrote:
> 
> I think that I have answered my own question. I guess that it can be
> done like this:
> 
> ECKey ecKeyFromHex =
> aWalletKitApp.wallet().findKeyFromPubKey(Utils.HEX.decode(hexPubKey));
> 
> However, I'm still wondering if the reason why there is not a method
> to do this directly
> (which to me, getting an ECKey from a public key hex seems something
> very common to require) is
> some conceptual mistake that I have.
> 
> 
>  
> 
> 
> On Wednesday, August 9, 2017 at 4:21:58 PM UTC+2, vba...@gmail.com
> wrote:
> 
> Dear all,
> 
> Is there a way that I can recover an ECKey from the hex? Kind of
> an inverse of ECKey.getPublicKeyAsHex.
> There is something similar with
> DeterministicKey.deserializeB58(base58,params). However, just
> base58 is accepted.
> 
> Or may be there is an explanation why I should not be doing that?
> 
> Regards.

-- 
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.

Re: Why block header starts at block 421344

[Andreas Schildbach]

More specifically, there is a piece of code that fetches the last
checkpoint from CheckpointManager and feeds it into the block store.
Just remove that line.


On 08/07/2017 11:06 PM, 'Jean-Pierre Rupp' via bitcoinj wrote:
> Hello,
> 
> Delete the checkpoints if you wish to sync from Genesis.
> 
> Cheers!
> 
> 
> Sent with ProtonMail  Secure Email.
> 
>>  Original Message 
>> Subject: Why block header starts at block 421344
>> Local Time: August 7, 2017 9:50 PM
>> UTC Time: August 7, 2017 8:50 PM
>> From: levduc...@gmail.com
>> To: bitcoinj 
>>
>> I tried to run the bitcoinj toy wallet app and sniff those packets
>> that were sent by the app.
>>
>> However, it seems that when the wallet app first connects to the
>> network, the bitcoinj sends a getheader that starts at block 421344
>> ( 2016-07-18 23:22:42 ). 
>> I understand that it may help reduce the time and works required to
>> sync the header chain, and it seems difficult for an adversary to
>> provide a long valid header chain.
>> But still ?
>>
>> 1. What else can go wrong with this approach?
>>
>> 2. Can I modify the code so it starts at block 1? I  just want to test
>> how long it may take.
>>
>> Thanks, 
>>
>>
>> --
>> 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.
> 
> -- 
> 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.


-- 
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.

Re: How to get the PK's from a backup

[Andreas Schildbach]

On 08/04/2017 05:33 AM, Dennis Fantoni wrote:
> 
> 
> On Thursday, 3 August 2017 04:10:13 UTC+2, Dennis Fantoni wrote:
> 
> i tried to use wallet-tool  dump --dumpprivkeys --password=spendingpin
> 
> but the resulting text file does not seem to have anything that i
> could identify as something that could be used with importprivkey in
> a core wallet.
> 
> 
> My preliminary results indicate that if you specify
> --password=spendingpin then there will be no private keys in the output
> even if the spendingpin is correct.
> However, if i create a new backup from bitcoin wallet where i have
> removed the spending pin  and then use wallet-tool dump --dumpprivkeys
> without the --password= command, then the private keys show up.



Thanks, indeed this functionality is broken. It has been filed as

https://github.com/bitcoinj/bitcoinj/issues/1431

You can use decrypt to decrypt your wallet first, then dump, then
encrypt it again. (Yes, this will make the plaintext version of your
wallet hit your harddrive.)


-- 
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.

migrating bitcoinj to segwit

[fdr636]

Hello,

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)
   - a few sw-related minor changes (like not using the payload hash that 
   comes with tx messages for sw txs)
   - a "segwit" mode (more info below)

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.