Coin spending for Proof of Existence

[Ramez Az]

I am trying to implement the Proof of Existence using below code.

NetworkParameters params = TestNet3Params.get();
WalletAppKit kit = new WalletAppKit(params, new File("."), "wallettest");
   kit.startAsync();
   kit.awaitRunning();
   System.out.println("Wallet Balance :" + kit.wallet().getBalance());
   System.out.println("Wallet :" + kit.wallet().toString());
   Coin amount = Coin.parseCoin("0");
   Sha256Hash hash3 = Sha256Hash.of(doc);
   System.out.println("Before sending hash doc"+hash3.toString());
// Create a tx with an OP_RETURN output
   Transaction tx = new Transaction(params);
   tx.addOutput(amount, 
ScriptBuilder.createOpReturnScript(hash3.getBytes()));
   Wallet.SendResult result = 
kit.wallet().sendCoins(kit.peerGroup(),SendRequest.forTx(tx));
  System.out.println("coins sent. transaction hash: " + 
result.tx.getHashAsString());

I am able to execute the code and transaction get posted in testnet and 
below is the URL where we can see my transaction.

https://testnet.blockexplorer.com/tx/346f5aab325efe0bb54f6f7e9fc36816129d08027c2815851cf64a111c67cdfc

In this transaction, the transaction is got completed by deducting the 
mining fee from one address in the wallet(which is selected by bitcoinj API 
by default) and the remaining value is getting transferred to different 
address within the same wallet. Can i know why it is transferring the 
remaining amount to the different address and can we restrict so that only 
the mining fee will get deducted.

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

[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 relay transactions to
you that were originally broadcast by Unlimited nodes and vice versa.

At a more philosophical level, I'm not so sure that the onus is on every
wallet provider to implement protection against contentious hard forks. You
could have made similar arguments that BitcoinJ should have added replay
protection when support for 8MB blocks was nearing 50% hashrate back in
2015.

On Tue, Mar 21, 2017 at 8:28 PM, Manfred Karrer 
wrote:

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

[Manfred Karrer]

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

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

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

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

[Patrick McCorry]

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

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

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

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

[Matt Corallo]

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

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