bitcoinj 0.14.2

[Andreas Schildbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(repost because Enigmail messed up my post)


I'm pleased to announce the release of bitcoinj 0.14.2, a maintenance
update to the Java implementation of the Bitcoin protocol.

This fixes a couple of regressions, most notably a bug that causes a
wrong (too low) balance calculation of a wallet.

For a thorough list, have a look at the release notes [1] and the git
log [2].

As always, the v0.14.2 release tag is signed with my's GPG key [3].
The pre-built jars can be fetched from Maven central and JCenter [4].
Those artifacts are signed with my key as well.

[1] https://bitcoinj.github.io/release-notes#version-0142
[2] https://github.com/bitcoinj/bitcoinj/commits/release-0.14
[3] https://bitcoin.org/andreas_schildbach.asc
[4] https://bitcoinj.github.io/using-maven
https://bitcoinj.github.io/using-gradle
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAldNjZkACgkQymYr4YuHemDd6wCbB6QgLXuDSIsOfCvJroBEmJMX
L6cAnAxK8Hizq5ae52muqR/hbLrHXFeU
=0IEV
-END PGP SIGNATURE-

-- 
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 gets too many connections after reconnect

[Andreas Schildbach]

Hmm, I think I've seen that on a small scale, where sometimes 7 rather
than 6 peers were connected. One fundamental problem is if you try to
connect to a number of peers to fill up your quota, you don't know how
many peers will actually get fully connected.

Anyway, I think the last one to work on the connection management was
Devrandom. Maybe he wants to take a look?

I noticed your branch isn't rebased on current master (or at least a
recent 0.14 release). Any chance you can do that?


On 06/16/2016 02:40 PM, Manfred Karrer wrote:
> BitcoinJ gets too many connections after a reconnect as it adds up a lot
> of potential candidates (inactives) and then try to connect to all of
> those when getting the connection again. A check for maxConnections is
> missing to not exceed connections. The nr. of connections I observed was
>> 100.
> 
> I added in my branch a fix for that, though as I am not very familiar
> with the BitcoinJ code base I don't want to do a PR here.
> Someone who knows BitcoinJ better might find a better place to add that
> check.
> 
> Here is my fix:
> https://github.com/bitsquare/bitcoinj/commit/e112b139d1f10c2245f78ec5dab93c19f5f8aca2
> 
> -- 
> 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: Disable retargeting for regtest

[Andreas Schildbach]

I prefer solution 2 as it is the simpler one, but it needs a code comment.


On 06/09/2016 10:02 PM, Oscar Guindzberg wrote:
> Hi,
> 
> Retargeting is disabled on bitcoin core for regtest, but enabled on
> bitcoinj for regtest.
> 
> See https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L257
> See https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L54
> 
> If you have a bitcoind running on regtest with more than 10k blocks, and
> use bitcoinj to sync with it, it will reject blocks starting on block
> 10,000.
> 
> I wrote 2 different solutions:
> 
> Solution 1: The way it is implemented on bitcoin core
> https://github.com/oscarguindzberg/bitcoinj/commit/1f6049e56077f3707f087f8648d5bfb571771a4e
> 
> Solution 2: Simple solution
> https://github.com/oscarguindzberg/bitcoinj/commit/3d322b7a3340f7a16187d649a2e6af9fdc6f0913
> 
> What solution sounds better?
> 
> -- 
> Oscar Guindzberg
> 
> -- 
> 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: tests fail when building bitcoinj under x86-64 openSUSE Leap 42.1 distro

[Andreas Schildbach]

What branch/commit are you on?

What JDK are you using?


On 06/23/2016 12:31 PM, mailto@gmail.com wrote:
> Please, help .
> 
> Some bitcoinj library tests failed,  when trying to install bitcoinj
> java library under openSUSE Leap 42.1 distro
> 
> Tests run: 42, Failures: 2, Errors: 0, Skipped: 2, Time elapsed: 12.254
> sec <<< FAILURE! - in org.bitcoinj.core.PeerGroupTest
> autoRescanOnKeyExhaustion[0](org.bitcoinj.core.PeerGroupTest)  Time
> elapsed: 0.311 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<150> but was:<100>
>at org.junit.Assert.fail(Assert.java:88)
>at org.junit.Assert.failNotEquals(Assert.java:834)
>at org.junit.Assert.assertEquals(Assert.java:118)
>at org.junit.Assert.assertEquals(Assert.java:144)
>at
> org.bitcoinj.core.PeerGroupTest.autoRescanOnKeyExhaustion(PeerGroupTest.java:804)
> 
> 
> Tests run: 15, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 2.944
> sec <<< FAILURE! - in org.bitcoinj.wallet.DeterministicKeyChainTest
> events(org.bitcoinj.wallet.DeterministicKeyChainTest)  Time elapsed:
> 0.157 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<12> but was:<10>
>at org.junit.Assert.fail(Assert.java:88)
>at org.junit.Assert.failNotEquals(Assert.java:834)
>at org.junit.Assert.assertEquals(Assert.java:645)
>at org.junit.Assert.assertEquals(Assert.java:631)
>at
> org.bitcoinj.wallet.DeterministicKeyChainTest.events(DeterministicKeyChainTest.java:196)
> 
> What could be wrong ? When I look at java code
> in DeterministicKeyChainTest.java, I see some constants:
> ... 
> assertEquals(12, secondEvent.size());  // (5 lookahead keys, +1
> lookahead threshold) * 2 chains
> ...
> Can these constants lead to such errors in tests ?
> 
> Thank you.
> 
> 
> 
> 
> -- 
> 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: tests fail when building bitcoinj under x86-64 openSUSE Leap 42.1 distro

[Andreas Schildbach]

On 06/23/2016 05:10 PM, mailto@gmail.com wrote:

>bitcoinj  0.13.1.4

This is not an official version and it's not even from the official
repository. Please get bitcoinj from here:

https://github.com/bitcoinj/bitcoinj


-- 
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 Sender Address and Receive Address in BitcoinJ

[Andreas Schildbach]

The concept of a "sender address" is not well defined in Bitcoin. I
suggest your app should do without.

Regarding the receiving address, there can be many recipients (in the
same transaction), so you need to iterate for the correct ones. E.g. for
incoming transactions, you can do

for (TransactionOutput output : tx.getOutputs())
{
try
{
if (output.isMine(wallet))
{
Script script = output.getScriptPubKey();
Address address = 
script.getToAddress(Constants.NETWORK_PARAMETERS,
true);
// do something with the address
}
}
catch (final ScriptException x)
{
// swallow
}
}


On 06/19/2016 04:52 AM, Minh Le Quang wrote:
> I'm create app with BitcoinJ lib. I have several address and I send them
> to my Friends, when my friend send money to me I don't know who is he. 
> So I want to know what is sender bitcoin address and what is receive
> bitcoin address.
> I'm using this code to detect the address but it alway show all my
> bitcoin address in my wallet. 
> 
> public void onCoinsReceived(Wallet w, Transaction tx, Coin prevBalance,
> Coin newBalance) {
> 
> 
>   List inputs = tx.getInputs();
> 
> |List outputs = tx.getOutputs(); for(TransactionOutput
> out : outputs){
> System.out.println(out.getAddressFromP2PKHScript(params));
> System.out.println(out.getAddressFromP2SH(params)); }
> for(TransactionInput in : inputs){
> System.out.println(in.getFromAddress()); }|
> 
> }
> 
> 
> Please give me a advise.
> 
> -- 
> 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 can get the from address of an transaction?

[Andreas Schildbach]

No, the method is deprecated because in general there is no "from
address". Read the comment on the method.


On 02/21/2017 10:04 PM, tuoz...@gmail.com wrote:
> Hi everyone, 
> 
> I would like to from address of an transaction without having to use 
> deprecated method getFromAddress() of the class TransactionInput. Is it 
> possible?
> 
> Best 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: How to get the master private key from a Wallet object?

[Andreas Schildbach]

Afaik MultiBit HD is using a modified version of bitcoinj, so maybe you
should ask there too.

The topic of watching wallets is covered in the docs:

https://bitcoinj.github.io/working-with-the-wallet#watching-wallets

Most important, in order to monitor you don't need any private key. Just
use the public master key ("xpub") like explained in the link.


On 09/26/2016 02:05 PM, Yvon Fortier wrote:
> Hi people.
> I'm trying to dump the master private key from MultibitHD to monitor
> from other wallet, but I can't get it right.
> What I do is restore a wallet and then try to get the private key from
> the Wallet object:
> 
> Code:
> 
> *NetworkParameters PARAMS = MainNetParams.get();DeterministicKeyChain kc 
> = wallet.getActiveKeychain();DeterministicKey rk = 
> kc.getRootKey();String key = rk.getPrivateKeyAsWiF(PARAMS);*
> 
> 
> I'm getting an exception saying *java.lang.IllegalStateException:
> Private key bytes not available *
> 
> Any help would be greatly appreciated.
> 
> Alternatively, if someone knows how to properly derive the master key
> from the seed using a third party tool, that'd help!
> 
> -- 
> 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: Unit tests in bitcoinj, dependencies on running properties with JUnit (via maven).

[Andreas Schildbach]

Indeed, I'm not too happy with this either. Which is why I simply tried
to fix bugs rather than continue with the work on Contexts for the last
bitcoinj release... (I did however move some static variables into the
context.)

Mike once compared bitcoinj contexts to OpenGL contexts, but
interestingly OpenGL contexts are mentioned one of the bad design
decisions which were "undone" with the Vulkan API.

Still I'm not sure how to continue here. We certainly would need a
broader discussion before decidiing to go back to parameters. Most (if
not all) of the parameter based calls are still there but I think they
were planned to be removed in future.


On 09/20/2016 04:59 PM, Jarl Fransson wrote:
> 
> So you suggest to deprecate the use of ThreadLocal for Context? 
> 
> Yes. I think it was a bad choice to put more semantics on threads than
> what is there already, even if it was temporary. It is better and safer
> to be explicit. It seems to have been the goal from start to eventually
> rid this: in the docs, "Eventually this auto-magic will be deleted and
> explicit passing of Context into all classes that need it will be used
> instead."
> 
> All tests that create there own context could get different context than
> they expect so that points to the problems with the design. I would also
> propose to make Context explicitly immutable, which it effectively is now.
> 
>  
> 
> The idea of contexts is we don't need to carry it around on lots of
> calls. Not sure if we want to go back to where we came from. Also
> afaicr
> the context refactoring isn't finished yet.
> 
> I realise that. I think the change is not too hard to make as most key
> objects like Wallet, Chain etc already has either Context or NetworkParams.
> 
> I think unless we discard the use Context.propagate/get, uses of
> different Context in the same process are unsafe.
> 
> -- 
> 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: Will RBF transactions be supported?

[Andreas Schildbach]

You can set sequence numbers on inputs so yes you could create an RBF
transaction, but there is currently no API for double spending.


On 09/27/2016 09:23 AM, Tobias Brandt wrote:
> With "supported" I mean that it's possible to send an RBF transaction
> (and send again with higher fee).
> Maybe that's also already possible and I missed it.
> 
> 
> Am Montag, 26. September 2016 10:22:06 UTC+2 schrieb Andreas Schildbach:
> 
> What do you mean by "supported"? There is
> TransactionInput.isOptInFullRBF() and Transaction.isOptInFullRBF() for
> quite some time. They are considered risky by DefaultRiskAnalysis, but
> you can customize your own analysis if you want.
> 
> 
> On 09/25/2016 12:37 PM, Tobias Immernochmeinesache wrote:
> 
> > neither do I really think that RBF was a good idea nor do I like
> peter
> > todd a lot (not that this matters but somehow I had to mention it).
> > But still I have a usecase for the application I'm developing
> right now
> > where it would be of some use.
> > So is it planned to make RBF transaction possible in bitcoinj?
> 
> 
> -- 
> 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
> <mailto: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: Will RBF transactions be supported?

[Andreas Schildbach]

Setting the flag is only the easy part. The hard part is properly
supporting double spends (and at the same time still support the old
behaviour). But yeah, just try it.


On 09/29/2016 11:04 PM, Tobias Brandt wrote:
> Ok, thanks for the reply.
> I want to allow my users to send a transaction again with a higher fee
> when it's not confirmed yet. So it would be nice if this will be
> supported by the API at some point.
> But I'll take a look at how to do it by using sequence numbers too. But
> my understanding right now is that there is/will be a special flag that
> has to be set to flag a transaction as rbf.. how could this be possible
> by using sequence numbers on inputs?
> 
> Am Dienstag, 27. September 2016 14:43:41 UTC+2 schrieb Andreas Schildbach:
> 
> You can set sequence numbers on inputs so yes you could create an RBF
> transaction, but there is currently no API for double spending.
> 
> 
> On 09/27/2016 09:23 AM, Tobias Brandt wrote:
> > With "supported" I mean that it's possible to send an RBF transaction
> > (and send again with higher fee).
> > Maybe that's also already possible and I missed it.
> >
> >
> > Am Montag, 26. September 2016 10:22:06 UTC+2 schrieb Andreas
> Schildbach:
> >
> > What do you mean by "supported"? There is
> > TransactionInput.isOptInFullRBF() and
> Transaction.isOptInFullRBF() for
> > quite some time. They are considered risky by
> DefaultRiskAnalysis, but
> > you can customize your own analysis if you want.
> >
> >
> > On 09/25/2016 12:37 PM, Tobias Immernochmeinesache wrote:
> >
> > > neither do I really think that RBF was a good idea nor do I
> like
> > peter
> > > todd a lot (not that this matters but somehow I had to
> mention it).
> > > But still I have a usecase for the application I'm developing
> > right now
> > > where it would be of some use.
> > > So is it planned to make RBF transaction possible in bitcoinj?
> >
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Segwit addresses can be 32-bytes long (#1312)

[Andreas Schildbach]

Out of curiosity: What other address formats are in development?


On 11/09/2016 07:42 PM, Matt Corallo wrote:
> I'm confused, it seems you're implementing BIP 142, which was withdrawn. 
> There is currently no proposed (AFAIK) address format for P2WSH/P2WPKH 
> scripts, though there is a ton of ongoing work in building a TON better 
> address format for it.
> 
> On November 9, 2016 7:25:55 AM PST, Andreas Schildbach 
> <andr...@schildbach.de> wrote:
>> (this is a followup to
>> https://github.com/bitcoinj/bitcoinj/issues/1312)
>>
>> Great to hear you're working on segwit! It's much appreciated.
>>
>> I would first invest some time to decide if a segwit address is
>> actually
>> similar enough to a regular Bitcoin address to be implemented with the
>> same class. In theory, it could also be another subclass of
>> VersionedChecksummedBytes.
>>
>> If your decision is you want a shared implementation for both types of
>> addresses (and your code seems to proove this), then I agree the
>> constant needs to go sooner or later. I would not worry too much about
>> backwards compatibility here, but marking it deprecated seems fine to
>> me
>> for now too.
>>
>>
>> On 11/09/2016 03:28 PM, Jean-Pierre Rupp wrote:
>>> I have been working on segwit addresses on my fork of this code. I
>>> noticed that the |Address| class has a static property |LENGTH| that
>> is
>>> set to 20. In order to work properly with segwit, the |LENGTH|
>> property
>>> has to be set individually per address instance, or not at all. I for
>>> now left it at 20 and marked it |@Deprecated|. I would like to know
>> if
>>> the property should instead be removed, even if it breaks backwards
>>> compatibility. My code is here
>>> <https://github.com/xenog/bitcoinj/tree/segwit>.
> 


-- 
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: warning from peers: This is outdated and network-inconsistent software

[Andreas Schildbach]

According to Bitcoin Core, their protocol is still backwards compatible.
So there should not be any issue to worry about.


On 11/04/2016 08:55 PM, Wei Hsu wrote:
> Hi, I'm getting this message running bitcoinj on prodnet:
> 
> Received alert from peer [...]:8333: Warning: This is outdated and
> network-inconsistent software. Also, the alert system has been
> deprecated. Upgrade is strongly recommended. See
> https://bitcoin.org/alert-retirement
> 
> The alert system deprecation shouldn't cause any issues, but could
> someone elaborate on the "network-inconsistent" part?
> 
> -- 
> 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: protobuf (protoc) new release 3.1.0

[Andreas Schildbach]

...but actually it should not matter much. You should be able to use
3.1.0 for your PR, and before merging I will amend the commit by running
protoc 2.6.1.


On 10/12/2016 02:10 PM, Andreas Schildbach wrote:
> Ubuntu 16.04 installs protoc 2.6.1 by default, which is why I'm
> currently sticking to this version.
> 
> 
> On 10/12/2016 11:56 AM, Jarl Fransson wrote:
>> This is a small issue, but for the next release we should maybe upgrade
>> protobuf (protoc) from protobuf-2.6.1 to the current 3.1.0.
>>
>> If you use homebrew or similar you get the 3.1.0 version. Older versions
>> can be downloaded and installed manually.  But it becomes tedious to
>> switch your protoc installation back and forth if you use it in other
>> projects. It should be binary compatible with no change in the proto
>> files (or we should add the version proto2 in the files explicitly as
>> there is now a proto3 version of the proto file type). The generated
>> java code will change.
>>
>> -- 
>> 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
>> <mailto: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: Determining the sender and receiver of a transaction

[Andreas Schildbach]

On 12/20/2016 01:58 AM, Ali Akhtar wrote:
> When I load a block, and go thru its transactions, how can I determine
> the sender, and recipient of the transaction?
> 
> Each transaction has an inputs and outputs list. How can the receiver
> and sender addresses be inferred through them?

If by sender/receiver you mean an identity of them, you can't. Bitcoin
is pseudonomous.

> There's also a scripts section which only returns an array of bytes.
> When I try to create a string of these bytes, its unreadable.

The byte array is a binary format. You an parse it into a script using
the org.bitcoinj.script.Script constructor.

> Do the scripts need to be used in determining the sender / receiver? Is
> there a parser for the scripts included in bitcoinJ (or in another library)?

If the script is a pay to pubkey hash, you can get the recipient address
from the script. See the .isSentToAddress() and .getToAddress() methods.


-- 
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: Question: Transaction version and Bitcoin Core 14

[Andreas Schildbach]

As far as I understood the problem, transaction versions are not part of
the consensus. So they can be any value and for confirmed transactions
it doesn't make a difference. However, in order to get the transaction
hash right, we persist the transaction version along with everything else.

Bitcoin Core 0.14 started to make use of the transaction version (for
unconfirmed transactions only), which is why you're starting to see this
problem.


On 03/22/2017 03:04 PM, Manfred Karrer wrote:
> I just saw that I get an UnreadableWalletException when I use Bitcoin
> Core 14 for creating blocks (regtest) and have a transaction in my
> wallet which is in that block.
> I found
> that 
> https://github.com/bitcoinj/bitcoinj/commit/be09b620626681c9e51a211ee314a34cb7958a12
> fixed an serialization issues with the transaction version. After
> applying that fix to my branch I get rid of the problem as well.
> 
> I wanted to ask for a bit more background why that suddenly breaks with
> Bitcoin Core 14. 
> Is transaction version added in Bitcoin Core 14 and was not used in
> earlier versions?
> 
> Br,
> Manfred
> 
> -- 
> 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: Problem in RefereshingWallet

[Andreas Schildbach]

Make sure ports 53 (DNS), 8333 (Bitcoin) and 18333 (Bitcoin-testnet) are
open for outgoing traffic.


On 03/23/2017 06:07 PM, Ramez Az wrote:
> I have firewall in my network. Anything should we need to do something
> on firewall?
> 
> On Tuesday, March 21, 2017 at 3:02:39 PM UTC+5:30, Andreas Schildbach wrote:
> 
> I don't see RefreshWallet connecting to peers. It didn't even discover
> peers. Is your network restricting DNS traffic somehow?
> 
> Without updating the blockchain it will never learn of the incoming
> payment and this is why the balance is zero.
> 
> 
> 
> On 03/21/2017 06:49 AM, Ramez Az wrote:
> > Hi,
> >
> > I have created wallet using WalletTool program and transfered some
> cons
> > into that from http://faucet.xeno-genesis.com/
> <http://faucet.xeno-genesis.com/>. I am able to see the
> > transaction detail
> > in
> 
> https://testnet.blockexplorer.com/address/mjhvWeeoPrAegY5od5rKdjCb4mPZhzp11Y
> 
> <https://testnet.blockexplorer.com/address/mjhvWeeoPrAegY5od5rKdjCb4mPZhzp11Y>.
> 
> >
> > When i try to spend from this
> > wallet, org.bitcoinj.core.InsufficientMoneyException: Insufficient
> > money,  missing 0.5 BTC is getting thrown and balance is also
> > getting displayed as 0. Then i tried to use the refresh the wallet
> using
> > RefereshWallet tool. The program seems hung at
> > peerGroup.downloadBlockChain(); method. The below log are getting
> generated.
> >
> > The same problem happened while using WalletAppKit.awaitRunning();
> Can
> > you please advise what might be the issue and how should be
> resolved the
> > issue. Please find the wallet file attached for your reference.
> >
> > Mar 21, 2017 10:46:28 AM org.bitcoinj.core.AbstractBlockChain 
> > INFO: chain head is at height 0:
> >  block:
> >hash:
> 0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
> >version: 1
> >previous block:
> > 
> >merkle root:
> > 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
> >time: 1296688602 (2011-02-02T23:16:42Z)
> >difficulty target (nBits): 486604799
> >nonce: 414098458
> >
> > Mar 21, 2017 10:46:28 AM org.bitcoinj.core.AbstractBlockChain
> addWallet
> > WARNING: Wallet/chain height mismatch: -1 vs 0
> > Mar 21, 2017 10:46:28 AM org.bitcoinj.core.AbstractBlockChain
> addWallet
> > WARNING: Hashes: null vs
> > 0933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943
> > Mar 21, 2017 10:46:29 AM org.bitcoinj.core.PeerGroup$8 run
> > INFO: Starting ...
> > Mar 21, 2017 10:46:30 AM org.bitcoinj.core.PeerGroup
> > maybeCheckForLocalhostPeer
> > INFO: Localhost peer not detected.
> > Mar 21, 2017 10:46:30 AM org.bitcoinj.core.PeerGroup discoverPeers
> > INFO: Peer discovery took 66.93 μs and returned 0 items
> >  
> >
> > Thanks,
> > Ramesh A
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Controlling the address from where the coins will be spent

[Andreas Schildbach]

Have a look at the various existing implementations of the CoinSelector
interface. It shouldn't be too difficult to come up with a selector that
only selects outputs that pay to a certain address.


On 03/22/2017 05:12 AM, Ramez Az wrote:
> Can you please provide some sample program for this implementation? Thanks.
> 
> On Tuesday, March 21, 2017 at 10:10:25 PM UTC+5:30, Andreas Schildbach
> wrote:
> 
> You could do this by implementing your own CoinSelector. Bitcoinj by
> default always spends the oldest coins first, so it doesn't matter what
> address they're currently on.
> 
> 
> On 03/21/2017 01:03 PM, Ramez Az wrote:
> > Hi,
> >
> > I am trying to transfer/spent some coins from one address in a
> > particular wallet to another. I am able to transfer the coins, but
> not
> > able to find the way to mention the address from where the coin
> should
> > be spent instead of spending from the address decided by the wallet
> > itself. Is there any way to achieve this using bitcoinj APIs.
> >
> > Thanks,
> > Ramesh A
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Linking transactions from historical blockchain/Getting full transaction values

[Andreas Schildbach]

Yes, you could probably do that. The API for connecting outputs with
inputs is public. And who knows, maybe we could add a "FullBlockStore"
to bitcoinj in future?


On 03/22/2017 10:57 PM, Sidd S wrote:
> Hi Andreas,
> 
> Thanks for the information! At this point, I guess the solution will be
> write some code manually that will connect transaction inputs and
> outputs together to calculate those fields, which hopefully shouldn't be
> super painful.
> 
> Sidd
> 
> On Wednesday, March 22, 2017 at 5:42:21 PM UTC-4, Andreas Schildbach wrote:
> 
> Welcome to bitcoinj!
> 
> The input values and the fee is only known for transactions that were
> created by bitcoinj's Wallet (which you're likely not using anyway).
> For
> incoming transactions there values are missing, it's a known limitation
> of the Bitcoin protocol.
> 
> Yes, MemoryBlockStore only stores headers. Afaik there is no block
> store
> in bitcoinj that actually stores the transactions. Bitcoinj is mainly
> designed for wallets and as a wallet you'd only keep what's relevant
> to you.
> 
> 
> On 03/22/2017 08:46 PM, Sidd S wrote:
> > I am new to BitcoinJ, but it seems like a good tool for building Java
> > applications around Bitcoin. I am trying to use BitcoinJ to try and
> > parse information from the blockchain. A lot of fields are pretty
> easy
> > to fetch, but I can't seem to get a couple of things.
> >
> > I'll provide some code below that I have written just to kind of give
> > some context as to the types of things I have been trying. As a
> note, I
> > am using Scala for this, but hopefully the code should be somewhat
> > intuitive.
> >
> > |
> > // importing too many things
> > import org.bitcoinj.core._
> > import org.bitcoinj.params._
> > import org.bitcoinj.utils._
> > import org.bitcoinj.store._
> > import java.io.File
> > import java.util.ArrayList
> >
> > // init
> > val params = new MainNetParams()
> > new Context(params)
> >
> > // load the blockchain files..only loading the first .dat file
> > val files = new ArrayList[File]()
> > files.add(new File("blk0.dat"))
> > val bfl = new BlockFileLoader(params, files)
> >
> > // this line will create an array of the first 10,000 blocks
> > val b = (1 to 1).map(_ => bfl.next)
> >
> > // trying to inspect a transaction..the outputs are below
> > val ts = b(3888).getTransactions
> > val t = ts.get(10)
> > t.getFee
> > // res34: org.bitcoinj.core.Coin = null
> > t.getInputSum
> > // res35: org.bitcoinj.core.Coin = 0
> > |
> >
> > It makes sense that I am unable to get the fee or input sum of the
> 10th
> > transaction of the 3889th block because it doesn't have a link to the
> > previous transactions. How can I add these links so I can use
> > functionality like getFee and getInputSum?
> >
> > I have tried to create a MemoryBlockStore object and BlockChain
> object
> > in hopes that these would link up the transactions, but apparently
> > StoredBlocks only store the headers of blocks but not the
> transactions
> > themselves. so I am unable to access them.
> >
> > Does anyone have any idea how I can accomplish this?
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

  So lets hope that BU does not escalate and we can
> spend time on more productive stuff.
> But at the end it demonstrates a very serious
> vulnerability with SPV mode. 
> I hope the work on Bitcoin Core SPV will become a
> viable alternative soon. I consider midterm to move
> over to that model in Bitsquare. That would solve
> the privacy issues with bloom filters as well.
> 
> 
> Am Donnerstag, 23. März 2017 10:46:51 UTC-5 schrieb
> Matt Corallo:
> 
> I'm not sure you can bet on BTC having a PoW
> change, let alone make that bet and risk users
> getting completely screwed if it doesn't happen.
> 
> On March 23, 2017 2:35:02 AM PDT, "Tobias B."
> <brand...@gmail.com> wrote:
> 
> So as the minority (core) chain is likely to
> make a PoW change, wouldn't this break SPV
> clients? I hope in such a case this chain
> would also add replay protection - people
> would have to install new clients anyway.
> 
> On Wednesday, March 22, 2017 at 10:14:39 PM
> UTC+1, Manfred Karrer wrote:
> 
> When you talk about minority chain we
> should take in consideration that this
> might change over time. So todays
> winning chain might be the loser of
> tomorrow and so on. Might be pretty
> messy with re-orgs and double spends...
> Also I would not count with what some
> people expect that the minority chain
> will quickly die (or get killed). The
> ETH devs made that mistake and
> underestimated ETC a lot. Mining
> resources and price are highly dynamic
> factors making predictions much harder.
> Not to talk about the emotional and
> political factors... 
> Also a PoW change is a very likely
> element in such a scenario...
> 
> 
> Am Mittwoch, 22. März 2017 11:18:23
> UTC-5 schrieb Andreas Schildbach:
> 
> Maybe the recommendation should be:
> if you want to follow a minority
> chain, use the Peer API to connect
> to a trusted peer under your control.
> You can then run your desired full
> node implemention on the trusted peer
> and bitcoinj will follow. If the
> network between bitcoinj and the
> trusted peer is not to be trusted,
> use a VPN to secure that connection
> (the Bitcoin protocol itself lacks
> authentication).
> 
> That would be far more reliable than
> a version string whitelist. In
> fact, frontending bitcoinj with
> bitcoind has always been a
> recommendation for centralized/web
> services, so if they followed that
> recommendation they should not have
> to change anything.
> 
> 
> On 03/22/2017 03:34 PM, Tobias B.
> wrote:
> > Still maybe it adding an API call
> to go into "whitelist mode" and then
> > add certain node ips would be a
> compromise. Software building on
> 

Re: Linking transactions from historical blockchain/Getting full transaction values

[Andreas Schildbach]

Welcome to bitcoinj!

The input values and the fee is only known for transactions that were
created by bitcoinj's Wallet (which you're likely not using anyway). For
incoming transactions there values are missing, it's a known limitation
of the Bitcoin protocol.

Yes, MemoryBlockStore only stores headers. Afaik there is no block store
in bitcoinj that actually stores the transactions. Bitcoinj is mainly
designed for wallets and as a wallet you'd only keep what's relevant to you.


On 03/22/2017 08:46 PM, Sidd S wrote:
> I am new to BitcoinJ, but it seems like a good tool for building Java
> applications around Bitcoin. I am trying to use BitcoinJ to try and
> parse information from the blockchain. A lot of fields are pretty easy
> to fetch, but I can't seem to get a couple of things.
> 
> I'll provide some code below that I have written just to kind of give
> some context as to the types of things I have been trying. As a note, I
> am using Scala for this, but hopefully the code should be somewhat
> intuitive.
> 
> |
> // importing too many things
> import org.bitcoinj.core._
> import org.bitcoinj.params._
> import org.bitcoinj.utils._
> import org.bitcoinj.store._
> import java.io.File
> import java.util.ArrayList
> 
> // init
> val params = new MainNetParams()
> new Context(params)
> 
> // load the blockchain files..only loading the first .dat file
> val files = new ArrayList[File]()
> files.add(new File("blk0.dat"))
> val bfl = new BlockFileLoader(params, files)
> 
> // this line will create an array of the first 10,000 blocks
> val b = (1 to 1).map(_ => bfl.next) 
> 
> // trying to inspect a transaction..the outputs are below
> val ts = b(3888).getTransactions
> val t = ts.get(10)
> t.getFee
> // res34: org.bitcoinj.core.Coin = null
> t.getInputSum
> // res35: org.bitcoinj.core.Coin = 0
> |
> 
> It makes sense that I am unable to get the fee or input sum of the 10th
> transaction of the 3889th block because it doesn't have a link to the
> previous transactions. How can I add these links so I can use
> functionality like getFee and getInputSum?
> 
> I have tried to create a MemoryBlockStore object and BlockChain object
> in hopes that these would link up the transactions, but apparently
> StoredBlocks only store the headers of blocks but not the transactions
> themselves. so I am unable to access them. 
> 
> Does anyone have any idea how I can accomplish this?
> 
> -- 
> 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: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

As long as a fork does not change the proof of work rules, bitcoinj
makes no assumptions about forks. It will always select the chain with
the most work.

What do you mean by "requesting an UTXO" and what do you want to achieve
by that?


On 03/14/2017 06:07 PM, Manfred Karrer wrote:
> If there would happen really a BU fork SPV wallets could get a
> connection to a majority of BU nodes and so a different view to the network.
> Any plans or ideas how to deal with that?
> 
> One idea would be to use a UTXO which is known to exist on only 1 chain
> request that and use that as a check to see which chain the node is
> operated on.
> If it is not the chain the wallet supports the node gets disconnected.
> 
> Br,
> Manfred
> 
> -- 
> 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: Wallet fee calculation - special case for outputs < 0.01 BTC

[Andreas Schildbach]

Great, that's good news! I think we can just copy Core's behaviour here.
The 0.01 BTC thing is probably some remains from the "free transaction"
rule. You basically didn't have to pay a fee if none of your outputs was
too dusty. The rule doesn't exist any more in Core.



On 03/17/2017 10:39 PM, Oscar Guindzberg wrote:
> I mean Transaction.REFERENCE_DEFAULT_MIN_TX_FEE (currently set to 5000
> satoshis/kb)
> 
> On Fri, Mar 17, 2017 at 6:38 PM, Oscar Guindzberg
>  wrote:
>> I am rewriting Wallet.calculateFee().
>>
>> I am copying bitcoin-core implementation so we can have "recipient pay
>> fees" feature and other fixes.
>>
>> This is the code I am copying from
>> https://github.com/bitcoin/bitcoin/blob/9c7b7cf0bb579714b35f7c88db20a407dfc716bd/src/wallet/wallet.cpp#L2302-L2629
>>
>>
>> One thing I don't understand in our current code is why we do
>> something "special" when there is an output whose value is less than
>> 0.01 BTC.
>> In that case we make sure the tx fee is at least
>> Transaction.REFERENCE_DEFAULT_MIN_TX_FEE (currently set to 500
>> satoshis/kb)
>> See 
>> https://github.com/bitcoinj/bitcoinj/blob/v0.14.4/core/src/main/java/org/bitcoinj/wallet/Wallet.java#L4873-L4874
>>
>> I could not find anything in bitcoin-core code that does anything
>> special when a tx output value is less than 0.01 BTC
>>
>> I found release notes for version 0.3.21
>> https://github.com/bitcoin/bitcoin/blob/9c7b7cf0bb579714b35f7c88db20a407dfc716bd/doc/release-notes/release-notes-0.3.21.md
>> which shows at that time they were doing something special.
>> But release notes for version 0.9
>> https://github.com/bitcoin/bitcoin/blob/9c7b7cf0bb579714b35f7c88db20a407dfc716bd/doc/release-notes/release-notes-0.9.0.md
>> shows the feature was disabled.
>>
>> So... I will assume nothing special should be done for outputs < 0.01
>> BTC in my new Wallet.calculateFee() implementation.
>>
>> Please, correct me if I am wrong.
>>
>> Regards, Oscar
> 
> 
> 


-- 
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: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

Forks happen every day. Every time the minority chain dies very quickly.
Why should this be different?

Afaik we'd need block a length commitment to be able to distinguish as
an SPV/lite wallet. E.g. as a field in the block header.


On 03/20/2017 05:04 PM, Manfred Karrer wrote:
> Exactly. Also there are many people (including me) who will not consider
> the longest PoW chain which follows a different consensus rule as the
> valid Bitcoin version.
> Beside that for a project like Bitsquare which is a wallet and exchange
> there are many potential issues and risks (replay attacks).
> I think BitcoinJ needs a feature to distinguish clearly which chain the
> user is supporting. 
> 
> 
> Am Montag, 20. März 2017 10:25:49 UTC-5 schrieb Matt Corallo:
> 
> Given it appears likely there will be two separate currencies, it
> seems really bad to not have some ability for users to differentiate
> between them. Users will end up highly confused when they do a
> trade, receive BTU, and deposit it to an exchange only to find no BTC.
> 
> 
> On March 19, 2017 6:42:57 PM PDT, Amitabh Saxena
> <amita...@gmail.com> wrote:
> 
> Will bitcoinj reject larger blocks?
> 
> On Wednesday, March 15, 2017 at 4:38:55 PM UTC+5:30, Andreas
> Schildbach wrote:
> 
> As long as a fork does not change the proof of work rules,
> bitcoinj
> makes no assumptions about forks. It will always select the
> chain with
> the most work.
> 
> What do you mean by "requesting an UTXO" and what do you
> want to achieve
> by that?
> 
> 
> On 03/14/2017 06:07 PM, Manfred Karrer wrote:
> > If there would happen really a BU fork SPV wallets could
> get a
> > connection to a majority of BU nodes and so a different
> view to the network.
> > Any plans or ideas how to deal with that?
> >
> > One idea would be to use a UTXO which is known to exist on
> only 1 chain
> > request that and use that as a check to see which chain
> the node is
> > operated on.
> > If it is not the chain the wallet supports the node gets
> disconnected.
> >
> > Br,
> > Manfred
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

Your proposal has the problem that block hashes are not known in
advance. By the time you (manually?) added the hash to the blacklist
most bitcoinj nodes will already have processed that block. You would
need to have the blacklist cause re-orgs, too. Here is gets tricky I
guess, both for the implementation and for the end-users.

Personally I'm not happy about blacklist features in general. But I'd
probably still review/merge a block blacklist feature if there is
considerable demand from developers using bitcoinj.

btw. Do you really think an EC fork will happen? Please correct me if
I've got the math wrong, but AD6 means you'd have to mine 7 blocks in a
row, for which you have to have about 91% of hashpower to make it
economically feasible (0.91^7=0.51). Yes you can skew that number a bit
by accepting losses, but still it feels EC is almost in the same boat as
SegWit.


On 03/21/2017 02:14 AM, Matt Corallo wrote:
> Given the animosity (and the exchanges making public comments on it), I don't 
> think it's worth risking users' safety on such a bet. The API should probably 
> at least allow a simple "the block with hash X is invalid, ignore that chain" 
> function. Might want to also have something similar for the Android wallet 
> (or at least notify users that they are likely to end up using BTU and not 
> BTC).
> 
> On March 20, 2017 6:07:46 PM PDT, Andreas Schildbach <andr...@schildbach.de> 
> wrote:
>> Forks happen every day. Every time the minority chain dies very
>> quickly.
>> Why should this be different?
>>
>> Afaik we'd need block a length commitment to be able to distinguish as
>> an SPV/lite wallet. E.g. as a field in the block header.
>>
>>
>> On 03/20/2017 05:04 PM, Manfred Karrer wrote:
>>> Exactly. Also there are many people (including me) who will not
>> consider
>>> the longest PoW chain which follows a different consensus rule as the
>>> valid Bitcoin version.
>>> Beside that for a project like Bitsquare which is a wallet and
>> exchange
>>> there are many potential issues and risks (replay attacks).
>>> I think BitcoinJ needs a feature to distinguish clearly which chain
>> the
>>> user is supporting. 
>>>
>>>
>>> Am Montag, 20. März 2017 10:25:49 UTC-5 schrieb Matt Corallo:
>>>
>>> Given it appears likely there will be two separate currencies, it
>>> seems really bad to not have some ability for users to
>> differentiate
>>> between them. Users will end up highly confused when they do a
>>> trade, receive BTU, and deposit it to an exchange only to find no
>> BTC.
>>>
>>>
>>> On March 19, 2017 6:42:57 PM PDT, Amitabh Saxena
>>> <amita...@gmail.com> wrote:
>>>
>>> Will bitcoinj reject larger blocks?
>>>
>>> On Wednesday, March 15, 2017 at 4:38:55 PM UTC+5:30, Andreas
>>> Schildbach wrote:
>>>
>>> As long as a fork does not change the proof of work
>> rules,
>>> bitcoinj
>>> makes no assumptions about forks. It will always select
>> the
>>> chain with
>>> the most work.
>>>
>>> What do you mean by "requesting an UTXO" and what do you
>>> want to achieve
>>> by that?
>>>
>>>
>>> On 03/14/2017 06:07 PM, Manfred Karrer wrote:
>>> > If there would happen really a BU fork SPV wallets
>> could
>>> get a
>>> > connection to a majority of BU nodes and so a different
>>> view to the network.
>>> > Any plans or ideas how to deal with that?
>>> >
>>> > One idea would be to use a UTXO which is known to exist
>> on
>>> only 1 chain
>>> > request that and use that as a check to see which chain
>>> the node is
>>> > operated on.
>>> > If it is not the chain the wallet supports the node
>> gets
>>> disconnected.
>>> >
>>> > Br,
>>> > Manfred
>>> >
>>> > --
>>> > You received this message because you are subscribed to
>>> the Google
>>> > Groups "bitcoinj" group.
>>> > To unsubscribe from this group and stop receiving
>> emails
>>>

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

I should add: In the default SPV mode...


On 03/15/2017 12:08 PM, Andreas Schildbach wrote:
> As long as a fork does not change the proof of work rules, bitcoinj
> makes no assumptions about forks. It will always select the chain with
> the most work.
> 
> What do you mean by "requesting an UTXO" and what do you want to achieve
> by that?
> 
> 
> On 03/14/2017 06:07 PM, Manfred Karrer wrote:
>> If there would happen really a BU fork SPV wallets could get a
>> connection to a majority of BU nodes and so a different view to the network.
>> Any plans or ideas how to deal with that?
>>
>> One idea would be to use a UTXO which is known to exist on only 1 chain
>> request that and use that as a check to see which chain the node is
>> operated on.
>> If it is not the chain the wallet supports the node gets disconnected.
>>
>> Br,
>> Manfred
>>
>> -- 
>> 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
>> <mailto: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: WalletAppKit.useTor() behind corporate proxy

[Andreas Schildbach]

Orchid has been removed from master, as it is unmaintained for years.
It's still in the current stable version (0.14.x), and I think it
doesn't need a proxy as it sets the circuits up itself (in-process).


On 03/30/2017 04:35 PM, Emilio Norrmann wrote:
> I'm trying to setup orchid to use my local proxy, and then to connect
> the wallet via orchid, but this is not working
> 
> |
> System.setProperty("http.proxyHost","10.4.8.21");
> System.setProperty("http.proxyPort","8080");
> System.setProperty("https.proxyHost","10.4.8.21");
> System.setProperty("https.proxyPort","8080");
> 
> BriefLogFormatter.init();
> NetworkParametersparams=MainNetParams.get();
> StringfilePrefix ="test";
> WalletAppKitkit =newWalletAppKit(params,newFile("."),filePrefix);
> kit.useTor();
> kit.startAsync();
> |
> 
> what is the correct way to tell orchid to use my corporate proxy ?
> 
> -- 
> 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 Increase feeperkb in bitcoinJ

[Andreas Schildbach]

What do you mean by "not working"? Can you elaborate?

Is there a reason for not using SendRequest.to() to create your spend?


On 04/13/2017 08:49 AM, Emerald Soft wrote:
> Hi, I am fairly new to android bitcoin development.
> I have been given a task by my client to increase the bitcoin
> transaction fees in his wallet program so that transactions are approved
> quicker.
> he is using bitcoinj api.
> 
> 
> here is the code for send request:-
> 
> public Map sendCoin(String fid,String address,String coin1,String coin2){
> Map rm=new HashMap();
> WalletAppKit appKit=wallets.get(fid);
> if(appKit!=null){
> Coin c1=Coin.parseCoin(coin1);
> Coin c2=Coin.parseCoin(coin2);
> SendRequest req,req1;
> try {
> Transaction tx = new Transaction(createBitcoinNetwork());
> tx.addOutput(c1,Address.fromBase58(createBitcoinNetwork(), address));
> if(!c2.isZero())tx.addOutput(c2,Address.fromBase58(createBitcoinNetwork(),
> jHipsterProperties.getBitcoin().getWallet().getMaster()));
> 
> SendRequest request=SendRequest.forTx(tx);
> request.feePerKb=Coin.valueOf(10);
> 
> 
> appKit.wallet().completeTx(request);
> appKit.peerGroup().broadcastTransaction(request.tx);
> rm.put("code",200);
> rm.put("msg","OK");
> } catch (InsufficientMoneyException e) {
> rm.put("code",400);
> rm.put("msg",e.getMessage());
> 
> }
> }else{
> rm.put("code",500);
> rm.put("msg","Can't send coin");
> }
> return rm;
> }
> 
> 
> 
> 
> 
> I am trying to change fees by adding code highlighted in gree, but its not 
> working...I also tried to increase the DEFAULT_TX_FEE in the Transaction 
> class,
> 
> but that didn't worked either..
> 
> 
> please help
> 
> 
> -- 
> 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: Get Value Associated with TransactionInput?

[Andreas Schildbach]

On 04/15/2017 05:57 AM, Nishil Shah wrote:
> I'm able to get the transaction input address using getFromAddress(). 
> However, when I try to get a value associated with a transaction input, I 
> keep getting null. Anyone know why this is? Is there any other way to get 
> it?

You only can get the input amount if it has a connected output. This is
usually only the case for transactions you created yourself.

This is a limitation of the Bitcoin transaction format. For redundancy
reasons, inputs do not have an amount -- they always spend a whole output.


-- 
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 Increase feeperkb in bitcoinJ

[Andreas Schildbach]

On 04/14/2017 06:23 AM, Emerald Soft wrote:

> This code is written by someone else ( a previous developer of my
> client).. So I don't know exactly hedidn't used SendRequest.to()
> 
> but think it is used because the app has additional fee which is charged
> by the wallet owner 
> 
> I only added the code highlighted in green..
> "by not working".I mean that the feePerKb remain the DEFAULT_TX_FEE of
> 5 mBTC, while I want to make it as 10 mBTC.

SendRequest.feePerKb isn't changed when completing transactions. Have
you looked at the transaction itself? Can you print
request.tx.toString() after completing and post the result here?


-- 
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: Risky transactions

[Andreas Schildbach]

You can set your own implementation of RiskAnalysis.Analyzer using
wallet.setRiskAnalyzer(). Hardcoding the result to OK should do.

(We could even change the .setRiskAnalyzer() method to accept null so
that you can disable any analysis.)


On 04/19/2017 03:48 PM, hererd...@gmail.com wrote:
> The wallet keeps on dropping some transactions, which it considers as
> risky. It breaks our app's logic when this happens.
> 
> Is it possible to not differentiate risky and pending transactions? How?
> 
> Or maybe even disable this risk detection.
> 
> Here is an example below:
> 
> --
> --
> Apr 19, 2017 1:51:43 PM org.bitcoinj.wallet.DefaultRiskAnalysis isStandard
> WARNING: TX considered non-standard due to unknown version number 2
> Apr 19, 2017 1:51:43 PM org.bitcoinj.wallet.Wallet isTransactionRisky
> WARNING: Pending transaction was considered risky: Risky due to
> non-standard tx
> 
> Apr 19, 2017 1:51:43 PM org.bitcoinj.wallet.Wallet receivePending
> WARNING: There are now 1 risk dropped transactions being kept in memory
> 
> 
> 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.
Y

-- 
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: Can not get a Wallet by DeterministicKey if the DeterministicKey is over one depth

[Andreas Schildbach]

On 04/21/2017 11:06 AM, wait.lin.hong...@gmail.com wrote:

> Now my problem is make a Determinister to a wallet. If my Determinister is 
> over one depth, get the exception like on top of what I show.

I think the issue is that if you create a deterministic key from a
mnenonic seed, it's always – by definition – at the root (depth 0). And
bitcoinj cannot deal with other paths than the one defined in BIP32
"default account". The naming of the variable "coinTypePriKey" in your
source fragment leads me to believe you're trying to follow some other
BIP (45? 44?) – that's not supported yet.


-- 
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: Risky transactions

[Andreas Schildbach]

Oh yes you're right. I didn't even know this method exists (-:


On 04/19/2017 04:48 PM, hererd...@gmail.com wrote:
> Thank you for your reply.
> 
> Maybe just using Wallet.setAcceptRiskyTransactions(true) method will do
> the job?
> 
> On Wednesday, April 19, 2017 at 5:03:50 PM UTC+3, Andreas Schildbach wrote:
> 
> You can set your own implementation of RiskAnalysis.Analyzer using
> wallet.setRiskAnalyzer(). Hardcoding the result to OK should do.
> 
> (We could even change the .setRiskAnalyzer() method to accept null so
> that you can disable any analysis.)
> 
> 
> On 04/19/2017 03:48 PM, here...@gmail.com wrote:
> > The wallet keeps on dropping some transactions, which it considers as
> > risky. It breaks our app's logic when this happens.
> >
> > Is it possible to not differentiate risky and pending
> transactions? How?
> >
> > Or maybe even disable this risk detection.
> >
> > Here is an example below:
> >
> > --
> > --
> > Apr 19, 2017 1:51:43 PM org.bitcoinj.wallet.DefaultRiskAnalysis
> isStandard
> > WARNING: TX considered non-standard due to unknown version number 2
> > Apr 19, 2017 1:51:43 PM org.bitcoinj.wallet.Wallet isTransactionRisky
> > WARNING: Pending transaction was considered risky: Risky due to
> > non-standard tx
> >
> > Apr 19, 2017 1:51:43 PM org.bitcoinj.wallet.Wallet receivePending
> > WARNING: There are now 1 risk dropped transactions being kept in
> memory
> >
> 
> 
> 
> >
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
> Y
> 
> -- 
> 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
> <mailto: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: three connections IP from bitcoinj

[Andreas Schildbach]

Hmm, that's certainly not normal. Can you share logs?


On 04/22/2017 06:32 AM, Adam Millerchip wrote:
> Hello.
> 
> I'm observing the incoming connections on a bitcoin node (running Satoshi 
> 0.14.0).
> 
> I've noticed that bitcoinj-based clients open three connections per IP 
> address. Does anybody know why this is?
> 
> Just curious, thanks.
> 
> Adam.
> 


-- 
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: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

Yes, anything that is protected by the POW (aka "commitment"). So a
length header field would do, or a new version number (though version
numbers tend to cause conflicts between branches if they're not
hierarchical).


On 03/21/2017 05:40 PM, Patrick McCorry wrote:
> But that is all it would take for Bitcoinj to have the choice on which
> chain to follow? I can't think of anything else (except which network
> nodes to connect too) that would need to be changed .
> 
> On Tuesday, 21 March 2017 16:35:18 UTC, Andreas Schildbach wrote:
> 
> Afaik no.
> 
> On 03/21/2017 05:20 PM, Patrick McCorry wrote:
> > Are there plans in BU to update the version number of the block
> header
> > and transactions?
> >
> > If so, then that should be able to indicate whether Bitcoinj is
> > following BTC or BTU?
> >
> > Maybe i'm overlooking something?
> >
> > On Tuesday, 21 March 2017 16:14:03 UTC, Matt Corallo wrote:
> >
> > The fork is caused by the hard fork being contentious, and many
> > wishing to stay on the old chain. The EC stuff has nothing to do
> > with the fork, aside from BU generally relaxing consensus rules,
> > making it a HF.
> >
> > On March 21, 2017 9:02:37 AM PDT, Andreas Schildbach
> > <and...@schildbach.de> wrote:
> > >Afaik the currency code isn't part of any protocol, so I don't
> > >understand how BTC vs. BTU can cause a fork. To my
> understanding it is
> > >the (differing) EC that would cause the fork you're fearing. If
> > this is
> > >not the case, can you please clarify what fork you mean?
> > >
> > >
> > >On 03/21/2017 04:22 PM, Matt Corallo wrote:
> > >> Hmm? I'm not referring to EC, but to BTU/BTC - a fork that
> does seem
> > >at least very possible. Because it's am SPV client I'm not
> sure what
> > >else could be done...An upgrade for Bitcoin Wallet for Android
> > could be
> > >pushed out to fetch from a URL that will be updated with the
> fork
> > block
> > >hash, which could be downloaded, validated as >1MB, and then
> the user
> > >could be asked which currency they wish to use.
> > >>
> > >> [Not to derail, but EC as implemented is horribly broken - the
> > sticky
> > >gate stuff the BU devs refused to remove opens the system up
> to all
> > >kinds of attacks. Even they've admitted that the only way it
> works is
> > >if 51% of miners select parameters and everyone else goes
> along with
> > >them, at which point I'm really not sure why not just do
> blocksize
> > >voting on chain, but whatever.]
> > >>
> > >> On March 21, 2017 2:48:08 AM PDT, Andreas Schildbach
> > ><and...@schildbach.de> wrote:
> > >>> Your proposal has the problem that block hashes are not
> known in
> > >>> advance. By the time you (manually?) added the hash to the
> > blacklist
> > >>> most bitcoinj nodes will already have processed that
> block. You
> > >would
> > >>> need to have the blacklist cause re-orgs, too. Here is gets
> > tricky I
> > >>> guess, both for the implementation and for the end-users.
> > >>>
> > >>> Personally I'm not happy about blacklist features in
> general. But
> > >I'd
> > >>> probably still review/merge a block blacklist feature if
> there is
> > >>> considerable demand from developers using bitcoinj.
> > >>>
> > >>> btw. Do you really think an EC fork will happen? Please
> correct me
> > >if
> > >>> I've got the math wrong, but AD6 means you'd have to mine
> 7 blocks
> > >in a
> > >>> row, for which you have to have about 91% of hashpower to
> make it
> > >>> economically feasible (0.91^7=0.51). Yes you can skew that
> number a
> > >bit
> > >>> by accepting losses, but still it feels EC is almost in
> the same
> > >boat
> > >>> as
&g

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

Afaik the currency code isn't part of any protocol, so I don't
understand how BTC vs. BTU can cause a fork. To my understanding it is
the (differing) EC that would cause the fork you're fearing. If this is
not the case, can you please clarify what fork you mean?


On 03/21/2017 04:22 PM, Matt Corallo wrote:
> Hmm? I'm not referring to EC, but to BTU/BTC - a fork that does seem at least 
> very possible. Because it's am SPV client I'm not sure what else could be 
> done...An upgrade for Bitcoin Wallet for Android could be pushed out to fetch 
> from a URL that will be updated with the fork block hash, which could be 
> downloaded, validated as >1MB, and then the user could be asked which 
> currency they wish to use.
> 
> [Not to derail, but EC as implemented is horribly broken - the sticky gate 
> stuff the BU devs refused to remove opens the system up to all kinds of 
> attacks. Even they've admitted that the only way it works is if 51% of miners 
> select parameters and everyone else goes along with them, at which point I'm 
> really not sure why not just do blocksize voting on chain, but whatever.]
> 
> On March 21, 2017 2:48:08 AM PDT, Andreas Schildbach <andr...@schildbach.de> 
> wrote:
>> Your proposal has the problem that block hashes are not known in
>> advance. By the time you (manually?) added the hash to the blacklist
>> most bitcoinj nodes will already have processed that block. You would
>> need to have the blacklist cause re-orgs, too. Here is gets tricky I
>> guess, both for the implementation and for the end-users.
>>
>> Personally I'm not happy about blacklist features in general. But I'd
>> probably still review/merge a block blacklist feature if there is
>> considerable demand from developers using bitcoinj.
>>
>> btw. Do you really think an EC fork will happen? Please correct me if
>> I've got the math wrong, but AD6 means you'd have to mine 7 blocks in a
>> row, for which you have to have about 91% of hashpower to make it
>> economically feasible (0.91^7=0.51). Yes you can skew that number a bit
>> by accepting losses, but still it feels EC is almost in the same boat
>> as
>> SegWit.
>>
>>
>> On 03/21/2017 02:14 AM, Matt Corallo wrote:
>>> Given the animosity (and the exchanges making public comments on it),
>> I don't think it's worth risking users' safety on such a bet. The API
>> should probably at least allow a simple "the block with hash X is
>> invalid, ignore that chain" function. Might want to also have something
>> similar for the Android wallet (or at least notify users that they are
>> likely to end up using BTU and not BTC).
>>>
>>> On March 20, 2017 6:07:46 PM PDT, Andreas Schildbach
>> <andr...@schildbach.de> wrote:
>>>> Forks happen every day. Every time the minority chain dies very
>>>> quickly.
>>>> Why should this be different?
>>>>
>>>> Afaik we'd need block a length commitment to be able to distinguish
>> as
>>>> an SPV/lite wallet. E.g. as a field in the block header.
>>>>
>>>>
>>>> On 03/20/2017 05:04 PM, Manfred Karrer wrote:
>>>>> Exactly. Also there are many people (including me) who will not
>>>> consider
>>>>> the longest PoW chain which follows a different consensus rule as
>> the
>>>>> valid Bitcoin version.
>>>>> Beside that for a project like Bitsquare which is a wallet and
>>>> exchange
>>>>> there are many potential issues and risks (replay attacks).
>>>>> I think BitcoinJ needs a feature to distinguish clearly which chain
>>>> the
>>>>> user is supporting. 
>>>>>
>>>>>
>>>>> Am Montag, 20. März 2017 10:25:49 UTC-5 schrieb Matt Corallo:
>>>>>
>>>>> Given it appears likely there will be two separate currencies,
>> it
>>>>> seems really bad to not have some ability for users to
>>>> differentiate
>>>>> between them. Users will end up highly confused when they do a
>>>>> trade, receive BTU, and deposit it to an exchange only to find
>> no
>>>> BTC.
>>>>>
>>>>>
>>>>> On March 19, 2017 6:42:57 PM PDT, Amitabh Saxena
>>>>> <amita...@gmail.com> wrote:
>>>>>
>>>>> Will bitcoinj reject larger blocks?
>>>>>
>>>>> On Wednesday, March 15, 2017 at 4:38:55 PM UTC+5:30,
>> Andreas
>>>>> Schildbach wrote:
>>>&g

Re: Any plans how to deal with a potential BU fork?

[Andreas Schildbach]

Afaik no.

On 03/21/2017 05:20 PM, Patrick McCorry wrote:
> Are there plans in BU to update the version number of the block header
> and transactions? 
> 
> If so, then that should be able to indicate whether Bitcoinj is
> following BTC or BTU? 
> 
> Maybe i'm overlooking something? 
> 
> On Tuesday, 21 March 2017 16:14:03 UTC, Matt Corallo wrote:
> 
> The fork is caused by the hard fork being contentious, and many
> wishing to stay on the old chain. The EC stuff has nothing to do
> with the fork, aside from BU generally relaxing consensus rules,
> making it a HF.
> 
> On March 21, 2017 9:02:37 AM PDT, Andreas Schildbach
> <and...@schildbach.de> wrote:
> >Afaik the currency code isn't part of any protocol, so I don't
> >understand how BTC vs. BTU can cause a fork. To my understanding it is
> >the (differing) EC that would cause the fork you're fearing. If
> this is
> >not the case, can you please clarify what fork you mean?
> >
> >
> >On 03/21/2017 04:22 PM, Matt Corallo wrote:
> >> Hmm? I'm not referring to EC, but to BTU/BTC - a fork that does seem
> >at least very possible. Because it's am SPV client I'm not sure what
> >else could be done...An upgrade for Bitcoin Wallet for Android
> could be
> >pushed out to fetch from a URL that will be updated with the fork
> block
> >hash, which could be downloaded, validated as >1MB, and then the user
> >could be asked which currency they wish to use.
> >>
> >> [Not to derail, but EC as implemented is horribly broken - the
> sticky
> >gate stuff the BU devs refused to remove opens the system up to all
> >kinds of attacks. Even they've admitted that the only way it works is
> >if 51% of miners select parameters and everyone else goes along with
> >them, at which point I'm really not sure why not just do blocksize
> >voting on chain, but whatever.]
> >>
> >> On March 21, 2017 2:48:08 AM PDT, Andreas Schildbach
> ><and...@schildbach.de> wrote:
> >>> Your proposal has the problem that block hashes are not known in
> >>> advance. By the time you (manually?) added the hash to the
> blacklist
> >>> most bitcoinj nodes will already have processed that block. You
> >would
> >>> need to have the blacklist cause re-orgs, too. Here is gets
> tricky I
> >>> guess, both for the implementation and for the end-users.
> >>>
> >>> Personally I'm not happy about blacklist features in general. But
> >I'd
> >>> probably still review/merge a block blacklist feature if there is
> >>> considerable demand from developers using bitcoinj.
> >>>
> >>> btw. Do you really think an EC fork will happen? Please correct me
> >if
> >>> I've got the math wrong, but AD6 means you'd have to mine 7 blocks
> >in a
> >>> row, for which you have to have about 91% of hashpower to make it
> >>> economically feasible (0.91^7=0.51). Yes you can skew that number a
> >bit
> >>> by accepting losses, but still it feels EC is almost in the same
> >boat
> >>> as
> >>> SegWit.
> >>>
> >>>
> >>> On 03/21/2017 02:14 AM, Matt Corallo wrote:
> >>>> Given the animosity (and the exchanges making public comments on
> >it),
> >>> I don't think it's worth risking users' safety on such a bet. The
> >API
> >>> should probably at least allow a simple "the block with hash X is
> >>> invalid, ignore that chain" function. Might want to also have
> >something
> >>> similar for the Android wallet (or at least notify users that they
> >are
> >>> likely to end up using BTU and not BTC).
> >>>>
> >>>> On March 20, 2017 6:07:46 PM PDT, Andreas Schildbach
> >>> <and...@schildbach.de> wrote:
> >>>>> Forks happen every day. Every time the minority chain dies very
> >>>>> quickly.
> >>>>> Why should this be different?
> >>>>>
> >>>>> Afaik we'd need block a length commitment to be able to
> >distinguish
> >>> as
> >>>>> an SPV/lite wallet. E.g. as a field in the block header.
> >>>>>
> >>>>>
&g

Re: bitcoinj 0.15 release

[Andreas Schildbach]

Good question. When I took over the project last year, I envisioned a
time-based release, similar to Ubuntu. However we're long past the
hypothetical due date (-:

Is there anything that warrants a release? What's your opinion?


On 04/05/2017 07:58 PM, Oscar Guindzberg wrote:
> Hi,
> 
> When bitcoinj 0.15 will be released?
> How release dates are set in general?
> 
> 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.

Re: Web examples and bitcoinj version

[Andreas Schildbach]

Yes, any help with the documentation is much appreciated!


On 08/11/2017 04:10 PM, Jameson Lopp wrote:
> It looks like the bitcoinj documentation site is open source and located
> here: https://github.com/bitcoinj/bitcoinj.github.io
> 
> So if you have updated examples, you should be able to create a pull
> request to fix them in that repository. Thanks!
> 
> On Wed, Aug 9, 2017 at 4:13 AM,  > wrote:
> 
> As I said in my previous message, most of the examples in the
> website do not work. I am learning and working on the examples.
> Since I am already modifying the examples, I could share the
> modifications. So, is there a way that I could provide these
> modifications to update the examples in the website? I think that
> his would be of great help for new learners.
> 
> On Tuesday, August 1, 2017 at 2:44:02 PM UTC+2, vba...@gmail.com
>  wrote:
> 
> Dear all,
> 
> I have recently started to play around with bitcoinj and I
> encountered the problem that the code examples in the website
> (https://bitcoinj.github.io) do not work straight away with
> bitcoinj 0.14.4. There are lots of classes and functions that
> are deprecated and some functions have even disappeared, for
> example when we are told to run peerGroup.startAndWait();.
> 
> Moreover, there are some advises that seemed to be a bit
> outdated, for example, when it is not recommended to use
> connections with Tor or to not use WalletAppKit for professional
> projects. I have seen many examples that  are using
> WalletAppKit, that's why I have the impression that the advise
> in the website is out of date.
> 
> So, my questions are:
> 
> - Are there online examples or a tutorial to learn the basics
> with bitcoinj 0.14.4?
> - Can we use WalletAppKit for real projects or is this class
> still not recommendable?
> 
> Regards,
> 
> V.
> 
> 
> -- 
> 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: Filtering out watched txs

[Andreas Schildbach]

There is currently no way to have bitcoinj filter the list of
transactions, you'll have to do that yourself ATM.

We always envisioned having a second, more usecase-oriented list of
"payments". This would then represent the list shown to the user.
Lightning payments could be visible there too in future (although LN is
a layer on top, so not sure if it's the right thing). So far, work on
this hasn't started.


On 07/08/2017 09:07 AM, Anton wrote:
> After an LN payment channel is open there is a constant need to monitor
> if it's P2WSH output has been spent, I use `addWatchedScripts` for that
> and it works great. The only UX level problem with this approach is when
> P2WSH output does get spent a user will see a strange spending tx which
> changes nothing in wallet, this may confuse many. 
> 
> So what is needed is a way to filter out purely watched transactions
> before displaying a tx list on a UI. Currently I do this as follows:
> https://github.com/btcontract/bitcoinj/commit/8475c850ef7b5d07ae7b30d605362c2dbea8d0d5,
> the code is based on a fact that a purely watched tx does not change
> wallet's balance so it's `getValue` is 0 when watched outputs and inputs
> are excluded so we can use that when deciding if a given tx should be
> displayed.
> 
> This works but I don't like an approach because it feels hacky
> (`getValue` is essentially duplicated in `getExcludeWatchedValue`),
> perhaps there are much better ways to do that?
> 
> Other simple approaches I was thinking of which won't do:
> 
> - Immediately stop watching a P2WSH output script once it is spent so a
> related watched tx won't be shown anymore (won't do because a peer may
> attempt to spend a P2WSH output multiple times using different commit
> txs which will create a race of double spends and there's no telling
> which of them will win, so we need to continue watching a script even
> after the first spend is seen to react accordingly).
> 
> - Just filter out all txs which contain a watched P2WSH output in their
> inputs (won't do since that will filter out mutual closing tx which does
> spend a P2WSH output but is legitimate since it sends money back to
> user's wallet)
> 
> 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.

Re: bitcoinj 0.14.4 : Send coin - get callback in receiveCoin too

[Andreas Schildbach]

What you probably see is the received change from your transaction. You
could try creating a transaction without change and see if there is an
onCoinsReceived event too.

Also, as always, study the logfile.


On 07/10/2017 04:51 PM, Kunal Ransing wrote:
> Hi
> 
> When I send coins I got callback in broadcastComplete as well
> as onCoinsReceived.
> 
> I added receive listner as below:
> 
>   // We want to know when we receive money.
>   kit.wallet().*addCoinsReceivedEventListener*(new
> *WalletCoinsReceivedEventListener*() {
>   @Override
>   public void *onCoinsReceived*(Wallet w, final Transaction
> tx, Coin prevBalance, Coin newBalance) {
>   Coin value = tx.getValueSentToMe(w);
>  
>   updateTxResult(tx, value, tx.getConfidence());
>   
>  
> Futures.addCallback(tx.getConfidence().getDepthFuture(6), new
> FutureCallback() {
>   @Override
>   public void onSuccess(TransactionConfidence result) 
>   {
> //Updated tx status to confirm when depth become
> 6 block
>   updateTxResult(tx, value,result);
>   }
> 
>   });
>   }
>   });
> 
> 
> I am sending coin using below method :
>   ...
>   Address to = Address.fromBase58("send-address");
>   SendRequest req = SendRequest.to(to, Coin.parseCoin("0.003"));
>   req.aesKey = kit.wallet().getKeyCrypter().deriveKey("--my_key--");
>   req.memo = msg;
>   Wallet.SendResult result = kit.wallet().sendCoins(req);
>   Transaction btcTx = result.tx;
>   Futures.addCallback(result.*broadcastComplete*, new
> FutureCallback() {
>   @Override
>   public void *onSuccess*(org.bitcoinj.core.Transaction resTx) 
>   {
>   //Send message to core that Mark tx as completed
>   }
> 
>   @Override
>   public void onFailure(Throwable t) {
> LOGGER.log(Level.INFO,"PayConfig_sendCoin: Something went
> wrong !!!",t);
>   }
>   });
>   ...
> 
> When I sent coin 0.003 BTC to my mobile wallet from my backend app, I
> receive 0.000812 BTC(i.e got call in *onCoinsReceivedfor all sent of
> different coin i receive this same amount*)...also got call
> in *onSuccess*  where fees for sending coin is 0.000188 BTC.
> 
> Please help me to understand this ?
> 
> Regards,
> Kunal
> 
> 
> 
> -- 
> 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: Transaction Fee - getInputSum() / getFee()

[Andreas Schildbach]

It's a limitation of the Bitcoin protocol, inputs do not have value it's
their connected output. In bitcoinj, only the Wallet class connects the
inputs to their outputs; since you probably don't use the Wallet you
likely need to do the connecting yourself.


On 07/06/2017 05:54 PM, Wladimir Filho wrote:
> Hi, I'm developing a block explorer in java using BITCOINJ version 0.14.4. 
> 
> There is a problem that can not be answered on the internet or in the
> forum, I can not access information in the Transaction Input as the fee
> or sum of the inputs. I tried to use the *SPVBlockStore* to
> *MySQLFullPrunedBlockStore* for a complete copy of the blockchain, even
> though the information remains "hidden".
> 
> I need this information to develop services like:
> 
> https://blockchain.info   |   https://live.blockcypher.com   |
>   https://blockexplorer.com/
> 
> Below is part of the application code:
> 
> 
> |
> 
> 
>
> publicstaticMySQLFullPrunedBlockStorecreateStore(NetworkParametersparams,intblockCount)
> 
>throwsBlockStoreException{
> 
>  
>  
> returnnewMySQLFullPrunedBlockStore(params,blockCount,DB_HOSTNAME,DB_NAME,DB_USERNAME,DB_PASSWORD);
> 
> }
> 
> 
> privatestaticNetworkParametersnetworkParameters =TestNet3Params.get();
> 
> 
> publicstaticvoidmain(String[]args)throwsException {
> 
> 
>  MySQLFullPrunedBlockStorechainStore
> =createStore(networkParameters,1000);
> 
>  FullPrunedBlockChainchain
> =newFullPrunedBlockChain(networkParameters,chainStore);
> 
> 
>  PeerGrouppeerGroup =newPeerGroup(networkParameters,chain);
> 
>peerGroup.addPeerDiscovery(newDnsDiscovery(networkParameters));
> 
> 
> 
>  BlockDownloadedManagerblockDM =newBlockDownloadedManager();
> 
> 
>  peerGroup.startAsync();
> 
> peerGroup.addBlocksDownloadedEventListener(blockDM);
> 
> peerGroup.downloadBlockChain();
> 
> blockDEL.wait();
> 
> 
> 
>  peerGroup.stop();   
> 
> }
> 
> 
> 
> publicclassBlockDownloadedManagerimplementsBlocksDownloadedEventListener{
> 
>  
> 
>@Override
> 
>  
>  
> publicvoidonBlocksDownloaded(Peerpeer,Blockblock,FilteredBlockfilteredBlock,intblocksLeft){
> 
>  
> System.out.println("-");
> 
>   System.out.println("hash - "+block.getHashAsString());
> 
>   System.out.println("transactions numer -
> "+block.getTransactions().size()); 
> 
>
> 
>blockDetail(block);
> 
>}
> 
> 
>staticvoidblockDetail(Blockblock){
> 
>  Listtx_list =block.getTransactions();
> 
> 
>   for(Transactiont :tx_list){
> 
> System.out.println("hash - "+t.getHashAsString());
> 
> System.out.println("input sum -"+t.getInputSum());
> 
>System.out.println("output sum -"+t.getOutputSum());
> 
>System.out.println("fee calc -
> "+(t.getInputSum().getValue()>0?t.getInputSum().getValue()-t.getOutputSum().getValue():0));
> 
> System.out.println("fee -"+t.getFee());
> 
> System.out.println("size - "+t.getMessageSize());
> 
>  }
> 
>}
> 
> }
> 
> 
> |
> 
> 
> 
> 
> *LOGS:*
> 
> 
> -
> 
> hash - e95fbedad07b7f95fa56e95ba11ed40f6a9f4b74fa2e0ce128ff6a42
> 
> transactions numer - 1
> 
> hash - d2e1049b895946525eb480070bcf678d94f709d6d621d79415dacb5ce73ac9db
> 
> input sum -0
> 
> output sum -50
> 
> fee calc - 0
> 
> fee -null
> 
> size - 96
> 
> -
> 
> hash - 409087525f6977c2634e636509e20bc61bc1c6e86eb6d17a394d7a7a
> 
> transactions numer - 2
> 
> hash - 1b93146ca6ec328b8f9e976fd49cd8dd4b74f2c1277807c75e941991948701bb
> 
> input sum -0
> 
> output sum -50
> 
> fee calc - 0
> 
> fee -null
> 
> size - 96
> 
> hash - e2e5b1e29596105817b74f50cfde585baeeddb6125f9e03e8a22858def9293f2
> 
> input sum -0
> 
> output sum -49
> 
> fee calc - 0
> 
> fee -null
> 
> size - 192
> 
> -
> 
> hash - d986f90a094b707e9ef4bf412d9a2a14df872e9409ddca7e0865bde6
> 
> transactions numer - 2
> 
> hash - 5ccf7e3494f5f05398b04f6bb3a72b635b2de6c494572c3e2078c8d89532abb3
> 
> input sum -0
> 
> output sum -55
> 
> fee calc - 0
> 
> fee -null
> 
> size - 96
> 
> hash - 23cc5dadd87f91c1fdce9c0ad090ce8f6e7fd7f79834ad1e579cd5a952c7c6b1
> 
> input sum -0
> 
> output sum -4904431364
> 
> fee calc - 0
> 
> fee -null
> 
> size - 373
> 
> -
> 
> hash - 4480dd8aa5a351cb8d66fb332496f4d54c97fb87584322ab05342144
> 
> transactions numer - 1
> 
> hash - 848771ee8e27418ec8af0c08ecfa61d6af230dfd6ab25809f5792565b4f57b85
> 
> input sum -0
> 
> output sum -50
> 
> fee calc - 0
> 
> fee -null
> 
> 

Re: Dealing with Balances

[Andreas Schildbach]

Your next step is to see if the chain is fully synched. In your wallet
dump, there is the line

> Last seen best block: 46367 (2013-01-02T05:58:10Z)

which implies it doesn't synch. Or maybe it synches, but is just very
slow. Read the logs.


On 07/12/2017 01:23 PM, santiago del valle wrote:
> I dont really what to do, seems that this is probably simple to solve
> but Im really stuck in this.
> Watching the Log I see in each Tx Hash this:
> [ STARTING] INFO org.bitcoinj.wallet.Wallet - New broadcaster so
> uploading waiting tx
> 6009856d8aea2b0161730783e6ab0c0ce6a6ab24e35375835050d2bb031fa65b
> [ STARTING] INFO org.bitcoinj.core.TransactionBroadcast - Waiting for 10
> peers required for broadcast, we have 0 ...
> 
> El miércoles, 12 de julio de 2017, 21:02:59 (UTC+10), Andreas Schildbach
> escribió:
> 
> According to https://testnet.blockexplorer.com
> <https://testnet.blockexplorer.com>, your transactions are
> confirmed. But in your wallet dump, they're still pending. Try synching
> the chain again. If the problem persists, the synch doesn't work. In
> this case carefully study the logfile.
> 
> 
> On 07/12/2017 12:38 PM, santiago del valle wrote:
> > I have a DownloadListener attached to the WalletAppKit, it gets fired
> > everytime a block is downloaded
> >
> >
> > Wallet containing 0.006 BTC (spendable: 0.00 BTC) in:
> >  
>  
> >6 pending transactions
> >  
>  
> >0 unspent transactions
> >  
>  
> >0 spent transactions
> >  
>  
> >0 dead transactions
> >  
>  
> >  Last seen best block: 46367 (2013-01-02T05:58:10Z):
> > 037835a92404acb2f18768a49d4f93685ead30aad6bb3b073f411e02
> >  
>
> >  
>  
> >  Keys:
> >  
>  
> >  Earliest creation time: 2017-07-10T14:10:29Z
> >  
>  
> >addr:mrXUTn2Ppe7iWszweQKCSnBPVocM75WorV
> >  hash160:78c290f8f0faf24e7cbd2bc96ba7cecd210e1273
> >  creationTimeSeconds:1499695830
> >  
>  
> >  Seed birthday: 1499695829  [2017-07-10T14:10:29Z]
> >  
>  
> >  Key to watch:
> >
>  
> tpubD8TWDx4Wgnoq6fCKBL8qfwmpNUPjDo8peuV4i7p2djLshkmUkALxDSuti8yJiF5dACwQQgpMySiqCj463LLte5FgMiYyS1G5jus7bSku7nX
> 
> >  
>  
> >addr:mvw9ExaSTDhHwW9dQ5CHgkcLaVrQC5BBJM
> >  hash160:a91d01f43b8c10ba9cb05fa07fe0b17d0a6d680e  (M/0H/0/0)
> >  
>  
> >addr:mscDf4bmhE1DUfKjXtdCyfivJaduQJfaov
> >  hash160:84a069b72a0ba737d1d46020845726a40db171dd  (M/0H/0/1)
> >  
>
> >  
>
> >  
>  
> >  >>> PENDING:
> >  
>  
> >  0.001 BTC total value (sends 0.00 BTC and receives 0.001 BTC)
> >  
>  
> >confidence: Seen by 4 peers (most recently: 2017-07-10T19:42:32Z).
> > Pending/unconfirmed. Source: NETWORK
> >  
>  
> >a6225bb48c7bb1ff8bc2ac2a2f45f5f65d085b3f640551f54130be8ae857ac91
> >  
>  
> >updated: 2017-07-10T19:42:33Z
> >  
>  
> >   in  
> >
> 

Re: Fee Calculation

[Andreas Schildbach]

Use Wallet.completeTx() to complete the transaction. Then you can query
for the fee as you noted.


On 07/20/2017 11:58 AM, santiago del valle wrote:
> Hi All.
> Is there away to calculate Fee just before broadcast the Transaction?
>  What I tried is:
> 
> SendRequest request = SendRequest.to(Address.fromBase58(parameters, 
> recipientAddress), Coin.parseCoin(amount));
> 
> return request.tx.getFee().toPlainString();
> 
> 
> /But, seems that the sum of inputs is Zero, so it shows me that the fee
> is the amount to send./
> 
> /
> /
> 
> /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.

Re: Bitcoin Cash

[Andreas Schildbach]

As far as I can tell, Bitcoin Cash blocks won't be accepted by bitcoinj
– regardless if validating or not – because Bitcoin Cash changes the
difficulty (in order to survive with much less hashing power than
Bitcoin has). This will fail the PoW-check.

Regarding pending transactions I'm not so sure. I heard they changed the
signing as well, probably in an incompatible way. In this case, it
should be detectable by bitcoinj. If anyone could create and post a
BCC-signed transaction in serialized form, we could add a unit test for
this.


On 07/26/2017 12:17 PM, saulius.beinor...@gmail.com wrote:
> As you may know, Bitcoin Cash is going to release(split?) on August 1st.
> They seem to have added a fork id, similar to segwit (if I understand
> correctly).
> I am assuming that bitcoinj will not be supporting their network, but I
> wanted to check that there is no chance that a Bitcoin Cash transaction
> lands in the wallet.
> Can anyone confirm this?
> 
> -- 
> 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: Security: How to properly destroy a Wallet/ECKey?

[Andreas Schildbach]

Some discussion about this has been going on at
https://github.com/bitcoinj/bitcoinj/pull/1411.

-- 
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 and Lightning network

[Andreas Schildbach]

That's great news, and many thanks for your demonstration!

I'm pretty confident that if segwit activates, sooner or later bitcoinj
will by default create wallets with segwit addresses/outputs only. Old
wallets will either be migrated (to be decided: on demand, or forcibly),
or old wallets will simply not be able to use the lightning network
(unless you're willing to implement your option 1 just for that case).

We have to decide on an extension to the BIP32 wallet layout though;
guess I'll start a thread about that soon.

tl;dr: I'm in favor of option 2.


I'm interested in how people on this mailing list think about the Scala
language choice you've taken for your work.


On 06/29/2017 10:51 AM, Anton wrote:
> Hi everyone,
> 
> currently I work on a Lightning network implementation which is intended
> to be used on lite clients such as mobile phones, a repo can be found
> here: https://github.com/btcontract/lnwallet and also recently I've made
> a demo if anyone is interested: https://www.youtube.com/watch?v=yNFfUfyL2xE
> 
> My goals are:  
> 
> - build a core Lightning library which is not tied to any specific
> wallet or platform and can be reused, related code can be found here:
> https://github.com/btcontract/lnwallet/tree/master/app/src/main/java/com/lightning/wallet/ln,
> it's a work in progress and a modification of
> https://github.com/ACINQ/eclair project where I basically dumb things
> down (by not using an Akka actor framework which may be too heavy for
> phones, not assuming a locally accessible Core node API is available,
> not relaying third party payments for now and so on). It's coming along
> nicely and I'm confident it will reach a production ready state sooner
> rather than later.
> 
> - build an end-user mobile Bitcoin/Lightning wallet on top of an
> aforementioned Lightning library (for Lightning part) and bitcoinj (for
> Bitcoin part). This seems like a very convinient and natural solution
> since users will be able to at once fund Lightning payment channels
> right from their Bitcoin wallet and also fall back to Bitcoin payments
> if Lightning is not available for some reason. And this is where some
> bitcoinj-specific help is really needed.
> 
> Two things are required for bitcoinj to power a mobile Lightning wallet:
> segwit support and ability to create segwit outputs.
> Thanks to Jean-Pierre Rupp's work at
> https://github.com/bitcoinj/bitcoinj/pull/1334 segwit support is already
> here, I use his segwit-enabled modification to create a P2WSH output (as
> required by Lightning funding transaction for a payment channel) and it
> does work great, as can be seen on a demo video.
> 
> Sadly, this alone is not enough as not only a funding tx should have a
> P2WSH output but also all of it's inputs must come from segwit outputs.
> This is a problem because currently bitcoinj uses base58 addresses which
> produce non-segwit outputs. A funding tx can be created using such
> non-segwit outputs but it can be malleated so payment channel can't be
> established in a trustless manner, basically it's a show stopper.
> 
> The way I see it, there are two options of getting over this, one
> requires no big changes to bitcoinj beyond what is already done but is
> quite horrible from UX point of view, the other one requires some deep
> changes in bitcoinj:
> 
> Option 1: instead of creating a funding tx directly, we create an
> intermediary non-segwit -> P2WPKH tx, then we use it to P2WPKH -> P2WSH
> (payment channel output). Pros are: no changes to bitcoinj. Cons are:
> doubled fees, doubled confirmation waiting time, implementation
> complexities (sending two txs is not atomic, things can happen in the
> middle).
> 
> Option 2: add bech32 support to bitcoinj and change it to generate
> bech32 addresses instead of base58 addresses in order to get native
> segwit outputs. Pros are: Lightning support out of the box, fee
> discounts for native segwit txs. Cons are: probably a lot of work and
> testing, a breaking change (?) which perhaps should live in a separate
> branch, probably something else I haven't thought of.
> 
> Despite implementation complexities associated with the sencond option I
> really like it much more since the first one essentially makes users
> handle those complexities and I'm not sure they would want to do that,
> plus sooner or later bech32 support and address generation will have to
> be done anyway. I'm not sure if I can handle all this myself since my
> knowledge of bitcoinj if fairly limited and I spend most of my free time
> working on Lightning but I'm definitely ready to help with programming
> work, especially if the whole process could be split into more or less
> clear tasks. 
> 
> Please let me know what you think of all this.
> 
> -- 
> 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
> 

Re: Issue with transaction on load balanced bitcoin back-end servers

[Andreas Schildbach]

What kind of balance are you querying for? Also, when querying server 2,
was the transaction already propagated from server 1 to server 2 (as
pending transaction)?

In general, I'm not sure if the Bitcoin network protocol is suitable for
synchronizing load-balanced servers. It might be much easier to
introduce server affinity to your load balancing logic.


On 06/29/2017 01:32 PM, Ajit Soman wrote:
> We have setup two same bitcoin back-end server for load balancing
> purpose. We are facing an issue on transaction. Consider that a user X
> is going to perform a bitcoin transaction. user X is able to perform
> transaction successfully using SERVER 1 . When  user X calls get our
> balance API he gets actual balance from SERVER 1 after that he calls the
> balance API one more time this time load balancer redirect request to
> SERVER 2, he get his previous balance before transaction. After 1
> confirmation user X is able to see actual balance.
> 
> Can anybody suggest how to deal with this issue?  
> 
> -- 
> 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: ECDSA compact signature

[Andreas Schildbach]

ECDSA signatures are expected to be different, because of the
semi-random k-factor. Have you cross-checked your sigs for validity, so
a sig produced with Intels library checked by bitcoinj and the other way
round?


On 06/29/2017 02:03 AM, Ghadi Shayban wrote:
> Thank you for the bitcoinj library, it's great!
> 
> I have been trying to mimic some stuff from Intel Sawtooth (another
> blockchain) in Java...I can successfully
> get the public/private EC keys to be byte-for-byte identical with their
> library, but I am
> struggling to produce an ECDSA signature that is identical to theirs
> when using the bitcoinj library.
> 
> Their message signatures are 64 bytes hex encoded (so 128 bytes total),
> and it looks like the 64 bytes are 32 bytes R field then 32 bytes S
> field.  Can anyone help me *generate a "compact signature*"? (If that is
> what this is...)
> 
> Here is an example of theirs (python):
> 
 privatekey
> '5K9gBxYNbtygky5sntvXqaMLj36q4W9ibkPG1WzquBSvXpyyjo8'
 sawtooth_signing.sign('asdf', privatekey)
> '0168026d34d6c65fd2002debec84cde2a2f90ee8c7329e28a2f5055861abb2757e0b8d1b1308c3d5f6741843e8244032617767495a52b2db26938777ae68bd02'
> # 64 bytes hex
> 
> *Using bitcoinj* the w/ same private key to sign the same exact message:
> (sign pk "asdf")
> =>
> "eecc7b60410b2a33a3c31482c0db80f56827923c7bd116805a9f29ebe93caa4d4076efab21a763eb13054dd155d888977ed804a1269f1ba001533576a5484a96"
> # 64 bytes hex
> 
> The broken code I'm using (clojure)
> 
> (defn sign
>   [^ECKey pk data]
>   (let [h (Sha256Hash/twiceOf data)
> sig (.sign pk h nil)
> arr (byte-array 64)]
> (System/arraycopy (Utils/bigIntegerToBytes (.-r sig) 32) 0 arr 0 32)
> (System/arraycopy (Utils/bigIntegerToBytes (.-s sig) 32) 0 arr 32 32)
> (.encode Utils/HEX arr))
> 
> Intel's documentation on transaction signing for reference
> https://intelledger.github.io/_autogen/txn_submit_tutorial.html#sign-the-header
> 
> -- 
> 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: Bitcoinj support for SegWit / NYA?

[Andreas Schildbach]

I guess if the receiving wallet supports segwit, then P2SH would be used
which is backwards compatible. This would mean that the sending wallet
(bitcoinj-based) would receive some discount.


On 06/28/2017 03:38 AM, Miles Suter wrote:
> So if the NYA goes through, applications running bitcoinj will not be
> able to take advantage of the 75% discount provided by Segwit transactions?
> 
> On Tuesday, June 27, 2017 at 10:25:43 AM UTC-7, Andreas Schildbach wrote:
> 
> The list entry is correct -- it's still wip. Plus, neither nya nor
> segwit should change anything for the existing users if the forks go
> well (in the sense that they don't split the network).
> 
> 
> On 06/27/2017 04:46 AM, 'Miles Suter' via bitcoinj wrote:
> > Hi Andreas - is bitcoinj fully prepared for Segwit? It seems unclear
> > from this list <https://bitcoincore.org/en/segwit_adoption/
> <https://bitcoincore.org/en/segwit_adoption/>>:
> >
> >
> >
> 
> <https://lh3.googleusercontent.com/-IH8yvbBWF6s/WVHFv1o0dJI/AA0/a-1qVwDnGacRDOnisw7thMieX6PTscWtQCLcBGAs/s1600/Screen%2BShot%2B2017-06-26%2Bat%2B7.40.16%2BPM.png
> 
> <https://lh3.googleusercontent.com/-IH8yvbBWF6s/WVHFv1o0dJI/AA0/a-1qVwDnGacRDOnisw7thMieX6PTscWtQCLcBGAs/s1600/Screen%2BShot%2B2017-06-26%2Bat%2B7.40.16%2BPM.png>>
> 
> >
> >
> > Is it still a work in progress? Do users of bitcoinj have to do
> anything
> > to be prepared? Your guidance would be much appreciated.
> >
> >
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Bitcoinj support for SegWit / NYA?

[Andreas Schildbach]

The list entry is correct -- it's still wip. Plus, neither nya nor
segwit should change anything for the existing users if the forks go
well (in the sense that they don't split the network).


On 06/27/2017 04:46 AM, 'Miles Suter' via bitcoinj wrote:
> Hi Andreas - is bitcoinj fully prepared for Segwit? It seems unclear
> from this list :
> 
> 
> 
> 
> 
> Is it still a work in progress? Do users of bitcoinj have to do anything
> to be prepared? Your guidance would be much appreciated.
> 
> 
> 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.

Re: Bitcoinj support for SegWit / NYA?

[Andreas Schildbach]

On 07/05/2017 07:31 PM, Kay PEY wrote:

> Is this still an open question?
> "Is it reasonable to believe that by the time SegWit goes live that 
> bitcoinj will support it?"

Yes, sure. This is a project run by volunteers. And also nobody knows
when SegWit will lock in. Anyway, there are no guarantees.

-- 
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: 2 instances of bitcoinj in the same JVM

[Andreas Schildbach]

On 04/24/2017 05:04 PM, Oscar Guindzberg wrote:

> I am planning to run 2 instances of bitcoinj in the same JVM.
> What things should I check in order to avoid doing a mess?
> 
> In fact, I will have:
> - 1 normal instance of bitcoinj
> - 1 "kind of" instance with just: Context +  Blockchain + my own
> blockstore + UTXO based wallet. No network connection. No listeners.
> No need for multithreading. I am creating a reduced version of
> bitcoinj just for this, removing all the classes and methods I don't
> need. Packages will be renamed.

Are you planning to use the reduced version plus the regular version at
the same time?

Probably the biggest mess is the Contexts and the threads. You need to
make sure threads stay 100% separated.

Ultimately I think this scenario has never been tested, so you'll likely
run into unexpected problems.

-- 
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: Clarification on DNS Lookup and PeerGroup Discovery

[Andreas Schildbach]

Other than the port number, there is no constant that you could use for
a firewall rule. And even the port number can be changed by peers, even
if that is very rare currently.

You could put your own full node outside of the firewall and then
connect to that node exclusively. In such a setup, you could use the IP
of your full node for the firewall rule.

SPV nodes do not relay blocks and transactions.


On 04/26/2017 05:14 PM, Ramez Az wrote:
> Thanks for your clarification.
> 
> For running full node, what are the steps i need to follow and Is there
> any reliable full node is available in the internet so that i can open
> my firewall to that fullnode and can connect. If i need to run as full
> node, what configuration(S/W and H/W) i should have.
> 
> The another thing i wanted to check is that Is the SPV node capable of
> propagate to other nodes. So that i can use the below approach.
> 
> The Machine(Within Firewall) -> SPV Node(Outside the firewall and
> connected with bitcoin network).
> 
> Thanks,
> Ramesh A
> 
> On Friday, April 21, 2017 at 1:53:46 PM UTC+5:30, Andreas Schildbach wrote:
> 
> Since Bitcoin is decentralized, peers can come and go without notice.
> The DNS queries are purposefully designed to return a different set of
> peers for each query. So yes this also applies to Mainnet.
> 
> The Bitcoin P2P network cannot work unless you allow full access to
> port
> 8333 (port 18333 for testnet).
> 
> To work around that limitation, we suggest you to run your own full
> node
> and connect to it exclusively (using the Peer API). However, that full
> node would need to sit outside your fireware or otherwise it could not
> connect to the P2P network either.
> 
> 
> On 04/21/2017 05:19 AM, Ramez Az wrote:
> > Hi,
> >
> > I am developing small client application for posting the txns and
> > receiving the txns. I have firewall in my network and i am able to
> allow
> > only some Peers to connect in the network. The list of peers(IP
> > addresses) are getting changed every DNS lookup at
> > testnet-seed.bitcoin.petertodd.org
> <http://testnet-seed.bitcoin.petertodd.org> domain. Can you please
> provide some
> > list of Peers through which we should be able to do connect at any
> time.
> > Is there any other domain where we can get some consistent Peers
> or any
> > alternatives?. If you provide some of consistent peers, i can open my
> > firewall for those nodes.
> >
> > I am facing this issue in Testnet, Is this the same case for
> mainnet as
> > well or can we get consistent Peers in MainNet.
> >
> > As this is bit urgent, Can any one clarify as soon as possible.
> >
> > Thanks in Advance.
> >
> > Thanks,
> > Ramesh A
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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 is partially resetting of transaction download supposed to work?

[Andreas Schildbach]

On 04/27/2017 11:09 PM, Leo Wandersleb wrote:

> So, if I have a wallet with birthday 100 and at time 200 want to add an
> address with date 198, I have to load all back from 100?

Yes.

> Now if I add an
> address with date 90, does the wallet update its "birthday" accordingly
> or do I have to also do something beyond the individual address creation
> dates?

The wallet calculates its birthdate automatically. Actually the wallet
birthdate isn't a persistent value but simply the minimum of all key and
seed birthdates in that wallet.

> How hard do you think it would be to improve bitcoinJ in that respect?

I'd say it's doable, but not trivial. Probably safest way to do this is
roll back (remove from wallet) transactions in the order latest to
oldest. At the same time, the block store would need to be rewound up to
the point where it is empty (it's a ring buffer).

> Do you see interest with others to implement something like that?

Good question. Replaying the chain (even parts of) should be rare. The
problem with removing transactions is also we loose all metadata (data
that doesn't come from the blockchain).

@all: What do others think about this one in particular?

> Do you see interest to merge it, if I implemented it with tests and all?

Yes, I think it would be useful.


-- 
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: three connections IP from bitcoinj

[Andreas Schildbach]

I see a lot of "double connections" by non-bitcoinj peers in your logs
too. So I assume this is/was a local problem.


On 04/23/2017 04:27 AM, Adam Millerchip wrote:
> It's not happening anymore - maybe it was a local issue.
> 
> Here is an excerpt from the log at the time it was happening. It doesn't
> contain the remote IP unfortunately, so it's not very useful. I notice
> that "us" is 127.0.0.1 for the duplicate connections, so maybe it's
> related to the local peer database?
> 
> On 23 April 2017 at 03:01, Andreas Schildbach <andr...@schildbach.de
> <mailto:andr...@schildbach.de>> wrote:
> 
> Hmm, that's certainly not normal. Can you share logs?
> 
> 
> On 04/22/2017 06:32 AM, Adam Millerchip wrote:
> > Hello.
> >
> > I'm observing the incoming connections on a bitcoin node (running
> Satoshi
> > 0.14.0).
> >
> > I've noticed that bitcoinj-based clients open three connections per IP
> > address. Does anybody know why this is?
> >
> > Just curious, thanks.
> >
> > Adam.
> >
> 
> 
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "bitcoinj" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoinj/CrzQHQEudWU/unsubscribe
> <https://groups.google.com/d/topic/bitcoinj/CrzQHQEudWU/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> bitcoinj+unsubscr...@googlegroups.com
> <mailto:bitcoinj%2bunsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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 is partially resetting of transaction download supposed to work?

[Andreas Schildbach]

Partial reset has never been implemented. Currently you always need to
sync from the wallet birthdate.


On 04/26/2017 10:32 PM, Leo Wandersleb wrote:
> Hi,
> 
> occasionally my app needs to add addresses with past, non-zero creation
> times.
> 
> I figured, iterating through the block headers until creation-time - 4h
> and feeding that block height to |public void clearTransactions(int
> fromHeight)| should trigger the resync but throws an error
> 
> in a way that I would at least expect a comment or TODO on that line.
> Is there another way to achieve what I want to achieve?
> 
> Regards,
> 
> Leo Wandersleb
> 
> -- 
> 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: Importing seed to any other wallet.

[Andreas Schildbach]

Try m/0'.


On 08/22/2017 10:21 PM, Frode Halvorsen wrote:
> When I try to import the wallet via the 12 generated seed-words, I'm
> asked about the Derivation-path.  I've tried a few, but I still havent
> succeded importing to a wallet where I can spend the balance.
> Some suggestions from wallet is :"m/44'/0'/0'"
> 
> Does anyone know what the correct value should be ?
> 
> I have succesfully imported the watch-key, so I can see all transactions
> and addresses, but this doesn't help me...
> 
> -- 
> 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: Importing seed to any other wallet.

[Andreas Schildbach]

You can't currently adjust the derivation path in bitcoinj. It is
hardcoded to the BIP32 spec default account.


On 08/22/2017 11:02 PM, Frode Halvorsen wrote:
> That worked :)
> 
> Next Q is then - If I want to import to BitcoinJ from another wallet
> that did used the suggested string. How can I specify this string during
> the wallet-restorefromseed ?
> Like this :
> DeterministicSeed seed = new DeterministicSeed(seedCode, null, "",
> creationtime);
> Wallet restoredWallet = Wallet.fromSeed(params, seed);
> 
> 
> ?  Like if I want to import a wallet created on blockchain.info...
> 
> 
> tirsdag 22. august 2017 22.30.57 UTC+2 skrev Andreas Schildbach følgende:
> 
> Try m/0'.
> 
> 
> On 08/22/2017 10:21 PM, Frode Halvorsen wrote:
> > When I try to import the wallet via the 12 generated seed-words, I'm
> > asked about the Derivation-path.  I've tried a few, but I still
> havent
> > succeded importing to a wallet where I can spend the balance.
> > Some suggestions from wallet is :"m/44'/0'/0'"
> >
> > Does anyone know what the correct value should be ?
> >
> > I have succesfully imported the watch-key, so I can see all
> transactions
> > and addresses, but this doesn't help me...
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Use extended xpub to initialize wallet

[Andreas Schildbach]

Yes, you can create a watching wallet from an xpub. See

Wallet.fromWatchingKeyB58()


On 05/15/2017 12:59 AM, Dexter wrote:
> Is it possible to use extended xpub from electrum and initiate the
> wallet so that it generates the same receive address as electrum.
> 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.

Re: Is there some way to confirm/sync tx confidence which built from your partner?

[Andreas Schildbach]

Confidence is basically something that you build yourself. When
receiving a transaction directly (e.g. via Bluetooth) confidence should
depend a lot on the existing relationship to the partner, since a
pending transaction alone doesn't guarantee much.

The default implementation builds confidence by receiving the
transaction from other peers it has randomly connected to, and of course
by receiving it via the blockchain.


On 05/13/2017 10:29 PM, vivid wang wrote:
> Suppose your partner build a valid tx and send it to you
> by tx.bitcoinSerialize() as soon as he broadcasts it, is there any
> method to sync the tx confidence only by your wallet and the
> deserialized tx?
> I have tried to add confidence listener, use wallet.commitTx(), or
> bitcoin.peerGroup.broadcast(tx) ,but these totally doesn't work.
> Listeners doesn't get any feedback,  and it's wired to find
> peerGroup.broadcast(tx)  stuck to "the TX has witnessed by 0 peers".
> I have searched the former posts ,and found Mike has said
> that" Confidence won't change unless the wallet contains transactions
> and keys *before* syncing the block chain."
> Does that mean the wallet has no means to listen or trace any tx even
> it's still pending and hasn't been included to any block as long as the
> tx has no connections with the wallet?
> Then how to deal with the circumstances that trust consensus
>  application relies?
> It's very important to me and I'd appreciated it if someone would help
> 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.

Re: How to build with Maven on Mac Os

[Andreas Schildbach]

The INFO message about secp256k1 is harmless, it will simply use the
Java implementation.

Your problem are the failing tests. While it is very important to look
for the reason of the "java.security.InvalidKeyException: Illegal key
size or default parameters" exceptions you're experiencing, for now you
could just skip the tests using -DskipTests.


On 05/08/2017 12:44 PM, 'Stefan Gillessen' via bitcoinj wrote:
> 
> I am on OS X 10.11.6, JDK java version "1.8.0_131"
> 
> The description on the webpage for installing bitcoinj unfortunately
> failed for me, see below.
> 
> Probably the issue is INFO: java.lang.UnsatisfiedLinkError: no secp256k1
> in java.library.path, and the error further down are a consequence of that?
> 
> Trying to fix that, I downloaded git clone
> https://github.com/bitcoin-core/secp256k1, but the autogen.sh failed:
> 
> Can't exec "/opt/local/bin/aclocal": No such file or directory at
> /opt/local/share/autoconf/Autom4te/FileUtils.pm line 326.
> autoreconf: failed to run /opt/local/bin/aclocal: No such file or directory
> 
> Anyone has some hint how to compile bitcoinj ?
> 
> Thanks!
> 
> ---
> objc[47319]: Class JavaLaunchHelper is implemented in both
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/bin/java
> and
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/libinstrument.dylib.
> One of the two will be used. Which one is undefined.
> Running org.bitcoinj.core.AddressTest
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.591
> sec - in org.bitcoinj.core.AddressTest
> Running org.bitcoinj.core.AlertMessageTest
> May 08, 2017 12:38:08 PM org.bitcoin.Secp256k1Context 
> INFO: java.lang.UnsatisfiedLinkError: no secp256k1 in java.library.path
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.077
> sec - in org.bitcoinj.core.AlertMessageTest
> Running org.bitcoinj.core.Base58Test
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046
> sec - in org.bitcoinj.core.Base58Test
> Running org.bitcoinj.core.BitcoinSerializerTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
> sec - in org.bitcoinj.core.BitcoinSerializerTest
> Running org.bitcoinj.core.BlockChainTest
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.021
> sec - in org.bitcoinj.core.BlockChainTest
> Running org.bitcoinj.core.BlockTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.205
> sec - in org.bitcoinj.core.BlockTest
> Running org.bitcoinj.core.BloomFilterTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006
> sec - in org.bitcoinj.core.BloomFilterTest
> Running org.bitcoinj.core.ChainSplitTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.738
> sec - in org.bitcoinj.core.ChainSplitTest
> Running org.bitcoinj.core.CoinTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007
> sec - in org.bitcoinj.core.CoinTest
> Running org.bitcoinj.core.DumpedPrivateKeyTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
> sec - in org.bitcoinj.core.DumpedPrivateKeyTest
> Running org.bitcoinj.core.ECKeyTest
> Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.622
> sec - in org.bitcoinj.core.ECKeyTest
> Running org.bitcoinj.core.H2FullPrunedBlockChainTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.665
> sec - in org.bitcoinj.core.H2FullPrunedBlockChainTest
> Running org.bitcoinj.core.LevelDBFullPrunedBlockChainTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.226
> sec - in org.bitcoinj.core.LevelDBFullPrunedBlockChainTest
> Running org.bitcoinj.core.MemoryFullPrunedBlockChainTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.092
> sec - in org.bitcoinj.core.MemoryFullPrunedBlockChainTest
> Running org.bitcoinj.core.MessageTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002
> sec - in org.bitcoinj.core.MessageTest
> Running org.bitcoinj.core.MySQLFullPrunedBlockChainTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.002
> sec - in org.bitcoinj.core.MySQLFullPrunedBlockChainTest
> Running org.bitcoinj.core.ParseByteCacheTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.216
> sec - in org.bitcoinj.core.ParseByteCacheTest
> Running org.bitcoinj.core.PeerAddressTest
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
> in org.bitcoinj.core.PeerAddressTest
> Running org.bitcoinj.core.PeerGroupTest
> Tests run: 42, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4.408
> sec - in org.bitcoinj.core.PeerGroupTest
> Running org.bitcoinj.core.PeerTest
> Tests run: 96, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.077
> sec - in org.bitcoinj.core.PeerTest
> Running org.bitcoinj.core.PostgresFullPrunedBlockChainTest
> Tests run: 1, Failures: 0, Errors: 0, 

Re: Wallet Balance become 0 BTC After Transaction and Actual balance reflect after more than 1 confirm

[Andreas Schildbach]

Yes, using ESTIMATED_SPENDABLE your balance should behave more like you
expect. Just beware that you can only spend confirmed coins (as long as
you're using the default CoinSelector).


On 05/12/2017 06:53 PM, Ajit Soman wrote:
> Hi Oscar,
> 
> I am using this: wallet.getBalance(BalanceType.AVAILABLE_SPENDABLE) to
> get balance.
> 
> I am facing this issue in 1 out of 10 transactions . i did a transaction
> right now it works fine. i am unable to figure out what is the issue. 
> 
> On Friday, May 12, 2017 at 6:32:50 PM UTC+5:30, Oscar Guindzberg wrote:
> 
> Hi,
> 
> wallet.getBalance() returns the confirmed balance
> You can use
> wallet.getBalance(Wallet.BalanceType.ESTIMATED)
> to get the unconfirmed balance.
> 
> Oscar
> 
> On Thu, May 11, 2017 at 2:04 PM, Ajit Soman  wrote:
> > Hi ,
> >
> > Initially my wallet has 2 BTC . I did a transaction of 1 BTC to a
> wallet
> > address . Transaction was successful i got a transaction hash now
> when i
> > check my wallet balance it shows 0 BTC . After getting more than 1
> > confirmation i got my actual wallet balance i.e 1 BTC. Here is my
> > bitcoinTransaction code:
> >
> > public String createTransaction(TransactionParams
> transactionparams) throws
> > Exception { // TransactionParams is a entity
> > String transactionHash = null;
> > Wallet wallet = null;
> >
> > Address receiverAddress;
> > Context.propagate(new Context(netparams.getNetworkParameters())); //
> > netparams is a util through which we are getting testnet3 or mainnet
> > depending upon environment
> > receiverAddress = new Address(netparams.getNetworkParameters(),
> > transactionparams.getReceiverAddress());
> > String amount =
> > String.valueOf(transactionparams.getTransactionTradeAmount());
> > System.out.println("Address " +
> transactionparams.getReceiverAddress());
> >
> > final File walletFile = new File(configuration.getWalletLocation()
> + "/" +
> > transactionparams.getWalletId() + ".dat");
> > wallet = (Wallet)
> >
> walletStoreService.getWalletMap().get(transactionparams.getWalletId());
> //
> > walletStoreService that has information about wallet object
> >
> > if (walletFile.exists()) {
> > Coin btcCoin = Coin.parseCoin(amount);
> > Wallet.SendRequest.DEFAULT_FEE_PER_KB = Coin.ZERO;
> >
> > SendRequest request = SendRequest.to(receiverAddress, btcCoin);
> > request.ensureMinRequiredFee = false;
> > request.fee = Coin.valueOf(1);
> > request.feePerKb = Coin.ZERO;
> > request.changeAddress = wallet.currentReceiveAddress(); // one of
> my friend
> > think this line is making this issue
> >
> > Transaction transaction = wallet.sendCoinsOffline(request);
> > TransactionPoolManager.addTransaction(transaction); //
> addTransaction is a
> > method in TransactioPoolManager service
> > walletStoreService.saveWallet(wallet); // saves the wallet object
> > transactionHash = request.tx.getHashAsString();
> > return transactionHash;
> > } else {
> > throw new FileNotFoundException("Wallet not found");
> > }
> > }
> >
> >
> > addTransaction method in TransactioPoolManager service:
> >
> > private static Vector transactionPool;
> >
> > public static void addTransaction(Transaction tx) {
> > if (find(tx) != null) {
> > return;
> > }
> > for (Map.Entry entry :
> > walletStoreService.getWalletMap().entrySet()) {
> > if (entry.getValue().isPendingTransactionRelevant(tx)) {
> > transactionPool.add(new Entry(entry.getKey(), tx));
> > break;
> > }
> > }
> > }
> >
> > Thanks in advance
> >
> > --
> > 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+u...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout
> .
> 
> 
> 
> -- 
> Oscar Guindzberg
> 
> -- 
> 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: Wallet security questions

[Andreas Schildbach]

By default your wallet is not encrypted. If you think of it, what
encryption key should it use? Usually you need to ask or instruct the
user first, then encrypt. But ultimately it's up to you as the app
developer.

If you store the wallet in app-private storage, then at least other apps
can't access it, thanks to the Android sandboxing. This is a huge
security improvement compared to the overly liberal model desktop OSes
use. In future, even more secure ways like storing and signing in secure
elements can be explored.


On 06/20/2017 11:36 AM, Bruno Martins wrote:
> Hey lads, first post, 
> 
> I've developed an android simple wallet using bitcoinj. ( 
> https://github.com/ehanoc/xwallet) 
> 
> Now, I'm using mostly WalletAppKit for all bootstrapping everything. The 
> documentation that  suggests for more serious projects to handle each 
> component on its own and then couple them together. 
> 
> I'm wondering what security risks or potential bugs I'm running into here by 
> just using the app kit? Also what should I look for in terms of security, how 
> is the wallet, keys & seed stored. Encrypted by default? 
> 
> Thanks 
> Bruno 
> 


-- 
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: correct way for backend(ejb) application receive payment - freshReceiveAddress() vs Payment_Request

[Andreas Schildbach]

First of all, I think it is a bad idea to keep the Bitcoins of your
users on a server. Many of such servers have been hacked in the past, or
simply taken over via their hosting provider.

The advantage of the BIP70 payment protocol is you can transmit the
payment directly, without the need for connectivity to the Bitcoin
network at the moment of payment. Also, you can transmit an amount, your
(the payees) identity and so on.

At the end of the day, it depends on your specific use case.

Bitcoinj supports the payment protocol via the
org.bitcoinj.protocols.payments.PaymentSession and .PaymentProtocol classes.


On 06/24/2017 10:22 AM, Kunal Ransing wrote:
> Hi,
> 
> I am developing java backend(ejb) application receive payment. So
> creating receive address for every payment request by
> kit.wallet().freshReceiveAddress().toString() & displaying that on web
> page in plain/QR format.
> But i read here about Create Payment request :
> https://en.bitcoin.it/wiki/Payment_Request
> Which is correct way for receiving payment ?  How to do Payment_Request
> using bitcoinj lib ?
> Please help!
> 
> Regards,
> Kunal
> 
> -- 
> 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: Save Bitcoin Wallet object in database

[Andreas Schildbach]

Currently the only persistence mechanism supported is protobuf. You
could probably save a protobuf blob to redis, if that's what you're
looking for.


On 06/26/2017 08:16 AM, Ajit Soman wrote:
> Is there is any way to save bitcoin wallet object in database. I have
> tried to save wallet object in redis database. i got this exception:
> 
> 
> |
> org.redisson.client.RedisException:Unexpectedexception whileprocessing
> command
>  at
> org.redisson.command.CommandAsyncService.convertException(CommandAsyncService.java:321)
>  at
> org.redisson.command.CommandAsyncService.get(CommandAsyncService.java:164)
>  at org.redisson.RedissonObject.get(RedissonObject.java:70)
>  at org.redisson.RedissonMap.put(RedissonMap.java:197)
>  at com.examples.redis.RedissonedBitcoin.main(RedissonedBitcoin.java:27)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
>  at java.lang.Thread.run(Thread.java:748)
> Causedby:com.fasterxml.jackson.databind.JsonMappingException:Infiniterecursion
> (StackOverflowError)(through reference
> chain:org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Params["genesisBlock"]->org.bitcoinj.core.Block["params"]->org.bitcoinj.params.TestNet3Para
> |
> 
> -- 
> 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: raw-dump file

[Andreas Schildbach]

I think bitcoinj serializes the secret bytes for these hierarchies: 0,
0/0, 0/1. All the signing keys are derived on the fly, when needed for
signing.

Actually the key you're quoting below should be an extended key. It's
the parent of the internal keychain (which is used mostly for change
addresses).


On 06/26/2017 06:01 PM, Stefano Pieri wrote:
> I wrote an octave script to convert the protobuf raw text into priv and
> pub keys and I succeeded.
> 
> < one: 
> http://grepcode.com/file/repo1.maven.org/maven2/org.bitcoinj/bitcoinj-core/0.12.1/org/bitcoinj/wallet/deterministic-wallet-serialization.txt>>
> 
> Ok now I have many priv keys more  - but not the extended keys and I'm
> little bit in confusion...,
> 
> next,
> since  I have the "hidden" info about the parents that generated the
> main address list but also the change address list (already checked)
> --see the following code-- path 1, with 18 subkeys...
> key {
>   type: DETERMINISTIC_KEY
>   secret_bytes:
> "\247\031\222\016\377\blabla/"
>   public_key: "\003 \341=\232?\203\363\355\022N\
> blabla"
>   deterministic_key {
> chain_code:
> "d\271\001\203\327\362.\032\.blabla."
> path: 2147483648
> path: 1
> issued_subkeys: 18
> lookahead_size: 100
>   }
> }
> 
> since the BTC are in subkey #2my question is how could I generate
> the priv keys of the 'subs' starting from these keys
> 
> I know "HMAC-SHA512(Parent_PublicKey + Parent_ChainCode +
> Index)...blabla " but I don't know how to apply it
> 
> could you ELI5?
> 
> thx
> 
> 
> 
> Il giorno venerdì 23 giugno 2017 13:07:53 UTC+2, Andreas Schildbach ha
> scritto:
> 
> I believe what you're seeing is the protobuf text format, as created by
> this mehod in com.google.protobuf.ByteString:
> 
> public static String escapeBytes(ByteString input)
> 
> Escapes bytes in the format used in protocol buffer text format, which
> is the same as the format used for C string literals. All bytes that
> are
> not printable 7-bit ASCII characters are escaped, as well as backslash,
> single-quote, and double-quote characters. Characters for which no
> defined short-hand escape sequence is defined will be escaped using
> 3-digit octal sequences.
> 
> If I'm right, you can convert that back into a byte string (basically
> byte array) using:
> 
> public static ByteString unescapeBytes(CharSequence charString)
> throws
> TextFormat.InvalidEscapeSequenceException
> 
> Un-escape a byte sequence as escaped using escapeBytes(ByteString).
> Two-digit hex escapes (starting with "\x") are also recognized.
> 
> 
> On 06/22/2017 11:05 AM, Stefano Pieri wrote:
> > I'm trying to restore a corrupted wallet (flip-bit error
> > https://github.com/bitcoinj/bitcoinj/issues/968
> <https://github.com/bitcoinj/bitcoinj/issues/968>) to read the priv
> keys
> > and get the BTC back.
> >
> > Unfortunately, with wallet-tool dump --dump-privkeys I get the
> dump file
> > with all the pub but just two priv keys readable.
> >
> > When I try with raw-dump option, the raw file has 11 "secret_bytes:
> > XX\XXX\XX..." so I'm wondering if there is the possibility to convert
> > that hex/byte/base58 (?!?) format into something that could be
> readable?
> >
> > thanks,
> > Stefano
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: correct way for backend(ejb) application receive payment - freshReceiveAddress() vs Payment_Request

[Andreas Schildbach]

Well, for refunding (or sending the payment on) you'll have to decrypt
the wallet.


On 06/25/2017 10:09 AM, Kunal Ransing wrote:
> Hi,
> 
> Thank you for useful response.
> I will check PaymentSession way. It seems interesting.
> 
> Actually in case refund issue we need to keep merchant's payment at our
> side for some duration. Once user is satisfy with merchant service then
> we will forward their payment. I guess bitpay.com, coinbase,com etc.
> doing same.
> We can encrypt wallet for safety, right ? Also we will back encrypted
> wallet file at some other place too.
> We have our own servers which are PCI-DSS complaint. Also for other case
> we use Amazon host prvoider.
> What do you suggest for such use case(i.e we need to hold some merchants
> amount for bad service case) ?
> 
> 
> 
> On Saturday, 24 June 2017 19:22:10 UTC+5:30, Andreas Schildbach wrote:
> 
> First of all, I think it is a bad idea to keep the Bitcoins of your
> users on a server. Many of such servers have been hacked in the
> past, or
> simply taken over via their hosting provider.
> 
> The advantage of the BIP70 payment protocol is you can transmit the
> payment directly, without the need for connectivity to the Bitcoin
> network at the moment of payment. Also, you can transmit an amount,
> your
> (the payees) identity and so on.
> 
> At the end of the day, it depends on your specific use case.
> 
> Bitcoinj supports the payment protocol via the
> org.bitcoinj.protocols.payments.PaymentSession and .PaymentProtocol
> classes.
> 
> 
> On 06/24/2017 10:22 AM, Kunal Ransing wrote:
> > Hi,
> >
> > I am developing java backend(ejb) application receive payment. So
> > creating receive address for every payment request by
> > kit.wallet().freshReceiveAddress().toString() & displaying that on
> web
> > page in plain/QR format.
> > But i read here about Create Payment request :
> > https://en.bitcoin.it/wiki/Payment_Request
> <https://en.bitcoin.it/wiki/Payment_Request>
> > Which is correct way for receiving payment ?  How to do
> Payment_Request
> > using bitcoinj lib ?
> > Please help!
> >
> > Regards,
> > Kunal
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: bitcoinj:0.14.4 stuck at kit.awaitRunning() when using regtest mode

[Andreas Schildbach]

I'm sorry, I have never used regtest mode. I always used testnet for
testing.

Can you give the DoubleSpend.java example a spin and see if it works for
you (progresses past the "awaitRunning()" line)?


On 06/23/2017 09:15 AM, Kunal Ransing wrote:
> @Andreas Schildbach
> Can you help me please ?
> 
> On Wednesday, 21 June 2017 19:31:54 UTC+5:30, Kunal Ransing wrote:
> 
> Hi,
> 
> I am new to this.
> I am trying to create test program to create new address to receive
> payment. It *works well with "testnet"* mode but when using
> "regtest" code stuck at  kit.awaitRunning().
> 
> For regtest mode before running code, I did below
> >bitcoind -regtest -debug -daemon
> 
> After started program I can see "connections": 1 by  running
> "bitcoin-cli -regtest getinfo" but code just stuck at
> walletAppKit.awaitRunning().
> 
> Please check below code & *bitcoind log*
> 
> public static void main(String[] args) {
> //System.setProperty("-Dbitcoinj.logging", "true");
> BriefLogFormatter.init();
> NetworkParameters params = RegTestParams.get();
> String filePrefix = "forwarding-service-regtest";
>
> WalletAppKit kit = new WalletAppKit(params, *new
> File(".")*, filePrefix);
> if (params == RegTestParams.get()) {
>  kit.connectToLocalHost();
> }
> 
>  // Download the block chain and wait until it's done.
> kit.startAsync();
>*kit.awaitRunning(); //execution just stop here and for
> long time..*
> 
> List list = kit.wallet().getWatchedAddresses();
> if (list.size() < 2) {
>
> kit.wallet().addWatchedAddress(kit.wallet().freshReceiveAddress());
> System.out.println("New address created");
> }
> 
> System.out.println("You have " + list.size() + "
> addresses!");
> for (Address a: list) {
> System.out.println(a.toString());
> }
> 
> String balance =
> kit.wallet().getBalance().toFriendlyString();
> System.out.println(balance);
> }
> 
> 
> 
> *bitcoind debug log*
> 
> 2017-06-21 13:42:38 Added connection peer=1
> 2017-06-21 13:42:38 connection from 127.0.0.1:52972
> <http://127.0.0.1:52972> accepted
> 2017-06-21 13:42:38 received: version (103 bytes) peer=1
> 2017-06-21 13:42:38 sending version (102 bytes) peer=1
> 2017-06-21 13:42:38 send version message: version 70015, blocks=101,
> us=[::]:0, peer=1
> 2017-06-21 13:42:38 sending verack (0 bytes) peer=1
> 2017-06-21 13:42:38 receive version message: /bitcoinj:0.14.4/:
> version 70001, blocks=0, us=127.0.0.1:18444
> <http://127.0.0.1:18444>, peer=1
> 2017-06-21 13:42:38 added time data, samples 2, offset +0 (+0 minutes)
> 2017-06-21 13:42:38 sending alert (168 bytes) peer=1
> 2017-06-21 13:42:38 received: verack (0 bytes) peer=1
> 2017-06-21 13:42:38 sending ping (8 bytes) peer=1
> 2017-06-21 13:42:38 received: filterload (1935 bytes) peer=1
> 2017-06-21 13:42:38 received: mempool (0 bytes) peer=1
> 2017-06-21 13:42:38 received: getheaders (3269 bytes) peer=1
> 2017-06-21 13:42:38 Ignoring getheaders from peer=1 because node is
> in initial block download
> 2017-06-21 13:42:38 received: pong (8 bytes) peer=1
> 2017-06-21 13:42:40 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:40 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:42 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:42 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:44 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:44 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:46 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:46 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:48 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:48 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:50 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:50 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:52 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:52 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:54 received: ping (8 bytes) peer=1
> 2017-06-21 13:42:54 sending pong (8 bytes) peer=1
> 2017-06-21 13:42:56 received: ping

Re: raw-dump file

[Andreas Schildbach]

I believe what you're seeing is the protobuf text format, as created by
this mehod in com.google.protobuf.ByteString:

public static String escapeBytes(ByteString input)

Escapes bytes in the format used in protocol buffer text format, which
is the same as the format used for C string literals. All bytes that are
not printable 7-bit ASCII characters are escaped, as well as backslash,
single-quote, and double-quote characters. Characters for which no
defined short-hand escape sequence is defined will be escaped using
3-digit octal sequences.

If I'm right, you can convert that back into a byte string (basically
byte array) using:

public static ByteString unescapeBytes(CharSequence charString)
throws
TextFormat.InvalidEscapeSequenceException

Un-escape a byte sequence as escaped using escapeBytes(ByteString).
Two-digit hex escapes (starting with "\x") are also recognized.


On 06/22/2017 11:05 AM, Stefano Pieri wrote:
> I'm trying to restore a corrupted wallet (flip-bit error
> https://github.com/bitcoinj/bitcoinj/issues/968) to read the priv keys
> and get the BTC back.
> 
> Unfortunately, with wallet-tool dump --dump-privkeys I get the dump file
> with all the pub but just two priv keys readable. 
> 
> When I try with raw-dump option, the raw file has 11 "secret_bytes:
> XX\XXX\XX..." so I'm wondering if there is the possibility to convert
> that hex/byte/base58 (?!?) format into something that could be readable?
> 
> thanks,
> Stefano
> 
> -- 
> 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: Clarification on DNS Lookup and PeerGroup Discovery

[Andreas Schildbach]

SPV nodes do not listen on ports (and make themselves discoverable via
DNS). So if you're the one connecting to the other node, it should be a
full node.


On 05/01/2017 04:51 PM, Ramez Az wrote:
> Is there any way to know about the connected node whether it is full
> node or SPV node?
> 
> Thanks,
> Ramesh A
> 
> On Friday, April 28, 2017 at 6:50:16 PM UTC+5:30, Andreas Schildbach wrote:
> 
> Other than the port number, there is no constant that you could use for
> a firewall rule. And even the port number can be changed by peers, even
> if that is very rare currently.
> 
> You could put your own full node outside of the firewall and then
> connect to that node exclusively. In such a setup, you could use the IP
> of your full node for the firewall rule.
> 
> SPV nodes do not relay blocks and transactions.
> 
> 
> On 04/26/2017 05:14 PM, Ramez Az wrote:
> > Thanks for your clarification.
> >
> > For running full node, what are the steps i need to follow and Is
> there
> > any reliable full node is available in the internet so that i can
> open
> > my firewall to that fullnode and can connect. If i need to run as
> full
> > node, what configuration(S/W and H/W) i should have.
> >
> > The another thing i wanted to check is that Is the SPV node
> capable of
> > propagate to other nodes. So that i can use the below approach.
> >
> > The Machine(Within Firewall) -> SPV Node(Outside the firewall and
>     > connected with bitcoin network).
> >
> > Thanks,
> > Ramesh A
> >
> > On Friday, April 21, 2017 at 1:53:46 PM UTC+5:30, Andreas
> Schildbach wrote:
> >
> > Since Bitcoin is decentralized, peers can come and go without
> notice.
> > The DNS queries are purposefully designed to return a
> different set of
> > peers for each query. So yes this also applies to Mainnet.
> >
> > The Bitcoin P2P network cannot work unless you allow full
> access to
> > port
> > 8333 (port 18333 for testnet).
> >
> > To work around that limitation, we suggest you to run your own
> full
> > node
> > and connect to it exclusively (using the Peer API). However,
> that full
> > node would need to sit outside your fireware or otherwise it
> could not
> > connect to the P2P network either.
> >
> >
> > On 04/21/2017 05:19 AM, Ramez Az wrote:
> > > Hi,
> > >
> > > I am developing small client application for posting the
> txns and
> > > receiving the txns. I have firewall in my network and i am
> able to
> > allow
> > > only some Peers to connect in the network. The list of peers(IP
> > > addresses) are getting changed every DNS lookup at
> > > testnet-seed.bitcoin.petertodd.org
> <http://testnet-seed.bitcoin.petertodd.org>
> > <http://testnet-seed.bitcoin.petertodd.org
> <http://testnet-seed.bitcoin.petertodd.org>> domain. Can you please
> > provide some
> > > list of Peers through which we should be able to do connect
> at any
> > time.
> > > Is there any other domain where we can get some consistent
> Peers
> > or any
> > > alternatives?. If you provide some of consistent peers, i
> can open my
> > > firewall for those nodes.
> > >
> > > I am facing this issue in Testnet, Is this the same case for
> > mainnet as
> > > well or can we get consistent Peers in MainNet.
> > >
> > > As this is bit urgent, Can any one clarify as soon as possible.
> > >
> > > Thanks in Advance.
> > >
> > > Thanks,
> > > Ramesh A
> > >
> > > --
> > > 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+u...@googlegroups.com
> > > <mailto:bitcoinj+u...@googlegroups.com>.
> > > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>

Re: Spending a multisig contract doesn't work in Main network

[Andreas Schildbach]

If you search the list archives for "multisig" you'll find a couple of
people who apparently use it. I myself do not, which is why I've not
responded.


On 05/07/2017 03:13 PM, Álvaro Castro-Castilla wrote:
> Has anyone ever succeeded in broadcasting a multisig spend using this
> library in production?
> I'd appreciate some help, since there isn't much documentation about
> this topic.
> 
> Thanks!
> 
> 
> 
> On Saturday, May 6, 2017 at 6:10:08 PM UTC+2, Álvaro Castro-Castilla wrote:
> 
> I've confirmed that the spend is performed with zero fees.
> When I create the multisig with createMultiSigOutputScript, the
> transaction is created with fees, that I can obtain with getFee().
> However, when I create the spend opeartion with
> createMultiSigInputScript, getFee() returns zero.
> 
> How should I handle this so it's processed by the network?
> 
> Thank you!
> 
> 
> 
> On Sunday, April 30, 2017 at 4:12:57 PM UTC+2, Álvaro
> Castro-Castilla wrote:
> 
> Hi!
> 
> I'm experiencing issues with multisig contracts in Main network.
> They seem to work OK in regtest and Testnet, but not in Main. I
> have the suspicion that is because I'm not adding a fee.
> I wanted to ask here since this is the only instance of
> different behaviour I found with respect the Main net.
> Is it possible that I need to manually set a fee or may be cause
> by a different issue?
> 
> 
> Thank you! 
> 
> -- 
> 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: Bitcoinj stuck after chain split

[Andreas Schildbach]

There are plenty of bitcoind forks: Bitcoin XT, Bitcoin Unlimited,
Bitcoin Classic are only some.

As for full verifying mode in bitcoinj: Seems as if no one is working on
it. If that doesn't change, at one point we will remove it from the
codebase.


On 06/02/2017 09:08 AM, BitcoinUser wrote:
> I am using full verifying mode...
> Is there any chance that it will be maintain again any time soon?
> 
> If no, is there any other library/bitcoind fork that allows to browsing
> blockchain by addresses/unspent outputs easily?
> I know that there is https://github.com/bitpay/bitcoin
> and https://github.com/btcdrak/bitcoin/releases forks with -addrindex
> and -txindex, but it seems to not be supported anymore.
> 
> W dniu niedziela, 28 maja 2017 23:15:15 UTC+2 użytkownik Andreas
> Schildbach napisał:
> 
> Are you using SPV or full verifying mode? Full verifying mode is almost
> guaranteed to get stuck since it is not really maintained any more.
> 
> 
> On 05/23/2017 03:44 PM, BitcoinUser wrote:
> > I am using LevelDBFullPrunedBlockStore as a BlockChain. once in every
> > 2-3 chainsplit in the network my bitcoinJ node stops to download new
> > block. The scenario is always the same
> >
> > 1)My node get block on height x that network will mark as orphaned
> later
> > 2)My node gets block x+1 (from mainchain) and says that block x
> > (orphaned by the network later) will be orphaned
> > 3)My node get the mainchain block on height x and says that "could
> not
> > verify block"
> >
> > Later peers are sending me single transactions, but I am unable to
> > download any more blocks, there is no logs about the new block at
> all. I
> > did not change anything in the code that is responsible for block
> > persistence. When I restart the application it does not download
> any new
> > block as well.
> >
> > Here is log form Saturday where it happend:
> >
> > |2017-05-13 22:45:56 INFO AbstractBlockChain:597 - Block forks the
> chain
> > at height 466251/block
> > 00c0b4c4e062b8cc77a5fd3dc5594bee9fd5a8cacdeba92b,
> but it
> > did not cause a reorganize:
> > 01b3699313793566fb947d554173c5f19fe790e597adedbf
> > 2017-05-13 22:45:56 INFO AbstractBlockChain:926 - Connected orphan
> > 0005b2d8a9d429b050a5a9ba4d44dbe1543280d6e89b77af
> > 2017-05-13 22:45:56 INFO AbstractBlockChain:576 - Block is causing a
> > re-organize 2017-05-13 22:45:56 INFO AbstractBlockChain:752 -
> > Re-organize after split at height 466251 2017-05-13 22:45:56 INFO
> > AbstractBlockChain:753 - Old chain head:
> > 00c89a56fec1a04a5981e7f614e6ba2f877559fc2ef9e138
> > 2017-05-13 22:45:56 INFO AbstractBlockChain:754 - New chain head:
> > 0005b2d8a9d429b050a5a9ba4d44dbe1543280d6e89b77af
> > 2017-05-13 22:45:56 INFO AbstractBlockChain:755 - Split at block:
> > 00c0b4c4e062b8cc77a5fd3dc5594bee9fd5a8cacdeba92b
> > 2017-05-13 22:45:57 WARN Peer:1025 - [2a03:4000:2:496:0:0:0:8]:8333:
> > Block verification failed org.bitcoinj.core.VerificationException:
> Could
> > not verify block: block: hash:
> > 01b3699313793566fb947d554173c5f19fe790e597adedbf
> > version: 536870912 (BIP34, BIP66, BIP65) previous block:
> > 00c0b4c4e062b8cc77a5fd3dc5594bee9fd5a8cacdeba92b
> merkle
> > root:
> dcf81e3a220fa3a14ed09cd76497e13fb9c9affeef9c9ce052c9c1e1854fac26
> > time: 1494708074 (2017-05-13T20:41:14Z) difficulty target (nBits):
> > 402781863 nonce: 2897470832 with 2100 transaction(s):
> > 8a0d0a5f11ef31f974f59658c27824b2ddacba88e6b6dfa1865caa48bf4bb444 |
> >
> > Did anyone had the same issue? I have no clue what I suppose to do.
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Upgrading Guava dependency to Guava 22

[Andreas Schildbach]

I tried on API level 18, works fine so far.


On 05/31/2017 09:48 PM, Sean Gilligan wrote:
> On 5/31/17 7:42 AM, Andreas Schildbach wrote:
>> The update seems pretty smooth. See
>> https://github.com/bitcoinj/bitcoinj/pull/1380
> 
> That's great news! Thanks for doing that!
> 
>> Hmmm Gingerbread (API level 10) has updated the Java API from 5 to 6. I
>> seriously doubt anything using the Java 7 API will run there. We had a
>> lot of breakage in bitcoinj because of this incompatibility.
> 
> Maybe they've neglected to update that sentence on their wiki?
> 
>> But I'll simply try it today. Raising the Android requirement to KitKat
>> would not be too bad either, everything below is inherently insecure
>> anyway (Google still supports KitKat with security patches).
> 
> Sounds reasonable to me. I have one test platform that uses API 17, but
> so far using JDK 7 (and Guava 22-android) has been working there.
> 
> 
> -- Sean
> 
> 
> 
> 
> -- 
> 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
> <mailto: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: ECKey object for Private Key

[Andreas Schildbach]

It looks like you're already holding a DeterministicKey object. That
object is already an ECKey!


On 05/31/2017 04:38 AM, Ramez Az wrote:
> Hi,
> 
> How can i create the ECKey object for the private key using any of the
> below detail which is dumped from the Wallet.
> 
> addr:miMTAPQuxpai7v78BcUXPbSSARAeNSyocL
>  hash160:1f1c50bc284fe7f987431448c973fdcc5b906998  (M/0H/1)
>   DeterministicKey{pub
> HEX=022f0441b4f9a44e6ef083329b45320e5681fd1c661eda2761f4eabfc1240b1f76,
> priv
> HEX=29e73f9e560715c427964cb1fbbe0dc264e1e0bb460c9a3bd52c2d2624d423da,
> priv WIF=cNzA1jjPHfxRNoXxP8JYfmfSFSVJGSoWayoqAeqfvuuxAEKN9jnu,
> isEncrypted=false, isPubKeyOnly=false}
> 
> 
> Thanks,
> Ramesh A
> 
> -- 
> 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: Can BitcoinJ get many child pubKey by a parent extPubKey

[Andreas Schildbach]

If you just want to derive, you might want to use the class
HDKeyDerivation. But the Wallet does it all for you, if you want to have
a Wallet too. It just supports the "default account" path described in
the BIP32 spec right now.


On 04/24/2017 08:06 AM, wait.lin.hong...@gmail.com wrote:
> Like the BIP32, it defined that public parent key to public child key
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#public-parent-key--public-child-key
> Please tell me how to achieve that if it can solve in BitcoinJ. Thx :) .
> My BitcoinJ version is 0.14.4.
> 
> -- 
> 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: Importing key into wallet but balance from corresponding address is not accounted

[Andreas Schildbach]

After importing a key, you need to sync the entire blockchain again to
know its balance. To speed that up, read
https://bitcoinj.github.io/speeding-up-chain-sync

Why do you want to transfer keys between wallets?


On 04/29/2017 12:07 AM, Alexey Ulyanov wrote:
> Hi
> 
> I have created one wallet in Testnet and got some BTC for testing on
> current receive address.
> 
> Now i'm looking for a way how can I import that address into another
> wallet created for Testnet.
> 
> I'm using snippet from examples
> https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/java/org/bitcoinj/examples/PrivateKeys.java
> I modified it to use Testnet instead of product net, importing private
> key of address where I have cons and just checking wallet details in
> console once blockchain is downloaded.
> 
> But as per wallet details balance is zero though imported key and
> corresponding address are shown in details.
> 
> Shouldn't t coins of imported address be accounted in wallet where
> private key has been imported?
> 
> -- 
> 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: Fail to recover wallet from DeterministicSeed

[Andreas Schildbach]

Have you looked at the RestoreFromSeed code example? It does exactly that.


On 05/07/2017 01:39 AM, Bruno Martins wrote:
> Hey,
> 
> I've started a Bitcoin wallet pet project to start getting familiarized
> with crypto / blockchain development.
> 
> I am having trouble recovering a wallet from the mnemonic seed and it's
> creation date.
> 
> After the attempting to sync i end up with a total new wallet but with
> the old (previous wallet) mnemonic seed attached to it . I'm a bit confused.
> 
> |
> finalDeterministicSeedseed =createDeterministicSeed();
> 
>
> _bitcoinManager.getCurrencyCoin().getWalletManager().addListener(newService.Listener(){
> @Override
> publicvoidterminated(Service.Statefrom){
> super.terminated(from);
> WalletAppKitappKit =setupWallet();
> 
> appKit.setDownloadListener(BitcoinRecoverAction.this)
> .setBlockingStartup(false)
> .setUserAgent(ServiceConsts.SERVICE_APP_NAME,"0.1")
> .restoreWalletFromSeed(seed);
> 
> _bitcoinManager.getCurrencyCoin().setWalletManager(appKit);
>
> _bitcoinManager.getCurrencyCoin().getWalletManager().startAsync();
> }
> },Executors.newSingleThreadExecutor());
> 
> _bitcoinManager.getCurrencyCoin().getWalletManager().stopAsync();
> |
> 
> The entire class / code can be found here :
> https://github.com/ehanoc/xwallet/blob/master/app/src/main/java/com/bytetobyte/xwallet/service/coin/bitcoin/actions/BitcoinRecoverAction.java
> 
> Thanks a million
> Bruno
> 
> -- 
> 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: Accessing bitcoinj via a thread that has not had any context set on it" in bitcoinj 0.14.4

[Andreas Schildbach]

The documentation about the Context class is here:

https://bitcoinj.github.io/contexts

And there is also some Javadoc.

Sorry, I can't answer your Spring question right now.


On 04/30/2017 03:27 PM, Alexander Oleinik wrote:
> Hi, I'm trying to run bitcoinj in a spring-based app within a separate
> class marked as @Service . When I make any
> Wallet's method invocation from another class (marked as @RestController
>  in my case), I constantly get this
> annoying message:
> 
> 
> "Performing thread fixup: you are accessing bitcoinj via a thread that
> has not had any context set on it.
> This error has been corrected for, but doing this makes your app less
> robust.
> You should use Context.propagate() or a ContextPropagatingThreadFactory.
> Please refer to the user guide for more information about this."
> 
> 
> But I couldn't find any mentionings in the doc addressing this issue. I
> saw a similar thread in this group but there was not the spring
> multithreaded case, so I've decided to create another topic on this.
> 
> 
> How should I instantiate a WalletKit in a separate @Service
>  class to make this message gone?
> 
> 
> Thanks in advance.
> 
> 
> Alexander.
> 
> -- 
> 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: UASF

[Andreas Schildbach]

Currently bitcoinj doesn't support BIP9, which of course is something we
should implement.

On top of that (as separate PRs) we could support signalling/activation
for several BIPs (e.g. Segwit), similar to how the old signalling via
block versions is supported today.

(Side note: I personally think UASF is a bad idea due to the risks
involved, but since the users of bitcoinj are devs who should know what
they're doing I would not object to optional BIP148 support.)


On 05/29/2017 01:34 PM, Manfred Karrer wrote:
> Similar to the BU fork risk scenario we will get troubles in Bitsquare
> if we mix connections to UASF nodes and non-UASF nodes.
> I am wondering what is the best way how to deal with it.  
> One user at Reddit responded:
> "SPV wallets check block headers, which is enough to enforce BIP148
> (i.e. rejecting non-segwit signalling block headers)."
> https://www.reddit.com/r/Bitcoin/comments/6dxo7h/electrum_and_mycelium_now_publicly_support_uasf/di6h39y/?context=3
> 
> Can anyone familiar with the BitcoinJ code confirm that?
> 
> -- 
> 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: Upgrading Guava dependency to Guava 22

[Andreas Schildbach]

The update seems pretty smooth. See
https://github.com/bitcoinj/bitcoinj/pull/1380

Hmmm Gingerbread (API level 10) has updated the Java API from 5 to 6. I
seriously doubt anything using the Java 7 API will run there. We had a
lot of breakage in bitcoinj because of this incompatibility.

But I'll simply try it today. Raising the Android requirement to KitKat
would not be too bad either, everything below is inherently insecure
anyway (Google still supports KitKat with security patches).


On 05/31/2017 01:52 AM, Sean Gilligan wrote:
> On 5/30/17 1:17 PM, Andreas Schildbach wrote:
>> Do you know on what versions of Android the 22.0-android Guava version
>> works? Seems like they use the Java7 API, which seems to imply KitKat+.
> 
> The last line of the README says:
> 
> https://github.com/google/guava/blob/master/README.md
> 
> 
> "For the Android flavor, our unit tests run on API level 10 (Gingerbread)."
> 
> 
> The 'Compatibility' page (under 'Older JDKs') says
> 
> For the medium-term future, Guava users who need to target JDK 7 can use
> the Android flavor, which has no Android-specific dependencies. At some
> point in the future, when Android diverges sufficiently from JDK 7,
> Guava may stop providing a JDK 7-compatible flavor, at which time those
> users will have to stay with the latest prior version.
> 
> https://github.com/google/guava/wiki/Compatibility
> 
> 
> -- Sean
> 
>>
>> On 05/30/2017 09:42 PM, Sean Gilligan wrote:
>>> Guava version 22 sets a new baseline for Guava JDK/Android
>>> compatibility. (see https://github.com/google/guava/wiki/Release22)
>>>
>>> The  'com.google.guava:guava:22.0' requires Java 8, but the
>>> 'com.google.guava:guava:22.0-android' is a compatible subset and works
>>> on Android.
>>>
>>> It would be nice to see the bitcoinj dependency updated to a more recent
>>> Guava and skipping to 22 would likely be the best long-term strategy.
>>>
>>> Does anyone have an idea how hard upgrading bitcoinj to Guava 22 would
>>> be? Is this something that might make sense for bitcoinj 0.15?
>>>
>>> -- Sean
>>>
>>>
>>>
>>>
>>>
> 
> -- 
> 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
> <mailto: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 sign a transaction's inputs?

[Andreas Schildbach]

If the transaction is in the context of a wallet, use

Wallet.signTransaction(SendRequest)

If it is kind of detached transaction, you can use one of the various
TransactionSigner implementations, possibly LocalTransactionSigner.



On 09/13/2017 03:52 AM, Private Z wrote:
> I get an unsign transaction's hex.
> Like this: 
> 02000157714d146d6e04a2693f52db1244d209d41105f1e2bb90a541f3ccbf0861aa6e010118ddf5051976a914797313e7510bb9c7c658a1a6e999fe7739eed44688ac
> 
> step 1: create an eckey from privatekey
>  
> |
> DumpedPrivateKey privateKey =
> DumpedPrivateKey.fromBase58(mNetworkParameters, key);
> ECKey ECKey = privateKey.getKey();
> |
> 
> step 2: crate an unsign transaction.
> 
> |
> NetworkParameters networkParameters = TestNet3Params.get();
> // hex2bytes is a conversion method that can hex to bytes.
> Transaction transaction = new Transaction(networkParameters,
> hex2bytes(signedTx));
> |
> 
> Now, i don't know how to sign the transaction？
> 
> -- 
> 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: Broadcast a transaction, issue with Context missing from thread created by BitcoinJ

[Andreas Schildbach]

Sounds like a bug in bitcoinj. What bitcoinj version are you using?


On 09/15/2017 03:29 PM, NelsoN Melina wrote:
> In this code i receive an already signed transaction in the form of a
> byte array and i would like to broadcast it to the Bitcoin network.
> 
> |
> |
> 
> |overridefun onHandleIntent(intent:Intent?){
>     org.bitcoinj.core.Context.propagate(Constants.CONTEXT)
>     if(intent !=null){
>         when(intent.action){
>             ACTION_BROADCAST_TRANSACTION ->{
>                 initializeBlockchain(null,0)
>                 val transactionByteArray =intent.getByteArrayExtra("TX")
>                 val tx
> =Transaction(Constants.NETWORK_PARAMETERS,transactionByteArray)
>                
> tx.getConfidence().setSource(TransactionConfidence.Source.SELF);
>                 tx.setPurpose(Transaction.Purpose.USER_PAYMENT);
>                 SpvModuleApplication.getWallet()!!.maybeCommitTx(tx)
>                 if(peerGroup !=null){
>                     val
> transactionBroadcast:TransactionBroadcast=peerGroup!!.broadcastTransaction(tx)
>                     val future
> :ListenableFuture=transactionBroadcast.future()
>                    
>                     future.get()
>   ..|
> 
> |
> 
> |
> 
> Issue is that in my own code i already propagated the context but then
> internally in BitcoinJ it creates another thread when it has enough
> peers, and then broadcast the transaction from this thread, which fails
> as the Context is not propagated there.
> 
> Any pointers as to what i am doing wrong ?
> 
> Thanks.
> 
> 
> 09-14 15:14:52.867 8281-8330/com.m.s.test E/ExecutionList:
> RuntimeException while executing runnable
> 
> org.bitcoinj.core.TransactionBroadcast$EnoughAvailablePeers@838ec24
> with executor org.bitcoinj.utils.Threading$2@7b38d
> java.lang.IllegalStateException: missing context
> 
>  
> 
> at org.bitcoinj.core.Context.get(Context.java:110)
> 
>  
> 
> 
> at
> org.bitcoinj.core.Transaction.getConfidence(Transaction.java:1198)
> 
>  
> 
> 
> at
> 
> org.bitcoinj.core.TransactionBroadcast$EnoughAvailablePeers.run(TransactionBroadcast.java:134)
> 
>  
> 
> 
> at org.bitcoinj.utils.Threading$2.execute(Threading.java:141)
> 
>  
> 
> 
> at
> 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> 
>  
> 
> 
> at
> 
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> 
>  
> 
> 
> at
> 
> com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)
> 
>  
> 
> 
> at
> 
> com.google.common.util.concurrent.SettableFuture.set(SettableFuture.java:53)
> 
>  
> 
> 
> at
> 
> org.bitcoinj.core.PeerGroup$14.onPeerConnected(PeerGroup.java:1938)
> 
>  
> 
> 
> at org.bitcoinj.core.PeerGroup$11.run(PeerGroup.java:1565)
> 
>  
> 
> 
> at
> org.bitcoinj.utils.Threading$UserThread.run(Threading.java:107)
> 
> -- 
> 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: Broadcast a transaction, issue with Context missing from thread created by BitcoinJ

[Andreas Schildbach]

Regarding your original issue: it would be great if you could test this
on our master branch, just to know if the issue stems from any custom
modifications.

I think PRs #1341 and #1441 are orthogonal for the most part. So if all
goes well, I expect both to be merged at some point (with modifications,
I added comments to both PRs). If you've got feedback (conceptual or
testing) directly related to one PR, directly commenting on the PRs
seems most productive.

About BIP44 there is a conflict that BIP44 is about multi-account,
whereas bitcoinj has decided to generally not support multiple accounts
per wallet to keep complexity low. You could use multiple wallets
instead. Or you could limit your BIP44 implementation to just one
account, kind of violating the spec.

Anyhow, it's great to see Mycelium onboard. Welcome!


On 09/18/2017 03:21 PM, NelsoN Melina wrote:
> I tried the code from https://github.com/uniquid/bitcoinj as i needed to
> try this pull request https://github.com/bitcoinj/bitcoinj/pull/1341
> 
> At Mycelium we are aiming to use BitcoinJ as one of the main part of our
> architecture but we need BIP44 implemented. Happy to contribute in the
> best way.
> 
> I am wondering right now if it's not better to contribute
> on https://github.com/bitcoinj/bitcoinj/pull/1441 instead. But that
> might be slightly off topic here.
> 
> Should we move this conversation elsewhere and focus on the bug ?
> 
> //
> 
> /Nelson MELINA Software Development Engineer/
> 
> /http://www.linkedin.com/in/nelsonmelina /
> 
> 
> 
> On Sat, Sep 16, 2017 at 5:12 PM, Andreas Schildbach
> <andr...@schildbach.de <mailto:andr...@schildbach.de>> wrote:
> 
> Sounds like a bug in bitcoinj. What bitcoinj version are you using?
> 
> 
> On 09/15/2017 03:29 PM, NelsoN Melina wrote:
> > In this code i receive an already signed transaction in the form of a
> > byte array and i would like to broadcast it to the Bitcoin network.
> >
> > |
> > |
> >
> > |overridefun onHandleIntent(intent:Intent?){
> >     org.bitcoinj.core.Context.propagate(Constants.CONTEXT)
> >     if(intent !=null){
> >         when(intent.action){
> >             ACTION_BROADCAST_TRANSACTION ->{
> >                 initializeBlockchain(null,0)
> >                 val transactionByteArray
> =intent.getByteArrayExtra("TX")
> >                 val tx
> > =Transaction(Constants.NETWORK_PARAMETERS,transactionByteArray)
> >                
> > tx.getConfidence().setSource(TransactionConfidence.Source.SELF);
> >                 tx.setPurpose(Transaction.Purpose.USER_PAYMENT);
> >                 SpvModuleApplication.getWallet()!!.maybeCommitTx(tx)
> >                 if(peerGroup !=null){
> >                     val
> >
> 
> transactionBroadcast:TransactionBroadcast=peerGroup!!.broadcastTransaction(tx)
> >                     val future
> > :ListenableFuture=transactionBroadcast.future()
> >                    
> >                     future.get()
> >   ..|
> >
> > |
> >
> > |
> >
> > Issue is that in my own code i already propagated the context but then
> > internally in BitcoinJ it creates another thread when it has enough
> > peers, and then broadcast the transaction from this thread, which
> fails
> > as the Context is not propagated there.
> >
> > Any pointers as to what i am doing wrong ?
> >
> > Thanks.
> >
> >
> >             09-14 15:14:52.867 8281-8330/com.m.s.test E/ExecutionList:
> >             RuntimeException while executing runnable
> >           
>  org.bitcoinj.core.TransactionBroadcast$EnoughAvailablePeers@838ec24
> >             with executor org.bitcoinj.utils.Threading$2@7b38d
> >             java.lang.IllegalStateException: missing context
> >
> >      
> >
> >             at org.bitcoinj.core.Context.get(Context.java:110)
> >
> >      
> >
> >
> >             at
> >           
>  org.bitcoinj.core.Transaction.getConfidence(Transaction.java:1198)
> >
> >      
> >
> >
> >             at
> >           
>  
> org.bitcoinj.core.TransactionBroadcast$EnoughAvailablePeers.run(TransactionBroadcast.java:134)
> >
> >      
> >
> >
> >             at
> org.bitcoinj.utils.Threading$

Re: TransactionConfidenceEventListener

[Andreas Schildbach]

BUILDING actually means confirmed, but being confirmed doesn't mean that
it can't be undone with a re-org. It just gets less and less likely with
each block, which is why the ConfidenceType is called BUILDING.

The >6 threshold is just a convention. Depending on the usecase, one (or
even none) might be enough.


On 10/02/2017 09:49 AM, Edik Edik wrote:
> Now BUILDING with depths exceeding 100...
> 
> I have to assume that >6 = CONFIRMED I guess!
> 
> Ed
> 
> 
> On Sunday, October 1, 2017 at 9:25:43 PM UTC+1, Edik Edik wrote:
> 
> Hi Guys
> 
> I am receiving callbacks that indicate that the transaction is
> BUILDING... it's good )))
> 
> However when I look at the transaction.confidence.depthInBlocks it
> can indicate a block depth of perhaps 40 (seems to be maximum so far).
> 
> Can I assume when the block depth > 6 that the transaction is confirmed?
> 
> If so, should BUILDING really be telling us CONFIRMED?
> 
> Many thanks... again!
> 
> -- 
> 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: bitcoinj wallet - one wallet for multi user or one wallet for one user

[Andreas Schildbach]

On 10/10/2017 09:18 AM, Arief Mulyana Djauhari wrote:

> I would like to ask about wallet class in bitcoinj, can the wallet have 
> multi user? or the wallet can only have one user?

No, the Wallet class doesn't do multi user or multi account. You can use
multiple Wallets instead, but be warned that this approach currently
doesn't scale well.

-- 
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: help replaying a store/chain, is it possible?

[Andreas Schildbach]

Generally, you need to keep all wallets connected while your PeerGroup
is running. As soon as you disconnect a wallet, it will get out of sync.
You can replay out of sync wallets, but you'll need to reset these
wallets and all other connected wallets, plus remove the blockchain so
it can start from genesis (or an appropriate checkpoint if you use
checkpoints).

Bitcoinj doesn't scale to many wallets. The "one PeerGroup per Wallet"
approach has afaik never been tested; it's probably best to run each
such combination in a separate VM.


On 10/15/2017 02:04 AM, alexfieldman...@gmail.com wrote:
> Can somebody please explain if it is possible to start a
> blockchain/store/peergroup, and add a wallet at a later time, disconnect
> it and let the chain run (24/7), then reconnect the wallet and catchup
> with the chain?
> 
> or even just have a BlockChain for every wallet but somehow not need to
> store.reset and startDownload() just to see some blocks? i also couldnt
> leave countless wallets constantly listening on the chain at all times,
> it would be so inefficient.
> 
> 
> I am using fullprunedblockchain and MYSQLFullPrunedBlockStore, i should
> be able to replay the chain to the wallet but its not working.
> 
> I cant have a peer group for every single wallet, connecting and
> downloading a new blockstore for every wallet that is made, that would
> be chaos on a server side environment.
> 
> can anybody tell me what i can do here short of writing in my own
> classes to pull from the blockstore? (id have no idea where to begin for
> this)

-- 
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: Listening to current traffic

[Andreas Schildbach]

On 10/14/2017 06:27 PM, Edik Edik wrote:
> What listener do I use to pull any new blockchain additions?
> 
> Can't seem to locate anything in the library to be able to pull this 
> information in real-time.

It depends a bit on your usecase. Generally, you create
BlockStore/BlockChain objects and fire up a PeerGroup. You specifically
asked for new blocks so BlockChain.addNewBestBlockListener() might be
interesting to you.

Have a look at the BuildCheckpoints tool for a code example.

-- 
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: wallet-tool dump doesn't show keypair with balance.

[Andreas Schildbach]

Is the wallet fully synched?


On 10/17/2017 01:41 AM, Ferrets in my Socks wrote:
> I have decrypted my wallet created by
> https://github.com/bitcoin-wallet/bitcoin-wallet and inspected it with
> `wallet-tool dump`. It prints 3 addresses none of which have a balance.
> 
> If I inspect it with a different tool
> (https://github.com/lloeki/bitcoinj-wallet-dump) I can see 271
> addresses, 3 of which are the addresses displayed by wallet-tool. One of
> the other addresses contains my current balance.
> 
> Can I get wallet-tool to display all the addresses?
> 
> 
> -- 
> 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: wallet-tool dump doesn't show keypair with balance.

[Andreas Schildbach]

Just for information, all the addresses are derived on the fly, as they
are used. A completely unsynched wallet only has the first few addresses.


On 10/17/2017 01:47 PM, Jem wrote:
> The sync helped. Thank you for the advice. 
> 
> On 17 October 2017 at 21:41, Jem <jem.maw...@gmail.com
> <mailto:jem.maw...@gmail.com>> wrote:
> 
> No, and it's quite old. I'm running a sync now in case that helps.
> I'll report back.
> 
> But to clarify, I don't want to see the balance. I want to get the
> private key associated with the one address that I know has a
> balance. That address appears in the wallet pre-sync using the
> lloeki tool (but I can't get a valid private key using lloeki).
> 
> On 17 October 2017 at 18:40, Andreas Schildbach
> <andr...@schildbach.de <mailto:andr...@schildbach.de>> wrote:
> 
> Is the wallet fully synched?
> 
> 
> On 10/17/2017 01:41 AM, Ferrets in my Socks wrote:
> > I have decrypted my wallet created by
> > https://github.com/bitcoin-wallet/bitcoin-wallet
> <https://github.com/bitcoin-wallet/bitcoin-wallet> and inspected
> it with
> > `wallet-tool dump`. It prints 3 addresses none of which have a 
> balance.
> >
> > If I inspect it with a different tool
> > (https://github.com/lloeki/bitcoinj-wallet-dump
> <https://github.com/lloeki/bitcoinj-wallet-dump>) I can see 271
> > addresses, 3 of which are the addresses displayed by wallet-tool. 
> One of
> > the other addresses contains my current balance.
> >
> > Can I get wallet-tool to display all the addresses?
> >
> >
> > --
> > 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
> <mailto:bitcoinj%2bunsubscr...@googlegroups.com>
> > <mailto:bitcoinj+unsubscr...@googlegroups.com
> <mailto:bitcoinj%2bunsubscr...@googlegroups.com>>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
> 
> 
> --
> You received this message because you are subscribed to a topic
> in the Google Groups "bitcoinj" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/bitcoinj/vFEVI_aV9ZU/unsubscribe
> <https://groups.google.com/d/topic/bitcoinj/vFEVI_aV9ZU/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email
> to bitcoinj+unsubscr...@googlegroups.com
> <mailto:bitcoinj%2bunsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Bitcoinj's DNS Seed Addresses

[Andreas Schildbach]

On 10/12/2017 02:08 AM, Manfred Karrer wrote:

> I had the same concerns regarding Bloq's seed node addition and removed
> it from Bisq's BitcoinJ fork
> (https://github.com/bisq-network/bitcoinj/commit/7b2ed972fa09237a79388d39c49f51ee6aa17ac3).

Perhaps we should add methods for removing and adding DNS seeds from
NetworkParameters. NetworkParameters is meant to be constant, but we
could have a configuration phase before it is actually being used.

> Though there are much more problematic privacy issues with the broken
> Bloom filter implementation and design. Any full node (operated by a
> surveillance company like Skry) can find out that all wallet addresses
> belong to one user and if you don't use Tor they even know your IP address.
> 
> Unfortunately nobody is working on that to fix that.

The current plan to fix this is by full nodes offering reverse bloom
filters (or similar), if I remember this correctly. Instead of lite
clients sending their custom bloom filter to the full node, full nodes
would construct filters from their blocks and send them to the lite
clients. They would be committed to the blockchain so full nodes could
not lie.

One unsolved problem with this is this idea would not work with pending
transactions.

> The chain blindness of BitcoinJ is another major concern not addressed
> as far I know and will set BitcoinJ users at risk to spend their Bitcoin
> on a chain which they don't want to support and/or get exposed to replay
> attacks. Very concerning IMO!

I would not say bitcoinj is blind to the chain. It always follows the
chain with most accumulated work, which is a very specific chain from a
users point of view.

-- 
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: In App Payment Check (BTC)

[Andreas Schildbach]

So you system doesn't have a server side component?

Just to be clear, if you only check client side you won't keep advanced
users from accessing the paid content without paying.


On 10/11/2017 04:33 PM, Drummshot wrote:
> Hi Mates !
> 
> I'm Completely new on bitcoinj, currently I'm working in one Android
> Application where the user buy items with Bitcoin. I need check if a
> payment comes to a certain centralized wallet (the company wallet) ...
> Show a Loading/Timer While the app confirms payment transaction then
> enable purchased item on the app. I have no idea how to start this, I
> was reading "Watching wallets" section  but  I`m little lost. I'll be
> grateful If some one can give me some example or recomend a tutorial o
> explain me in some main steps what I have to do.
> 
> In advance thank you, all.
> 
> -- 
> 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: aritthmetic operations in bitcoin script for integers greater than 128 in java

[Andreas Schildbach]

Have you looked at the ScriptBuilder class? The number() method should
allow negative values.


On 10/12/2017 02:18 PM, mshikha...@gmail.com wrote:
> Hi all,
> I want to execute a simple series of instructions to implement a bitcoin
> script in java using bitcoinj API. All I am looking for is performing
> arithmetic operations for negative integers or integers greater than
> 128. An example bitcoin script for the task would look like this:
> 
> |150 120 OP_ADD 270 OP_CHECKNUMEQUAL|
> 
> This script should return True eventually. To implement this in java, to
> push integer values like 150, 270 etc i have to first convert them to
> byte arrays. I have followed answers given in Convert integer into byte
> array (Java)
> 
>  but
> none of them works in here probably because of differently defined
> arithmetic operations in bitcoinj API script. Can anyone please help me
> in this. Much thanks in advance!
> 
> Best,
> 
> -- 
> 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: Bitcoinj's DNS Seed Addresses

[Andreas Schildbach]

On 10/13/2017 03:56 AM, Manfred Karrer wrote:

> How do you deal in Android wallet with it?

Bitcoin Wallet follows the chain with the most accumulated proof of
work. Users can configure a trusted peer if they want to follow a
specific ruleset.

-- 
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: WalletAppKit - Instantiate NetworkParameters

[Andreas Schildbach]

If you're doing your own altcoin, I suggest forking the bitcoinj project
to implement the specific rules. Add a new NetworkParameters subclass
for your altcoin.


On 10/13/2017 03:45 AM, Arief Mulyana Djauhari wrote:
> HI Andreas,
> 
> In MainNetParams, how about  id field, default is  id = ID_MAINNET ,if
> we want to running our own network, what is the value of id ?
> 
> Best regards,
> 
> Arief
> 
> On Friday, October 13, 2017 at 3:25:25 AM UTC+7, Andreas Schildbach wrote:
> 
> Use MainNetParams.get() for example.
> 
> 
> On 10/12/2017 11:45 AM, Arief Mulyana Djauhari wrote:
> > HI,
> >
> > In the  WalletAppKit, we can instantiate new WalletAppKit using three
> > param  - WalletAppKit(NetworkParameters params, File directory,
> String
> > filePrefix).
> > How to instantiate NetworkParameter?
> >
> > Best Regards,
> >
> > Arief
> >
> > --
> > 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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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: Unable to load wallet after restarting application

[Andreas Schildbach]

0.13.6 is very old. Can you migrate your app to 0.14.5?


On 09/07/2017 10:27 AM, Abhishek Saini wrote:
> 
> i am using 0.13.6 version
> On Thursday, September 7, 2017 at 12:13:24 PM UTC+5:30, Abhishek Saini
> wrote:
> 
> i have created one primary wallet and its multiple addresses but my
> wallet is unable to load when i am restarting my application and all
> balance are gone.I am getting this exception
> 
> org.bitcoinj.store.UnreadableWalletException: Transaction did not
> deserialize completely:
> 1a6c029b70be0f1cc2f6f1a37ebaef5ecc189d23a32768830df821e7c6c8813e vs
> 6109fd34586a3230c2f4cfc678d33ea99a46d5d72db2a437707e72b72cfebd98
> 
> i have also tried to recover that wallet but unable to do this.I
> have searched a lot but unable to resolve this issue .I have also
> found this answer deleteing the ".spvchain" file and reboot it
> solved this,but i am unable to find this file location. Please help.
> 
> -- 
> 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: Sync too low when using BitCoinJ to create and host own wallet

[Andreas Schildbach]

What do you mean by 3rd party API? What does that API do? Bitcoinj is
designed to use the Bitcoin P2P protocol.


On 08/30/2017 04:12 AM, Alex Yang wrote:
> What I need is to create the wallet and just call 3rd party APIs to make
> the transactions.
> 
> In this case,  Do we need to set up a bitcoin node or we can just use
> bitcoinj to create a wallet and then use 3rd party APIs(The APIs will
> handle the sync etc.)? 
> 
> 在 2017年8月28日星期一 UTC+8下午11:00:25，Andreas Schildbach写道：
> 
> You will need at least one node to sync from, typically Bitcoin Core or
> some fork of it. PeerGroup automatically discovers peers and
> connects to
> a number of them.
> 
> 
> On 08/28/2017 10:57 AM, Alex Yang wrote:
> > Thanks Andreas! Do we need to install and run bitcoin-core or we just
> > need to set up the checkpointing?
> >
> > 在 2017年8月28日星期一 UTC+8下午2:38:51，Andreas Schildbach写道：
> >
> > See this document on how set up checkpointing:
> >
> > https://bitcoinj.github.io/speeding-up-chain-sync
> <https://bitcoinj.github.io/speeding-up-chain-sync>
> > <https://bitcoinj.github.io/speeding-up-chain-sync
> <https://bitcoinj.github.io/speeding-up-chain-sync>>
> >
> >
> > On 08/27/2017 07:22 PM, Alex Yang wrote:
> > > I need to use BitcoinJ to create and host wallet on my own
> website.
> > > However, it keeps downloading blocks and the sync seems taking
> > forever.
> > > I need to be able to create a wallet within a few seconds.
> > >
> > > Could anyone please advice what should i do to optimize the
> sync
> > time?
> > >
> > > |ECKey key = new ECKey(); Address addressFromKey =
> > key.toAddress(params);
> > > Wallet wallet = new Wallet(params); wallet.importKey(key); File
> > > blockFile = new File(“/tmp/bitcoinblocks”); BlockStore
> blockStore
> > = new
> > > MemoryBlockStore(params); BlockChain chain = new
> > > BlockChain(params,blockStore); PeerGroup peerGroup = new
> > > PeerGroup(params, chain); peerGroup.addPeerDiscovery(new
> > > DnsDiscovery(params)); peerGroup.addWallet(wallet);
> > peerGroup.start();
> > > peerGroup.downloadedBlockChain(); |
> > >
> > > --
> > > 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+u...@googlegroups.com
> > > <mailto:bitcoinj+u...@googlegroups.com>.
> > > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> > <https://groups.google.com/d/optout
> <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+u...@googlegroups.com
> > <mailto:bitcoinj+u...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout
> <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
> <mailto: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 create a wallet without HD mode?

[Andreas Schildbach]

On 09/05/2017 10:06 AM, Private Z wrote:
> I wanna create a wallet without HD mode. 
> But I can't find any code in the doc or example.
> Anyone can help me?

You can use Wallet.fromKeys() to create a wallet from a given set of
private keys.


-- 
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: possible causes for UnreadableWalletException: Could not connect to

[Andreas Schildbach]

What bitcoinj branch/tag/commit are you testing this on?


On 09/26/2017 05:14 PM, Fabrice Drouin wrote:
> Hi,
> 
> I'm trying to investigate a problem where wallets cannot be loaded from
> backups anymore: readWallet throws
> org.bitcoinj.wallet.UnreadableWalletException: Could not connect 
> to 
> This happens on testnet, and  cannot be found anymore. Before it
> happended, chains of unconfirmed transactions add been published (i.e
> unconfirmed transactions that spend other unconfirmed transactions.
> They're all segwit txs and cannot be malleated). I suspect that it was
> caused by a reorg but have not yet been able to reproduce the problem on
> regtest. I also don't have the bitcoinj logs...
> 
> It seems to be similar to
> https://github.com/Multibit-Legacy/multibit-hd/issues/781 for which I
> could not find much info (caused by malleated transactions ?)
> 
> Thanks,
> 
> 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.


-- 
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: Reading non wallet transactions

[Andreas Schildbach]

The problem is the Bitcoin protocol doesn't support this in the general
case. You can fetch transactions from a node's mempool, but once a
transaction is confirmed it can only be discovered by synching the
blockchain. You can use a bloom filter to and checkpoints to speed this
up. But in any case it will be a costly process, much more costly than a
simple "get" query.


On 09/22/2017 08:50 AM, KG wrote:
> Hi!
> 
> I have been searching for an answer to my question for couple of hours
> both on the internet and in code base, but couldn't quite find it.
> 
> Question is:  can I use bitcoinj to retrieve *non-wallet* transaction
> data from blockstore database? 
> For reference see this bitcoin core API to understand what I
> need: https://bitcoin.org/en/developer-reference#getrawtransaction
> 
> If it is possible could you please point me in the right direction, if
> it is not currently a feature can it be easily implemented, if so maybe
> I can do so myself (again pointer in the right direction would be
> appreciated)?
> 
> -- 
> 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.