ntinue to work on bugfixes and
> improvements of the existing features! If anyone wants to help out, I'm
> happy to review PRs.
>
>
> On 05/17/2016 11:26 AM, Manfred Karrer wrote:
> > Fixing or at least improving the bloomfilters would be very important
> > IMO. I got shocke
n support was removed.
I plan later to change to Protobuffer but that will take some more time,
but after that I can catch up to the current version again.
>
> On 06/16/2016 02:40 PM, Manfred Karrer wrote:
> > BitcoinJ gets too many connections after a reconnect as it adds up a
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.
Thanks for your recommendation. I implemented it now and it seems it works
like expected (still testing). Please note that I have a bit different use
case as usual replace by fee style txs. I need to "unlock" inputs which
were use for a trade MultiSig tx where the other users inputs come from a
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
> >> decentralized nature of bitcoin. Also what if nodes switch their
> >> software? Not that unlikely in case they notice that their minority
> >> chain is dying.
> >>
> >> On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameso
rity
> > chain is dying.
> >
> > On Wednesday, March 22, 2017 at 1:28:09 PM UTC+1, Jameson Lopp
> wrote:
> >
> >
> >
> > On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer
> > <manfred...@gmail.com> wrote:
> >
> &g
gt;
>
> 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 fo
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
Btw. of course the whitelist can be set by the user himself, so if he runs
a full node he can use that.
But knowing that the majority of users are not running their own full node
we need alternative solutions as well.
Am Dienstag, 21. März 2017 19:23:56 UTC-5 schrieb Manfred Karrer
s 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 0
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
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.
ut 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 c
Am Donnerstag, 12. Oktober 2017 12:49:25 UTC-5 schrieb 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.co
The risk the users get exposed if following the longest PoW chain is not
acceptable at least in the case for Bisq (P2P exchange using 2of3 MultiSig
to secure the trade).
If both chains have similar hash power and miners switch between chains the
longest PoW would change, leading to massive
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).
Though there are much more problematic privacy issues with the broken Bloom
filter implementation and
. Oktober 2017 19:08:00 UTC-5 schrieb Manfred Karrer:
>
> 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
> ).
>
> Though there are
Background about Bloq's acquisition of Skry:
http://www.nasdaq.com/article/bloq-acquires-skry-supercharges-blockchain-analytics-with-ai-and-machine-learning-cm754603
Am Mittwoch, 11. Oktober 2017 19:10:44 UTC-5 schrieb Manfred Karrer:
>
> Regarding privacy issue with Bloom filters, here are
I just stumbled over a change of MIN_NONDUST_OUTPUT in release 0.13 which
got reverted in 0.14.
(https://github.com/bitcoinj/bitcoinj/commit/470cda4ccf4eb1ec1bacce6ec00a3bf2faf44715#diff-25a7d8851e54b470509e6fc28323aa8b)
What was the reason for that?
And is the actual version correct? E.g. min
We get in Bisq since roughly 1-2 month repeated issues with tx broadcasts.
The onConfidenceChanged is never called at the ConfidenceChange listener in
TransactionBroadcast which leads then to timeouts in the trade protocol. The
transaction gets successfully broadcasted though BitcoinJ does not
We get in Bisq since roughly 1-2 month repeated issues with tx broadcasts.
The onConfidenceChanged is never called at the ConfidenceChange listener in
TransactionBroadcast which leads then to timeouts in the trade protocol.
The transaction gets successfully broadcasted though BitcoinJ does not
What is the best way to access the date when the block containing a
transaction was mined?
With:
final StoredBlock storedBlock = vChain.getBlockStore().get(tx.getHash());
the storedBlock is null.
--
You received this message because you are subscribed to the Google Groups
"bitcoinj" group.
I wanted to merge the v2 tx support changes to our fork based on release
0.14.4 but I see that there are many old trivial changes like "Add a
generic copyright
statement"
(https://github.com/bitcoinj/bitcoinj/commit/3773a4343c53634f3bc8ab24eff16ecb31109aa6)
or "use generic type"
Another question:
Is the master branch tested sufficiently to be considered safe or it is a
pure dev branch where more profound testing is done only in releases?
Am Dienstag, 9. Januar 2018 14:58:00 UTC+1 schrieb Manfred Karrer:
>
> I wanted to merge the v2 tx support changes to our fork
w a tx is confirmed
> (see its confidence to know that).
>
>
> On 01/09/2018 11:27 PM, Manfred Karrer wrote:
> > What is the best way to access the date when the block containing a
> > transaction was mined?
> >
> > With:
> >
> &g
> On 12 Jan 2018, at 11:51, Andreas Schildbach <andr...@schildbach.de> wrote:
>
> You can use Transaction.getUpdateTime() if you know a tx is confirmed
> (see its confidence to know that).
Thanks!
>
>
> On 01/09/2018 11:27 PM, Manfred Karrer wrote:
>> What i
the logfile of both bitcoinj and Bitcoin Core.
>
>
> On 04/12/2018 00.12, Manfred Karrer wrote:
> > I use whitelist=127.0.0.1 in the bitcoin.conf file. There was another
> > property but that does require the port as well and we use random local
> > ports.
> >
&g
Here is a bug report form a user as
well: https://github.com/bisq-network/bisq/issues/1823
Here is the fork we are using:
https://github.com/bisq-network/bitcoinj/commits/bisq_0.14.4.1
Am Sonntag, 2. Dezember 2018 18:53:49 UTC+1 schrieb Manfred Karrer:
>
> When having latest Bitcoi
.
There are probably a few minor issues like the disconnection from the local
node, the orphan (seems an block processing ordering issue) and the logs
not being clear...
Am Donnerstag, 6. Dezember 2018 00:27:24 UTC+1 schrieb Manfred Karrer:
>
> After further testing I could isolate the issue to be b
Congrats! Great to see the release!
> On 2 Mar 2019, at 03:44, Andreas Schildbach wrote:
>
> I'm pleased to announce the release of bitcoinj 0.15! This release
> represents about 30 months of work by more than 100 contributors:
> thanks to you all!
>
> The main theme of this release is
Ah great news!
> On 2 Feb 2019, at 23:14, Andreas Schildbach wrote:
>
> I've spent the last couple of weeks finishing off support for native
> segwit. Please have a look at this PR; feedback welcome!
>
> https://github.com/bitcoinj/bitcoinj/pull/1563
>
> I plan to merge this soon and --
32 matches
Mail list logo
