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 k
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 Lightning
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 (hard-forking
On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> I think the shortest reasonable timeframe for an uncontroversial
> hardfork is somewhere in the range between 6 and 12 months.
This argument would hold more weight if it didn't looks like a stalling
tactic in context.
6 months ago, th
On 12/20/2015 10:33 PM, Pieter Wuille via bitcoin-dev wrote:
> Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
By "solve" do you mean, "actually implement", or do you mean "make
future implementation theoretically possible?"
In other wo
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 e
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 bikes
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 first
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 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
I guess by "locked transaction" you must mean a P2SH output?
If so, that's a rather bizarre use of terms since outputs and
transactions are very different things.
0xEAD9E623.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
On 11/01/2015 05:46 PM, Tier Nolan via bitcoin-dev wrote:
> An OP_CAT script that requires TBs of RAM to validate crosses the
> threshold of reasonableness.
Are there actually any OP_CAT scripts currently in the utxo set?
It's one thing to have a theoretical scripting ability that gets removed
b
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 redundant
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
cod
On 22/10/15 16:47, Luke Dashjr wrote:
> Well, I strongly disagree with adopting the BIP as it stands.
That's fine. Nobody is required to adopt an informational BIP if they do
not wish to do so.
> No, those are not network-level changes. They are mere software changes that
> can be deployed along
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 to
On 19/09/15 15:11, Rune K. Svendsen wrote:
> An honest miner is a miner that supports the network by building on top of
> the best valid chain. A malicious miner is one who wants to disrupt the
> Bitcoin network, not support it, for example by executing a 51% attack which
> mines empty blocks on
On 19/09/15 10:45, Rune Kjær Svendsen wrote:
> We need to distinguish between two different things here:
>
> 1) A 51% attack, where the majority of mining power is *malicious* (hence
> “attack”)
What does "malicious" mean?
In other words, If miner A is mining honestly, and miner B is mining
mal
On 18/09/15 15:17, Rune Kjær Svendsen via bitcoin-dev wrote:
> Bitcoin does not function if the majority of mining power is dishonest. There
> is no way around that. It’s how proof-of-work functions.
None of those statements are true.
If a majority of Bitcoin miners are mining invalid blocks, t
On 09/04/2015 01:21 PM, Luke Dashjr wrote:
> This is not Bitcoin's problem... Polluting the BIP repository with N non-
> Bitcoin related specifications would be.
HD generation of keypairs from a single seed for many non-conflicting
uses is a valuable and useful technique.
Intentionally making a u
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 co
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/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 s
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 revelat
On 08/31/2015 03:06 PM, Monarch via bitcoin-dev wrote:
> What is Bitcoin if not decentralized?
>
> Bitcoin the most awkward, unprivate and damaging currencies ever
> created. It is terribly slow for general use, and it is very
> difficult for users to get over the technical hurdles required to us
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 fees
28 matches
Mail list logo
