Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-08-30 Thread Christian Decker via bitcoin-dev
Thanks for the update Johnson, just wanted to give a really quick NACK
on the SIGHASH_NOINPUT variant: the whole idea of BIP 118 is to have
floating transactions that can be bound to predecessors, and still
enforce some application logic. In eltoo's case this is the fact that
the state number needs to be smaller than the state number of the
transaction that is being rewritten. The state number that we bind to is
part of the `scriptPubKey`, so we can't commit to the `scriptPubKey` in
the signature since we don't know which output (and thus it's
scriptPubKey`) is at the time we sign.

If we are committing to `scriptPubKey` this whole way of enforcing order
in updates is no longer possible, and the only thing we actually get
from this change is a (very weak) malleability fix. The same argument
goes for `scriptCode`.

Cheers,
Christian

Johnson Lau  writes:
> After gathering some feedbacks I substantially revised the proposal. This 
> version focus on improving security, and reduces the number of optional 
> features.
>
> Formatted BIP and sample code at:
> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
> https://github.com/jl2012/bitcoin/commits/sighash2
>
> The major new features compared with BIP143:
>
> 1. If signing all inputs, also sign all input value. BIP143 signature only 
> covers the value of the same input. In some cases this may not be adequate 
> for hardware wallet to determine the right amount of fees. Signing all input 
> values will secure any possible case.
> 2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin 
> design, previous scriptPubKey is signed as the scriptCode. However, this is 
> not the case with P2SH and segwit. Explicitly committing to the scriptPubKey 
> allows hardware wallet to confirm what it is actually signing (e.g. 
> P2SH-segwit vs. Native-segwit).
> 3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to 
> both scriptCode and scriptPubKey. This prevents signature replay if the same 
> public key is used in different scripts.
> 4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range 
> case.
> 5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
> 6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index 
> output. Described by gmaxwell at 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html 
> 
> 7. Signing the amount of fees (optional, yes by default). In case of not 
> signing all inputs or outputs, users may still want to commit to a specific 
> fee amount.
> 8. Signing the witness size (optional, yes by default). While segwit fixed 
> txid malleability, it is not a fix of script malleability. It may cause some 
> trouble if an attacker could bloat the witness and reduce the fee priority of 
> a transaction. Although the witness size is not malleable for most simple 
> scripts, this is not guaranteed for more complex ones. Such kind of size 
> malleability could be avoided if signatures commit to the size of witness.
>
> Any suggestions are welcomed. But I have the following questions:
>
> 1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it 
> should, because that helps avoid signature replay in some cases, and also 
> lets hardware wallets know what they are signing. I am asking this because 
> BIP118 proposes the opposite. I want to make sure I’m not missing something 
> here.
> 2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, an 
> example use case is kickstarter, where individual supporters send money to 
> the last output for a kickstarter project, and send change to the matched 
> output. However, I doubt if this would be actually used this way, because the 
> kickstarter organiser could always take the money before the target is met, 
> by making up the difference with his own input. This is an inherent problem 
> for any anonymous kickstarter scheme. If these new SIGHASHs are not useful in 
> other applications, I am not sure if we should add them.
> 3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully 
> flexible way to sign a subset of outputs? The indexes of signed outputs are 
> put at the end of the signature, and the signature won’t commit to these 
> index values. Therefore, a third party could collect all transactions of this 
> kind and merge them into one transaction. To limit the sighash cost, number 
> of signed outputs might not be more than 2 or 3. Some potential problems: a) 
> code complexity; b) 1-byte or 2-byte index: 1-byte will limit the number of 
> outputs to 256. 2-byte will use more space even for smaller txs; c) highly 
> variable signature size makes witness size estimation more difficult
> 4. Should we sign the exact witness size (as proposed), or an upper size 
> limit? Signing an upper limit will take up more space, as the limit has to be 
> explicitly shown 

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-08-30 Thread Johnson Lau via bitcoin-dev
After gathering some feedbacks I substantially revised the proposal. This 
version focus on improving security, and reduces the number of optional 
features.

Formatted BIP and sample code at:
https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki
https://github.com/jl2012/bitcoin/commits/sighash2

The major new features compared with BIP143:

1. If signing all inputs, also sign all input value. BIP143 signature only 
covers the value of the same input. In some cases this may not be adequate for 
hardware wallet to determine the right amount of fees. Signing all input values 
will secure any possible case.
2. Sign both scriptCode and previous scriptPubKey. In the original bitcoin 
design, previous scriptPubKey is signed as the scriptCode. However, this is not 
the case with P2SH and segwit. Explicitly committing to the scriptPubKey allows 
hardware wallet to confirm what it is actually signing (e.g. P2SH-segwit vs. 
Native-segwit).
3. SIGHASH2_NOINPUT: basically same as BIP118, but the signature commits to 
both scriptCode and scriptPubKey. This prevents signature replay if the same 
public key is used in different scripts.
4. SIGHASH2_MATCHOUTPUT (previously SIGHASH_SINGLE) disallows out-of-range case.
5. SIGHASH2_LASTOUTPUT: signs only the highest index output.
6. SIGHASH2_DUALOUTPUT: signs the matched output and the highest index output. 
Described by gmaxwell at 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016188.html 

7. Signing the amount of fees (optional, yes by default). In case of not 
signing all inputs or outputs, users may still want to commit to a specific fee 
amount.
8. Signing the witness size (optional, yes by default). While segwit fixed txid 
malleability, it is not a fix of script malleability. It may cause some trouble 
if an attacker could bloat the witness and reduce the fee priority of a 
transaction. Although the witness size is not malleable for most simple 
scripts, this is not guaranteed for more complex ones. Such kind of size 
malleability could be avoided if signatures commit to the size of witness.

Any suggestions are welcomed. But I have the following questions:

1. Should NOINPUT commit to scriptCode and/or scriptPubKey? I think it should, 
because that helps avoid signature replay in some cases, and also lets hardware 
wallets know what they are signing. I am asking this because BIP118 proposes 
the opposite. I want to make sure I’m not missing something here.
2. Do we want to add LASTOUTPUT and DUALOUTPUT? Suggested by gmaxwell, an 
example use case is kickstarter, where individual supporters send money to the 
last output for a kickstarter project, and send change to the matched output. 
However, I doubt if this would be actually used this way, because the 
kickstarter organiser could always take the money before the target is met, by 
making up the difference with his own input. This is an inherent problem for 
any anonymous kickstarter scheme. If these new SIGHASHs are not useful in other 
applications, I am not sure if we should add them.
3. Instead of these restrictive MATCH/LAST/DUALOUTPUT, do we want a fully 
flexible way to sign a subset of outputs? The indexes of signed outputs are put 
at the end of the signature, and the signature won’t commit to these index 
values. Therefore, a third party could collect all transactions of this kind 
and merge them into one transaction. To limit the sighash cost, number of 
signed outputs might not be more than 2 or 3. Some potential problems: a) code 
complexity; b) 1-byte or 2-byte index: 1-byte will limit the number of outputs 
to 256. 2-byte will use more space even for smaller txs; c) highly variable 
signature size makes witness size estimation more difficult
4. Should we sign the exact witness size (as proposed), or an upper size limit? 
Signing an upper limit will take up more space, as the limit has to be 
explicitly shown in the witness. The overhead could be avoided by showing the 
limit only if the actual witness size is not equal to the committed limit. 
However, I tend to keep it simple and sign the exact value. If in a multi-sig 
setup some signers are unable to accurately estimate the witness size, they 
should leave this responsibility to the last signer who should know the exact 
size.


> On 1 Jun 2018, at 2:35 AM, Johnson Lau via bitcoin-dev 
>  wrote:
> 
> Since 2016, I have made a number of proposals for the next generation of 
> script. Since then, there has been a lot of exciting development on this 
> topic. The most notable ones are Taproot and Graftroot proposed by Maxwell. 
> It seems the most logical way is to implement MAST and other new script 
> functions inside Taproot and/or Graftroot. Therefore, I substantially 
> simplified my earlier proposal on SIGHASH2. It is a superset of the existing 
> SIGHASH and the BIP118 SIGHASH_NOINPUT, with further flexibility but not 
> being 

Re: [bitcoin-dev] Testnet3 Reest

2018-08-30 Thread Johnson Lau via bitcoin-dev
A public testnet is still useful so in articles people could make references to 
these transactions.

Maybe we could have 2 testnets at the same time, with one having a smaller 
block size?

> On 31 Aug 2018, at 4:02 AM, Peter Todd via bitcoin-dev 
>  wrote:
> 
> Signed PGP part
> On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev 
> wrote:
>> Hi,
>> 
>> Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
>> 
>> Is a testnet reset scheduled in the next release or any reason not to do a
>> reset ?
>> 
>> Fast onboarding/lower disk overheads would be  very much appreicated for
>> testing purposes
> 
> Actually I'd advocate the opposite: I'd want testnet to be a *larger*
> blockchain than mainnet to find size-related issues first.
> 
> Note that for testing regtest is often a better alternative, and you can setup
> private regtest blockchains fairly easily and with good control over exactly
> when and how blocks are created.
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 
> 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Testnet3 Reest

2018-08-30 Thread Jimmy Song via bitcoin-dev
Stupid question time:

Why don't we have multiple testnets?

On Thu, Aug 30, 2018 at 3:31 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev
> wrote:
> > Hi,
> >
> > Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
> >
> > Is a testnet reset scheduled in the next release or any reason not to do
> a
> > reset ?
> >
> > Fast onboarding/lower disk overheads would be  very much appreicated for
> > testing purposes
>
> Actually I'd advocate the opposite: I'd want testnet to be a *larger*
> blockchain than mainnet to find size-related issues first.
>
> Note that for testing regtest is often a better alternative, and you can
> setup
> private regtest blockchains fairly easily and with good control over
> exactly
> when and how blocks are created.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

2018-08-30 Thread Bram Cohen via bitcoin-dev
This seems like a case where a distinction should be made between soft
forks which are likely to cause non-upgraded miners to get orphaned and
ones where they are. Of course in this case it's only 1/2016 of all blocks
so it doesn't really matter, but it's worth thinking about the principle.
In general soft forks are better when they don't cause orphaning on
non-upgraded miners.

The whole problem seems to be caused by the difference between the
timestamps at the end of a period and the block right after it. Soft
forking to force those to be 'close enough' together sounds like a solid
approach. Given that blocks are generally send around fairly quickly, and
that blocks more than two hours in the future are ignored, it seems
reasonable to not allow a backwards jump of that plus some safety
parameter. Let's say three hours. It also feels like a good idea to not
allow a jump of more than three hours forwards either, just on principle.

That should result in minimal code changes, and rarely any orphaning of
non-upgraded miners at all, and still only 1/2016 blocks when they do. And
no trace of a hard fork. It suffers from still allowing the attack a little
bit, but three hours out of every two weeks seems like no big deal.

On Sat, Aug 25, 2018 at 5:10 AM Johnson Lau via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> To determine the new difficulty, it is supposed to compare the timestamps
> of block (2016n - 1) with block (2016n - 2017). However, an off-by-one bug
> makes it compares with block (2016n - 2016) instead.
>
> A naive but perfect fix is to require every block (2016x) to have a
> timestamp not smaller than that of its parent block. However, a chain-split
> would happen even without any attack, unless super-majority of miners are
> enforcing the new rules. This also involves mandatory upgrade of pool
> software (cf. pool software upgrade is not mandatory for segwit). The best
> way is to do it with something like BIP34, which also requires new pool
> software.
>
> We could have a weaker version of this, to require the timestamp of block
> (2016x) not smaller than its parent block by t-seconds, with 0 <= t <=
> infinity. With a bigger t, the fix is less effective but also less likely
> to cause intentional/unintentional split. Status quo is t = infinity.
>
> Reducing the value of t is a softfork. The aim is to find a t which is
> small-enough-to-prohibit-time-wrap-attack but also
> big-enough-to-avoid-split. With t=86400 (one day), a time-wrap attacker may
> bring down the difficulty by about 1/14 = 7.1% per round. Unless new blocks
> were coming incredibly slow, the attacker needs to manipulate the MTP for
> at least 24 hours, or try to rewrite 24 hours of history. Such scale of 51%
> attack is already above the 100-block coinbase maturity safety theshold and
> we are facing a much bigger problem.
>
> With t=86400, a non-majority, opportunistic attacker may split the chain
> only if we have no new block for at least 24 - 2 = 22 hours (2-hours is the
> protocol limit for using a future timestamp) at the exact moment of
> retarget. That means no retarget is possible in the next 2016 blocks. Doing
> a time-wrap attack at this point is not quite interesting as the coin is
> probably already worthless. Again, this is a much bigger problem than the
> potential chain spilt. People will yell for a difficulty (and time wrap
> fix, maybe) hardfork to resuscitate the chain.
>
>
>
>
> > On 21 Aug 2018, at 4:14 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
> > difficulty calculation was vulnerable to gaming with inaccurate
> > timestamps to massively increase the rate of block production beyond
> > the system's intentional design. It can be fixed with a soft-fork that
> > further constraints block timestamps, and a couple of proposals have
> > been floated along these lines.
> >
> > I put a demonstration of timewarp early in the testnet3 chain to also
> > let people test mitigations against that.  It pegs the difficulty way
> > down and then churned out blocks at the maximum rate that the median
> > time protocol rule allows.
> >
> > I, and I assume others, haven't put a big priority into fixing this
> > vulnerability because it requires a majority hashrate and could easily
> > be blocked if someone started using it.
> >
> > But there haven't been too many other network consensus rules going on
> > right now, and I believe at least several of the proposals suggested
> > are fully compatible with existing behaviour and only trigger in the
> > presence of exceptional circumstances-- e.g. a timewarp attack.  So
> > the risk of deploying these mitigations would be minimal.
> >
> > Before I dust off my old fix and perhaps prematurely cause fixation on
> > a particular approach, I thought it would be useful to ask the list if
> > anyone else was aware of a favourite backwards compatible timewarp 

Re: [bitcoin-dev] Testnet3 Reest

2018-08-30 Thread Peter Todd via bitcoin-dev
On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev wrote:
> Hi,
> 
> Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
> 
> Is a testnet reset scheduled in the next release or any reason not to do a
> reset ?
> 
> Fast onboarding/lower disk overheads would be  very much appreicated for
> testing purposes

Actually I'd advocate the opposite: I'd want testnet to be a *larger*
blockchain than mainnet to find size-related issues first.

Note that for testing regtest is often a better alternative, and you can setup
private regtest blockchains fairly easily and with good control over exactly
when and how blocks are created.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

2018-08-30 Thread Ryan Havar via bitcoin-dev
I've just finished writing an implementing of this, and extremely happy with 
how it turned out. So I'd like to go and try go down the path of more formally 
describing it and getting some comments and ultimately encourage its 
wide-spread use.

==Abstract==

The way bitcoin transactions are overwhelming used is known to leak more
information than desirable. This has lead to fungibility concerns in bitcoin
and a raise of unreasonably effective blockchain analysis.

Bustapay proposes a simple, practical way to bust these assumptions to immediate
benefit of the sender and recievers. Furthermore it does so in such a way that
helps recievers avoid utxo bloat, a constant problem for bitcoin merchants.

==Copyright==

This BIP is in the public domain.

==Motivation==

One of the most powerful heuristic's employed by those whose goal is to 
undermine
bitcoin's fungiblity has been to assume all inputs of a transaction are signed 
by
a single party. In the few cases this assumption does not hold, it is generally
readibly recognizable (e.g. traditional coinjoins have a very obvious structure,
or multisig outputs are most frequently validated onchain).

Bustapay requires no changes to bitcoin and creates bitcoin transactions that 
are
indistinguishable from normal ones.

It is worth noting that this specification has been intentionally kept as simple
as possible to encourage adoption. There are almost an endless amount of 
extensions
possible but the harder the implementation of clients/server the less likely it
will ever be done. Should bustapay enjoy widespread adoption, a "v2" 
specification
will be created with desired extensions.

==Specification==

A bustapay payment is made from a sender to a receiver.

Step 1. Sender creates a bitcoin transaction paying the receiver

This transaction must be fully valid, signed and all inputs must use segwit. 
This transaction is known as the "template transaction". This transaction must 
not be propagated on the bitcoin network.

Step 2. Sender gives the "template transaction" to the receiver

This would generally be done as an HTTP POST. The exact URL to submit it to 
could be specified with a bip21 encoded address. Such as 
bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit
 and the HTTP body should be the raw transaction hex encoded as text.

Step 3. Receiver processes the transaction and returns a partially signed 
coinjoin

The receiver validates the transaction is valid, pays himself and is eligible 
for propation. The receiver then adds one of his own inputs (known as the 
"contributed input") and increase the output that pays himself by the 
contributed input amount. Doing so will invalidate the "template transaction"'s 
original input signatures, so the sender needs to return this "partial 
transaction" back to the receiver to sign. This is returned as a hex-encoded 
raw transaction a response to the original HTTP POST request.

Step 4. Receiver validates, re-signs, and propagates on the bitcoin network

The receiver is responsible in making sure the "partial transaction" returned 
by the sender was changed correctly (it should assume the connection has been 
MITM'd and act accordingly), resign its original inputs and propagates this 
transaction over the bitcoin network. The client must be aware that the server 
can reorder inputs and outputs.

Step 5. Receiver observes the finalized transaction on the bitcoin network

Once the receiver has seen the finalized transactions on the network (and has 
enough confirmations) it can process it like a normal payment for the sent 
amount (as opposed to the amount that it looks like on the network). If the 
receiver does not see the finalized transaction after a timeout will propagate 
the original "template transaction" to ensure the payment happens and function 
a strong anti-DoS mechanism.

=== Implementation Notes ===
For anyone wanting to implement bustapay payments, here are some notes for 
receivers:

* A transaction can easily be checked if it's suitable for the mempool with 
testmempoolaccept in bitcoin core 0.17
* Tracking transactions by txid is precarious. To keep your sanity make sure 
all inputs are segwit. But remember segwit does not prevent txid malleability 
unless you validate the transaction. So really make sure you're using 
testmempoolaccept at the very least
* Bustapay could be abused by a malicious party to query if you own a deposit 
address or not. So never accept a bustapay transaction that pays an already 
used deposit address
* You will need to keep a mapping of which utxos people have showed you and 
which you revealed. So if you see them again, you can reveal the same one of 
your own
* Check if the transaction was already sorted according to BIP69, if so ensure 
the result stays that way. Otherwise probably just shuffle the inputs/outpus

Notes for sending applications:

* The HTTP response must *not* be trusted. It should be fully validated that no 
unexpected 

Re: [bitcoin-dev] Building a Bitcoin API and query system.

2018-08-30 Thread Blockchain Group via bitcoin-dev
Thanks, I'll check it out.

On Thu, Aug 30, 2018, 3:33 PM Aymeric Vitte  wrote:

>
>
> Le 28/08/2018 à 20:36, Jonas Schnelli via bitcoin-dev a écrit :
> > I’d like to hear some concrete use-cases for a such block explorer(ish)
> API.
>
> https://github.com/Ayms/bitcoin-transactions which is somewhere
> bitcoin-cli outside of bitcoin core with no wallet, which implies that
> you don't want to mix/provide your wallet with/to the app creating your
> transactions and/or you don't want to use wallet sw
>
> Problem: quasi nobody succeeds to use it (and probably this trend is
> unlikely to revert), that's why there is https://peersm.com/wallet which
> is querying the info outside and output the right command to use with
> the tool (or output the transaction if people put their keys, which is
> of course not advised unless they are sure that the corresponding
> addresses are dead ones)
>
> It is planned to put the app for the advanced mode (ie people must know
> all the parameters) as an offline one inside browsers, then back to the
> above problem...
>
> So probably the offline mode should include a phase where the tool
> connects to some APIs/explorers like the one suggested here before
> switching to the offline mode to enter the keys, this will always be not
> very secure for the query phase unless it can become something
> decentralized (and usable the same way on different networks), which as
> far as I understand is envisioned here
>
> --
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Building a Bitcoin API and query system.

2018-08-30 Thread Aymeric Vitte via bitcoin-dev


Le 28/08/2018 à 20:36, Jonas Schnelli via bitcoin-dev a écrit :
> I’d like to hear some concrete use-cases for a such block explorer(ish) API.

https://github.com/Ayms/bitcoin-transactions which is somewhere
bitcoin-cli outside of bitcoin core with no wallet, which implies that
you don't want to mix/provide your wallet with/to the app creating your
transactions and/or you don't want to use wallet sw

Problem: quasi nobody succeeds to use it (and probably this trend is
unlikely to revert), that's why there is https://peersm.com/wallet which
is querying the info outside and output the right command to use with
the tool (or output the transaction if people put their keys, which is
of course not advised unless they are sure that the corresponding
addresses are dead ones)

It is planned to put the app for the advanced mode (ie people must know
all the parameters) as an offline one inside browsers, then back to the
above problem...

So probably the offline mode should include a phase where the tool
connects to some APIs/explorers like the one suggested here before
switching to the offline mode to enter the keys, this will always be not
very secure for the query phase unless it can become something
decentralized (and usable the same way on different networks), which as
far as I understand is envisioned here

-- 
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Testnet3 Reest

2018-08-30 Thread shiva sitamraju via bitcoin-dev
Hi,

Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.

Is a testnet reset scheduled in the next release or any reason not to do a
reset ?

Fast onboarding/lower disk overheads would be  very much appreicated for
testing purposes

Regards


-- 
Shiva S
CEO @ Blockonomics 
Decentralized and Permissionless Payments
Join us on Telegram 
View our Welcome Guide

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev