Credit card transactions are simply an expample of a widely used payment
system that has frequent fraud and chargebacks. The argument I'm making is
that different people in different situations value speed and convenience
over a known fraud risk. Instant zero confirmation transactions are
extremely
It's easy enough to mark a transaction as "pending". People with bank
accounts are familiar with the concept.
Although the risk of accepting gossip information from multiple random
peers, in the case where the sender does not control the receivers network
is still minimal. Random node operators ha
lose money). I want to
>>> work on it and may be able to at some point as it's somewhat related
>>> to lightning.
>>>
>>> Also, if you're running a light client, and storing the filters the
>>> way you store block headers, there's really no
.
>
> Also, if you're running a light client, and storing the filters the way
> you store block headers, there's really no reason to go all the way back to
> height 0. You can start grabbing headers at some point a while ago, before
> your set of keys was generated. I thin
Unconfirmed transactions are incredibly important for real world use.
Merchants for instance are willing to accept credit card payments of
thousands of dollars and ship the goods despite the fact that the
transaction can be reversed up to 60 days later. There is a very large cost
to losing the abil
On Thu, Jun 23, 2016 at 3:56 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> In any case, I'd strongly argue that we remove BIP75 from the bips
> repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin
> developers
> to willingly partic
This works for segwit version 1 with the addition of also using a different
chain id.
I presume that segwit version 2 will be implementing schnorr signatures.
What do we know about the likely implementation details? Is there any way
to avoid using a third derivation path to support it?
Aaron Voi
On Sun, May 15, 2016 at 5:08 AM, Daniel Weigl via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > 0x4000 would be the next available to specify witness addresses.
> > This is compatible with existing accounts and wallet layouts.
>
> my main concern here is that
> -) every Bi
On Sat, May 14, 2016 at 7:08 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 14/05/16 09:00, Andreas Schildbach via bitcoin-dev wrote:
> > The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
> > define balance retrieval never changes. This is
That's a valid concern, but I don't see the conflict here. In order to
recover funds from a wallet conforming to BIPXX, you must have wallet
software that handles BIPXX. Simply making BIPXX backwards compatible with
previously created BIP44 or BIP43 purpose 0 wallets doesn't change this at
all.
A
This scheme is independent of the number of accounts. It works with BIP44
as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of
overloading the account index to indicate the type of address, you use the
chain index, which is already being used to indicate what the specific
addre
We use the default BIP32 wallet layout, mentioned in BIP43 as purpose "0".
We were thinking of of having 4 chains below the "account" level, the
original 0 and 1 for receive and change addresses, and then 0x4000 and
0x4001 for P2WPKH-in-P2SH versions of receive and change addresses.
I like
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.
Pieter, what's actually happening is that
Breadwallet also implements CPFP when spending unconfirmed non-change
inputs. It was released back in May, but happy to let Andreas have the
bounty:
https://github.com/voisine/breadwallet/blob/v0.5.1/BreadWallet/BRWallet.m#L382
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, Jul 15, 20
14 matches
Mail list logo
