Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

Gregory Maxwell via bitcoin-dev writes: > Based on how fast we saw segwit adoption, why is the BIP149 timeout so > far in the future? > > It seems to me that it could be six months after release and hit the > kind of density required to make a stable transition. Agreed, I would suggest 16th Decem

Re: [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold

Instead of block thresholds, use utxo bits to coordinate size changes (larger and smaller should be allowed). There is no reason for miners to be involved in a decision to change this aspects of the protocol. Plenty of other ways to coordinate. Otherwise someone can make it seem to a miner like

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing. I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM growth, of which bandwidth seems the most constraining. - Erik On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@list

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning, >> (What happens if the h* to be put in the coinbase, by chance - even very >> unlikely chance - is 0? Then OP_NOP4 is not the same as >> OP_BRIBE scripts in result - the former will be rejected by old nodes, >> the latter will be accepted by new nodes) > >That would indeed be a bu

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

Ah. I see now. It wasn't very clear to me that that is what will happen. Also, shouldn't the timeout date be set for before the BIP141 timeout? Otherwise this could lock in but not have enough time for Segwit to be locked in. On 5/23/2017 4:42 PM, James Hilliard wrote: > That is incorrect, it is

Re: [bitcoin-dev] Rolling UTXO set hashes

On Mon, May 22, 2017 at 9:47 PM, Rusty Russell wrote: > Gregory Maxwell via bitcoin-dev > writes: >> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille >> wrote: >>> just the first - and one that has very low costs and no normative >>> datastructures at all. >> >> The serialization of the txout it

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

That is incorrect, it is compatible with the current segwit implementation because it triggers a mandatory signalling period that will activate segwit on existing nodes. On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev wrote: > Hi James, > > From what I understand, this proposal is in

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

Hi James, >From what I understand, this proposal is incompatible with the current segwit implementation with regards to the NODE_WITNESS service bit. I believe it could cause network partitioning if the service bit is not changed. Andrew On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrot

[bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

In light of some recent discussions, I wrote up this BIP for a real 2 MB block size hardfork following Segwit BIP148 activation. This is not part of any agreement I am party to, nor anything of that sort. Just something to throw out there as a possible (and realistic) option. Note that I cannot

[bitcoin-dev] BIP149 timeout-- why so far in the future?

Based on how fast we saw segwit adoption, why is the BIP149 timeout so far in the future? It seems to me that it could be six months after release and hit the kind of density required to make a stable transition. (If it were a different proposal and not segwit where we already have seen what netw

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

On Tue, May 23, 2017 at 5:51 AM, Kekcoin wrote: > I think there may be merit to this idea, allowing for political compromise > without sacrificing the technological integrity of Bitcoin. There are a few > mechanical problems I see with it, though. > > 1. It should change its activation logic from

[bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions

Hello List, I would like to propose a BIP that specifies a way of referring to transactions that have been successfully inserted into the blockchain. The format makes use of the excellent Bech32 encoding, and is designed to be short and useful for human use. A C reference implementation is incl

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote: > On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc > wrote: > > I would replace "Bitcoins you manage to steal" with "Bitcoins you > manage to double-spend". Then, it still seems the same to me. > > > With

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On 5/22/2017 8:13 PM, ZmnSCPxj wrote: > Good morning, > > > >>What you read is only an introduction of BMM. You may also consult the > notes (at the bottom of the BMM post) or the code, although this is time > consuming of course. > > Looking over the code, I have a question: Is OP_BRIBE supp

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev wrote: > On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote: >> Essentially, if we make a potentially very harmful option easy to >> enable for users, we are putting them at risk, so yes, this is about >> protecting u

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote: > Essentially, if we make a potentially very harmful option easy to > enable for users, we are putting them at risk, so yes, this is about > protecting users of the base Bitcoin Core implementation. In this case, NOT enforcing

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

I think there may be merit to this idea, allowing for political compromise without sacrificing the technological integrity of Bitcoin. There are a few mechanical problems I see with it, though. 1. It should change its activation logic from BIP9-style to BIP8-style with a flagday of August 1. Th

Re: [bitcoin-dev] I do not support the BIP 148 UASF

On Tue, May 23, 2017 at 1:03 PM, Steven Pine via bitcoin-dev wrote: > Correct me if I am wrong, but currently core developers are arguing over > whether or not to allow an optional configuration switch which defaults off > but signals and enforces BIP148 when used. Who are we protecting users from

[bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold

I have a proposal that would allow each user to optionally configure the maximum block weight at a support threshold. It recognizes that there is no need for off chain bickering, by providing a mechanism that lets each users freely choose their own parameters while still maintaining full coordinat

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc wrote: > I would replace "Bitcoins you manage to steal" with "Bitcoins you manage > to double-spend". Then, it still seems the same to me. > > With double spending, you can only get ownership of coins that you owned at some point in the past. Coins th

Re: [bitcoin-dev] I do not support the BIP 148 UASF

> Who are we protecting users from, themselves? Are you protecting core? from what? I am somewhat genuinely befuddled by those who can't even allow a user config switch to be set. Indeed. It seems silly. If you're activating the switch, you're most likely fully aware of what you're doing. I also s