Re: Ideas for 0.15
I still did not had time to dive deeper into the bloom filter issue but I set up a bounty for a review of my changes: https://github.com/bitsquare/bitsquare/issues/487 Am Mittwoch, 18. Mai 2016 15:16:58 UTC+2 schrieb Andreas Schildbach: > > That's a great idea and yes, we should continue 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 shocked when I was reading the research papers regarding the > > bloom filters. > > I started to work on that in my branch but did not had time yet for a > > more in depth investigation. > > But fixing the most critical issues was pretty easy (though it needs a > > review and more time to be sure that it covers all edge cases). > > > > Here is a summary of my changes as well as a call for devs to help to > > improve that: > > https://github.com/bitsquare/bitsquare/issues/414 > > > > Br, > > Manfred > > > > > > Am Dienstag, 17. Mai 2016 10:21:24 UTC+2 schrieb Andreas Schildbach: > > > > Two more ideas: > > > > - Proper reject message handling, feeding into transaction > confidence. > > > > - Addr message handling, to reduce dependency on the DNS and HTTP > > seeds. > > > > > > On 05/14/2016 02:38 PM, Andreas Schildbach wrote: > > > It's time to think about what we'd like to see in bitcoinj 0.15. > > > > > > Here are some initial ideas... > > > > > > - Finish the context refactoring. I recently (re-)discovered the > plan > > > laid out by Mike for this: > > > > > > https://github.com/bitcoinj/bitcoinj/blob/master/designdocs/Contexts.md > > < > https://github.com/bitcoinj/bitcoinj/blob/master/designdocs/Contexts.md> > > > > > > > > - Migrate the build to Gradle. The main compile should be pretty > > > straightforward; but the gritty details are a bit hidden: protobuf > > > generation, deploying to binary repos, authenticating dependencies > > > > > > - Segregated Witness. Nicolas Dorier started a branch for this, > > > unfortunately it lost a bit of steam in the past weeks: > > > https://github.com/bitcoinj/bitcoinj/pull/1171 > > <https://github.com/bitcoinj/bitcoinj/pull/1171> > > > > > > - Introduce a Payments API that takes a different view on > > transactions. > > > See this (preliminary) gist: > > > https://gist.github.com/schildbach/a1c0c05e205baa229077 > > <https://gist.github.com/schildbach/a1c0c05e205baa229077> > > > > > > What do you think? > > > > > > > > > -- > > 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. > > > -- 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
Am Mittwoch, 22. Juni 2016 19:49:50 UTC+2 schrieb Andreas Schildbach: > > Hmm, I think I've seen that on a small scale, where sometimes 7 rather > than 6 peers were connected. A few peers more or less would be ok, but > 100 is a bit heavy... The longer it is offline the higher the number. > 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? > That would be great! > > I noticed your branch isn't rebased on current master (or at least a > recent 0.14 release). Any chance you can do that? > I use Java serialisation so I am unfortunately stuck with the old BitcoinJ version before Java serialisation 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 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+u...@googlegroups.com > > <mailto:bitcoinj+u...@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.
BitcoinJ gets too many connections after reconnect
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.
Re: Support for double spend in BitcoinJ?
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
never confirming tx (too low fees). So I just grab my inputs and transfer
it to a new address I control with a fee higher as the double spent tx.
public void doubleSpendTransaction(Transaction txToDoubleSpend, Address
newOutputAddress, Runnable resultHandler, ErrorMessageHandler
errorMessageHandler) throws InsufficientMoneyException {
final TransactionConfidence.ConfidenceType confidenceType =
txToDoubleSpend.getConfidence().getConfidenceType();
if (confidenceType == TransactionConfidence.ConfidenceType.PENDING) {
Transaction newTransaction = new Transaction(params);
txToDoubleSpend.getInputs().stream().forEach(input -> {
if (input.getConnectedOutput() != null &&
input.getConnectedOutput().isMine(wallet) &&
input.getConnectedOutput().getParentTransaction()
!= null && input.getValue() != null) {
newTransaction.addInput(new TransactionInput(params,
newTransaction,
new byte[]{},
new TransactionOutPoint(params,
input.getOutpoint().getIndex(),
new Transaction(params,
input.getConnectedOutput().getParentTransaction().bitcoinSerialize())),
Coin.valueOf(input.getValue().value)));
} else {
log.error("Input had null values: " + input.toString());
}
}
);
if (!newTransaction.getInputs().isEmpty() && txToDoubleSpend.getFee()
!= null) {
// We use a higher fee to be sure we get that tx confirmed
final Coin newFee =
txToDoubleSpend.getFee().add(FeePolicy.getFixedTxFeeForTrades());
newTransaction.addOutput(txToDoubleSpend.getValueSentFromMe(wallet).subtract(newFee),
newOutputAddress);
Wallet.SendRequest sendRequest =
Wallet.SendRequest.forTx(newTransaction);
sendRequest.aesKey = aesKey;
sendRequest.coinSelector = new TradeWalletCoinSelector(params,
newOutputAddress);
// We don't expect change but set it just in case
sendRequest.changeAddress = newOutputAddress;
sendRequest.feePerKb = newFee;
Wallet.SendResult sendResult = wallet.sendCoins(sendRequest);
Futures.addCallback(sendResult.broadcastComplete, new
FutureCallback() {
@Override
public void onSuccess(Transaction result) {
log.error(result.toString());
resultHandler.run();
}
@Override
public void onFailure(@NotNull Throwable t) {
errorMessageHandler.handleErrorMessage(t.getMessage());
}
});
} else {
errorMessageHandler.handleErrorMessage("We could not find inputs we
control in the transaction we want to double spend.");
}
} else if (confidenceType == TransactionConfidence.ConfidenceType.BUILDING)
{
errorMessageHandler.handleErrorMessage("That transaction is already in
the blockchain so we cannot double spend it.");
} else if (confidenceType == TransactionConfidence.ConfidenceType.DEAD) {
errorMessageHandler.handleErrorMessage("One of the inputs of that
transaction has been already double spent.");
}
}
--
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.
Question: Transaction version and Bitcoin Core 14
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.
Re: Any plans how to deal with a potential BU fork?
Do you have a link to that discussion? Am Mittwoch, 22. März 2017 14:49:15 UTC-5 schrieb Matt Corallo: > > Luke made a good observation this morning that you can do (somewhat) > compact fraud proofs of blocks > 1MB because of the structure of SHA256 > (you can provide a midstate + the last few bytes of the tx and have a > proof of each txn's length). Having a tor-based (or even public, if it > must be) service which will provide fraud proofs for blocks as proof of > which chain/currency its on is likely very doable (sadly getting nodes > to upgrade to support it now is likely difficult). > > At a minimum any wallet which is not going to do this should almost > certainly have a popup warning their users that Bitcoin is likely > splitting and they are going to be using BTU otherwise users will get > completely screwed trying to do localbitcoins and then sell on an > exchange only to find they received a different coin. > > Matt > > On 03/22/17 16:18, Andreas Schildbach wrote: > > 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 > >> bitcoinj could then offer the user to go into this mode and add certain > >> ips there. > >> > >> On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: > >> > >> A whitelist of nodes for me sounds highly conflicting with the > >> 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, Jameson Lopp > wrote: > >> > >> > >> > >> On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer > >> <manfred...@gmail.com> wrote: > >> > >> A Bitcoin core node will not mine a transaction originated > >> in a >1 MB block (not sure if it would relay it). BitcoinJ > >> has no validation of that consensus rule, so it would > accept > >> a tx from a BTU block. I think with a whitelist to connect > >> to BTC core nodes only (or better run your local node) you > >> should be safe against receiving txs from a BTU block (> > >> 1MB or built on top of a >1MB block). If BTC core does not > >> check if a tx has inputs from a >1 MB block for replaying > >> then we need to take extra care of 0 confirmation txs. > >> Does anyone here know if that is the case? > >> > >> > >> If your software ignores all unconfirmed transactions then I > >> could see a slightly stronger argument for going the whitelist > >> route. My point was that unconfirmed transactions will get > >> relayed around the network by nodes on both chain forks. > >> > >> > >> Yes I agree on the protocol level it will be hard as the > >> nodes can easily lie. > >> > >> Sure wallet providers should not have to deal with it. But > I > >> don't see much alternative. As pure wallet it might be > >> easier to tell the people just dont use yoru wallet for a > >> few days/week. But for Bitsquare as an exchange that is not > >> really an option, trading should not get stopped (and in > >> case of Bitsquare cannot really). > >> > >> Maybe 2015 people have not been so nervous about it because > >> it was before ETH demonstrated the risk and damage of a > HF
Re: Any plans how to deal with a potential BU fork?
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 > > bitcoinj could then offer the user to go into this mode and add certain > > ips there. > > > > On Wednesday, March 22, 2017 at 3:25:15 PM UTC+1, Tobias B. wrote: > > > > A whitelist of nodes for me sounds highly conflicting with the > > 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, Jameson Lopp > wrote: > > > > > > > > On Wed, Mar 22, 2017 at 1:55 AM, Manfred Karrer > > <manfred...@gmail.com> wrote: > > > > A Bitcoin core node will not mine a transaction originated > > in a >1 MB block (not sure if it would relay it). BitcoinJ > > has no validation of that consensus rule, so it would accept > > a tx from a BTU block. I think with a whitelist to connect > > to BTC core nodes only (or better run your local node) you > > should be safe against receiving txs from a BTU block (> > > 1MB or built on top of a >1MB block). If BTC core does not > > check if a tx has inputs from a >1 MB block for replaying > > then we need to take extra care of 0 confirmation txs. > > Does anyone here know if that is the case? > > > > > > If your software ignores all unconfirmed transactions then I > > could see a slightly stronger argument for going the whitelist > > route. My point was that unconfirmed transactions will get > > relayed around the network by nodes on both chain forks. > > > > > > Yes I agree on the protocol level it will be hard as the > > nodes can easily lie. > > > > Sure wallet providers should not have to deal with it. But I > > don't see much alternative. As pure wallet it might be > > easier to tell the people just dont use yoru wallet for a > > few days/week. But for Bitsquare as an exchange that is not > > really an option, trading should not get stopped (and in > > case of Bitsquare cannot really). > > > > Maybe 2015 people have not been so nervous about it because > > it was before ETH demonstrated the risk and damage of a > HF... > > > > Am Dienstag, 21. März 2017 21:42:07 UTC-5 schrieb Jameson > Lopp: > > > > I don't think replay protection can be added at the > > network level. Peers could lie about their software > > version and/or switch it, plus it's highly likely that a > > chain split won't result in a clean network partition. > > Transactions will get relayed around the network > > comprised of nodes on both chains and you can expect > > that Core nodes would still r
Re: Question: Transaction version and Bitcoin Core 14
Thanks for the clarification! Am Mittwoch, 22. März 2017 09:35:05 UTC-5 schrieb 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+u...@googlegroups.com > > <mailto:bitcoinj+u...@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?
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. >>> >>> >>> -- 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?
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: > > Andreas, how are you planning to protect users of the Android wallet > agains replay attacks? > How does a user know if she/he can send his wallet coins to a peer who > accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty > frustrated to see outgoing transactions at this wallet but not confirmation > of receipt at the receiver. > > You cannot assume that all your users are blindly following the longest > PoW chain as the only valid BTC chain and ignore the replay attack risks. > There might be even legal issues connected to it (see ETH HF and losses > from replay attacks), probably less for a wallet provider than for a > centralized exchange holding customers funds. But I am not sure if that > would not fall back to others as well (due diligence), at least people > could try to sue... > > One of the easiest solution I see is to deploy a whitelist of Bitcoin > Core nodes and use those for the P2P network connections. > You can give the user the choice to select between whitelist Bitcoin > Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public > network (if he thinks all plays out by itself and is aware of the included > risk/mess). > Of course a whitelist is not great as well but that would solve the > problem that we cannot know in advance the data which helps us to > distinguish between the chains (like blockID or certain transactions). That > whitelist only need to be used as long the HF is messy, once things have > settled it can be removed or replaced by other distinguishing data sources > like blockIds. > > If BTU implements a clean mechanism to make it easy to distinguish that > would be the best solution of course but I am not aware of any concrete > plans for such. > > > Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb 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+u...@googlegroups.com >> > <mailto:bitcoinj+u...@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, how are you planning to protect users of the Android wallet agains replay attacks? How does a user know if she/he can send his wallet coins to a peer who accepts only BTC or BTU (e.g. exchange)? Otherwise he might end up pretty frustrated to see outgoing transactions at this wallet but not confirmation of receipt at the receiver. You cannot assume that all your users are blindly following the longest PoW chain as the only valid BTC chain and ignore the replay attack risks. There might be even legal issues connected to it (see ETH HF and losses from replay attacks), probably less for a wallet provider than for a centralized exchange holding customers funds. But I am not sure if that would not fall back to others as well (due diligence), at least people could try to sue... One of the easiest solution I see is to deploy a whitelist of Bitcoin Core nodes and use those for the P2P network connections. You can give the user the choice to select between whitelist Bitcoin Core nodes (if he wants BTC), whitelist BU nodes (i he wants BTU) or public network (if he thinks all plays out by itself and is aware of the included risk/mess). Of course a whitelist is not great as well but that would solve the problem that we cannot know in advance the data which helps us to distinguish between the chains (like blockID or certain transactions). That whitelist only need to be used as long the HF is messy, once things have settled it can be removed or replaced by other distinguishing data sources like blockIds. If BTU implements a clean mechanism to make it easy to distinguish that would be the best solution of course but I am not aware of any concrete plans for such. Am Mittwoch, 15. März 2017 06:08:55 UTC-5 schrieb 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+u...@googlegroups.com > > <mailto:bitcoinj+u...@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.
Any plans how to deal with a potential BU fork?
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.
UASF
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.
Re: UASF
I agree that BIP148 is high risk and I also don't find it a good strategy, though support the basic motivation behind it. Am Dienstag, 30. Mai 2017 19:19:10 UTC+2 schrieb 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+u...@googlegroups.com > > <mailto:bitcoinj+u...@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
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.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. > Yes that would be a good idea. Also to make usage of http seed optional (there are some concerns with http seed regarding privacy as well - See Peter Todd’s replies when Mike was suggesting that). > > > 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. > I would be happy if the low hanging fruits would get fixed like: - persisting the nonce - not adding both pukKey and pukKeyHash as that reveals the real addresses I am aware that this would also not lead to perfect privacy, but it would be at least better as the current state. > > > 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. > A big problem with that is, that if miners switch between chains (as we saw with BCH/BTC) the longest PoW chain might change as well, leading to security risks and potential losses. So if today I am following the BTC chain and sending you coins and tomorrow the longest PoW chain becomes B2X then BitcoinJ will not recognise that tx anymore. In Bisq the deposit tx might get renders invalid after a chain switch and the exchange loses its primary security mechanism. I am tired of those fork attacks and don’t assume they will succeed (as all the past attempts) but it consumes valuable dev time to prepare strategies how to deal with that menace… Best would be if there would be some option in BitcoinJ to guarantee to stay on one chain (Luke DashJr has recommended one solution a few months ago at the last fork attempt. Don’t remember the details but as far I remember it was not a huge change, just a small extra check when accepting blocks/nodes). Otherwise we need to setup own BTC full nodes and use those instead of the public network. But that would render the SPV model obsolete and would turn BitcoinJ to a Electrum federated server model. To move to Bitcoin Core SPV mode is our preferred strategy to get rid of those attacks (and the latest features instantly like SegWit), but that requires much more effort and time and I am not sure how good that SPV model really works. Not looked closer so far into it... So all in all it would be great to get some solid protection from the BitcoinJ library. And forking off from Bitcoin without proper separation as an altcoin seems to be something we will see more often in future as long it is hurting the ecosystem and therefore serves as an efficient attack. 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.
Enforce BitcoinJ to follow a specific chain (BTC vs. B2X)
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 reorgs/wipeouts of past transactions (and would render a trade in Bisq insecure). Using custom nodes to connect to might be one option to stick to one chain, but that would render the P2P architecture pointless and BitcinJ would become a federated server model. Luke Dash Jr. suggested [1] to use Block 494784 [2] to let the light wallet distinguish on which chain it is. Any thoughts on that? Anyone interested to implement that in BitcoinJ? What are the strategies others are planning to use? Which projects/wallets are actually using BitconJ? I am aware of: - Andoid wallet (Schildbach wallet) - MultiBit - Mycelium - Bisq Br, Manfred [1] https://twitter.com/LukeDashjr/status/919053114912727040 [2] https://segwit2x.github.io/segwit2x-announce.html -- 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
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 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 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! Am Freitag, 29. September 2017 03:59:50 UTC-5 schrieb quantu...@gmail.com: > > I was recently made aware on Twitter than Bitcoinj updated its DNS seed > node list to include Jeff Garzik's and Bloq's nodes. I would like to know > why these were added, and why other 2x seed nodes were not. This bothers me > both because of the(though a leap to a degree) concerns over Bloq's > investment in Skry and acquiring its analytics software and techniques, and > the fact that these seed nodes are running BTC1. > > This creates two problems in my mind. 1) It opens up all users of wallets > basing off your version of Bitcoinj to be tagged and identified on a > network level by a company that has directly invested in chain analytics > company. This is a huge privacy risk for users. It also opens up the > potential to be compromised in terms of the Bitcoin network as well as the > seed nodes would decide what nodes to pass the new wallet off to. > > Which leads me to my next issue. These new seed nodes operating BTC1 > creates a huge systemic risk for users in the event the NY Agreement is > fulfilled and there is a fork in November. These new DNS seed additions > could be guaranteeing wallets are connected to both network post-fork and > cause unpredicted/detrimental behavior for users. > > I would ask that these additions be removed, and would like to know why > they were added in the first place, as they introduce two different risk > surfaces for your userbase that would not exist without them. > > Thank you for taking the time to read my concerns. > -- 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
Regarding privacy issue with Bloom filters, here are a few references: https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ https://eprint.iacr.org/2014/763.pdf https://github.com/bisq-network/exchange/issues/487 https://bisq.network/blog/privacy-in-bitsquare/ Am Mittwoch, 11. 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 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 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! > > > Am Freitag, 29. September 2017 03:59:50 UTC-5 schrieb quantu...@gmail.com: >> >> I was recently made aware on Twitter than Bitcoinj updated its DNS seed >> node list to include Jeff Garzik's and Bloq's nodes. I would like to know >> why these were added, and why other 2x seed nodes were not. This bothers me >> both because of the(though a leap to a degree) concerns over Bloq's >> investment in Skry and acquiring its analytics software and techniques, and >> the fact that these seed nodes are running BTC1. >> >> This creates two problems in my mind. 1) It opens up all users of wallets >> basing off your version of Bitcoinj to be tagged and identified on a >> network level by a company that has directly invested in chain analytics >> company. This is a huge privacy risk for users. It also opens up the >> potential to be compromised in terms of the Bitcoin network as well as the >> seed nodes would decide what nodes to pass the new wallet off to. >> >> Which leads me to my next issue. These new seed nodes operating BTC1 >> creates a huge systemic risk for users in the event the NY Agreement is >> fulfilled and there is a fork in November. These new DNS seed additions >> could be guaranteeing wallets are connected to both network post-fork and >> cause unpredicted/detrimental behavior for users. >> >> I would ask that these additions be removed, and would like to know why >> they were added in the first place, as they introduce two different risk >> surfaces for your userbase that would not exist without them. >> >> Thank you for taking the time to read my concerns. >> > -- 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
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 a few references: > > https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ > https://eprint.iacr.org/2014/763.pdf > https://github.com/bisq-network/exchange/issues/487 > https://bisq.network/blog/privacy-in-bitsquare/ > > > Am Mittwoch, 11. 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 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 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! >> >> >> Am Freitag, 29. September 2017 03:59:50 UTC-5 schrieb quantu...@gmail.com >> : >>> >>> I was recently made aware on Twitter than Bitcoinj updated its DNS seed >>> node list to include Jeff Garzik's and Bloq's nodes. I would like to know >>> why these were added, and why other 2x seed nodes were not. This bothers me >>> both because of the(though a leap to a degree) concerns over Bloq's >>> investment in Skry and acquiring its analytics software and techniques, and >>> the fact that these seed nodes are running BTC1. >>> >>> This creates two problems in my mind. 1) It opens up all users of >>> wallets basing off your version of Bitcoinj to be tagged and identified on >>> a network level by a company that has directly invested in chain analytics >>> company. This is a huge privacy risk for users. It also opens up the >>> potential to be compromised in terms of the Bitcoin network as well as the >>> seed nodes would decide what nodes to pass the new wallet off to. >>> >>> Which leads me to my next issue. These new seed nodes operating BTC1 >>> creates a huge systemic risk for users in the event the NY Agreement is >>> fulfilled and there is a fork in November. These new DNS seed additions >>> could be guaranteeing wallets are connected to both network post-fork and >>> cause unpredicted/detrimental behavior for users. >>> >>> I would ask that these additions be removed, and would like to know why >>> they were added in the first place, as they introduce two different risk >>> surfaces for your userbase that would not exist without them. >>> >>> Thank you for taking the time to read my concerns. >>> >> -- 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.
Is MIN_NONDUST_OUTPUT in master up to date?
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 dust output is 546 sat for non-segwit outputs. Is the REFERENCE_DEFAULT_MIN_TX_FEE the min relay fee in Bitcoin Core? In release-0.13 the REFERENCE_DEFAULT_MIN_TX_FEE was increased from 1000 to 5000: https://github.com/bitcoinj/bitcoinj/blob/release-0.13/core/src/main/java/org/bitcoinj/core/Transaction.java public static final Coin REFERENCE_DEFAULT_MIN_TX_FEE = Coin.valueOf(5000); // satoshis public static final Coin MIN_NONDUST_OUTPUT = Coin.valueOf(2730); // satoshis In release-0.14 and current master it was reverted to the previous values: https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/Transaction.java public static final Coin REFERENCE_DEFAULT_MIN_TX_FEE = Coin.valueOf(1000); // 0.01 mBTC public static final Coin MIN_NONDUST_OUTPUT = Coin.valueOf(546); // satoshis -- 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.
TX broadcast failures
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 hear back from the full nodes or do not notify the listener. I have seen in the master branch that support for version 2 transactions has been added which seems to be at least in one case the reason for the problems as I got warnings in the logs reagarding non-standard and unrecognized version nr., but I have seen other cases where that does not seem to be the cause. Any idea what can cause those problems? I assume it is related to unconfirmed txs used for the inputs and BitcoinJ seems to not call the onConfidenceChanged. Typical logs for a tx which gets broadcasted: Dec-28 15:49:50.451 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Waiting for 7 peers required for broadcast, we have 9 ... Dec-28 15:49:50.451 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: We have 9 peers, adding 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 to the memory pool Dec-28 15:49:50.451 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Sending to 5 peers, will wait for 2, sending to: [mxdtrjhe2yfsx3pg.onion]:8333,[3r44ddzjitznyahw.onion]:8333,[c6ac4jdfyeiakex2.onion]:8333,[sjyzmwwu6diiit3r.onion]:8333,[vlf5i3grro3wux24.onion]:8333 Dec-28 15:49:53.585 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: SEEN_PEERS: TX 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 seen by 1 peers Dec-28 15:49:53.631 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: SEEN_PEERS: TX 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 seen by 2 peers Dec-28 15:49:53.631 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 complete Dec-28 15:49:53.632 [JavaFX Application Thread] INFO o.b.w.Wallet: Received a pending transaction 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 that spends 0.005153 BTC from our own wallet, and sends us 0.003731 BTC Dec-28 15:49:53.632 [JavaFX Application Thread] INFO o.b.w.Wallet: commitTx of 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 Dec-28 15:49:53.633 [JavaFX Application Thread] INFO o.b.w.Wallet: marked 24ca182732bb3ca386dd2aa5ea4f9bd3223319862b5d35b7c8d10a58ff1ff5d5:2 as spent by 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 Dec-28 15:49:53.633 [JavaFX Application Thread] INFO o.b.w.Wallet: ->pending: 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 Dec-28 15:49:53.634 [JavaFX Application Thread] INFO o.b.w.Wallet: Estimated balance is now: 0.005731 BTC Dec-28 15:49:53.635 [JavaFX Application Thread] INFO o.b.w.WalletFiles: Saving wallet; last seen block is height 501436, date 2017-12-28T15:47:16Z, hash 001ef574fe2b15a338b53da3fa0ce60e3e5695b384192685 Dec-28 15:49:53.731 [JavaFX Application Thread] INFO o.b.w.WalletFiles: Save completed in 95.79 ms Dec-28 15:49:53.789 [JavaFX Application Thread] INFO i.b.c.b.w.BtcWalletService: swap addressEntry with address 15JSW1Ki2hqbi2ugg42LtewXGc7pJnoCsa and offerId V6W7W86-0166f8d9-7c2b-4490-b005-cef0a18eed7d-062 from context OFFER_FUNDING to available Dec-28 15:49:53.790 [JavaFX Application Thread] INFO i.b.c.t.TaskRunner: Run task: AddOfferOfferBook Typical logs for a tx which fails to get broadcasted (broadcastTransaction: SEEN_PEERS never called): Jan-02 04:10:59.891 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Waiting for 7 peers required for broadcast, we have 9 ... Jan-02 04:10:59.892 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: We have 9 peers, adding 42c98fc9ce2622f2aeae65828639c6389cf573c4e97600c2c28652d687b9a00a to the memory pool Jan-02 04:10:59.892 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Sending to 5 peers, will wait for 2, sending to: [4jyh6llqj264oggs.onion]:8333,[c6ac4jdfyeiakex2.onion]:8333,[sjyzmwwu6diiit3r.onion]:8333,[fz6nsij6jiyuwlsc.onion]:8333,[i3a5xtzfm4xwtybd.onion]:8333 Jan-02 04:11:03.922 [BlockingClient network thread for mxdtrjhe2yfsx3pg.onion:8333] INFO o.b.core.Peer: [mxdtrjhe2yfsx3pg.onion]:8333: Downloading dependencies of 42c98fc9ce2622f2aeae65828639c6389cf573c4e97600c2c28652d687b9a00a Jan-02 04:11:04.515 [BlockingClient network thread for mxdtrjhe2yfsx3pg.onion:8333] INFO o.b.core.Peer: [mxdtrjhe2yfsx3pg.onion]:8333: Downloaded dependency of 42c98fc9ce2622f2aeae65828639c6389cf573c4e97600c2c28652d687b9a00a: 09b9765de45cc7be1d4bb9c78b161900d2d7a6bf997421996ddaa3c439d1443b Jan-02 04:11:04.515 [BlockingClient network thread for
Tx broadcast failures
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 hear back from the full nodes or do not notify the listener. I have seen in the master branch that support for version 2 transactions has been added which seems to be at least in one case the reason for the problems as I got warnings in the logs reagarding non-standard and unrecognized version nr., but I have seen other cases where that does not seem to be the cause. Any idea what can cause those problems? I assume it is related to unconfirmed txs used for the inputs and BitcoinJ seems to not call the onConfidenceChanged. Typical logs for a tx which gets broadcasted: Dec-28 15:49:50.451 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Waiting for 7 peers required for broadcast, we have 9 ... Dec-28 15:49:50.451 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: We have 9 peers, adding 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 to the memory pool Dec-28 15:49:50.451 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Sending to 5 peers, will wait for 2, sending to: [mxdtrjhe2yfsx3pg.onion]:8333,[3r44ddzjitznyahw.onion]:8333,[c6ac4jdfyeiakex2.onion]:8333,[sjyzmwwu6diiit3r.onion]:8333,[vlf5i3grro3wux24.onion]:8333 Dec-28 15:49:53.585 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: SEEN_PEERS: TX 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 seen by 1 peers Dec-28 15:49:53.631 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: SEEN_PEERS: TX 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 seen by 2 peers Dec-28 15:49:53.631 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 complete Dec-28 15:49:53.632 [JavaFX Application Thread] INFO o.b.w.Wallet: Received a pending transaction 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 that spends 0.005153 BTC from our own wallet, and sends us 0.003731 BTC Dec-28 15:49:53.632 [JavaFX Application Thread] INFO o.b.w.Wallet: commitTx of 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 Dec-28 15:49:53.633 [JavaFX Application Thread] INFO o.b.w.Wallet: marked 24ca182732bb3ca386dd2aa5ea4f9bd3223319862b5d35b7c8d10a58ff1ff5d5:2 as spent by 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 Dec-28 15:49:53.633 [JavaFX Application Thread] INFO o.b.w.Wallet: ->pending: 227c6310c01094ba57df6dd2f303a453389fa5b5c31bd752dc2946ca747456a5 Dec-28 15:49:53.634 [JavaFX Application Thread] INFO o.b.w.Wallet: Estimated balance is now: 0.005731 BTC Dec-28 15:49:53.635 [JavaFX Application Thread] INFO o.b.w.WalletFiles: Saving wallet; last seen block is height 501436, date 2017-12-28T15:47:16Z, hash 001ef574fe2b15a338b53da3fa0ce60e3e5695b384192685 Dec-28 15:49:53.731 [JavaFX Application Thread] INFO o.b.w.WalletFiles: Save completed in 95.79 ms Dec-28 15:49:53.789 [JavaFX Application Thread] INFO i.b.c.b.w.BtcWalletService: swap addressEntry with address 15JSW1Ki2hqbi2ugg42LtewXGc7pJnoCsa and offerId V6W7W86-0166f8d9-7c2b-4490-b005-cef0a18eed7d-062 from context OFFER_FUNDING to available Dec-28 15:49:53.790 [JavaFX Application Thread] INFO i.b.c.t.TaskRunner: Run task: AddOfferOfferBook Typical logs for a tx which fails to get broadcasted (broadcastTransaction: SEEN_PEERS never called): Jan-02 04:10:59.891 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Waiting for 7 peers required for broadcast, we have 9 ... Jan-02 04:10:59.892 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: broadcastTransaction: We have 9 peers, adding 42c98fc9ce2622f2aeae65828639c6389cf573c4e97600c2c28652d687b9a00a to the memory pool Jan-02 04:10:59.892 [JavaFX Application Thread] INFO o.b.c.TransactionBroadcast: Sending to 5 peers, will wait for 2, sending to: [4jyh6llqj264oggs.onion]:8333,[c6ac4jdfyeiakex2.onion]:8333,[sjyzmwwu6diiit3r.onion]:8333,[fz6nsij6jiyuwlsc.onion]:8333,[i3a5xtzfm4xwtybd.onion]:8333 Jan-02 04:11:03.922 [BlockingClient network thread for mxdtrjhe2yfsx3pg.onion:8333] INFO o.b.core.Peer: [mxdtrjhe2yfsx3pg.onion]:8333: Downloading dependencies of 42c98fc9ce2622f2aeae65828639c6389cf573c4e97600c2c28652d687b9a00a Jan-02 04:11:04.515 [BlockingClient network thread for mxdtrjhe2yfsx3pg.onion:8333] INFO o.b.core.Peer: [mxdtrjhe2yfsx3pg.onion]:8333: Downloaded dependency of 42c98fc9ce2622f2aeae65828639c6389cf573c4e97600c2c28652d687b9a00a: 09b9765de45cc7be1d4bb9c78b161900d2d7a6bf997421996ddaa3c439d1443b Jan-02 04:11:04.515 [BlockingClient network thread for
How to get the block date for a confirmed transaction?
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. 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.
Why are old changes from master not in the release branches?
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" (https://github.com/bitcoinj/bitcoinj/commit/3177bd52a2bfa491c5902e95b8840030e1a31159) which affects tons of classes and make a merge from the release version with the changes in master very time consuming. Is there any reason for that? Any plans to sync the release with master? -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why are old changes from master not in the release branches?
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 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" ( > https://github.com/bitcoinj/bitcoinj/commit/3177bd52a2bfa491c5902e95b8840030e1a31159) > > which affects tons of classes and make a merge from the release version > with the changes in master very time consuming. > Is there any reason for that? > Any plans to sync the release with master? > -- 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 block date for a confirmed transaction?
At Transaction.setBlockAppearance it states:
"Sets updatedAt to be the earliest valid block time where this tx was seen."
But the method:
public void setUpdateTime(Date updatedAt) {
this.updatedAt = updatedAt;
}
is called by the wallet.commit method thus the date is set once hte tx is
created and committed to the wallet.
The check at Transaction.setBlockAppearance
if (bestChain && (updatedAt == null || updatedAt.getTime() == 0 ||
updatedAt.getTime() > blockTime)) {
updatedAt = new Date(blockTime);
}
will cause that the block update time will not be applied as the updatedAt
time is earlier as the block time.
It seems the code wants to handle casss with orphans but does not consider
the wallet commit call.
Am Freitag, 12. Januar 2018 05:52:19 UTC-5 schrieb Andreas Schildbach:
>
> You can use Transaction.getUpdateTime() if you know 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:
> >
> > 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.
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 block date for a confirmed transaction?
> 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 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. > 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: Download stalled at 91MB at testnet
After further testing I could isolate the issue to be between v14.4. and v.14.5. Bisq is based on 14.4. After comparing and I found that the checkpoint files was causing the issue. After updating it from 14.5. it works. Any idea why? I got those logs in the "broken" version: 00:09:44 26 AbstractBlockChain.add: Block does not connect: 0001c7ea71d37675ab53ee77851d46bcd2688077343eeccda4d50570 prev ff74c2f0973e6b9eb0fa6f9033ee093dc38e7cbec52b7cc5ef41 00:09:45 26 AbstractBlockChain.tryConnectingOrphans: Connected orphan 0001c7ea71d37675ab53ee77851d46bcd2688077343eeccda4d50570 00:09:45 26 AbstractBlockChain.tryConnectingOrphans: Connected 1 orphan blocks. maybe thats related... Am Dienstag, 4. Dezember 2018 17:18:35 UTC+1 schrieb Andreas Schildbach: > > The stall messages are just a symptom. For finding the cause have a look > at 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. > > > > Am Montag, 3. Dezember 2018 23:12:33 UTC+1 schrieb Jameson Lopp: > > > > H I believe I ran into similar issues a while back - have you > > tried whitelisting the IP of your bitcoinj client in the Bitcoin > > Core conf? > > > > I also vaguely recall getting stalled connections from time to time > > and adding logic in my app to hack around it by disconnecting and > > reconnecting. > > > > On Sun, Dec 2, 2018 at 4:51 PM Manfred Karrer > > > wrote: > > > > Here is a bug report form a user as > > well: https://github.com/bisq-network/bisq/issues/1823 > > <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 > > <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 Bitcoin Core running in testnet and > > starting a new BitcoinJ instance (Bisq, using latest > > BitcoinJ release) I get download stalled at 91MB (as seen in > > Bictoin Core debug window) then gets disconnected from > > Bitcoin Core and then reconnects but gets very low > > bandwidth. Seems Bitcoin Core added some ddos protection. I > > never observed that in earlier versions. Does anyone know > > how to avoid that issue? > > > > With mainet it seems even lower, about 7,8 MB. > > > > I can reproduce that with each fresh start (deleting Bisq > > app directory so it starts as new node again). > > > > 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. > > 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+u...@googlegroups.com > > <mailto:bitcoinj+u...@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: Download stalled at 91MB at testnet
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 Bitcoin Core running in testnet and starting a new > BitcoinJ instance (Bisq, using latest BitcoinJ release) I get download > stalled at 91MB (as seen in Bictoin Core debug window) then gets > disconnected from Bitcoin Core and then reconnects but gets very low > bandwidth. Seems Bitcoin Core added some ddos protection. I never observed > that in earlier versions. Does anyone know how to avoid that issue? > > With mainet it seems even lower, about 7,8 MB. > > I can reproduce that with each fresh start (deleting Bisq app directory so > it starts as new node again). > > 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.
Re: Download stalled at 91MB at testnet
Giving myself the answer ;-): It seems that the heavy loading of so many blockheaders just consumed a lot o CPU and that caused that bas user experience to have the startup getting stalled. With a newly created up to date checkpoint file the initial download is not super fast. 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 between v14.4. and > v.14.5. Bisq is based on 14.4. After comparing and I found that the > checkpoint files was causing the issue. After updating it from 14.5. it > works. Any idea why? > > I got those logs in the "broken" version: > 00:09:44 26 AbstractBlockChain.add: Block does not connect: > 0001c7ea71d37675ab53ee77851d46bcd2688077343eeccda4d50570 prev > ff74c2f0973e6b9eb0fa6f9033ee093dc38e7cbec52b7cc5ef41 > 00:09:45 26 AbstractBlockChain.tryConnectingOrphans: Connected orphan > 0001c7ea71d37675ab53ee77851d46bcd2688077343eeccda4d50570 > 00:09:45 26 AbstractBlockChain.tryConnectingOrphans: Connected 1 orphan > blocks. > > maybe thats related... > > Am Dienstag, 4. Dezember 2018 17:18:35 UTC+1 schrieb Andreas Schildbach: >> >> The stall messages are just a symptom. For finding the cause have a look >> at 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. >> > >> > Am Montag, 3. Dezember 2018 23:12:33 UTC+1 schrieb Jameson Lopp: >> > >> > H I believe I ran into similar issues a while back - have you >> > tried whitelisting the IP of your bitcoinj client in the Bitcoin >> > Core conf? >> > >> > I also vaguely recall getting stalled connections from time to time >> > and adding logic in my app to hack around it by disconnecting and >> > reconnecting. >> > >> > On Sun, Dec 2, 2018 at 4:51 PM Manfred Karrer >> >> > wrote: >> > >> > Here is a bug report form a user as >> > well: https://github.com/bisq-network/bisq/issues/1823 >> > <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 >> > <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 Bitcoin Core running in testnet and >> > starting a new BitcoinJ instance (Bisq, using latest >> > BitcoinJ release) I get download stalled at 91MB (as seen >> in >> > Bictoin Core debug window) then gets disconnected from >> > Bitcoin Core and then reconnects but gets very low >> > bandwidth. Seems Bitcoin Core added some ddos protection. I >> > never observed that in earlier versions. Does anyone know >> > how to avoid that issue? >> > >> > With mainet it seems even lower, about 7,8 MB. >> > >> > I can reproduce that with each fresh start (deleting Bisq >> > app directory so it starts as new node again). >> > >> > 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. >> > 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+u...@googlegroups.com >> > <mailto:bitcoinj+u...@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.15
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 Segregated Witness! You can create > P2WPKH keychains and receive to, spend from and send to Bech32 > addresses. There are also lots of smaller enhancements like Peer > learning the recently introduced service bits. Or MonetaryFormat > making use of the Unicode Bitcoin symbol. Also, building has been > improved by migrating to Gradle and making sure everything builds > under Java 11 (but you can still use Java 7 for the core module). > > For a thorough list of changes, have a look at the release notes [1] > and the git log [2]. > > The v0.15 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. > > Thanks go to Bloq (for sponsoring my work), GitHub (for hosting our > git repository and issue management) and Travis (for running > continuous integration on every commit and PR). > > [1] https://bitcoinj.github.io/release-notes#version-015 > [2] https://github.com/bitcoinj/bitcoinj/commits/release-0.15 > [3] https://bitcoin.org/andreas_schildbach.asc > [4] https://bitcoinj.github.io/using-gradle > https://bitcoinj.github.io/using-maven > > -- > 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: Branch/Freeze for 0.15 incoming!
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 -- if there are no objections -- branch > the codebase off for 0.15. The release-0.15 branch will then be frozen > for new features and only receive patches meant for > stabilization/bigfixes. I hope to be able to release 0.15 by the end of > the month. > > -- > 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.
