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
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
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
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 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
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.
>
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
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
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
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
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
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 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
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
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?
>
>
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
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
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 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
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
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"
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
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
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
24 matches
Mail list logo
