On 7/23/19 9:47 AM, Andreas Schildbach via bitcoin-dev wrote:
> BIP 157/158 is not an alternative to BIP 37:
They complement each other pretty well though.
Wallets can save the deterministic GCS filters in the same way as
headers, which means blocks can be re-scanned if necessary (importing
new
On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote:
> Finally, regarding alternatives, the filter-generation code for BIP
> 157/158 has been in Bitcoin Core for some time, though the P2P serving
> side of things appears to have lost any champions working on it. I
> presume one of the
On 12/26/2015 06:13 PM, Bryan Bishop wrote:
> I think you'll find that there hasn't been stalling regarding an
> uncontroversial hard-fork deployment. You might be confusing an
> uncontroversial hard-fork decision instead with how developers have
> brought up many issues about various
On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote:
> I am not convinced that SW softfork should be the *only* short term
> scalability solution
I don't think SW is relevant at all with respect to scalability.
Fraud proofs are extremely important from a security perspective. The
network as it
On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote:
> Stuffing the segwitness merkle tree in the coinbase
If such a change is going to be deployed via a soft fork instead of a
hard fork, then the coinbase is the worst place to put the segwitness
merkle root.
Instead, put it in the
On 12/08/2015 11:41 AM, Mark Friedenbach wrote:
> A far better place than the generation transaction (which I assume means
> coinbase transaction?) is the last transaction in the block. That allows
> you to save, on average, half of the hashes in the Merkle tree.
I don't care what color that
On 02/11/15 14:33, Gavin Andresen via bitcoin-dev wrote:
> I like those guidelines, although I'm sure there may be lots of arguing
> over what fits under "protects the integrity of the network" or what
> constitutes "reasonable notice" (publish a BIP at least 30 days before
> rolling out a change?
On 10/30/2015 10:43 PM, Rusty Russell via bitcoin-dev wrote:
> By that benchmark, we should aim for "reasonable certainty". A
> transaction which would never have been generated by any known software
> is the minimum bar. Adding "...which would have to be deliberately
> stupid with many
On 11/01/2015 07:30 PM, Tier Nolan via bitcoin-dev wrote:
> If at least one year's notice was given, then people aren't going to
> lose their money, since they have notice.
So after realizing that I misread substantial portions of this thread
due to a lack of attention to detail I'd like to point
On 22/10/15 20:22, Peter Todd wrote:
> FWIW multi-push OP_RETURN outputs will be standard in v0.12.0:
>
> https://github.com/bitcoin/bitcoin/pull/6424
>
As I said before, once the prerequisites for a better notification
method are usable in the network, I'd love to define a version 2 payment
On 22/10/15 15:43, Luke Dashjr wrote:
> BIPs should in general not be
> designed around current software
I strongly disagree with this statement.
There is a version byte in the payment code specification for a reason.
Version 1 payment codes are designed to be deployable by wallet
implementers
On 22/10/15 00:53, Luke Dashjr wrote:
> Sorry for the late review. I'm concerned with the "notification address"
> requirement, which entails address reuse and blockchain spam. Since it
> entails
> address reuse, the recipient is forced to either leave them unspent forever
> (bloating the UTXO
On 14/10/15 19:02, Jeff Garzik via bitcoin-dev wrote:
> *Disclose potential conflicts*
>
> 1. List discussions often involve interested parties. We expect
> participants to be aware when they are conflicted due to employment or
> other projects they are involved in, and disclose those interests
On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> Since BIP 43 is still a draft, I propose modifying it to refer non-
> Bitcoin purpose codes to the SLIP repository:
> https://doc.satoshilabs.com/slips/
What benefit is created by delegating the BIP-43 namespace management to
that
On 09/01/2015 03:29 PM, Wladimir J. van der Laan wrote:
> On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev
> wrote:
>
>> * They should own their bitcoins, meaning that they retain exclusive
>> control over their balances. Even more precisely, the n
On 08/30/2015 01:38 AM, Adam Ritter via bitcoin-dev wrote:
> Still, it doesn't have anything that is practical for me as an user of
> the Bitcoin network (I use it for storing long-term purchase value, as
> most of the people who I know): it doesn't help me if I still need to
> pay transaction
On 08/31/2015 04:42 PM, Monarch wrote:
> The justification for the existence of Bitcoins hinges on it. What is
> described in the whitepaper is a system without the trust of third
> parties to process electronic payments, this can not exist without
> decentralization. Absent any unforseen
On 08/31/2015 05:53 PM, Monarch wrote:
>
> Bitcoin is a decentralized currency which allows any person the
> ability to transact in a way that does not require specific trust in
> any particular party. Users can independently verify that
> transactions they receive are valid and confirmed, with
18 matches
Mail list logo
