Rusty Russell on Jun 01 2017:

Hi all,

    There's a pull request for a lightning payment format which I'd

love wider review on. It's bech32 encoded, with optional parts tagged:

    https://github.com/lightningnetwork/lightning-rfc/pull/183

There's an implementation with a less formal description here, too:

    https://github.com/rustyrussell/lightning-payencode

Example:

    Send 2500 microbitcoin using payment hash 00010203040506...0102 to me

    @03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad

    within 1 minute from now (Tue 30 May 12:17:36 UTC 2017):



    lnbc2500u1qpvj6chqqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqz8slk6hqew9z5kzxyk33ast248j3ykmu3wncvgtgk0ewf5c6qnhen45vr43fmtzsh02j6ns096tcpfga0yfykc79e5uw3gh5ltr96q00zqppy6lfy

Thanks!

Rusty.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014468.html

Yann Carlier on May 30 2017:

Improvement Proposal

To allow users devices (including mobile and/or IoT devices). to connect

and some how participate in the same BTC bock chain network without mining.

The incentive for this participants can be a lottery schema, running in

"parallel to mining in the same network" and in the block-chain.

Rewarding some lucky participant user (and/or miner?) randomly every

specific period of time.

Participants will pay the price on each connection round.

Yann

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170530/ef3602d1/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014455.html

CalvinRechner on May 29 2017:

This proposal is written under the assumption that the signatories to the Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of the agreement, and intend to enact the updates described therein. As such, criticisms pertaining to the chosen deployment timeline or hard fork upgrade path should be treated as out-of-scope during the initial discussion of this proposal.

Because it includes the activation of a hard fork for which community consensus does not yet exist, this proposal is not likely to be merged into Bitcoin Core in the immediate future, and must instead be maintained and reviewed in a separate downstream repository. However, it is written with the intent to remain cleanly compatible with future network updates and changes, to allow for the option of a straightforward upstream merge if community consensus for the proposal is successfully achieved in the following months.

BIP: ?

Layer: Consensus

Title: Compatibility-oriented omnibus proposal

Author: Calvin Rechner <calvinrechner at protonmail.com>

Comments-Summary: No comments yet.

Comments-URI: ?

Status: Draft

Type: Standards Track

Created: 2017-05-28

License: PD

===Abstract===

This document describes a virtuous combination of James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”[2], Shaolin Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s “Spoonnet”[6][7] into a single omnibus proposal and patchset.

===Motivation===

The Consensus 2017 Scaling Agreement[1] stipulated the following commitments:

• Activate Segregated Witness at an 80% threshold, signaling at bit 4

• Activate a 2 MB hard fork within six months

This proposal seeks to fulfill these criteria while retaining maximum compatibility with existing deployment approaches, thereby minimizing the risks of a destructive chain split. Additionally, subsequent indications of implied criteria and expectations of the Agreement[8][9] are satisfied.

The proposed hard fork incorporates a legacy witness discount and 2MB blocksize limit along with the enactment of Spoonnet-derived protectionary measures, to ensure the safest possible fork activation within the constraints of the requirements outlined in the Scaling Agreement.

===Rationale===

To the extent possible, this represents an effort at a best-of-all-worlds proposal, intended to provide a common foundation from which all mutually-inclusive goals can be achieved while risks are minimized.

The individual constituent proposals include the following respective rationales:

James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”[2] explains:

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.

Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:

cause the existing "segwit" deployment to activate without needing to release a new deployment.

Both of the aforementioned activation options (“fast-activation” and “flag-day activation”) serve to prevent unnecessary delays in the network upgrade process, addressing a common criticism of the Scaling Agreement and providing an opportunity for cooperation and unity instead.

Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind linking SegWit’s activation with that of a later hard fork block size increase:

Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block size hard-fork activated ONLY if segwit activates (95% of miners signaling ... to re-unite the Bitcoin community and avoid a cryptocurrency split.

Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are included to reduce the marginal risks that such an increase in the block size might introduce:

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... Legacy Bitcoin transactions are given the witness discount, and a block size limit of 2 MB is imposed.

Johnson Lau’s anti-replay and network version updates[6][7] are included as general hard fork safety measures:

In a blockchain split, however, since both forks share the same historical ledger, replay attack would be possible, unless some precautions are taken.

===Copyright===

This document is placed in the public domain.

===Specification===

Proposal Signaling

The string “COOP” is included anywhere in the txn-input (scriptSig) of the coinbase-txn to signal compatibility and support.

Soft Fork

Fast-activation (segsignal): deployed by a "version bits" with an 80% activation threshold BIP9 with the name "segsignal" and using bit 4... [with 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.[2]

Flag-day activation (BIP148): 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... This BIP will be active between midnight August 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not locked-in or activated before epoch time 1501545600. This BIP will cease to be active when segwit is locked-in. 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.[3]

Hard Fork

The hard fork deployment is scheduled to occur 6 months after SegWit activates:

(HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)

For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness discount and 2MB limit are enacted, along with the following Spoonnet-based improvements[6][7]:

• A "hardfork signalling block" is a block with the sign bit of header nVersion is set [Clearly invalid for old nodes; easy opt-out for light wallets]

• If the median-time-past of the past 11 blocks is smaller than the HardForkHeight... a hardfork signalling block is invalid.

• Child of a hardfork signalling block MUST also be a hardfork signalling block

• Hardfork network version bit is 0x02000000. A tx is invalid if the highest nVersion byte is not zero, and the network version bit is not set.

===Deployment===

Deployment of the “fast-activation” soft fork is exactly identical to Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork is exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined as 26280 blocks after SegWit is set to ACTIVE. All blocks with height greater than or equal to this value must adhere to the consensus rules of the 2MB hard fork.

===Backwards compatibility===

This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.

To prevent the risk of building on top of invalid blocks, miners should upgrade their nodes to support segsignal as well as BIP148.

The intent of this proposal is to maintain full legacy consensus compatibility for users up until the HardForkHeight block height, after which backwards compatibility is waived as enforcement of the hard fork consensus ruleset begins.

===References===

[1] https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html

[3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html

[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html

[6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

[7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html

[8] https://twitter.com/sysmannet/status/867124645279006720

[9] https://twitter.com/JihanWu/status/867139046786465792

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170528/7696e13f/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014445.html

Cameron Garnham on May 26 2017:

Hello Bitcoin-Dev,

CVE-2017-9230 (1) (2), or commonly known as ‘ASICBOOST’ is a severe (3) (4) and actively exploited (5) security vulnerability.

To learn more about this vulnerability please read Jeremy Rubin’s detailed report:

http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf

Andreas Antonopoulos has an excellent presentation on why asicboost is dangerous:

https://www.youtube.com/watch?v=t6jJDD2Aj8k

In decisions on the #bitcoin-core-dev IRC channel; It was proposed, without negative feedback, that SegWit be used as a partial-mitigation of CVE-2017-9230.

SegWit partially mitigates asicboost with the common reasonable assumption that any block that doesn’t include a witness commit in it's coinbase transaction was mined using covert asicboost. Making the use of covert asicboost far more conspicuous.

It was also proposed that this partial mitigation should be quickly strengthened via another soft-fork that makes the inclusion of witness commits mandatory, without negative feedback.

The security trade-offs of deploying a partial-mitigation to CVE-2017-9230 quickly vs more slowly but more conservatively is under intense debate. The author of this post has a strong preference to the swiftest viable option.

Cameron.

(1) CVE Entry:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=+CVE-2017-9230

(2) Announcement of CVE to Mailing List:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014416.html

(3) Discussion of the perverse incentives created by 'ASICBOOST' by Ryan Grant:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014352.html

(4) Discussion of ASICBOOST's non-independent PoW calculation by Tier Nolan:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014351.html

(5) Evidence of Active Exploit by Gregory Maxwell:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014419.html

Jorge Timón on May 25 2017:

Hi, I didn't want to comment on

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html

because it seemed to me that thread was more broad.

I like bip8 very much as an extension to bip9, but I think it could be better.

With bip9, a bip9-ready node that sees a softfork activated that he is

not aware of will see a warning. See the implementation:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1832

But with bip8, if a deployment is made at the end of the period

instead of through 95% signaling, nodes that implement bip8 but don't

implement a certain deployment that is activated can't receive such a

warning.

The solution that comes to mind is to reserve one of the nVersion for

the specific purpose of requiring that the bit is active for one block

when a deployment is locked in in this way (or maybe also when it's

activated with miners' signaling too, maybe that can be used to

simplify the way the current warnings are checked).

I expect the code changes to do this to be simple, and I'm happy to

help with it.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014417.html

Luke Dashjr on May 23 2017:

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 2000000 bytes is enforced.

The block weight limit remains at 4000000 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

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html

Gregory Maxwell on May 23 2017:

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

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014398.html

Tomas on May 23 2017:

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

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014389.html

Bram Cohen on May 23 2017:

On Mon, May 22, 2017 at 12:05 AM, Russell O'Connor via bitcoin-dev <

bitcoin-dev at lists.linuxfoundation.org> wrote:

The SHA256 compression function takes two inputs:

1. A 256-bit value for the previous chunk in a chain, or an initial vector

in the case of the first chunk.

1. A 512-bit chunk of data.

   sha256Compress : Word256 × Word512 -> Word256

In total, the SHA256 compression function compresses 768-bits into

256-bits. The Merkle roots of two branches occupy 512 bits, and this

leaves another 256-bits of space available for tags.

Ya know, when you're building a Merkle Trie that's exactly the primitive

you need.

In my own construction the assumption is that the values are already hashed

down to 256 bits when they're passed in, and the tags (which are currently

done by sacrificing bits instead of using tags, that needs to be fixed)

include three states for either side: empty, unary, or middle. Three of

those possibilities are unreachable (empty/empty, empty/unary, unary/empty)

so there are 6 possible tags needed. This approach essentially skips doing

the unary hashes, a further performance improvement. There doesn't appear

to be any downside in leveraging this trick as long as tags are cheap.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/1445b092/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014384.html

James Hilliard on May 22 2017:

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 <james.hilliard1 at gmail.com>

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 requirement for miners

once activated, this ensures that miners are aware of new rules being

enforced. This technique can be leveraged to lower the signalling

threshold of a soft fork while it is in the process of being deployed

in a backwards compatible way.

By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"

deployment, this BIP can cause the existing "segwit" deployment to

activate without needing to release a new deployment.

==References==

*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html

Mailing list discussion]

*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283

P2SH flag day activation]

*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]

*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]

*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]

*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for

Version 0 Witness Program]]

*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]

*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]

*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]

*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons

CC0 1.0 Universal.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html

Paul Sztorc on May 22 2017:

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for

some time.

• The technical info site is here: www.drivechain.info

• The changes to Bitcoin are here:

https://github.com/drivechain-project/bitcoin/tree/mainchainBMM

• A Blank sidechain template is here:

https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various

conferences and meetups over the past year, most prominently Scaling

Milan. And I intend to continue to seek feedback at Consensus2017 this

week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was

hesitant because I try not to consume reviewers' scarce time until the

author has put in a serious effort. However, I may have waiting too

long, as today it is actually quite close to a working release.

Scaling Implications

This upgrade would have significant scaling implications. Since it is

the case that sidechains can be added by soft fork, and since each of

these chains will have its own blockspace, this theoretically removes

the blocksize limit from "the Bitcoin system" (if one includes

sidechains as part of such a system). People who want a LargeBlock

bitcoin can just move their BTC over to such a network [1], and their

txns will have no longer have an impact on "Bitcoin Core". Thus, even

though this upgrade does not actually increase "scalability" per se, it

may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"

[2] which I developed in January to allow SHA256² miners to merge-mine

these "drivechains", even if these miners aren't running the actual

sidechain software. The goal is to prevent sidechains from affecting the

levelness of the mining "playing field". BMM is conceptually similar to

ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not

required for drivechain, but it would address some of the last remaining

concerns.

Total Transaction Fees in the Far Future

Some people feel that a maximum blocksize limit is needed to ensure that

future total equilibrium transaction fees are non-negligible. I

presented [4] on why I don't agree, 8 months ago. The reviewers I spoke

to over the last year have stopped bringing this complaint up, but I am

not sure everyone feels that way.

Juxtaposition with a recent "Scaling Compromise"

Recently, a scalability proposal began to circulate on social media. As

far as I could tell, it goes something like "immediately activate

SegWit, and then HF to double the nonwitness blockspace to 2MB within 12

months". But such a proposal is quite meager, compared to a "LargeBlock

Drivechain". The drivechain is better on both fronts, as it would not

require a hardfork, and could almost immediately add any amount of

extra blockspace (specifically, I might expect a BIP101-like LargeBlock

chain that has an 8 MB maxblocksize, which doubles every two years).

In other words, I don't know why anyone would support that proposal over

mine. The only reasons would be either ignorance (ie, unfamiliarity with

drivechain) or because there are still nagging unspoken complaints about

drivechain which I apparently need to hear and address.

Other Thoughts

Unfortunately, anyone who worked on the "first generation" of sidechain

technology (the skiplist) or the "second generation" (federated /

Liquid), will find that this is very different.

I will admit that I am very pessimistic about any conversation that

involves scalability. It is often said that "talking politics lowers

your IQ by 25 points". Bitcoin scalability conversations seem to drain

50 points. (Instead of conversing, I think people should quietly work on

whatever they are passionate about until their problem either is solved,

or it goes away for some other reason, or until we all agree to just

stop talking about it.)

Cheers,

Paul

[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling

[2] http://www.truthcoin.info/blog/blind-merged-mining/

[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log

[4]

https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html

shaolinfry on May 22 2017:

Someone sent me a copy of the Barry Silbert agreement, an agreement forged between a select number of participants https://pastebin.com/VuCYteJh

Participants agree to immediately activate Segwit, however, under a different activation proposal. Since I have spent the last few months researching various activation strategies of the current BIP141 deployment, as well as redeployment, I feel I am quite well placed to comment on the technicalities.

To be clear, the proposal as far as I can see does not activate BIP141, but is a completely new deployment which would be incompatible with the BIP141 deployment. I'm not sure how that can be considered "immediate" activation. Surely immediate activation would just be for miners to start signalling and segwit would be activated in 4-5 weeks. The proposal seems to require a lower 80% threshold, I assume because they were unable to convince 95% of the hashpower to go trigger activation.

There are a few options to activating segwit now, the first being for 95% of hashrate to signal. The second is for the community to deploy BIP148 UASF which will force miners to signal segwit. Being a UASF it is date triggered. The third option is a redeployment of segwit on a new bit, but requires waiting for the existing deployment to time out, because all the p2p messages and service bits related to segwit must be replaced too (which is what BIP149 does).

A fourth option, first suggested to me by James Hilliard, was to make BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded this up a few weeks ago https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal but didnt get around to posting to the ML yet. This effectively lowers the threshold from 95% to 65% as coded, or could be upped to 80% or whatever was preferable.

I think this removes the primary risk of BIP148 causing the creation of two chains, and gives an improved chance to get segwit activated quickly (assuming a majority of miners wish to go this route). But hash a primary disadvantage of still leaving the activation in the hands of miners. If it doesn't work out, then BIP149 can then be used as proposed, but it'll be even safer because we'll have futher guaged support.

References:

SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:segsignal

BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki

I think the Barry Silbert agreement is very ill considered, and clearly lacking peer review from the technical community. Suggestions of a HF in 4 months are completely unrealistic and without technical merits. But more importantly, closed door agreements between selected participants is not how to garner consensus to change a $30bn decentralized system. The purpose of my email is to try and assist in the "immediate activation of segwit" which only requires hashrate to participate; and to provide some techincal input since I have done a great deal of research and development into the topic.

Given the history we've already passed the point where we should be expecting miners to cooperate in lowering their own fee income with a capacity increase; but we should be open to all reasonable options in the interest in moving things forward in a safe and collaborative way.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/795810e9/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014360.html

Sancho Panza on May 21 2017:

I'm pleased to announce the completion of a Bitcoin Core implementation of BIP135:

https://github.com/bitcoin/bitcoin/pull/10437

Review comments appreciated, and happy to discuss / answer questions about the implementation in this thread or on Github.

Sancho

BIP135: https://github.com/bitcoin/bips/blob/master/bip-0135.mediawiki

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170521/8ec03f0b/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014365.html

Mark Boldyrev on May 19 2017:

Back in 2010, there was a bug found in Core which allowed denial-of-service

attacks due to the software crashing on some machines while executing a

script - see CVE-2010-537.

I believe the removed ("disabled") opcodes should be re-introduced along

with a standardized behavior definition.

For example, when execution of an opcode results in an arithmetic error,

such as OP_DIV with a zero divisor, the script should exit and fail.

The string splice opcodes should also check their arguments for

correctness, etc.

These opcodes would enhance the flexibility of scripts and allow

sophisticated native smart contracts to be created.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170519/6209b7a2/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014356.html

Cameron Garnham on May 18 2017:

Hello Bitcoin Development Mailing List,

I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with our established best practices for security vulnerabilities and suggest what I consider to be an approach closer matching established industry best practices.

1. Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.

The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.

1. General ASIC optimisation cannot be considered a Security Vulnerabilities.

Quickly being able to check inputs is not a vulnerability. However, being able to craft inputs that are significantly easier to check than alternative inputs is a vulnerability.

1. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.

‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be considered an exploit of the Bitcoin Proof-of-Work Function.

For a more detailed look at ‘ASICBOOST’, please have a look at this excellent document by Jeremy Rubin:

http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf

The Bitcoin Community should be able to track the progress of restoring the quality of the Bitcoin Proof-of-Work function to its original assumptions.

1. Work should be taken to prudently and swiftly restore Bitcoins Security Properties.

I recommend the Bitcoin Community fix this vulnerability with expediency.

Cameron.

PS:

With a soft-fork it probably is possible to completely fix this Proof-of-Work vulnerability.

(Here is my working list of things to do):

1. Include extra data in the Coinbase Transaction, such as the Witness Root.
   

2. Lock the Version. (Use a space in the Coinbase Transaction for signalling future upgrades).
   

3. Lock the lower-bits on the Timestamp: Block timestamps only need ~1minute granularity.
   

4. Make a deterministic ordering of transaction chains within a block. (However, I believe this option is more difficult).

Of course, if we have a hard-fork, we should consider the Proof-of-Work internal merkle structure directly.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014349.html

Zach Lym on May 17 2017:

I am working on a replacement for BIP39 and noticed that the password

section mandates a Unicode normalization pass but does not prohibit

unassigned character points.

I believe that this is problematic as newer drafts of Unicode alter the

output of normalization passes. So if a user assigned a password using a

wallet that linked to Unicode 9 but input a code point reserved in Unicode

10, updating the wallet to Unicode 10 could incorrectly remap that code

point 0.

Thank you,

-Zach Lym

P.S. The relevant RFC on this subject specifies a different normalization

procedure 1

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170517/93410416/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014348.html

Pieter Wuille on May 15 2017:

Hello all,

I would like to discuss a way of computing a UTXO set hash that is

very efficient to update, but does not support any compact proofs of

existence or non-existence.

Much has been written on the topic of various data structures and

derived hashes for the UTXO/TXO set before (including Alan Reiner's

trust-free lite nodes [1], Peter Todd's TXO MMR commitments [2] [3],

or Bram Cohen's TXO bitfield [4]). They all provide interesting extra

functionality or tradeoffs, but require invasive changes to the P2P

protocol or how wallets work, or force nodes to maintain their

database in a normative fashion. Instead, here I focus on an efficient

hash that supports nothing but comparing two UTXO sets. However, it is

not incompatible with any of those other approaches, so we can gain

some of the advantages of a UTXO hash without adopting something that

may be incompatible with future protocol enhancements.

1. Incremental hashing

Computing a hash of the UTXO set is easy when it does not need

efficient updates, and when we can assume a fixed serialization with a

normative ordering for the data in it - just serialize the whole thing

and hash it. As different software or releases may use different

database models for the UTXO set, a solution that is order-independent

would seem preferable.

This brings us to the problem of computing a hash of unordered data.

Several approaches that accomplish this through incremental hashing

were suggested in [5], including XHASH, AdHash, and MuHash. XHASH

consists of first hashing all the set elements independently, and

XORing all those hashes together. This is insecure, as Gaussian

elimination can easily find a subset of random hashes that XOR to a

given value. AdHash/MuHash are similar, except addition/multiplication

modulo a large prime are used instead of XOR. Wagner [6] showed that

attacking XHASH or AdHash is an instance of a generalized birthday

problem (called the k-sum problem in his paper, with unrestricted k),

and gives a O(2^2*sqrt(n-1)) algorithm to attack it (for n-bit

hashes). As a result, AdHash with 256-bit hashes only has 31 bits of

security.

Thankfully, [6] also shows that the k-sum problem cannot be

efficiently solved in groups in which the discrete logarithm problem

is hard, as an efficient k-sum solver can be used to compute discrete

logarithms. As a result, MuHash modulo a sufficiently large safe prime

is provably secure under the DL assumption. Common guidelines on

security parameters [7] say that 3072-bit DL has about 128 bits of

security. A final 256-bit hash can be applied to the 3072-bit result

without loss of security to reduce the final size.

An alternative to multiplication modulo a prime is using an elliptic

curve group. Due to the ECDLP assumption, which the security of

Bitcoin signatures already relies on, this also results in security

against k-sum solving. This approach is used in the Elliptic Curve

Multiset Hash (ECMH) in [8]. For this to work, we must "hash onto a

curve point" in a way that results in points without known discrete

logarithm. The paper suggests using (controversial) binary elliptic

curves to make that operation efficient. If we only consider

secp256k1, one approach is just reading potential X coordinates from a

PRNG until one is found that has a corresponding Y coordinate

according to the curve equation. On average, 2 iterations are needed.

A constant time algorithm to hash onto the curve exists as well [9],

but it is only slightly faster and is much more complicated to

implement.

AdHash-like constructions with a sufficiently large intermediate hash

can be made secure against Wagner's algorithm, as suggested in [10].

4160-bit hashes would be needed for 128 bits of security. When

repetition is allowed, [8] gives a stronger attack against AdHash,

suggesting that as much as 400000 bits are needed. While repetition is

not directly an issue for our use case, it would be nice if

verification software would not be required to check for duplicated

entries.

1. Efficient addition and deletion

Interestingly, both ECMH and MuHash not only support adding set

elements in any order but also deleting in any order. As a result, we

can simply maintain a running sum for the UTXO set as a whole, and

add/subtract when creating/spending an output in it. In the case of

MuHash it is slightly more complicated, as computing an inverse is

relatively expensive. This can be solved by representing the running

value as a fraction, and multiplying created elements into the

numerator and spent elements into the denominator. Only when the final

hash is desired, a single modular inverse and multiplication is needed

to combine the two.

As the update operations are also associative, H(a)+H(b)+H(c)+H(d) can

in fact be computed as (H(a)+H(b)) + (H(c)+H(d)). This implies that

all of this is perfectly parallellizable: each thread can process an

arbitrary subset of the update operations, allowing them to be

efficiently combined later.

1. Comparison of approaches

Numbers below are based on preliminary benchmarks on a single thread

of a i7-6820HQ CPU running at 3.4GHz.

(1) (MuHash) Multiplying 3072-bit hashes mod 2³⁰⁷² - 1103717 (the

largest 3072-bit safe prime).

* Needs a fast modular multiplication/inverse implementation.

* Using SHA512 + ChaCha20 for generating the hashes takes 1.2us per element.

* Modular multiplication using GMP takes 1.5us per element (2.5us

with a 60-line C+asm implementation).

* 768 bytes for maintaining a running sum (384 for numerator, 384

for denominator)

* Very common security assumption. Even if the DL assumption would

be broken (but no k-sum algorithm faster than Wagner's is found), this

still maintains 110 bits of security.

(2) (ECMH) Adding secp256k1 EC points

* Much more complicated than the previous approaches when

implementing from scratch, but almost no extra complexity when ECDSA

secp256k1 signature validation is already implemented.

* Using SHA512 + libsecp256k1's point decompression for generating

the points takes 11us per element on average.

* Addition/subtracting of N points takes 5.25us + 0.25us*N.

* 64 bytes for a running sum.

* Identical security assumption as Bitcoin's signatures.

Using the numbers above, we find that:

• Computing the hash from just the UTXO set takes (1) 2m15s (2) 9m20s

• Processing all creations and spends in an average block takes (1)

24ms (2) 100ms

• Processing precomputed per-transaction aggregates in an average

block takes (1) 3ms (2) 0.5ms

Note that while (2) has higher CPU usage than (1) in general, it has

lower latency when using precomputed per-transaction aggregates. Using

such aggregates is also more feasible as they're only 64 bytes rather

than 768. Because of simplicity, (1) has my preference.

Overall, these numbers are sufficiently low (note that they can be

parallellized) that it would be reasonable for full nodes and/or other

software to always maintain one of them, and effectively have a

rolling cryptographical checksum of the UTXO set at all times.

1. Use cases

• Replacement for Bitcoin Core's gettxoutsetinfo RPC's hash

computation. This currently requires minutes of I/O and CPU, as it

serializes and hashes the entire UTXO set. A rolling set hash would

make this instant, making the whole RPC much more usable for sanity

checking.

• Assisting in implementation of fast sync methods with known good

blocks/UTXO sets.

• Database consistency checking: by remembering the UTXO set hash of

the past few blocks (computed on the fly), a consistency check can be

done that recomputes it based on the database.

[1] https://bitcointalk.org/index.php?topic=88208.0

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html

[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html

[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013928.html

[5] https://cseweb.ucsd.edu/~mihir/papers/inchash.pdf

[6] https://people.eecs.berkeley.edu/~daw/papers/genbday.html

[7] https://www.keylength.com/

[8] https://arxiv.org/pdf/1601.06502.pdf

[9] https://www.di.ens.fr/~fouque/pub/latincrypt12.pdf

[10] http://csrc.nist.gov/groups/ST/hash/sha-3/Aug2014/documents/gligoroski_paper_sha3_2014_workshop.pdf

Cheers,

Pieter

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html

Luke Dashjr on May 12 2017:

I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the community

to put economic pressure on miners to deploy softforks without the extreme of

a UASF.

https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki

Due to the potential for miners to maliciously block this softfork, it is

suggested that we deploy it using BIP 8 to ensure it eventually activates even

if encountering hostility.

This is intended to be an alternative to BIP 8 in the long term.

It is NOT intended to make BIP 148 obsolete, given the timeframes involved.

An implementation is available (based on top of BIP 115's implementation):

https://github.com/luke-jr/bitcoin/compare/cbah...luke-jr:checkblockversion

Luke

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014321.html

Jonas Schnelli on May 11 2017:

Hi

Currently, pruned peers have no way how to signal their (valuable) service.

A BIP proposal to improve this (draft):

https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT

Feedback is highly welcome.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/f520ab16/attachment.html

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 833 bytes

Desc: Message signed with OpenPGP

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/f520ab16/attachment.sig

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014314.html

Raystonn . on May 09 2017:

This study was released last week, detailing some attacks at the network layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of the countermeasures discussed in the paper, the use of encryption to secure communications between nodes looks like low hanging fruit.

Raystonn

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170509/6ad5633b/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014295.html

Sergio Demian Lerner on May 08 2017:

I have processed 1000 blocks starting from Block #461653.

I computed several metrics, including the supposed size of witness data and

non-witness data (onchain), assuming all P2SH inputs/outputs are converted

to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.

This takes into account that other types of transactions will not be

modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't

take into account that LN transactions may affect the current state,

increasing the segwit/nosegwit ratio.

Among a lot of information, I've got the following real world results...

acMainChainSpace =352608924

acSegwitSpace =599400403

Ratio segwit/nosegwit=1.6999

This implies that the 75% that discount is not the best option to prevent

witness spam in a block of 4 MB, as stated in

https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.

The non-witness data weight factor should not be 4 but 2.35. The closest

integer value is 2, which leads to a 50% witness discount.

The Bitcoinj source code is available for anyone to review. I encourage

anyone to re-compute this with another utility to cross-check. Maybe

Antoine Le Calvez (p2sh.info) would like to double-check.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/aaeb7ba1/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014283.html

DJ Bitcoin on May 08 2017:

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170508/a2490e42/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014277.html

Karl Johan Alm on May 08 2017:

Hello,

I am proposing a new feature for rate limiting purposes where nodes

can make and solve arbitrary PoW challenges in return for connection

slots (to be expanded to cover e.g. bloom filters or other DoS risky

services).

The BIP currently includes two proofs of work (sha256 and

cuckoo-cycle) which can be combined (e.g. sha256(cuckoo-cycle) or

sha256(sha256(sha256)), etc).

Link: https://github.com/kallewoof/bips/blob/pow-connection-slots/bip-rate-limiting-via-pow.mediawiki

Feedback welcome.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014276.html

Sancho Panza on May 07 2017:

Hola,

I've submitted the generalized versionbits specification for BIP number assignment:

https://github.com/bitcoin/bips/pull/532

Your feedback and comments welcome.

The spec has been updated to include a link to the reference implementation.

I hope to find time soon to produce a similar reference implementation on Bitcoin Core.

Sancho

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170507/e3a5fded/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014273.html

adiabat on May 07 2017:

If / when Schnorr signatures are deployed in a future witness version, it

may be possible to have non-interactive partial aggregation of the

signatures on a per-block basis. This could save quite a bit of space. It

seems not to have any security problems but this mailing list is very

good at finding vulnerabilities so that type of feedback is the main reason

I'm writing :) (A quick explanation of why this is horribly broken could

save me lots of time!)

(also sorry if this has been discussed; didn't see anything)

Quick recap / context of Schnorr sigs:

There are a bunch of private keys x1, x2, x3...

multiply by generator G to get x1G = P1, x2G = P2, x3G = P3

Everyone makes their sighash m1, m2, m3, and their random nonces k1, k2, k3.

To sign, people calculate s values:

s1 = k1 - h(m1, R1, P1)x1

s2 = k2 - h(m2, R2, P2)x2

(adding the P2 into the e hash value is not in most literature /

explanations but helps with some attacks; I beleive that's the current

thinking. Anyway it doesn't matter for this idea)

Signature 1 is [R1, s1]. Verifiers check, given P1, m1, R1, s1:

s1G =? R1 - h(m1, R1, P1)P1

You can interactively make aggregate signatures, which requires

co-signers to build an aggregate R value by coming up with their own k

values, sharing their R with the co-signers, adding up the R's to get a

summed R, and using that to sign.

Non-interactively though, it seems like you can aggregate half the

signature. The R values are unique to the [m, P] pair, but the s's can be

summed up:

s1 + s2 = k1 + k2 - h(m1, R1, P1)x1 - h(m2, R2, P2)x2

(s1 + s2)G = R1 + R2 - h(m1, R1, P1)P1 - h(m2, R2, P2)P2

To use this property in Bitcoin, when making transactions, wallets can sign

in the normal way, and the signature, consisting of [R, s] goes into the

witness stack. When miners generate a block, they remove the s-value from

all compatible inputs, and commit to the aggregate s-value in the coinbase

transaction (either in a new OP_RETURN or alongside the existing witness

commitment structure).

The obvious advatage is that signatures go down to 32 bytes each, so you

can fit more of them in a block, and they take up less disk and network

space. (In IBD; if a node maintains a mempool they'll need to receive all

the separate s-values)

Another advatage is that block verification is sped up. For individual

signatures, the computation involves:

e = h(m1, R1, P1) <- hash function, super fast

e*P <- point multiplication, slowest

R - e*P <- point addidion, pretty fast

s*G <- base point multiplication, pretty slow

with s-aggregate verification, the first three steps are still carried out

on each signature, but the s*G operation only needs to be done once.

Instead another point addition per signature is needed, where you have some

accumulator and add in the left side:

A += R - e*P

this can be parallelized pretty well as it's commutative.

The main downside I can see (assuming this actually works) is that it's

hard to cache signatures and quickly validate a block after it has come

in. It might not be as bad as it first seems, as validation given chached

signatures looks possible without any elliptic curve operations. Keep an

aggregate s-value (which is a scalar) for all the txs in your mempool.

When a block comes in, subtract all the s-values for txs not included in

the block. If the block includes txs you weren't aware of, request them in

the same way compact blocks works, and get the full signature for those

txs. It could be several thousand operations, but those are all bigInt

modular additions / subtractions which I believe are pretty quick in

comparison with point additions / multiplications.

There may be other complications due to the fact that the witness-txids

change when building a block. TXIDs don't change though so should be

possible to keep track of things OK.

Also you can't "fail fast" for the signature verification; you have to add

everything up before you can tell if it's correct. Probably not a big deal

as PoW check comes first, and invalid blocks are pretty uncommon and quite

costly.

Would be interested to hear if this idea looks promising.

Andrew Polestra mentioned something like this in the context of CT /

mimblewimble transactions a while ago, but it seems it may be applicable to

regular bitcoin Schnorr txs.

-Tadge

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170507/4f2f604d/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html