[bitcoin-dev] BIP70 is dead. What now?

2021-02-19 Thread Thomas Voegtlin via bitcoin-dev
I never liked BIP70. It was too complex, had too many features, and when
people discuss it, they do not even agree on what the main feature was.

Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
that payment requests were signed. I am making this post to discuss this.

When I send bitcoins to an exchange, I would like to receive a signed
request. I want to have a proof that the exchange asked me to send coins
to that address, in case it has been hijacked by some intern working
there. If that feature was implemented by an exchange, it would guide my
decision to use that exchange over its competitors.

I do not think that a single exchange ever implemented that, but I guess
this is because BIP70 is a terrible standard. LN payment requests are
signed, do not require SSL, do not require interactivity, and therefore
exchanges use them. Can't we achieve the same for on-chain payments? Is
anyone working on that?

I would be more than happy to remove BIP70 support from Electrum, if
there was another standard for signed requests.

Thomas

-- 
Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

2020-05-23 Thread Thomas Voegtlin via bitcoin-dev
Hello list,

I have been trying to CPFP a transaction using OP_RETURN, because the
remaining output value would have been lower than the dust threshold.

The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
single p2wsh input.

The result is a 60 bytes transaction (without witness), that gets
rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
is equal to 82 bytes.

Why is that value so high? Would it make sense to lower it to 60?


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


[bitcoin-dev] JSONRPC vulnerability in Electrum 2.6 to 3.0.4

2018-01-10 Thread Thomas Voegtlin via bitcoin-dev
A vulnerability has been found in Electrum, and patched in version
3.0.5. Please update your software if you are running an earlier version.

The following is a copy of the summary and guidelines we posted on our
website: https://github.com/spesmilo/electrum-docs/blob/master/cve.rst

A CVE number for the issue has been requested 2 days ago, and has not
been attributed yet.



JSONRPC vulnerability in Electrum 2.6 to 3.0.4
==

On January 6th, a vulnerability was disclosed in the Electrum wallet
software, that allows malicious websites to execute wallet commands
through JSONRPC executed in a web browser. The bug affects versions
2.6 to 3.0.4 of Electrum, on all platforms. It also affects clones of
Electrum such as Electron Cash.


Can funds be stolen?


Wallets that are not password protected are at risk of theft, if they
are opened with a version of Electrum older than 3.0.5 while a web
browser is active.

In addition, the vulnerability allows an attacker to modify user
settings, the list of contacts in a wallet, and the "payto" and
"amount" fields of the user interface while Electrum is running.

Although there is no known occurrence of Bitcoin theft occurring
because of this vulnerability, the risk increases substantially now
that the vulnerability has been made public.


Can wallet data be leaked?
--

Yes, an attacker can obtain private data, such as: Bitcoin addresses,
transaction labels, address labels, wallet contacts and master public
keys.


Can a password-protected wallet be bruteforced?
---

Not realistically. The vulnerability does not allow an attacker to
access encrypted seed or private keys, which would be needed in order
to perform an efficient brute force attack. Without the encrypted
seed, an attacker must try passwords using the JSONRPC interface,
while the user is visiting a malicious page. This is several orders of
magnitude slower than an attack with the encrypted seed, and
restricted in time. Even a weak password will protect against that.


What should users do?
-

All users should upgrade their Electrum software, and stop using old
versions.

Users who did not protect their wallet with a password should create a
new wallet, and move their funds to that wallet. Even if it never
received any funds, a wallet without password should not be used
anymore, because its seed might have been compromised.

In addition, users should review their settings, and delete all
contacts from their contacts list, because the Bitcoin addresses of
their contacts might have been modified.


How to upgrade Electrum
---

Stop running any version of Electrum older than 3.0.5, and install
Electrum the most recent version. On desktop, make sure you download
Electrum from https://electrum.org and no other website. On Android,
the most recent version is available in Google Play.

If Electrum 3.0.5 (or any later version) cannot be installed or does
not work on your computer, stop using Electrum on that computer, and
access your funds from a device that can run Electrum 3.0.5. If you
really need to use an older version of Electrum, for example in order
to access wallet seed, make sure that your computer is offline, and
that no web browser is running on the computer at the same time.


Should all users move their funds to a new address?
---

We do not recommend moving funds from password protected wallets. For
wallets that were not password protected, moving funds is an extreme
precaution, that might not be necessary; indeed, if a wallet was
compromised, it is very likely that the attacker would have stolen the
funds immediately.


When was the issue reported and fixed?
--

The absence of password protection in the JSONRPC interface was
reported on November 25th, 2017 by user jsmad:
https://github.com/spesmilo/electrum/issues/3374

jsmad's report was about the Electrum daemon, a piece of software that
runs on web servers and is used by merchants in order to receive
Bitcoin payments. In that context, connections to the daemon from the
outside world must be explicitly authorized, by setting 'rpchost' and
'rpcport' in the Electrum configuration.

On January 6th, 2018, Tavis Ormandy demonstrated that the JSONRPC
interface could be exploited against the Electrum GUI, and that the
attack could be carried out by a web browser running locally, visiting
a webpage with specially crafted JavaScript.

We released a new version (3.0.4) in the hours following Tavis' post,
with a patch written by mithrandi (Debian packager), that addressed
the attack demonstrated by Tavis. In addition, the Github issue
remained open, because mithrandi's patch was not adding password
protection to the JSONRPC interface.

Shortly after the 3.0.4 release we started to work on adding proper
password 

[bitcoin-dev] Electrum 3.0 release

2017-11-02 Thread Thomas Voegtlin via bitcoin-dev
Electrum 3.0 was tagged and released yesterday night.

Release notes:

# Release 3.0 - Uncanny Valley (November 1st, 2017)

  * The project was migrated to Python3 and Qt5. Python2 is no longer
supported. If you cloned the source repository, you will need to
run "python3 setup.py install" in order to install the new
dependencies.

  * Segwit support:

- Native segwit scripts are supported using a new type of
  seed. The version number for segwit seeds is 0x100. The install
  wizard will not create segwit seeds by default; users must
  opt-in with the segwit option.

- Native segwit scripts are represented using bech32 addresses,
  following BIP173. Please note that BIP173 is still in draft
  status, and that other wallets/websites may not support
  it. Thus, you should keep a non-segwit wallet in order to be
  able to receive bitcoins during the transition period. If BIP173
  ends up being rejected or substantially modified, your wallet
  may have to be restored from seed. This will not affect funds
  sent to bech32 addresses, and it will not affect the capacity of
  Electrum to spend these funds.

- Segwit scripts embedded in p2sh are supported with hardware
  wallets or bip39 seeds. To create a segwit-in-p2sh wallet,
  trezor/ledger users will need to enter a BIP49 derivation path.

- The BIP32 master keys of segwit wallets are serialized using new
  version numbers. The new version numbers encode the script type,
  and they result in the following prefixes:

 * xpub/xprv : p2pkh or p2sh
 * ypub/yprv : p2wpkh-in-p2sh
 * Ypub/Yprv : p2wsh-in-p2sh
 * zpub/zprv : p2wpkh
 * Zpub/Zprv : p2wsh

  These values are identical for mainnet and testnet; tpub/tprv
  prefixes are no longer used in testnet wallets.

- The Wallet Import Format (WIF) is similarly extended for segwit
  scripts. After a base58-encoded key is decoded to binary, its
  first byte encodes the script type:

 * 128 + 0: p2pkh
 * 128 + 1: p2wpkh
 * 128 + 2: p2wpkh-in-p2sh
 * 128 + 5: p2sh
 * 128 + 6: p2wsh
 * 128 + 7: p2wsh-in-p2sh

  The distinction between p2sh and p2pkh in private key means that
  it is not possible to import a p2sh private key and associate it
  to a p2pkh address.

  * A new version of the Electrum protocol is required by the client
(version 1.1). Servers using older versions of the protocol will
not be displayed in the GUI.

  * By default, transactions are time-locked to the height of the
current block. Other values of locktime may be passed using the
command line.





-- 
Electrum Technologies GmbH / Waldemarstr 37a / 10999 Berlin / Germany
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
Geschäftsführer: Thomas Voegtlin
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] proposal: extend WIF format for segwit

2017-09-17 Thread Thomas Voegtlin via bitcoin-dev
On 17.09.2017 04:29, Pieter Wuille wrote:
> 
> This has been a low-priority thing for me, though, and the computation work
> to find a good checksum is significant.
> 

Thanks for the info. I guess this means that a bech32 format for private
keys is not going to happen soon. Even if such a format was available,
the issue would remain for segwit-in-p2sh addresses, which use base58.

The ambiguity of the WIF format is currently holding me from releasing a
segwit-capable version of Electrum. I believe it is not acceptable to
use the current WIF format with segwit scripts; that would just create
technological debt, forcing wallets to try all possible scripts. There
is a good reason why WIF adds a 0x01 byte for compressed pubkeys; it
makes it unambiguous.

I see only two options:
 1. Disable private keys export in Electrum Segwit wallets, until a
common WIF extension has been agreed on.
 2. Define my own WIF extension for Electrum, and go ahead with it.

Defining my own format does make sense for the xpub/xprv format, because
Electrum users need to share master public keys across Electrum wallets.
It makes much less sense for WIF, though, because WIF is mostly used to
import/sweep keys from other wallets.

I would love to know what other wallet developers are going to do,
especially Core. Are you going to export private keys used in segwit
scripts in the current WIF format?

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


[bitcoin-dev] proposal: extend WIF format for segwit

2017-09-15 Thread Thomas Voegtlin via bitcoin-dev
The Wallet Import Format (WIF) currently appends a 0x01 byte after the
raw private key, when that key needs to be used in conjunction with a
compressed public key. This allows wallets to associate a single Bitcoin
address to a WIF key.

It would be useful to extend the semantics of that byte, to signal for
segwit scripts, because these scripts result in different addresses.
That way, a WIF private key can still be associated to a single Bitcoin
address.

What WIF currently does is:

Nothing -> uncompressed pubkey
0x01-> compressed pubkeys, non-segwit (can be used in P2PKH or P2SH)

We could extend it as follows:

0x02 -> segwit script embedded in P2SH (P2WPKH or P2WSH)
0x03 -> native segwit script (P2WKH or P2WSH)


Note 1: This is similar to my {x,y,z}{pub,prv} proposal for bip32
extended keys. (see other thread)

Note 2: It is probably not useful to use distinct bytes for P2WKH and
P2WSH, because the P2SH script is not known anyway. We did not do it for
non-segwit addresses, I guess we should keep it the way it is.

Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.

Note 4: my proposal will not result in a user visible change at the
beginning of the string, like we have for compressed/uncompressed. This
could be improved.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32

2017-09-12 Thread Thomas Voegtlin via bitcoin-dev


On 09.09.2017 16:08, shiva sitamraju via bitcoin-dev wrote:
> Hi,
> 
> I understand the motivation of adding the birthdate field. However, not
> very comfortable with having this in the public key serialization. There
> are privacy implication of both the birthday field and having the complete
> derivation path, which takes space.
> > I am fine with Thomas proposal of {x,y,z}. Having additional version byte
> field looks modular but since since we already have the big enough version
> field in bip32, better to use that instead of adding more bytes.
> 
> Thomas, can you please explain why we require different version for P2WPKH
> or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that they
> would have the same output bitcoin address and under same account.

no, native scripts do not have the same address. see bip173


> 
> On Fri, Sep 8, 2017 at 2:09 AM, <
> bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:
> 
>> Send bitcoin-dev mailing list submissions to
>> bitcoin-dev@lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>> bitcoin-dev-requ...@lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>> bitcoin-dev-ow...@lists.linuxfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Proposal: Extended serialization format for   BIP-32
>>   wallets (Andreas Schildbach)
>>2. Re: Proposal: Extended serialization format for BIP-32
>>   wallets (Pavol Rusnak)
>>3. Re: Fast Merkle Trees (Mark Friedenbach)
>>4. Re: Proposal: Extended serialization format for BIP-32
>>   wallets (Thomas Voegtlin)
>>
>>
>> --
>>
>> Message: 1
>> Date: Thu, 7 Sep 2017 21:35:49 +0200
>> From: Andreas Schildbach <andr...@schildbach.de>
>> To: bitcoin-dev@lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>> BIP-32 wallets
>> Message-ID: <oos72e$rjp$1...@blaine.gmane.org>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
>>> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>>>> A solution is still needed to wallets who do not wish to use BIP43
>>>
>>> What if we added another byte field OutputType for wallets that do not
>>> follow BIP43?
>>>
>>> 0x00 - P2PKH output type
>>> 0x01 - P2WPKH-in-P2SH output type
>>> 0x02 - native Segwit output type
>>>
>>> Would that work for you?
>>
>> I think that would work.
>>
>>> The question is whether this field should be present only if depth==0x00
>>> or at all times. What is your suggestion, Thomas?
>>
>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
>> we need this field. I think it should always be present if a chain is
>> limited to a certain script type.
>>
>> There is however the case where even on one chain, script types are
>> mixed. In this case the field should be omitted and the wallet needs to
>> scan for all (known) types. Afaik Bitcoin Core is taking this path.
>>
>>
>>
>> --
>>
>> Message: 2
>> Date: Thu, 7 Sep 2017 22:00:05 +0200
>> From: Pavol Rusnak <st...@satoshilabs.com>
>> To: Andreas Schildbach <andr...@schildbach.de>, Bitcoin Protocol
>> Discussion <bitcoin-dev@lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>> BIP-32 wallets
>> Message-ID: <40ed03a1-915c-33b0-c4ac-e898c8c73...@satoshilabs.com>
>> Content-Type: text/plain; charset=windows-1252
>>
>> On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
>>> In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
>>> we need this field.
>>
>> But the depth of exported public key will be null. It does not make
>> sense to export xpub for m or m/0' for your particular case.
>>
>>> I think it should always be present if a chain is
>>> limited to a certain script type.
>>
>> I am fine with having the path there all the time.
>

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

2017-09-07 Thread Thomas Voegtlin via bitcoin-dev


On 07.09.2017 18:23, Pavol Rusnak wrote:
> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>> A solution is still needed to wallets who do not wish to use BIP43
> 
> What if we added another byte field OutputType for wallets that do not
> follow BIP43?
> 
> 0x00 - P2PKH output type
> 0x01 - P2WPKH-in-P2SH output type
> 0x02 - native Segwit output type
> 
> Would that work for you?
> 
> The question is whether this field should be present only if depth==0x00
> or at all times. What is your suggestion, Thomas?
> 


well, in my initial proposal, I wrote that this value should be user
visible. That is why I used version bytes. If you create an extra byte
field, and then use base58 or bech32 encoding, the value will not be
user visible anymore.

The initial implementation of segwit xpub/xprv in Electrum used a flag
that was not user visible (I added 1 to the bip32 version bytes, which
leaves the xpub/xprv prefix unchanged). I have experimented with that
invisible flag for more than 6 months now, and I am now convinced that
it is better to make that flag user visible.

The reason is that when users create wallets with multisig scripts, they
need to combine several master public keys. However, these master public
keys should all be of the same type: it would not make sense to create a
2 of 3 multisig wallet with a one xpub, one ypub and one zpub. By
imposing that all master keys are of the same type, we ensure that all
cosigners agree on the script type that will be used to derive addresses.

In other words, if users are exposed to master keys and need to
manipulate them, it is better to let them see what they are doing.

OTOH if you do not plan to expose your users to these keys, you probably
do not need a serialization format.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

2017-09-06 Thread Thomas Voegtlin via bitcoin-dev


On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev wrote:
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
> 
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
> 
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
> 
> Feel free to comment.
> 


Your proposal forces wallets to use the derivation path in order to
determine the type of output script. it will work only in the context of
BIP43.

Therefore, it should not be proposed as a BIP32 improvement, but as a
improvement of BIP43.

A solution is still needed to wallets who do not wish to use BIP43
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

2017-09-06 Thread Thomas Voegtlin via bitcoin-dev


On 05.09.2017 21:00, Kabuto Samourai wrote:
> 
> The Electrum approach is nice but may not go far enough, as xpub and zpub
> both list "P2PKH or P2SH." Why not expand the number of version prefixes to
> eliminate the ambiguity?
> 

I agree that this would make sense if we had done it from the start.
However, fixing that now might be difficult.

My "xyz" proposal extends the current format in a way that is very easy
to deploy, because existing software will require minimal changes.
However, if we eliminate the p2sh ambiguity now, wallets will need to
add extra safeguards, in order to prevent scenarios that are currently
allowed, and they will need to handle legacy xpub/xprv differently than
ypub and zpub. This would take much more time to deploy.

In addition, consensus might be more difficult to reach on that; I guess
not all developers will not agree that removing that ambiguity is
useful. Since there is an infinity of possible P2SH scripts, it will
never be possible to remove ambiguity from a master key associated to a
P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
strong.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

2017-09-05 Thread Thomas Voegtlin via bitcoin-dev


On 05.09.2017 19:03, Luke Dashjr wrote:

> It seems desirable to use the same seed for all different script formats...

That does not seem desirable to everybody.

If you want to guarantee that users will be able to recover all their
funds from their mnemonic seed (and that is what they expect), then
wallets must implement all script formats, even the ones that are
deprecated. In addition, the list of script formats that must be
supported is not defined in advance, but it keeps growing. This makes
wallet implementation increasingly difficult. In the long run, seed
portability is guaranteed to fail in such a system.

> As you note, xpub\xprv are already being used for both P2PKH and P2SH. It 
> really doesn't make sense to differentiate segwit specifically.

That's not a reason. The fact that xpub/xprv can be used for both P2PKH
and P2SH has already resulted in users receiving coins on addresses they
do not control.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] BIP49 Derivation scheme changes

2017-09-05 Thread Thomas Voegtlin via bitcoin-dev


On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> Hi,
> 
> Thanks Thomas. The procedure described in
> http://docs.electrum.org/en/latest/seedphrase.html is really what I was
> looking for ! I really don't see any point of following BIP49, If possible
> it would be great if you can propose an alternative to BIP49 that follows
> similar structure to what is used in electrum.
> 
> I have proposed following changes to BIP32 serialization format
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format
> to differentiate segwit xpub/xprv. Below the list of new version bytes,
> resulting base58 prefix and network type:
> 
> 0x042393df ,  sxpr ,   segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb ,  segwit testnet public key
> 0x042224cc ,  stpr ,  segwit testnet private key
> 

I have proposed a similar idea, with letters z,y,z combined with pub/prv
(see the electrum documentation page)

The point is that we need 3 types of keys, not 2, because there are two
types of segwit output scripts: native and nested in p2sh.

We could use t,u,v for testnet.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

2017-09-05 Thread Thomas Voegtlin via bitcoin-dev
BIP32 extended public/private keys have version bytes that result in the
user visible xpub/xprv prefix. The BIP's recommendation is to use
different version bytes for other networks (such as tpub/tprv for testnet)

I would like to use additional version bytes to indicate the type of
output script used with the public keys.

I believe the change should be user visible, because users are exposed
to master public keys. I propose the following prefixes:

== === ===
VersionPrefix  Description
== === ===
0x0488ade4 xprvP2PKH or P2SH
0x0488b21e xpubP2PKH or P2SH
0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
0x04b2430c zprvP2WPKH or P2WSH
0x04b24746 zpubP2WPKH or P2WSH
== === ===
(source: http://docs.electrum.org/en/latest/seedphrase.html)

I have heard the argument that xpub/xprv serialization is a format for
keys, and that it should not be used to encode how these keys are used.
However, the very existence of version bytes, and the fact that they are
used to signal whether keys will be used on testnet or mainnet goes
against that argument.

If we do not signal the script type in the version bytes, I believe
wallet developers are going to use dirtier tricks, such as the bip32
child number field in combination with bip43/bip44/bip49.


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


Re: [bitcoin-dev] BIP49 Derivation scheme changes

2017-09-02 Thread Thomas Voegtlin via bitcoin-dev


On 30.08.2017 09:24, shiva sitamraju via bitcoin-dev wrote:

> 
> 2. Segwit wallet seed words have a different format which is incompatible
> with previous wallet seed words. This  encodes the information that this
> wallet is segwit in the seed words itself. We need to define a structure
> for this
> 

That is what Electrum does.
See http://docs.electrum.org/en/latest/seedphrase.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] BIP proposal for Lightning-oriented multiaccount multisig HD wallets

2017-08-30 Thread Thomas Voegtlin via bitcoin-dev


On 29.08.2017 12:19, Simone Bronzini via bitcoin-dev wrote:

> 2. SegWit addresses:
> since mixing SegWit and non-SegWit addresses on the same BIP44 structure
> could lead to UTXOs not being completely recognised by old wallets,
> BIP49 was proposed to separate the key space. 

This will lead to old UTXOs not being recognized by NEW wallets, because
at some point new wallets will not care about implementing old standards.

The only way to address this is to get out of bip39 and bip43, and to
include a version number in the mnemonic seed.

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


Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling

2017-04-13 Thread Thomas Voegtlin via bitcoin-dev
I think it is better not to use the coinbase, because it might collide
with other proposals, and because coinbase is not part of the block header.

I agree that a small set of standard threshold may be sufficient; a one
percent resolution is probably not needed. If we use 4 bits we can
encode 15 different thresholds + zero (meaning no support). For example
we can have all thresholds between 25% and 95% separated by 5%.

Using 4 bits per soft-fork proposal leaves enough room to fit 7
simultaneous proposals in version bits. That should be plenty.

> 
> I still like the coinbase idea though - more than using up the BIP9 
> versionbits range for verbose signaling.
> 
> BIP9 (and other proposals which use those 29 versionbits) currently assume 
> that the participants on the network will coordinate in some form or other, 
> to agree on what the bits mean (in terms of change deployments).
> 
> It would be very easy to also agree on a set of "standard" threshold levels 
> and map those onto e.g. 1 byte.
> 
> Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. 
> "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are 
> standardized deployment schedules that people find useful.
> So a BIP9 conformant schedule could be A = 95% / 2016 window,
> while B = 75%/2016, etc.
> 
> This would be quite a compact yet still readable signaling. The space of 
> values is large enough that I doubt we'd see much contention.
> 
> Regards
> Sancho
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Proposal: Soft Fork Threshold Signaling

2017-04-13 Thread Thomas Voegtlin via bitcoin-dev
Hi Sancho,

I saw your proposal. However, my point is that the threshold should be
part of the signaling, and not fixed in the soft-fork proposal.

I agree that coinbase space might be a limitation.

To avoid this, I realize that the threshold could be encoded in the
version bits. We have 32 version bits, and the top 3 bits must be set to
001 in BIP9. In order to extend BIP9 in a backward compatible way, we
could set these 3 top bits to 010, and use the 29 remaining bits for
soft fork signaling.

If we use 7 bits per soft-fork proposal, we have enough space to encode
four simultaneous soft-fork proposals, and sub-percent granularity for
the threshold (2^7=128).



Le 13/04/2017 à 16:17, Sancho Panza a écrit :
> Thomas,
> 
> I wonder if you've seen my proposal on how to make BIP9 more configurable:
> https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
> 
> This could be extended with a coinbase signaling feature as you suggest.
> This could include parameter information for forks which a miner is 
> signaling, for coordination.
> 
> Currently I've not included something like this, but it might make a nice 
> addition.
> One problem is the limited space in coinbase for embedding data on the large 
> number of possible independent deployments.
> 
> Regards,
> Sancho
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Proposal: Soft Fork Threshold Signaling

2017-04-13 Thread Thomas Voegtlin via bitcoin-dev
Disclaimer: I am fully supportive of Segregated Witness and its
activation by users through BIP148. However, I also believe that a
soft fork would be less risky if it was initially activated by miners,
before the date set in BIP148. This proposal is not intended to
replace UASF, but to mitigate the risks.

The following idea might already have been proposed and discussed
elsewhere. If that is the case, I am sorry for the noise.


Background
==

BIP9 requires 95% of miner hashrate support in order to activate a
soft-fork. So far, the lack of miner consensus about Segwit has been
frustrating both users and developers. This had led some users to
propose a soft fork activation regardless of the expressed level of
miner support (UASF, BIP148).

There are many risks associated with UASF. If the fork is activated
with less than 50% of the hashing power, the blockchain will have two
competing branches. In addition, if the hashrate on the forking branch
is very low, that branch will be exposed to attacks, where non-empty
blocks are systematically orphaned by adverse miners. This threat may
be a strong deterrent for miners willing to support the fork.

The main argument in favor of UASF is that users, not miners, give its
value to Bitcoin. Therefore, users and markets should have the power
to decide which branch of the fork has the most value, and
profit-driven miners should follow. If the soft-forking branch is
valued more than the non-forking branch, it will end up attracting a
majority of the hashing power, and the non-forking branch will
eventually be orphaned.

Feedback through markets, however, will only work if the forking
branch can effectively be used. If the forking branch is rendered
unusable by adverse miners, there is little chance the new coins will
ever reach markets. To make things worse, profit-driven miners might
adopt a passive attitude and decide to mine on the forking branch only
once a proper price has been set by markets, or only once they see
that it has enough hashing power to be usable. Thus, the lack of
hashrate information prior to the soft fork increases the risk.

On the other hand, if a soft fork was initiated with more than 33% of
the hashing power, then it would probably be viable, because the
remaining two thirds of the hashing power cannot successfully be
allocated to mine blocks on the non-forking branch and to orphan
blocks on the forking branch. Therefore, users will be able to move
coins on the forking branch, and markets will be able to set a price
on these coins, thus creating the feedback needed by profit-driven
miners.

Today about 30% of the hashing power are signaling their intention to
activate Segwit using BIP9. This hashrate is very close to the 33%
threshold, and it would probably be enough to initiate a viable soft
fork; indeed we can expect additional hashing power to be gained from
miners mining on both branches of the fork.

However, nothing suggests that a soft fork triggered with 30% of the
hashrate would be followed by the miners who are currently signaling
Segwit using BIP9. BIP9 signaling means that these miners are willing
to soft fork if support reaches 95%; it does not say anything about
their intentions if support is as low as 30%. In other words, BIP9
signaling does allow miners to properly signal their intentions.


BIP9 signaling
==

The activation threshold is part of the semantics of BIP9. Miners who
use BIP9 do not only signal their support for a soft fork; they also
signal to other miners that they will activate the soft fork if and
only if support reaches 95%.

Some of these miners might actually be willing to activate a soft fork
with a lower support, even at the cost of creating two chains. Other
miners might not be supportive of that idea, because they consider
that the danger of their blocks being orphaned is too high.

The problem is that this information, at which level of support miners
are willing to initiate a soft fork, is not available. Thus, miners
who are willing to initiate a soft fork at a lower hashrate cannot
coordinate their action.


Proposal: Soft Fork Threshold Signaling
===

Miners signal the threshold at which they are willing to activate a
soft fork. The value of the threshold is published in the coinbase
transaction of the block, with the corresponding version bit.

Miners activate a soft fork if their threshold has been reached over
the last retargeting period. For example, if 504 of 2016 blocks signal
a soft fork with a threshold equal or lower to 25%, then the soft fork
is activated by these miners.

If no activation threshold is reached, the current BIP9 signaling rate
indicator is replaced by a distribution of signaling rates per
threshold. The public availability of threshold information allows
miners to adjust their own threshold, and to optimize their chances of
activating the soft fork.


UASF


Even if the soft fork is not activated by miners, this 

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

2016-08-25 Thread Thomas Voegtlin via bitcoin-dev


Le 25/08/2016 à 09:39, Jonas Schnelli via bitcoin-dev a écrit :
> (I think this case if not completely unrealistic):
> 
> What would happen, if a user gave out 21 addresses, then address0 had
> receive funds in +180 days after generation where address21 had receive
> funds immediately (all other addresses never received a tx).
> 
> In a scan, address0 would be detected at +180 days
> which would trigger the resize+20 of the address-lookup-window, but, we
> would require to go back 180day in order to detect received transaction
> of address21 (new lookup-window) in that case.
> 
> Or do I misunderstand something?
> 
> 

That case is not unrealistic; a merchant might generate addresses that
are beyond their gap limit, and orders get filled at a later date.

In that case you will not get the same result when restoring your wallet
in a block-scanning wallet and in Electrum.

The lack of consideration for these cases is another issue with BIP44.



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


Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

2016-08-24 Thread Thomas Voegtlin via bitcoin-dev
Le 23/08/2016 à 22:12, Luke Dashjr via bitcoin-dev a écrit :
> BIP 39: Mnemonic code for generating deterministic keys
> - Used by many wallets and hundreds of thousands of users.
> 
> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
> - Appears to be implemented by multiple wallets.
> 

I personally believe that BIP39/BIP44 is a bad design. There is limited
support for these BIPs in Electrum, in order to provide compatibility
with hardware wallets. However, I do not plan to use BIP39/BIP44 for
default Electrum wallets, for the following reasons.

(Note that it does not make sense to consider BIP39 and BIP44
independently. Any wallet that decides to implement one without the
other would be considered as broken.)

Here is why I rejected this design:

1 - BIP44 uses multiple accounts. This means that in order to be
compatible with the standard, a wallet *must* implement multiple
accounts. A wallet that decides to keep things simple and use only one
account, will not allow users to recover all their funds when they
restore from a BIP39 seed, and will be considered as broken.

2 - An appealing feature of deterministic wallets is that you can use
the same instance of your wallet on different devices. Two instances of
your wallet can automatically synchronize their Bitcoin addresses, and
display the same balance. The problem is that hardened derivations break
this property. Indeed, with hardened derivations, software wallets need
to ask the user's password in order to derive new accounts. Therefore,
in order to implement automated detection of newly created accounts, a
BIP44-compatible software wallets would need to ask the user's password
whenever a new account is detected. This means that the wallet would ask
the password without the user initiating any action. This seems to be an
avenue for malware.

Of course, hardware wallets do not have that issue, because they can
derive new accounts without requesting a password from the user. BIP44
is a standard that has been designed for hardware wallets, but that
makes things really difficult for software wallets.

3 - Unneeded complexity. From an end user perspective, the multiple
accounts in BIP44 achieve the same result as using different derivation
passphrases with the same BIP39 seed phrase. The only real difference is
that BIP44 accounts can be enumerated deterministically, while
passphrases in general cannot. However, this property is of limited
interest, because automatic synchronization of multiple accounts cannot
be guaranteed for bip44 software wallets, as explained in 2.

4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
phrase' in order to derive the BIP32 seed. This hash-based derivation
was added on my suggestion, in order to make the BIP independent from
the particular wordlist used to generate the seed phrases. However,
BIP39 also requires the implementation of a checksum, in order to verify
that a seed phrase is valid. Suprisingly, the specification of the
checksum involves wordlist indices. This means the checksum (and thus
the BIP) requires a fixed wordlist. This defeats the purpose of using a
hash for the derivation of the seed.

The authors of the BIP should either have used hash functions for both
the seed AND the checksum (that is what Electrum does), or for none of
them (in that case case, you can have a bidirectional function between
seed phrases and entropy, which is nice if you want to perform Shamir
secret sharing of seed phrases, at the expenses of a fixed wordlist). In
its current state, BIP39 takes the worst of both worlds.

5 - The fact that the wordlist must be part of BIP39, and cannot be
changed in the future, seems a terrible idea to me. I believe that a
specification should always try to be minimal. In that case, the
specification includes a 2000+ words dictionary, when it could have
avoided that.

Even if you decide that BIP39 is final, there will always be users
requiring the addition of wordlists for new languages. So, in practice,
this BIP will never be final.

6 - Finally, and most importantly, BIP39 seed phrases do not have a
version number. Without a version number, how are you going to derive
addresses from a BIP39 seed phrase, when wallets start to use to new
derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
that a BIP39 compatible wallet will have to check addresses from all the
derivation methods that ever existed in the past, in order to ensure
that all coins are correctly retrieved? Or will there be users that
cannot access their coins because their BIP39 seed phrase is too old for
newer software?



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


Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

2016-06-22 Thread Thomas Voegtlin via bitcoin-dev
IMO the moderate success of BIP70 is caused by its complexity. Since the
amount of data in a BIP70 payment request does not fit in a bitcoin:
URI, an https server is required to serve the requests.

Only large merchants are able to maintain such an infrastructure; (even
Coinbase recently failed at it, they forgot to update their
certificate). For end users that is completely unpractical.

The main benefit of BIP70 is that the payment request is signed by the
requestor; this gives the sender a proof that they are sending to the
right person, and that the person actually requested the payment.

The same benefit can be achieved without the complexity of BIP70, by
extending the Bitcoin URI scheme. The requestor is authenticated using
DNSSEC, and the payment request is signed using an EC private key. A
domain name and an EC signature are short enough to fit in a Bitcoin URI
and to be shared by QR code or SMS text.

 bitcoin:address?amount=xx=yyy=john.example.com=zzz

The URI scheme is extended with two fields:
 name: DNS name containing a public key or bitcoin address
 sig: signature

That extension is sufficient to provide authenticated requests, without
requiring a https server. The signed data can be serialized from the
URI, and DNSSEC verification succeeds without requesting extra data from
the requestor. The only assumption is that the verifier is able to make
DNS requests.

I am willing to write a BIP if other wallet developers are interested.




Le 20/06/2016 19:33, Erik Aronesty via bitcoin-dev a écrit :
> BIP 0070 has been a a moderate success, however, IMO:
> 
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol.  Not too late
> to support JSON messages as the standard going forward
> 
> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification.   alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas.   personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)
> 
> - missing an optional client supplied identification
> 
> - lack of basic subscription support
> 
> *Proposed for subscriptions:*
> 
> - BIP0047 payment codes are recommended instead of wallet addresses when
> establishing subscriptions.  Or, merchants can specify replacement
> addresses in ACK/NACK responses.   UI confirms are *required *when there
> are no replacement addresses or payment codes used.
> 
> - Wallets must confirm and store subscriptions, and are responsible for
> initiating them at the specified interval.
> 
> - Intervals can *only *be from a preset list: weekly, biweekly, or 1,
> 2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
> suspension until the user re-verifies.
> 
> - Wallets *may *optionally ask the user whether they want to be notified
> and confirm every interval - or not.   Wallets that do not ask *must *notify
> before initiating each payment.   Interval confirmations should begin at 
> *least
> *1 day in advance of the next payment.
> 
> 
> *Proposed in general:*
> - JSON should be used instead of protocol buffers going forward.  Easier to
> use, explain extend.
> 
> - "Extendible" URI-like scheme to support multi-mode identity mechanisms on
> both payment and subscription requests.   Support for keybase://, netki://
> and others as alternates to https://.
> 
> - Support for client as well as merchant multi-mode verification
> 
> - Ideally, the identity verification URI scheme is somewhat
> orthogonal/independent of the payment request itself
> 
> Question:
> 
> Should this be a new BIP?  I know netki's BIP75 is out there - but I think
> it's too specific and too reliant on the domain name system.
> 
> Maybe an identity-protocol-agnostic BIP + solid implementation of a couple
> major protocols without any mention of payment URI's ... just a way of
> sending and receiving identity verified messages in general?
> 
> I would be happy to implement plugins for identity protocols, if anyone
> thinks this is a good idea.
> 
> Does anyone think https:// or keybase, or PGP or netki all by themselves,
> is enough - or is it always better to have an extensible protocol?
> 
> - Erik Aronesty
> 
> 
> 
> ___
> 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


[bitcoin-dev] Making Electrum more anonymous

2015-07-22 Thread Thomas Voegtlin via bitcoin-dev
Hello,

Although Electrum clients connect to several servers in order to fetch
block headers, they typically request address balances and address
histories from a single server. This means that the chosen server knows
that a given set of addresses belong to the same wallet. That is true
even if Electrum is used over TOR.

There have been various proposals to improve on that, but none of them
really convinced me so far. One recurrent proposal has been to create
subsets of wallet addresses, and to send them to separate servers. In my
opinion, this does not really improve anonymity, because it requires
trusting more servers.

Here is an idea, inspired by TOR, on which I would like to have some
feedback: We create an anonymous routing layer between Electrum servers
and clients.

* Each server S publishes a RSA public key, KS
* Each client receives a list of available servers and their pubkeys
* For each wallet address, addr_i, a client chooses a server S_i, and a
RSA keypair (K_addr_i, k_addr_i)
* The client creates a list of encrypted requests. Each request contains
addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
* The client chooses a main server M, and sends the list of encrypted
requests to M
* M dispatches the client's requests to the corresponding servers S_i
(without the client's IP address.)
* Each server decrypts the requests it receives, performs the request,
and encrypts the result with K_addr_i
* M receives encrypted responses, and forwards them to the client.
* The client decrypts the encrypted response with k_addr_i

What do you think? What are the costs and benefits of such an approach?

(Note: this will not work if all servers, or a large fraction of them,
are controlled by the same entity that controls M)


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


Re: [bitcoin-dev] QR code alternatives (was: Proposal: extend bip70 with OpenAlias)

2015-07-21 Thread Thomas Voegtlin via bitcoin-dev


Le 20/07/2015 16:40, Mike Hearn a écrit :
 
 If we accept a single payment address i.e. no clever tricks around merge
 avoidance, such a QR code could look like this:
 
 bitcoin:1aBcD1234?x=serialized_payment_request
 
 However this requires text mode and wastes bytes at the front for the URI
 type.
 

It is possible to be both backward-compatible and to avoid wasting space
in URIs, if we simply assume that the payment request is a single
standard output + amount (that scenario will probably cover 99% of the
cases, and the few other cases may not need QR codes). We generate a
serialized bip70 PR from the parameters found in the URI, sign that
string, and add the signature to the URI.

Example:

bitcoin:1H14AiSc4PqkK9VTmeutZU3edSy3HS5HL8?amount=1message=here%20is%20a%20testtime=1437489571exp=604800name=ecdsa.netsig=3Quot6m2RsR43NgV8VQQx3Ngf5u8wZY18mu523x3ViLrA3WLwSoQum2Znw3gRsTgfADpHuEiyyjnpxCLKWrkR4RQM

'time' is the timestamp of the request
'exp' is the duration of validity, 1 week here
(it saves a few bits to express it that way)

'name' is the domain name of the signer
'sig' is the signature

The QR code derived from that URI is perfectly scannable with a phone.


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


Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

2015-07-20 Thread Thomas Voegtlin via bitcoin-dev


Le 19/07/2015 01:01, Justin Newton via bitcoin-dev a écrit :

 I would rather not make Namecoin part of the standard, because .bit
 records cannot be verified easily by lightweight/spv wallets; they would
 need a copy of the Namecoin blockchain for that.
 
 You are the second person to raise this.  Clearly this is an item that
 requires some discussion before anything is decided for sure.  We had
 gone this direction (and I assume Riccardo did as well) to provide a
 censor resistant option as well as one that would be low cost for
 individuals to be able register their own names.  This also allows for
 lookups that never leave the local network.  The trade off there for
 mobile wallets was one I feel we failed to properly consider.
 

I think our common goal should be to standardize DNS records holding
Bitcoin addresses, because they are going to be used by both Netki and
Electrum.

You and Ricardo may find it useful to have other types of lookups, such
as Namecoin, and that's fine with me, but I do not want that to slow
down or stall the current standardisation effort, because Namecoin
lookups are clearly not an option for lightweight wallets. That is what
I meant by 'not part of the standard'; let's work on what we have in
common :)


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