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

[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

[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

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

[bitcoin-dev] Electrum 3.0 release

[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

[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

[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

[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 
>> To: bitcoin-dev@lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
>> BIP-32 wallets
>> Message-ID: 
>> 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 
>> To: Andreas Schildbach , Bitcoin Protocol
>> Discussion 
>> 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.
>>
>>> There is however the case where even on one chain, script types are
>>> mixed. In this case the field should be 

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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&message=yyy&name=john.example.com&sig=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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Thomas Voegtlin via bitcoin-dev]

Le 14/05/2016 18:14, Jonas Schnelli via bitcoin-dev a écrit :
> 
> AFAIK: Bip39 import (cross-wallet) is not supported by [...] Electrum [2] .
> 

That is correct. There are several reasons why I decided not to use
BIP39 in Electrum. One of them was that BIP39 seed phrases do not
include a version number. A version number is needed in order to
maintain backward compatibility, everytime you change the address
derivation.

Electrum will allocate a new version number for seed phrases that should
be derived to segwit addresses.

I guess BIP39 designers will have to change the semantics of their
checksum bits, in order to encode a version number for segwit.



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] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin via bitcoin-dev]

Le 27/07/2015 23:51, Justin Newton via bitcoin-dev a écrit :
> Thomas,
>   I think this is interesting and has some good thoughts behind it.  For
> clarity, are you recommending that the "_oa2" portion of the domain name be
> "hidden" as a way to make it easier to delegate just wallet names from a
> zone?
> 

I don't think you can completely "hide" it, because you need to know
where the _oa2 is in the name, in order to perform requests. In my
proposal it was denoted by a @ character in the alias:

x@y.z -> x._oa2.y.w

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

Re: [bitcoin-dev] Electrum Server Speed Test

[Thomas Voegtlin via bitcoin-dev]

There is some room for optimization in the Electrum server:
 - the utxo database (patricia tree) should be made a binary tree.
 - the server is written in python, which is slow.

I am not too worried about the short-term; a block takes on average 15s
to process on my server. For example, here are the last blocks in my log:

[23/07/2015-17:11:57] catch_up: block 366604 (0.145s 27.278s)
[23/07/2015-17:37:55] catch_up: block 366605 (0.126s 24.453s)
[23/07/2015-17:50:23] catch_up: block 366606 (0.133s 21.666s)
[23/07/2015-18:03:22] catch_up: block 366607 (0.110s 31.680s)
[23/07/2015-18:11:14] catch_up: block 366608 (0.093s 18.269s)
[23/07/2015-18:26:38] catch_up: block 366609 (0.115s 27.925s)
[23/07/2015-18:29:07] catch_up: block 366610 (0.062s 8.163s)
[23/07/2015-18:44:18] catch_up: block 366611 (0.118s 21.294s)
[23/07/2015-18:52:14] catch_up: block 366612 (0.075s 12.535s)
[23/07/2015-18:58:54] catch_up: block 366613 (0.100s 17.857s)
[23/07/2015-19:04:18] catch_up: block 366614 (0.061s 11.174s)
[23/07/2015-19:10:31] catch_up: block 366615 (0.064s 10.151s)
[23/07/2015-19:11:04] catch_up: block 366616 (0.035s 2.962s)
[23/07/2015-19:19:53] catch_up: block 366617 (0.081s 13.125s)
[23/07/2015-19:25:23] catch_up: block 366618 (0.037s 8.377s)
[23/07/2015-19:28:08] catch_up: block 366619 (0.044s 3.984s)
[23/07/2015-19:30:36] catch_up: block 366620 (0.051s 6.105s)
[23/07/2015-19:40:05] catch_up: block 366621 (0.058s 14.632s)
[23/07/2015-19:42:10] catch_up: block 366622 (0.040s 4.143s)

That server is a Hetzner EX40 box, rented for 50 eur/month. Of course if
you run the electrum server on a cheap VPS, performance might not be as
good.



Le 23/07/2015 17:56, Slurms MacKenzie via bitcoin-dev a écrit :
> Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at 
> how the Electrum server software handles under load. The Electrum wallet is 
> extremely popular, and the distributed servers which power it are all hosted 
> by volunteers without budget. The server requires a fully indexed Bitcoin 
> Core daemon running, and produces sizable external index in order to allow 
> SPV clients to quickly retrieve their history. 
> 
> 3.9Gelectrum/utxo
> 67M electrum/undo
> 19G electrum/hist
> 1.4Gelectrum/addr
> 24G electrum/
> 
> Based on my own logs produced by the electrum-server console, it takes this 
> server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes per 
> megabyte of block to process into the index. This seems to hold true through 
> the 10 or so blocks I have in my scroll buffer, the contents of blocks seem 
> to be of approximately the same processing load. Continuing this trend with 
> the current inter-block time of 9.8 minutes, an electrum-server instance 
> running on modest-high end dedicated server is able to support up to 2.64 MB 
> block sizes before permanently falling behind the chain. 
> ___
> 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] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin via bitcoin-dev]

Le 23/07/2015 11:48, Thomas Voegtlin via bitcoin-dev a écrit :
> 
> One benefit of having an intermediate "_wallet" level is to allow zone
> delegation. Is that the reason for that choice?
> 

Thinking about it, I think that it would be better to separate those two
operations: on one hand, the listing of TXT records under a name, and on
the other hand, the possibility to use Zone Delegation.

For example, let us use the "_oa2" name (Openalias version 2) when we
need to introduce an intermediate level, and "_oa2_keys" for key listing.

Here is an example:

_oa2_keys.sample  3600 IN TXT "btc ltc email fullname"
_btc.sample   3600 IN TXT "bitcoinaddress"
_ltc.sample   3600 IN TXT "litecoinaddress"
_btc.sample   3600 IN TXT "otherbitcoinaddress"
_email.sample 3600 IN TXT "john.sm...@googlemail.com"
_fullname.sample  3600 IN TXT "John Smith"

Zone Delegation: Let us assume example.com wants to delegate all its
Bitcoin aliases to Netki. We introduce an intermediate level, with the
"_oa2" name. In the alias, this string is translated as "@"

john._oa2.example.com<--  will be looked up as j...@example.com
_btc.john._oa2.example.com   <--  bitcoin address of j...@example.com

___
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

[Thomas Voegtlin via bitcoin-dev]

Le 17/07/2015 03:01, Justin Newton via bitcoin-dev a écrit :
>> 3> We use a 2 tier lookup format. [...]
>>
>> We do the same thing, except in a single call. [...]
> 
> We looked at doing this in a single lookup as you did.  With one or two
> currencies this can be potentially more efficient.  As the number of
> supported currencies and addresses under a single name grows, however, this
> solution becomes potentially more problematic. [...]

Hi Justin,

Your lookup solution is indeed more efficient than OpenAlias, and more
robust to DoS. However, that is not because you use a two-tier lookup.

Indeed, instead of having the following records:
_wallet.sample = "btc ltc"
_btc._wallet.sample = "mybitcoinadress"

you could simply have:
_wallet.sample = "btc ltc"
_btc.sample = "mybitcoinaddress"

In practice, a wallet supporting only Bitcoin will skip the currencies
lookup in both cases, and go directly for the _btc record.

One benefit of having an intermediate "_wallet" level is to allow zone
delegation. Is that the reason for that choice?

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

[bitcoin-dev] Making Electrum more anonymous

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

[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=1&message=here%20is%20a%20test&time=1437489571&exp=604800&name=ecdsa.net&sig=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

[Thomas Voegtlin via bitcoin-dev]

Le 20/07/2015 17:14, Mike Hearn a écrit :
> 
> By "alias" you mean domain name? I'm not sure what DNS key means in this
> context.
> 

yes, sorry, I mean the domain name corresponding to the TXT record.
it's called 'alias' in the context of OpenAlias.


> I'm still not really convinced that a domain name under some new roots is
> an identity people will want to use, but yes, I guess your approach would
> work for those who do want it.

What do you mean by "under some new roots" ?

If I believe Netki, there is enough people who want to have a Bitcoin
address stored in DNS, for at least one company to thrive. :)

All I am proposing is a new usage for these already existing DNS
records; not only to receive BTC, but also to sign requests with them.

> It still may be worth exploring the compact cert+optimized BIP70 (no
> DNSSEC) in a qrcode if making a network that stores small bits of data
> really is beyond us :(
> 
Heh, pastebin + base64 encoding the PR could work. However, it might
violate their ToS. More seriously, there might be some legal issues for
a company willing to provide that kind of service.

Re QR codes: 150 bytes, using base43 encoding, is not too bad.
___
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

[Thomas Voegtlin via bitcoin-dev]

Le 20/07/2015 16:42, Mike Hearn a écrit :
>>
>> In my previous post, I was suggesting to *not* include the proof in the
>> request, because the payer can download it independently. Only the final
>> signature is needed. What makes DNSSEC interesting is not the size of
>> the proof, but rather the fact that you can request it easily, and in a
>> canonical way.
>>
> 
> Yes, but you still need the final signature. Is it possible to use an EC
> signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
> about that, and all you need is 32 bytes, then my argument does not hold.
> 

The final signature is a signature of the payment request, it is not
part of DNSSEC. So, yes, that signature can be EC.

The DNSSEC proof is used to verify that the public key, which is
recovered from the signature, corresponds to the alias.

The payment requests I am currently playing with have the following values:

pki_type = "dnssec+btc" (btc means that the signature is checked against
a Bitcoin address stored in DNS)
pki_data = the user's alias (DNS key)

___
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

[Thomas Voegtlin via bitcoin-dev]

hi Mike,

I hope you had a good trip!


> To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
> 
>1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
>won't fit nicely in a QR code, I think.
> 
>2. 1024 bit is the absolute minimum strength you can get away with,
>really. DNSSEC assumes frequent key rotations to try and help, which
>complicates things.
> 
> So I'm not sure using DNSSEC fixes the usability problem we want to fix.
> 

In my previous post, I was suggesting to *not* include the proof in the
request, because the payer can download it independently. Only the final
signature is needed. What makes DNSSEC interesting is not the size of
the proof, but rather the fact that you can request it easily, and in a
canonical way.

A typical lightweight payment request, serialized with EC signature and
without the proof, would be about 150 bytes long.


> I will do a separate reply to break out some thoughts on replacing QR codes.
> 
> Would it be possible to create the same kind of "lightweight payment
>> requests" using SSL certificates? Probably, if the final signing key is
>> a EC key, and if the payment request does not include the whole chain of
>> certificates.
> 
> 
> Given that the pre-existing value of the PKI is much lower for individuals
> than for companies/websites, where they all have certs already, building a
> Bitcoin-specific or entirely new/independent PKI for people is not so
> unthinkable, I agree.
> 
> In theory such a cert could be as minimal as:
> 
> thom...@electrum.org
> 
> so literally just a signature + a UTF-8 string, and that's it! You don't
> need anything more if you're willing to sacrifice extensibility,
> revocability, etc.

Again, we don't have to sacrifice revocability, if the proof is
downloaded separately.

> 
> The pubkey of the CA would be obtained by running the pubkey recovery
> algorithm on the signature, and then checked against a table of trusted
> pubkeys.
> 
___
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

[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

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

[Thomas Voegtlin via bitcoin-dev]

Hi Mike,

The reason why I would like to extend BIP70 is because it is currently
not being used in transactions between end-users. BIP70 works very well
in B2C situations, where users buy products from a website. However,
end-users still share Bitcoin addresses.

Before BIP70 was written, I had proposed "Signed URIs", where the
signature is a public proof that a payee requested a payment. This is
one of the main benefits of BIP70, and I still want to bring it to
user-to-user transactions.

I believe one of the main barriers to BIP70 adoption is that bitcoin:
URIs have been extended in a way that requires the request to be hosted
on a webserver. You may complain about the lack of store-and-forward
network, despite the apparent simplicity of creating one such network.
However, that does not mean we should absolutely do things that way and
wait until such a network exists.

Bitcoin addresses do not require a webserver. If we want to build
something that competes with that, we should have at least that level of
convenience.

EC signatures are short, and they can be shared by copy-paste, or added
to a bitcoin: URI. This is a features of my "Signed URIs" proposal, that
was lost in BIP70. Indeed, signed URIs were self-contained. A serialized
payment request can also be made very short, if it is signed by a EC
key, and if it does not include the chain of certificates. Such a
"lightweight request" can be base58-encoded, and easily shared by
copy-paste, or passed in a bitcoin: URI.

Size is another reason why I proposed to use DNSSEC in BIP70 (the first
reason is that the subdomain is signed by the domain, not by an external
CA). Indeed, DNSSEC provides a canonical way to download the chain of
signatures needed to verify a record. Thus, the chain of signatures does
not need to be included in the payment request; it can be downloaded and
archived by the verifier.

Now, I understand that SSL vertificates have distinct advantages over
DNSSEC; for example, CA-signed SSL certificates have a legal value,
which is important for dispute resolution.

Would it be possible to create the same kind of "lightweight payment
requests" using SSL certificates? Probably, if the final signing key is
a EC key, and if the payment request does not include the whole chain of
certificates. (However, that would require an additional infrastructure
to publish the chain of certificates, and I do not think that x509
certification path are unique, which makes things more complicated, but
not impossible).

Sorry if I did not answer point-by-point to your post. I felt that I
failed to explain one of the reasons why I want to use DNSSEC in the
validation of payment requests.

Thomas




Le 14/07/2015 13:45, Mike Hearn a écrit :
> Hi Thomas,
> 
> Re: NetKi, I think any proposal in this space has to be an open standard,
> almost by the definition of what it is. At any rate, it may be worth
> talking to them. They have signed up to implement their system at least.
> 
> I did understand that your proposal does not rely on email - for instance a
> web forum could issue usern...@reddit.com type aliases, even if those are
> not also email accounts. I am just continuing the comparison against email
> address certs.
> 
> It's also the case that a domain can use the DKIM setup without actually
> offering email accounts. They can just have a web form or API that triggers
> sending of the signed email (or simply, providing the signed headers
> themselves). Thus the same system can be used transparently by both email
> providers and other sites that don't give their users email addresses, but
> would still like to use the same system.
> 
> Hardly anyone uses email certificates today, so I don't think it would
>> affect a lot of users.
> 
> 
> No, but obviously we'd like to change that! The holdup is not the
> certificate side of things, really, but rather the lack of a
> store-and-forward network for signed payment requests. I keep asking
> someone to build one but I fear the problem is almost too simple ..
> everyone who looks at this decides to solve 12 other problems
> simultaneously, it gets complicated, then they never launch :(
> 
> Once there's a simple and robust way to get PaymentRequest's from one end
> user to another, even when that first user is offline, then getting an
> email cert issued is no big deal.
> 
> That does not look so... not until (1) BIP70 wallets integrate with
>> https://crt.sh, (2) you convince that service to index email certs (3)
>> you convince all CAs to report all email certs they issue to crt.sh.
>>
> 
> Any solution that separates identity providers from certificate issuers
> would have these requirements, though. And as many identity providers today
> do not wish to become CAs too, it seems fundamental.
> 
> I don't think it's such a problem, mind you. The crt.sh website is actually
> a frontend to the CT protocol, which is a somewhat blockchain like audit
> log that's eventually intended to contain all issued certific

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

[Thomas Voegtlin via bitcoin-dev]

Le 14/07/2015 19:29, Justin Newton a écrit :

> Hi there.  You are correct that we are a company providing a service,
> however, that service is also based on an open standard which we are
> proposing.  I'll be honest that we haven't done the greatest job in
> promoting the standard so far.  More coming soon on that front.  Any
> of the Open Source Wallet Name resolvers that we have created do
> lookups against the standard record formats, and not directly against
> our servers in any way.  Information on the record formats as well as
> links to the lookup API server and some early libraries can be found
> here:  https://www.netki.com/#/developers and here:
> https://github.com/netkicorp
> 

Sorry to answer late, and thanks for the clarification. After talking
with you, I believe that it will not be difficult to agree on a common
standard, that gives maximum freedom to everyone.

I also believe that it is in Netki's interest to convey the message that
they are actively promoting an open standard, and not pushing a private
solution. For this reason, and assuming that the future standard
satisfies you fully, will you mind if that standard carries a neutral
name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
your company? I reckon that is purely a PR issue.


> To break it down briefly, we have an open lookup standard based on
> both the namecoin blockchain as well as traditional DNSSEC.  (You can
> choose your own adventure of using namecoin based names or traditional
> ICANN names).

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.

> Differences:
> 
> 1> We do not use DNSCrypt.  I understand why you chose to, but we were
> concerned about broad interoperability and easy broad distribution of
> hosting, so decided not to use it.  We have other ways of achieving
> privacy, using HD Wallets and Payment Requests.
> 

As far as Electrum is concerned, I do not see DNSCrypt as something
usable in the short term. I do not think it should be mandated, because
there are other ways of achieving privacy, as you say.

> 2> We have the option of storing a URL rather than just a wallet
> address in the TXT record.  This allows a second level lookup against
> the URL to get back a unique HD Wallet address or Payment Request each
> time, further protecting user privacy and security.  Using Wallet
> Names with Payment Requests allows for the user experience of typing
> in an easy to remember name and getting back the "green lock" and who
> the validated recipient is.  This also provides an auto audit of the
> end to end DNS SEC process, in the case the path were somehow
> compromised, the signature on the payment request can provide an
> additional check.
> 

I see value in the ability to store differerent types of strings in TXT
records. In particular, I have the need to store an email address, and
more than one Bitcoin address or xpubkey per alias.

> 3> We use a 2 tier lookup format.  The first lookup returns a list of
> currencies or payment types supported by the Wallet Name.  The second
> lookup goes to a record specific to that currency type to get the
> address to go to.  We believe this to be a more scalable solution in a
> world where someone can have both multiple digital currency types, but
> then also multiple types of colored coins, and wants a simple way to
> share a single name for all of those different addresses.  This allows
> the wallet to do the work behind the scene of choosing the currency it
> wants to send, and automatically getting back the right address to
> send to, without the user having to do anything different.
> 

This seems to be a major difference, and I believe it makes sense to do
it the way you describe. Does that solution fully replace the tags used
in OpenAlias, or does it make sense to combine these two systems?


> 4> We mandate DNSSEC while you make it optional.  We did this because
> we believe giving the user the option of NOT using DNSSEC is like
> letting them order a car with no brakes.  We weren't sure how we would
> explain to them why their money was gone when they really didn't
> understand the risks they were taking up front. We had a lot of
> discussion about it before coming to the decision we did, and I can
> see why you went the other way, although I do believe we made the
> right choice.

I agree on this; there is no point using OpenAlias without DNSSEC.
Wallets can use fallback servers if the default DNS does not have DNSSEC.

> 
> 
> Additionally, we just released another open source API server to help
> with the "other half" of the lookup problem.  Its in its infancy, and
> we are certainly taking feedback on it at this time.  It is called
> Addressimo  and will serve
> unique HD Wallet addresses or Payment Requests for every lookup, thus
> allowing a user to have