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 :" +
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
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
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
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
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
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
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
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
10 matches
Mail list logo
