[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

[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

[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

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

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

[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

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

2017-09-12 Thread Thomas Voegtlin via bitcoin-dev
dation.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 bitco

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

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

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

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

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

[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

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

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

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

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

[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

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

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

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

[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

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

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