Re: [bitcoin-dev] Drivechain RfD -- Follow Up

Greg is still conflating two different usages of the word "theft": 1. Whether the soft fork rules have been followed, and 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes. In his message he claims to uniquely adopt definition #2, saying (emphasis

Re: [bitcoin-dev] how to disable segwit in my build?

On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote: > I think that terminology isn't quite precise. I think your options are: > > - if you're a miner or run a mining pool, you can *signal* (or not >signal) support for segwit activation; you do this by controlling >the block

Re: [bitcoin-dev] how to disable segwit in my build?

On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote: >> I believe that a good reason not to wish your node to be segwit > compliant is to avoid having to deal with the extra bandwidth that > segwit could require. Running a 0.14.2 node means being ok with >1MB > blocks, in case segwit is

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

Hello, On 7/13/2017 9:17 AM, Hampus Sjöberg wrote: > In softforks, I would argue that 100% of all nodes and miners need to > upgrade to the new rules. > This makes sure that trying to incorrectly spend an "AnyOneCanSpend" > will result in a hardfork, instead of a temporary (or permanent) >

Re: [bitcoin-dev] how to disable segwit in my build?

> I believe that a good reason not to wish your node to be segwit compliant is to avoid having to deal with the extra bandwidth that segwit could require. Running a 0.14.2 node means being ok with >1MB blocks, in case segwit is activated and widely used. Users not interested in segwit

Re: [bitcoin-dev] how to disable segwit in my build?

On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Can you explain why you wish to do this? It should have absolutely no > adverse impact on you-- if you don't use segwit, you don't use it-- it > may be the case that there is some

Re: [bitcoin-dev] A Segwit2x BIP

The BIP has been updated. Changes: - The technical spec has been improved: now the block size increase is specified in terms of weight and not in terms of bytes. - The increase in the maximum block sigops after HF has been documented. - Comments added about the worst case block size. Happy

Re: [bitcoin-dev] A Segwit2x BIP

What's special about block 475776? On July 13, 2017 12:23:46 PM Sergio Demian Lerner via bitcoin-dev wrote: The BIP has been updated. Changes: - The technical spec has been improved: now the block size increase is specified in terms of weight and not

Re: [bitcoin-dev] A Segwit2x BIP

Andrew, Block 475776 and block 477792 (July 26) are the last 2 difficulty adjustment periods before Aug 1st. Charlie On Thu, Jul 13, 2017 at 3:48 PM, Andrew Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What's special about block 475776? > > On July 13, 2017 12:23:46

Re: [bitcoin-dev] how to disable segwit in my build?

On 07/13/2017 09:35 AM, Jameson Lopp wrote: > > > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev > > wrote: > > On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote: > >> I

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

I'm interested in hearing a reply from Russell/ZmnSCPxj in what they think about lightning bribes. I hadn't given much thought about those while writing my original BIP, but it does seem like my original BIP (minus the fixed indexes in the coinbase output) fits this pretty well. If I understand

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

On 7/13/2017 4:22 PM, Chris Stewart wrote: > In general though, I'm still unclear of what purpose the 'Ratchet' > serves. Can you either link to documentation about it or write > something up quick? > > -Chris In Bitcoin, new coins are held for 100 blocks. One result of this is that the coins

Re: [bitcoin-dev] how to disable segwit in my build?

On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote: > >> I believe that a good reason not to wish your node to be segwit > > compliant is to avoid having to deal with the extra

Re: [bitcoin-dev] how to disable segwit in my build?

> I would like to understand it a bit better, as I think it applies equally to any pre-segwit node, yes? So let's say I am running 0.13.0 and someone sends me bitcoins to a P2PKH address, but that person previously received them to a P2WPKH address. Yes, this applies to all non-SegWit nodes. >

Re: [bitcoin-dev] how to disable segwit in my build?

Hampus, thanks for the explanation! On 07/13/2017 03:50 PM, Hampus Sjöberg wrote: > Yes. > So you have two choices to be fully secure: > 1. Validate using the new rules of the network (in other words, run a > SegWit node) > 2. Avoid any chain of transaction that contains a SegWit transaction

Re: [bitcoin-dev] how to disable segwit in my build?

2017-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > If I understand correctly, my node will accept the incoming tx inputs > but obviously will not perform any segwit related validation, thus those > inputs are not fully validated. I don't yet