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

[Rusty Russell via bitcoin-dev]

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 December, 2017 (otherwise, it should be
16th January 2018; during EOY holidays seems a bad idea).

This means this whole debacle has delayed segwit exactly 1 (2) month(s)
beyond what we'd have if it used BIP8 in the first place.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Erik Aronesty via bitcoin-dev]

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 99pct of nodes are ready
for a larger weight even though that's false.

On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 coordination of any changes.
>
> The BIP can be found here:
>
> https://github.com/tomasvdw/bips/blob/master/bip-changing-
> the-maximum-block%20weight-based-on-a-support-threshold.mediawiki
>
> It is worth noting that this proposal does neither gives more power to
> miners nor reduces decentralization. Miners still rely on their blocks
> being accepted by economic nodes to sell their minted coins. This
> proposal doesn't change that.
>
> Regards,
> Tomas van der Wansem
> bitcrust
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Erik Aronesty via bitcoin-dev]

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@lists.linuxfoundation.org> wrote:

> 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 recommend this to be adopted, since frankly 1 MB blocks
> really are still too large, and this blunt-style hardfork quite risky even
> with consensus. But if the community wishes to adopt (by unanimous
> consensus)
> a 2 MB block size hardfork, this is probably the best way to do it right
> now.
> The only possible way to improve on this IMO would be to integrate it into
> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size HF
> improvements).
>
> I have left Author blank, as I do not intend to personally champion this.
> Before it may be assigned a BIP number, someone else will need to step up
> to
> take on that role. Motivation and Rationale are blank because I do not
> personally think there is any legitimate rationale for such a hardfork at
> this
> time; if someone adopts this BIP, they should complete these sections. (I
> can
> push a git branch with the BIP text if someone wants to fork it.)
>
> 
> BIP: ?
> Layer: Consensus (hard fork)
> Title: Post-segwit 2 MB block size hardfork
> Author: FIXME
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-2-Clause
> 
>
> ==Abstract==
>
> Legacy Bitcoin transactions are given the witness discount, and a block
> size
> limit of 2 MB is imposed.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Specification==
>
> Upon activation, a block size limit of 200 bytes is enforced.
> The block weight limit remains at 400 WU.
>
> The calculation of block weight is modified:
> all witness data, including both scriptSig (used by pre-segwit inputs) and
> segwit witness data, is measured as 1 weight-unit (WU), while all other
> data
> in the block is measured as 4 WU.
>
> The witness commitment in the generation transaction is no longer required,
> and instead the txid merkle root in the block header is replaced with a
> hash
> of:
>
> 1. The witness reserved value.
> 2. The witness merkle root hash.
> 3. The transaction ID merkle root hash.
>
> The maximum size of a transaction stripped of witness data is limited to 1
> MB.
>
> ===Deployment===
>
> This BIP is deployed by flag day, in the block where the median-past time
> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).
>
> It is assumed that when this flag day has been reached, Segwit has been
> activated via BIP141 and/or BIP148.
>
> ==Motivation==
>
> FIXME
>
> ==Rationale==
>
> FIXME
>
> ==Backwards compatibility==
>
> This is a hardfork, and as such not backward compatible.
> It should not be deployed without consent of the entire Bitcoin community.
> Activation is scheduled for 18 months from the creation date of this BIP,
> intended to give 6 months to establish consensus, and 12 months for
> deployment.
>
> ==Reference implementation==
>
> FIXME
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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 bug, if it happened as you described. I will
>check when I get the chance, thanks.

Indeed, this is the reason why CLTV and CSV do not pop off their parameters 
when executed, and require a subsequent OP_DROP. I suggest, that OP_BRIBE 
should not manipulate stack (pop, then push 0/1); my understanding is that this 
requirement is necessary for compatibility with old nodes, which will not 
manipulate stack on OP_NOP4. Instead, OP_BRIBE should imitate CLTV and CSV 
code, and raise an error in script execution if the check fails.

>>
>> How is OP_BRIBE superior to just using a  OP_RETURN script? Cannot
>> a sidechain scan the block for OP_RETURN attesting that the block hash
>> is present in the block?
>
>The sidechain software can indeed, but the mainchain software cannot
>(without making validation of both chains part of the mainchain, which
>defeats the original purpose of sidechains).
>
>The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
>(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
>Mary could provide Sam with some guarantee that Sam's sidechain block
>[defined by h*] would make it into the largest chain.

Regarding "largest chain", do you mean mainchain or sidechain?

An OP_RETURN is still some guarantee that it will make it into the longest 
mainchain. If OP_RETURN tx is in a shorter mainchain but not on the longer 
mainchain, then on the longer mainchain, the utxo's funding the OP_RETURN tx is 
still unspent and the OP_RETURN tx will still be mineable by any miner 
following the longer mainchain. The X BTC would be the OP_RETURN transaction's 
fee, which Mary would still want to mine into the longest mainchain, as it is 
still money on the table if it is not mined on the longest mainchain.

Or, does OP_BRIBE somehow assure that Sam's block goes onto the longer 
sidechain? But then, do not side blocks refer to their previous side block to 
define the sidechain?

>1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
>for B's good or service (provided on the sidechain)
>2. side:B attempts to move side-to-main with the 100 BTC, using the
>lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
>3. C attempts to move side-to-main, using the slow, settlement method.
>4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
>a withdrawal attempt (WT^)
>5. The WT^ attempt is initiated on the mainchain.
>6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
>(upvotes / downvotes), on the mainchain.
>7. The transaction either succeeds or fails.
>
>I'm not sure, but your question seems to concern B, who exploits a reorg
>that happens just after step 2. After the reorg, the sidechain chain
>history will have a different side-to-main withdrawal in part 3. The
>time between each of these step is very long, on the order of weeks
>(summing to a length of time totaling months), for exactly this reason
>(as well as to encourage people to avoid using this 'formal' method, in
>favor of the cooperative LN and Atomic Swaps).
>
>I think that this principle of scale (ie, very VERY slow withdrawals) is
>important and actually makes the security categorically different.

I see.

Is there some predictable schedule for side->main withdrawals? If a withdrawal 
is imminent, or if some actor can get "insider information" about whether a 
withdrawal is imminent, cannot some actor induce the above, with potentially 
shorter time to reach step 3?

From my reading, Blockstream's sidechains proposal supports a reorg proof after 
a side->main withdrawal on the mainchain side, with a reorg proof burn window 
after the main:side->main withdrawal, preventing its utxo from being used. If 
the reorg proof is published and shows that a sidechain reorg invalidates a 
particular side->main withdrawal, then the main:side->main withdrawal's utxo is 
burned.

>For extraordinary DAO-like situations, disinterested mainchain miners
>merely need a single bit of information (per sidechain), which is
>"distress=true", and indicates to them to temporarily stop ACKing
>withdrawals from the sidechain. This alone is enough to give the reorg
>an unlimited amount of time to work itself out.

Do you have some document containing these details? I cannot find this in the 
blog posts I've read so far.

>>>I feel that my proposal is more secure, as it can operate healthily and
>> quickly while using spv proofs which are much slower and much much
>> easier to audit.
>>
>> I don't quite understand how Drivechain handles sidechain reorgs, while
>> keeping Bitcoin miners blinded. It seems sidechains need to be known
>> ("seen") by the miner, so I don't see what is being bl

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

[Andrew Chow via bitcoin-dev]

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 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 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 wrote:
>>> I would like to propose an implementation that accomplishes the first
>>> part of the Barry Silbert proposal independently from the second:
>>>
>>> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>>> in a way that
>>>
>>> The goal here is to minimize chain split risk and network disruption
>>> while maximizing backwards compatibility and still providing for rapid
>>> activation of segwit at the 80% threshold using bit 4.
>>>
>>> By activating segwit immediately and separately from any HF we can
>>> scale quickly without risking a rushed combined segwit+HF that would
>>> almost certainly cause widespread issues.
>>>
>>> Draft proposal:
>>> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>>>
>>> Proposal text:
>>> 
>>>   BIP: segsignal
>>>   Layer: Consensus (soft fork)
>>>   Title: Reduced signalling threshold activation of existing segwit 
>>> deployment
>>>   Author: James Hilliard 
>>>   Status: Draft
>>>   Type: Standards Track
>>>   Created: 2017-05-22
>>>   License: BSD-3-Clause
>>>CC0-1.0
>>> 
>>>
>>> ==Abstract==
>>>
>>> This document specifies a method to activate the existing BIP9 segwit
>>> deployment with a majority hashpower less than 95%.
>>>
>>> ==Definitions==
>>>
>>> "existing segwit deployment" refer to the BIP9 "segwit" deployment
>>> using bit 1, between November 15th 2016 and November 15th 2017 to
>>> activate BIP141, BIP143 and BIP147.
>>>
>>> ==Motivation==
>>>
>>> Segwit increases the blocksize, fixes transaction malleability, and
>>> makes scripting easier to upgrade as well as bringing many other
>>> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>>>
>>> This BIP provides a way for a simple majority of miners to coordinate
>>> activation of the existing segwit deployment with less than 95%
>>> hashpower. For a number of reasons a complete redeployment of segwit
>>> is difficulty to do until the existing deployment expires. This is due
>>> to 0.13.1+ having many segwit related features active already,
>>> including all the P2P components, the new network service flag, the
>>> witness-tx and block messages, compact blocks v2 and preferential
>>> peering. A redeployment of segwit will need to redefine all these
>>> things and doing so before expiry would greatly complicate testing.
>>>
>>> ==Specification==
>>>
>>> While this BIP is active, all blocks must set the nVersion header top
>>> 3 bits to 001 together with bit field (1<<1) (according to the
>>> existing segwit deployment). Blocks that do not signal as required
>>> will be rejected.
>>>
>>> ==Deployment==
>>>
>>> This BIP will be deployed by a "version bits" with an 80%(this can be
>>> adjusted if desired) activation threshold BIP9 with the name
>>> "segsignal" and using bit 4.
>>>
>>> This BIP will have a start time of midnight June 1st, 2017 (epoch time
>>> 1496275200) and timeout on midnight November 15th 2017 (epoch time
>>> 1510704000). This BIP will cease to be active when segwit is
>>> locked-in.
>>>
>>> === Reference implementation ===
>>>
>>> 
>>> // Check if Segregated Witness is Locked In
>>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>>> Consensus::Params& params)
>>> {
>>> LOCK(cs_main);
>>> return (VersionBitsState(pindexPrev, params,
>>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>>> THRESHOLD_LOCKED_IN);
>>> }
>>>
>>> // SEGSIGNAL mandatory segwit signalling.
>>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>>> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>>> &&
>>>  !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>>> // Segwit is not locked in
>>>  !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>>> and is not active.
>>> {
>>> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>>> VERSIONBITS_TOP_BITS;
>>> bool fSegbit = (pindex->nVersion &
>>> VersionBitsMask(chainparams.GetConsensus(),
>>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>>> if (!(fVersionBits && fSegbit)) {
>>> return state.DoS(0, error("ConnectBlock(): relayed block must

Re: [bitcoin-dev] Rolling UTXO set hashes

[Pieter Wuille via bitcoin-dev]

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 itself is normative, but very minimal.
>
> I do prefer the (2) approach, BTW, as it reuses existing primitives, but
> I know "simpler" means a different thing to mathier brains :)

Oh, I didn't mean it that way at all. (1) is simpler to get decent
performance out of. Implementing (1) using any language that has big
integer support or can link against GMP is likely going to be faster
than the fastest possible implementation of (2).

> Since it wasn't explicit in the proposal, I think the txout information
> placed in the hash here is worth discussing.
>
> I prefer a simple txid||outnumber[1], because it allows simple validation
> without knowing the UTXO set itself; even a lightweight node can assert
> that UTXOhash for block N+1 is valid if the UTXOhash for block N is
> valid (and vice versa!) given block N+1.  And miners can't really use
> that even if they were to try not validating against UTXO (!) because
> they need to know input amounts for fees (which are becoming
> significant).
>
> If I want to hand you the complete validatable UTXO set, I need to hand
> you all the txs with any unspent output, and some bitfield to indicate
> which ones are unspent.

That seems to completely defeat the purpose... if I want to give you a
UTXO set, and prove its correctness wrt the hash you know... I need to
remember the full transactions those outputs came from?

> OTOH, if you serialize more (eg. ...||amount||scriptPubKey ?), then the UTXO
> set size needed to validate the utxohash is a little smaller: you need
> to send the txid, but not the tx nVersion, nLocktime or inputs.  But in a
> SegWit world, that's actually *bigger* AFAICT.

That's an interesting idea, but I believe you're forgetting:
* The size of txin prevout/nsequence, which is typically larger than
txouts (even when excluding scriptSig/witness data).
* The size of spent txouts for transactions with unspent outputs left.
* The fact that you can deduplicate the txids for txn that have
multiple unspent outputs in the UTXO set serialization, even if that
txid is repeated in the rolling hash computation.

The construction I was considering and benchmarking is using 256-bit
truncated SHA512(256bit txid || 32bit voutindex || 1bit coinbase ||
31bit height || CTxOut output) as secp256k1 X coordinate, or as key to
seed a ChaCha20 PRNG whose outputs is the 3072-bit MuHash number. The
reason for using SHA512 is that it can process most UTXOs in a single
transformation (as opposed to SHA256 which will almost always need 2).
The reason for using ChaCha20 is that it's incredibly fast for
producing much data when a key is already known. An alternative is
using SHAKE256 for the whole construction (as it both takes an
arbitrary amount of data, and produces an arbitrary length hash) - but
it's a bit slower.

> Thanks,
> Rusty.
>
> [1] I think you could actually use txid^outnumber, and if that's not a
> curve point SHA256() again, etc.  But I don't think that saves any
> real time, and may cause other issues.

That just seems scary to me...

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[James Hilliard via bitcoin-dev]

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 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 wrote:
>> I would like to propose an implementation that accomplishes the first
>> part of the Barry Silbert proposal independently from the second:
>>
>> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>> in a way that
>>
>> The goal here is to minimize chain split risk and network disruption
>> while maximizing backwards compatibility and still providing for rapid
>> activation of segwit at the 80% threshold using bit 4.
>>
>> By activating segwit immediately and separately from any HF we can
>> scale quickly without risking a rushed combined segwit+HF that would
>> almost certainly cause widespread issues.
>>
>> Draft proposal:
>> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>>
>> Proposal text:
>> 
>>   BIP: segsignal
>>   Layer: Consensus (soft fork)
>>   Title: Reduced signalling threshold activation of existing segwit 
>> deployment
>>   Author: James Hilliard 
>>   Status: Draft
>>   Type: Standards Track
>>   Created: 2017-05-22
>>   License: BSD-3-Clause
>>CC0-1.0
>> 
>>
>> ==Abstract==
>>
>> This document specifies a method to activate the existing BIP9 segwit
>> deployment with a majority hashpower less than 95%.
>>
>> ==Definitions==
>>
>> "existing segwit deployment" refer to the BIP9 "segwit" deployment
>> using bit 1, between November 15th 2016 and November 15th 2017 to
>> activate BIP141, BIP143 and BIP147.
>>
>> ==Motivation==
>>
>> Segwit increases the blocksize, fixes transaction malleability, and
>> makes scripting easier to upgrade as well as bringing many other
>> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>>
>> This BIP provides a way for a simple majority of miners to coordinate
>> activation of the existing segwit deployment with less than 95%
>> hashpower. For a number of reasons a complete redeployment of segwit
>> is difficulty to do until the existing deployment expires. This is due
>> to 0.13.1+ having many segwit related features active already,
>> including all the P2P components, the new network service flag, the
>> witness-tx and block messages, compact blocks v2 and preferential
>> peering. A redeployment of segwit will need to redefine all these
>> things and doing so before expiry would greatly complicate testing.
>>
>> ==Specification==
>>
>> While this BIP is active, all blocks must set the nVersion header top
>> 3 bits to 001 together with bit field (1<<1) (according to the
>> existing segwit deployment). Blocks that do not signal as required
>> will be rejected.
>>
>> ==Deployment==
>>
>> This BIP will be deployed by a "version bits" with an 80%(this can be
>> adjusted if desired) activation threshold BIP9 with the name
>> "segsignal" and using bit 4.
>>
>> This BIP will have a start time of midnight June 1st, 2017 (epoch time
>> 1496275200) and timeout on midnight November 15th 2017 (epoch time
>> 1510704000). This BIP will cease to be active when segwit is
>> locked-in.
>>
>> === Reference implementation ===
>>
>> 
>> // Check if Segregated Witness is Locked In
>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> Consensus::Params& params)
>> {
>> LOCK(cs_main);
>> return (VersionBitsState(pindexPrev, params,
>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> THRESHOLD_LOCKED_IN);
>> }
>>
>> // SEGSIGNAL mandatory segwit signalling.
>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>> &&
>>  !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>>  !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>> and is not active.
>> {
>> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>> VERSIONBITS_TOP_BITS;
>> bool fSegbit = (pindex->nVersion &
>> VersionBitsMask(chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> if (!(fVersionBits && fSegbit)) {
>> return state.DoS(0, error("ConnectBlock(): relayed block must
>> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>> 
>>
>> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1
>> deployment scheduled between midnight November 15th, 2016 and midnight
>> November 15th, 2017. Miners will need t

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

[Andrew Chow via bitcoin-dev]

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 wrote:
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> The goal here is to minimize chain split risk and network disruption
> while maximizing backwards compatibility and still providing for rapid
> activation of segwit at the 80% threshold using bit 4.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
> 
>   BIP: segsignal
>   Layer: Consensus (soft fork)
>   Title: Reduced signalling threshold activation of existing segwit deployment
>   Author: James Hilliard 
>   Status: Draft
>   Type: Standards Track
>   Created: 2017-05-22
>   License: BSD-3-Clause
>CC0-1.0
> 
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required
> will be rejected.
>
> ==Deployment==
>
> This BIP will be deployed by a "version bits" with an 80%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "segsignal" and using bit 4.
>
> This BIP will have a start time of midnight June 1st, 2017 (epoch time
> 1496275200) and timeout on midnight November 15th 2017 (epoch time
> 1510704000). This BIP will cease to be active when segwit is
> locked-in.
>
> === Reference implementation ===
>
> 
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SEGSIGNAL mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
> &&
>  !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
>  !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> 
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. Miners will need to upgrade their nodes to
> support segsignal otherwise they may build on top of an invalid block.
> While this bip is active users should either upgrade to segsignal or
> wait for additional confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requireme

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

[Luke Dashjr via bitcoin-dev]

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 recommend this to be adopted, since frankly 1 MB blocks 
really are still too large, and this blunt-style hardfork quite risky even 
with consensus. But if the community wishes to adopt (by unanimous consensus) 
a 2 MB block size hardfork, this is probably the best way to do it right now. 
The only possible way to improve on this IMO would be to integrate it into 
MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size HF 
improvements).

I have left Author blank, as I do not intend to personally champion this. 
Before it may be assigned a BIP number, someone else will need to step up to 
take on that role. Motivation and Rationale are blank because I do not 
personally think there is any legitimate rationale for such a hardfork at this 
time; if someone adopts this BIP, they should complete these sections. (I can 
push a git branch with the BIP text if someone wants to fork it.)


BIP: ?
Layer: Consensus (hard fork)
Title: Post-segwit 2 MB block size hardfork
Author: FIXME
Comments-Summary: No comments yet.
Comments-URI: ?
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-2-Clause


==Abstract==

Legacy Bitcoin transactions are given the witness discount, and a block size 
limit of 2 MB is imposed.

==Copyright==

This BIP is licensed under the BSD 2-clause license.

==Specification==

Upon activation, a block size limit of 200 bytes is enforced.
The block weight limit remains at 400 WU.

The calculation of block weight is modified:
all witness data, including both scriptSig (used by pre-segwit inputs) and 
segwit witness data, is measured as 1 weight-unit (WU), while all other data 
in the block is measured as 4 WU.

The witness commitment in the generation transaction is no longer required, 
and instead the txid merkle root in the block header is replaced with a hash 
of:

1. The witness reserved value.
2. The witness merkle root hash.
3. The transaction ID merkle root hash.

The maximum size of a transaction stripped of witness data is limited to 1 MB.

===Deployment===

This BIP is deployed by flag day, in the block where the median-past time 
surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).

It is assumed that when this flag day has been reached, Segwit has been 
activated via BIP141 and/or BIP148.

==Motivation==

FIXME

==Rationale==

FIXME

==Backwards compatibility==

This is a hardfork, and as such not backward compatible.
It should not be deployed without consent of the entire Bitcoin community.
Activation is scheduled for 18 months from the creation date of this BIP, 
intended to give 6 months to establish consensus, and 12 months for 
deployment.

==Reference implementation==

FIXME



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

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 network penetration looks like-- that would be another
matter.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[James Hilliard via bitcoin-dev]

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 BIP9-style to BIP8-style with
> a flagday of August 1. This to maintain backwards compatibility with the
> current deployment of BIP148 nodes. This proposal seems to be a measure to
> prevent a chainsplit, so it must make sure to avoid triggering one.
That can be done as a separate proposal, it's not mutually exclusive
to this one for those who intend to run BIP148.
>
> 2. This should be for miners only; non-miners should not enforce this. It
> severely weakens the block-signalling activation mechanism in several ways
> (lowered threshold, short deployment timeframe, no "locked in" delay before
> activation) and by doing so opens up attack vectors for
> consensus-partitioning attacks using malicious false signalling. For
> non-miners that seek to take their fate into their own hands, enforcing
> BIP148 is enough.
I disagree that it should be only run by miners, enforcement of
segsignal mandatory signalling by economic nodes strongly discourages
any false signaling.
>
> 3. Even for miners this is more risky than usual; only 31% of hashrate is
> required to false-signal the activation to fork-off honest miners. This
> attack vector is magnified by the lack of "locked in" delay that would allow
> laggards to upgrade before activation. I suggest adding in at least a 1-week
> lock-in period (given the shorter timeframes 2 weeks may eat up too much of
> the available voting time before the brick wall of BIP148 activation on
> August 1).
Those who can should still upgrade for segsignal, the more that
upgrade ahead of activation the more secure it is. Those who don't
upgrade would want to wait for more confirmations anyways. I didn't
think a lock in period was all that good an idea here due to the
fairly short deployment timeline.
>
> Under the assumption that this is indeed compatible with the terms of the
> Silbert agreement, we can presume the involved miners are willing to trust
> eachother more than usual so such a short lock-in period should be
> acceptable.
>
>  Original Message 
> Subject: [bitcoin-dev] Reduced signalling threshold activation of existing
> segwit deployment
> Local Time: May 23, 2017 1:40 AM
> UTC Time: May 22, 2017 10:40 PM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: Bitcoin Dev 
>
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> The goal here is to minimize chain split risk and network disruption
> while maximizing backwards compatibility and still providing for rapid
> activation of segwit at the 80% threshold using bit 4.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
> 
> BIP: segsignal
> Layer: Consensus (soft fork)
> Title: Reduced signalling threshold activation of existing segwit deployment
> Author: James Hilliard 
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> 
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required
> will be rejecte

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

[Велеслав via bitcoin-dev]

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 included.

Special care has been taken so this BIP is naturally extendable to support 
future upgrades to Bitcoin, Bitcoin Sidechains, or even from other blockchain 
projects. However, only support for the Bitcoin Main Chain, and the Test 
Network is specified in this draft.

I hope that the participants of the bitcoin-development mailing list find this 
draft BIP both interesting and useful. You are welcomed to read the full text 
here: 
https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip--Bech32_Encoded_Transaction_Postion_References.mediawiki

If assigned with a BIP number some small updates to the specification will be 
made in accommodation.

С наилучшими пожеланиями,

Велеслав___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Paul Sztorc via bitcoin-dev]

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 double spending, you can only get ownership of coins that you owned
> at some point in the past.  Coins that are owned by someone else from
> coinbase to their current owners cannot be stolen by a re-org (though
> they can be moved around).

I'm not sure it makes much of a difference. First of all, in point of
fact, the miners themselves own the coins from the coinbase. But more
importantly, even if miners did not explicitly own the coins, they might
profit by being bribed -- these bribes would come from people who did
own the coins.

The principle is that value "v' has been taken from A and given to B.
This is effectively coercive activity, and therefore itself has value
proportional to 'v'.

> 
> With BMM, you can take the entire reserve.  Creating a group of double
> spenders can help increase the reward.
>  
> 
> 
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in
> addition to the lost future tx fee revenues of the attacked chain.
> 
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
> 
> 
> 
> That is a fair point.  If sidechains are how Bitcoin is scaled, then
> shaking confidence in a side-chain would shake confidence in Bitcoin's
> future.

Yes. The more value _on_ the sidechain, the more abhorrent the malfeasance.

> 
> I wasn't thinking of a direct miner 51% attack.  It is enough to assume
> that a majority of the miners go with the highest bidder each time.

What do you think of my argument, that we already labor under such an
assumption? An attacker could pay fees today equal to greater than
sum(blockreward_(last N block)). According to you this would force a
reorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has never
happened.

It seems that this argument fully reduces to the "what will happen when
the block subsidy falls to zero" question.

> 
> If (average fees) * (timeout) is less than the total reserves, then it
> is worth it for a 3rd party to just bid for his theft fork.  Miners
> don't have to be assumed to be coordinating, they just have to be
> assumed to take the highest bid.
> 
> Again, I don't really think it is that different. One could
> interchange "recent txns" (those which could be double-spent within
> 2-3 weeks) with "sidechain deposit tnxs".
> 
> 
> It is not "recent txns", it is recent txns that you (or your group) have
> the key for.  No coordination is required to steal the entire reserve
> from the sidechain.

See above (?) for why I still feel they are comparable, if not identical.

> 
> Recent txns and money on the sidechain have the property that they are
> riskier than money deep on the main chain.  This is the inherent point
> about sidechains, so maybe not that big a deal. 

Yes. Sidechains have newer, more interesting features, and
simultaneously more risk.


> 
> My concern is that you could have a situation where an attack is
> possible and only need to assume that the miners are indifferent.

Again, I think that we _already_ need to eliminate any assumption of
"charitable miners".

> 
> If the first attacker who tries it fails (say after creating a fork that
> is 90% of the length required, so losing a lot of money), then it would
> discourage others.   If he succeeds, then it weakens sidechains as a
> concept and that creates the incentive for miners to see that he fails.
> 
> I wonder how the incentives work out.  If a group had 25% of the money
> on the sidechain, they could try to outbid the attacker.

Yes, we may see interesting behavior where people buy up these
liabilities using the LN. In my original post, I mention that miners
themselves may purchase these liabilities (at competitive rates, even if
these arent the idealized 1:1). At this point, miners would be paying
themselves and there would be no agency problem.

> 
> In fact, since the attacker, by definition, creates an illegal fork, the
> effect is that he reduces the block rate for the side chain (possibly to
> zero, if he wins every auction).  This means that there are more
> transactions per block, if there is space, or more fees per transaction,
> if the blocks are full. 
> 
> In both cases, this pushes up the total fees per block, so he has to pay
> more per block, weakening his attack.  This is similar to where
> transaction spam on Bitcoin is self-correcting by increasing the fees
> required to keep the spam going.
> 
> Is there a description of the actual implementation you decided to go
> with, other than the code?

If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is

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

[Paul Sztorc via bitcoin-dev]

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 supposed to be
> softforked in, or hardforked?

Softforked, of course.

  From my understanding, the code as
> published in your linked github cannot be softforked in, since it is not
> a softfork-compatible replacement for OP_NOP: it replaces the stack top
> value with a 0/1 value.  Both CLTV and CSV do not touch the stack, only
> flag an error if they fail.

Your understanding may exceed my own. I don't understand the principle
of your distinction, as it seems to me that one could add a new protocol
rule which says that the block is invalid unless the OP Code does
results in arbitrary-item-x. The intent is to mimic CLTV or CSV
behavior, by causing something that would otherwise succeed, to fail, if
arbitrary new conditions are met.

> 
> (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 bug, if it happened as you described. I will
check when I get the chance, thanks.

> 
> Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

Yes. Sorry if that was confusing.

> 
> How is OP_BRIBE superior to just using a  OP_RETURN script? Cannot
> a sidechain scan the block for OP_RETURN attesting that the block hash
> is present in the block?

The sidechain software can indeed, but the mainchain software cannot
(without making validation of both chains part of the mainchain, which
defeats the original purpose of sidechains).

The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
Mary could provide Sam with some guarantee that Sam's sidechain block
[defined by h*] would make it into the largest chain.

So, as I see it, this needs to be a mainchain consensus rule, but one
which enforces the bare minimum criteria.


> 
>>The literal answer to your question is that mainchain Bitcoin will
> notice that, for the second withdrawal, the sum of the inputs is less
> than the sum of the outputs and they the transaction is therefore invalid.
> 
> You misunderstand.  The first withdrawal was done by double-spending,
> and exchanging your sidechain funds for mainchain funds using some
> off-chain method.  The second withdrawal is done on-chain.

If A, B, and C are transacting, and each has an account on both chains.
Then your example would be something like:

1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
for B's good or service (provided on the sidechain)
2. side:B attempts to move side-to-main with the 100 BTC, using the
lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
3. C attempts to move side-to-main, using the slow, settlement method.
4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
a withdrawal attempt (WT^)
5. The WT^ attempt is initiated on the mainchain.
6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
(upvotes / downvotes), on the mainchain.
7. The transaction either succeeds or fails.

I'm not sure, but your question seems to concern B, who exploits a reorg
that happens just after step 2. After the reorg, the sidechain chain
history will have a different side-to-main withdrawal in part 3. The
time between each of these step is very long, on the order of weeks
(summing to a length of time totaling months), for exactly this reason
(as well as to encourage people to avoid using this 'formal' method, in
favor of the cooperative LN and Atomic Swaps).

I think that this principle of scale (ie, very VERY slow withdrawals) is
important and actually makes the security categorically different.

For extraordinary DAO-like situations, disinterested mainchain miners
merely need a single bit of information (per sidechain), which is
"distress=true", and indicates to them to temporarily stop ACKing
withdrawals from the sidechain. This alone is enough to give the reorg
an unlimited amount of time to work itself out.


> 
> That said, I confused OP_h_is_in_coinbase as your method of getting out
> of the sidechain into the mainchain.  It seems, OP_h_is_in_coinbase is
> only for blind mining?

Correct

> 
> 
> 
>>I feel that my proposal is more secure, as it can operate healthily and
> quickly while using spv proofs which are much slower and much much
> easier to audit.
> 
> I don't quite understand how Drivechain handles sidechain reorgs, while
> keeping Bitcoin miners blinded.  It seems sidechains need to be known
> ("seen") by the miner, so I don't see what is being blinded by blinded
> merge mining.

Mainchain miners do need to mainta

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

[Jorge Timón via bitcoin-dev]

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 users of the base Bitcoin Core implementation.
>
> In this case, NOT enforcing BIP148 puts users at more risk. Since devs are
> divided in opinion, we should at the very least have an option to let users
> decide one way or the other.

Well, it's putting users at more risk only if for those users who
actively decided to put themselves at risk.
I also feel bip148 is rushed and that makes it more risky. I don't
want to reiterate points other have made but I don't fully agree with
all of them.
I prefer the way it is over the way it was (just activating at a given
date without forcing mining signaling), but I still think it's rushed
and unnecessarily risky (unless activating segwit was urgent, which I
think it's not, no matter how much I want it to become active as soon
as possible).
On the other hand, I support uasf and bip8 to replace bip9 for future
deployments, since bip9 made assumptions that weren't correct (like
assuming miners would always signal changes that don't harm any user
and are good for some of them).
Perhaps bip149 can be modified to activate earlier if the current
proposal is perceived as unnecessarily cautious.

Luke, I've seen you say in other forums that "bip148 is less risky
than bip149", but I think that's clearly false.

As a reminder, one of my complains about bip109 was precisely that it
was also rushed in how fast it could activate.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

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 BIP148 puts users at more risk. Since devs are 
divided in opinion, we should at the very least have an option to let users 
decide one way or the other.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Kekcoin via bitcoin-dev]

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. This to maintain backwards compatibility with the current 
deployment of BIP148 nodes. This proposal seems to be a measure to prevent a 
chainsplit, so it must make sure to avoid triggering one.

2. This should be for miners only; non-miners should not enforce this. It 
severely weakens the block-signalling activation mechanism in several ways 
(lowered threshold, short deployment timeframe, no "locked in" delay before 
activation) and by doing so opens up attack vectors for consensus-partitioning 
attacks using malicious false signalling. For non-miners that seek to take 
their fate into their own hands, enforcing BIP148 is enough.

3. Even for miners this is more risky than usual; only 31% of hashrate is 
required to false-signal the activation to fork-off honest miners. This attack 
vector is magnified by the lack of "locked in" delay that would allow laggards 
to upgrade before activation. I suggest adding in at least a 1-week lock-in 
period (given the shorter timeframes 2 weeks may eat up too much of the 
available voting time before the brick wall of BIP148 activation on August 1).

Under the assumption that this is indeed compatible with the terms of the 
Silbert agreement, we can presume the involved miners are willing to trust 
eachother more than usual so such a short lock-in period should be acceptable.

 Original Message 
Subject: [bitcoin-dev] Reduced signalling threshold activation of existing 
segwit deployment
Local Time: May 23, 2017 1:40 AM
UTC Time: May 22, 2017 10:40 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev 

I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:

"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that

The goal here is to minimize chain split risk and network disruption
while maximizing backwards compatibility and still providing for rapid
activation of segwit at the 80% threshold using bit 4.

By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.

Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki

Proposal text:

BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard 
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0


==Abstract==

This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.

==Definitions==

"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.

==Motivation==

Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].

This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.

==Specification==

While this BIP is active, all blocks must set the nVersion header top
3 bits to 001 together with bit field (1<<1) (according to the
existing segwit deployment). Blocks that do not signal as required
will be rejected.

==Deployment==

This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.

This BIP will have a start time of midnight June 1st, 2017 (epoch time
1496275200) and timeout on midnight November 15th 2017 (epoch time
1510704000). This BIP will cease to be active when segwit is
locked-in.

=== Reference implementation ===


// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}

// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainpar

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

[Karl Johan Alm via bitcoin-dev]

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,
> 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.

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. Users have,
hopefully, come to appreciate this implementation for the peer
review-based strict development process, and making a hasty decision
due to time constraints (segwit activation expiration) may have
undesirable consequences. Opinions among the regular contributors are
split on the matter, which to me is an indication we should be
cautious and consider all aspects before making a decision on the
matter.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tomas via bitcoin-dev]

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 coordination of any changes.

The BIP can be found here: 

https://github.com/tomasvdw/bips/blob/master/bip-changing-the-maximum-block%20weight-based-on-a-support-threshold.mediawiki

It is worth noting that this proposal does neither gives more power to
miners nor reduces decentralization. Miners still rely on their blocks
being accepted by economic nodes to sell their minted coins. This
proposal doesn't change that. 

Regards,
Tomas van der Wansem
bitcrust
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tier Nolan via bitcoin-dev]

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 that are owned by someone else from coinbase
to their current owners cannot be stolen by a re-org (though they can be
moved around).

With BMM, you can take the entire reserve.  Creating a group of double
spenders can help increase the reward.


>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in addition
> to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
>
>
That is a fair point.  If sidechains are how Bitcoin is scaled, then
shaking confidence in a side-chain would shake confidence in Bitcoin's
future.

I wasn't thinking of a direct miner 51% attack.  It is enough to assume
that a majority of the miners go with the highest bidder each time.

If (average fees) * (timeout) is less than the total reserves, then it is
worth it for a 3rd party to just bid for his theft fork.  Miners don't have
to be assumed to be coordinating, they just have to be assumed to take the
highest bid.

Again, I don't really think it is that different. One could interchange
> "recent txns" (those which could be double-spent within 2-3 weeks) with
> "sidechain deposit tnxs".
>

It is not "recent txns", it is recent txns that you (or your group) have
the key for.  No coordination is required to steal the entire reserve from
the sidechain.

Recent txns and money on the sidechain have the property that they are
riskier than money deep on the main chain.  This is the inherent point
about sidechains, so maybe not that big a deal.

My concern is that you could have a situation where an attack is possible
and only need to assume that the miners are indifferent.

If the first attacker who tries it fails (say after creating a fork that is
90% of the length required, so losing a lot of money), then it would
discourage others.   If he succeeds, then it weakens sidechains as a
concept and that creates the incentive for miners to see that he fails.

I wonder how the incentives work out.  If a group had 25% of the money on
the sidechain, they could try to outbid the attacker.

In fact, since the attacker, by definition, creates an illegal fork, the
effect is that he reduces the block rate for the side chain (possibly to
zero, if he wins every auction).  This means that there are more
transactions per block, if there is space, or more fees per transaction, if
the blocks are full.

In both cases, this pushes up the total fees per block, so he has to pay
more per block, weakening his attack.  This is similar to where transaction
spam on Bitcoin is self-correcting by increasing the fees required to keep
the spam going.

Is there a description of the actual implementation you decided to go with,
other than the code?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Hampus Sjöberg via bitcoin-dev]

> 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 saw some very harsh rhetoric being used against BIP148, which seems
unjustified as we have no idea yet how it all will play out. We can only
guess.

Hampus

2017-05-23 6:03 GMT+02:00 Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> I'm glad some discussion has been moved back here.
>
> 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, 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.
>
> I guess I find it all incredibly silly, but perhaps I suffer from some
> basic confusion.
>
>
>
> On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I also do not support the BIP 148 UASF, and I'd like to add to the points
>> that Greg has already raised in this thread.
>>
>> BIP 148 would introduce a new consensus rule that softforks out
>> non-segwit signalling blocks in some time period.  I reject this consensus
>> rule as both arbitrary and needlessly disruptive.  Bitcoin's primary
>> purpose is to reach consensus on the state of a shared ledger, and even
>> though I think the Bitcoin network ought to adopt segwit, I don't think
>> that concern trumps the goal of not splitting the network.
>>
>> Many BIP 148 advocates seem to start with the assumption that segwit
>> already has a lot of support, and suggest that BIP 148 does as well.
>> However I don't think it's fair or correct to separate the activation
>> proposal for segwit from the rest of the segwit proposal.  The deployment
>> parameters for segwit are consensus-critical; assuming that some other
>> deployment has consensus because it would result in the rest of the segwit
>> proposal activating is an unjustified leap.
>>
>> Even if there were no feasible alternate segwit deployment method
>> available to us, I would hesitate to recommend that the network adopt a
>> potentially consensus-splitting approach, even though I firmly believe that
>> the ideas behind segwit are fundamentally good ones.  But fortunately that
>> is not the situation we are in; we have substantially less disruptive
>> methods available to us to activate it, even if the current BIP 9
>> deployment were to fail -- such as another BIP 9 deployment in the future,
>> or perhaps a BIP 149 deployment.
>>
>> If we do pursue a "user-activated" deployment of segwit, I'd recommend
>> that we do so in a more careful way than BIP 148 or 149 currently suggest,
>> which as I understand would otherwise make very few changes to the current
>> implementation.  However, due to the BIP 9 activation assumption, the
>> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
>> the idea that miners would both enforce the rules and mine segwit blocks.
>> However, we can separate these concerns, as we started to do in the Bitcoin
>> Core 0.14.1 release, where mining segwit blocks is not required in order to
>> generally mine or signal for segwit in the software.  And we can go further
>> still: without too much work, we could make further improvements to
>> accommodate miners who, for whatever reason, don't want to upgrade their
>> systems, such as by improving block relay from pre-segwit peers [1], or
>> optimizing transaction selection for miners who are willing to enforce the
>> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
>>
>> If we would seek to activate a soft-fork with less clear miner signaling
>> (such as BIP 149), then I think such improvements are warranted to minimize
>> network disruption.  In general, we should not seek to censor hashpower on
>> the network unless we have a very important reason for doing so.  While the
>> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
>> proposal on the spectrum of "censorship attack on Bitcoin" to "benign
>> protocol upgrade", BIP 148 strikes me as closer to the former than the
>> latter.  There is simply no need here to orphan these non-signalling blocks
>> that could otherwise be used to secure the network.
>>
>> To go further: I think BIP 148 is ill-conceived even for achieving its
>> own presumed goals -- the motivation for adding a consensus rule that
>> applies to the version bits on blocks is surely for the effect such bits
>> have on older software, such as Bitcoin Core releases 0.13.1 and later.
>> Yet in trying to bring those implementations along as segwit-enforcing
>> software, BIP 148 would risk forking from such clients in t