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
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 t
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 u
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 pr
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),
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 sta
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
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?
>
>
-32
>> wallets (Thomas Voegtlin)
>>
>>
>> --
>>
>> Message: 1
>> Date: Thu, 7 Sep 2017 21:35:49 +0200
>> From: Andreas Schildbach
>> To: bitcoin-dev@lists.linuxfoundation.org
&g
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 si
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 w
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" i
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 f
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 versio
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
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
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
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
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 versio
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 di
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 c
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 pro
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
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 g
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
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 dom
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
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 Ele
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
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
operat
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 t
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
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),
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
34 matches
Mail list logo
