I fully agree with sipa and his reasoning that this proposal is not solving
any particular problem, but making it actually a bit worse.
Also, do you know what I hate more than copy&pasting bitcoin addresses?
Copy pasting zillion random fields for SEPA/wire transfers. And I believe
that a single co
On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> seems a bit overkill for how simple the format is, and pulling in a
> large dependency just for this is a bit silly. Although making it
> protobuf-compatible is an interesting idea,
On Sun, Oct 16, 2016 at 10:58 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
> wrote:
> > It's not the website's fault if wallet devs aren't updating their
> > statuses. Besides, "WIP" can mean
As Luke pointed, BIP44 is already used by many wallets and to my knowledge
people don't have any real world issues with that, including loading funds
in another BIP44 wallet. I'm not saying that BIP44 is perfect from all
points of view, but IMO it just works for most use cases. Let's set it as
fina
On Thu, Aug 18, 2016 at 11:35 AM, Jonas Schnelli
wrote:
> I agree that BIP70 is a mess (including the bitcoin:// additions). The
> proposed URI scheme would be completely different.
This reminds me https://xkcd.com/927/
I have some experience with hardware wallet development and its integratio
> Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?
The main benefit is that you don't need "standard" to solve problem, but
use natural tools in given environment and programming stack. Build a
"standar
Hi,
I fundamentally disagree with the concept of driving signing workflow by
the wallet software. Wallet software does not know in advance all data
necessary for the signer to do the job. As Jochen mentioned above, Segwit
vs Non-segwit use cases are a good example, but there may be many.
Currentl
Ehm, I though those discussions about "ASICs are bad, because X" ended
years ago by starting "ASIC unfriendly" altcoins. ASIC industry is twisted
even without AsicBoost. I don't see any particular reason why to change
rules just because of 10% edge.
This is opening Pandora box and it is potentiall
I received this:
-- Forwarded message --
From: Pieter Wuille
Date: Fri, Apr 22, 2016 at 6:44 PM
Subject: Re: [bitcoin-dev] Proposal to update BIP-32
To: Marek Palatinus
Cc: Bitcoin Dev
On Thu, Apr 21, 2016 at 2:08 PM, Marek Palatinus wrote:
> On Wed, Apr 20, 2016 at 6:32 PM,
Sipa, you are probably the most competent to answer this. Could you please
tell us your opinion? For me, this is straightforward, backward compatible
fix and I like it a lot. Not sure about the process of changing "Final" BIP
though.
Slush
On Wed, Apr 20, 2016 at 6:32 PM, Jochen Hoenicke via bitc
To my understanding it is purely software thing. It cannot be detected from
outside if miner uses this improvement or not. So patenting it is worthless.
slush
On Tue, Apr 5, 2016 at 1:01 AM, Mustafa Al-Bassam via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Alternatively scenari
11 matches
Mail list logo
