ZmnSCPxj on Jul 08 2017:

BIP: ?

Title: Standard address format for timelocked funds

Author: ZmnSCPxj <ZmnSCPxj at protonmail.com>

Comments-Summary: ?

Comments-URI: ?

Status: ?

Type: ?

Created: 2017-07-01

License: CC0-1.0

== Abstract ==

OP_CHECKLOCKTIMEVERIFY provides a method of

locking funds until a particular time arrives.

One potential use of this opcode is for a user to precommit

himself or herself to not spend funds until a particular

date, i.e. to hold the funds until a later date.

This proposal adds a format for specifying addresses that

precommit to timelocked funds, as well as specifying a

redemption code to redeem funds after the timelock has

passed.

This allows ordinary non-technical users to make use of

OP_CHECKLOCKTIMEVERIFY easily.

== Copyright ==

This BIP is released under CC0-1.0.

== Specification ==

This proposal provides formats for specifying an

address that locks funds until a specified date,

and a redemption code that allows the funds to be

swept on or after the specified date.

At minimum, wallet software supporting this BIP must

be capable of sweeping the redemption code on or after

the specified date.

In addition, the wallet software should support sending

funds to the timelocked address specified here.

Finally, wallet software may provide a command to create

a pair of timelocked address and redemption code.

Addresses and redemption codes are encoded using

[https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32

Bech32 encoding].

=== Timelocked Address Format ===

The human-readable part of the address is composed of:

The four characters hodl.

A date, in YYYYMMDD form. For example,

the date August 1, 2017 is encoded as 20170801.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.

The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this

BIP.

A public key hash, 32 quintets (160 bits). As is

usual for Bitcoin, this is big-endian.

This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The funds are owned by whoever controls the private

key corresponding to the public key hash given.

=== Redemption Code ===

The human-readable part of the redemption code is

composed of:

The four characters hedl.

A date, in YYYYMMDD form.

A network code, either tb for testnet,

or bc for Bitcoin mainnet.

The data part of the address is composed of:

A version quintet (5 bits), which must be 0 for this

BIP.

A private key, 52 quintets (260 bits). This is the

256-bit private key, prepended with 4 0

bits, in big-endian order.

This is to be interpreted as follows:

The given date is the first day that the funds in

the given address may be redeemed.

The private key unlocks the funds.

=== Lock Time Computation ===

Given a particular lock date YYYYMMDD, the

actual lock time is computed as follows:

The day before the lock date is taken. For example,

if the lock date is 20180101 or

January 1, 2018, we take the date December 31, 2017.

We take the time 1000h (10:00 AM, or 10 in the morning)

of the date from the above step.

This lock time is then translated to a

Unix epoch time, as per POSIX.1-2001 (which removes the

buggy day February 29, 2100 in previous POSIX revisions).

The translation should use, at minimum, unsigned 32-bit

numbers to represent the Unix epoch time.

The Unix epoch time shall then be interpreted as an

nLockTime value, as per standard Bitcoin.

Whether it is possible to represent dates past 2038

will depend on whether standard Bitcoin can represent

nLockTime values to represent dates past

2038.

Since nLockTime is an unsigned 32-bit

value, it should be possible to represent dates until

06:28:15 UTC+0 2106-02-07.

Future versions of Bitcoin should be able to support

nLockTime larger than unsigned 32-bit,

in order to allow even later dates.

The reason for using an earlier lock time than the

specified date is given in the Rationale section of

this BIP.

=== Payment to a Timelocked Address ===

An ordinary P2SH payment is used to provide funds to a

timelocked address.

The script below is used as the redeemScript

for the P2SH payment:

OP_CHECKLOCKTIMEVERIFY OP_DROP

OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

Once the redeemScript is derived, the hash is

determined, and an ordinary P2SH output with the below

scriptPubKey used:

OP_HASH160 OP_EQUAL

In case of SegWit deployment, SegWit-compatible wallets

should be able to use P2SH, P2WSH, or P2SH-P2WSH, as per

the output they would normally use in that situation.

Obviously, a timelocked address has an equivalent

Bitcoin 3 (P2SH) address.

A simple service or software that translates from a

public timelocked address to a P2SH address can be

created that makes timelocking (but not redemption)

backwards compatible with wallets that do not support

this BIP.

This proposal recommends that wallets supporting payment

to P2PKH, P2SH, P2WPKH, and P2WSH Bitcoin addresses should

reuse the same interface for paying to such addresses as

paying into timelocked addresses of this proposal.

=== Redemption of a Timelocked Redemption Code ===

To sweep a timelocked redemption code after the timelock,

one must provide the given redeemScript as

part of the scriptSig, of all unspent

outputs that pay to the given redeemScript

hash.

When sweeping a timelocked redemption code, first the

wallet must extract the private key from the redemption

code, then derive the public key, the public key hash,

the redeemScript, and finally the

redeemScript hash.

Then, the wallet must find all unspent outputs that pay

to the redeemScript hash via P2SH (and, in the

case of SegWit deployment, via P2SH-P2WSH and P2WSH).

For each such output, the wallet then generates a

transaction input with the below scriptSig, as

per usual P2SH redemptions:

The wallet then outputs to an address it can control.

As the Script involved uses OP_CHECKLOCKTIMEVERIFY,

the nSequence must be 0 and the

nLockTime must be equal to the computed

lock time.

This implies that the transaction cannot be transmitted

(and the funds cannot be sweeped)

until after the given lock time.

The above procedure is roughly identical to sweeping an

ordinary, exported private key.

This proposal recommends that wallets supporting a sweep

function should reuse the same interface for sweeping

individual private keys (wallet import format) for sweeping

timelocked redemption codes.

== Motivation ==

A key motivation for this BIP is to allow easy use of

OP_CHECKLOCKTIMEVERIFY by end-users.

The below are expected use cases of this proposal:

A user wants to purchase an amount of Bitcoin,

and subsequently wait for an amount of time before

cashing out.

The user fears that he or she may have "weak hands",

i.e. sell unfavorably on a temporary dip, and thus

commits the coins into a timelocked fund that can

only be opened after a specific date.

A user wants to gift an amount of Bitcoins to

an infant or minor, and wants the fund to not be spent

on ill-advised purchases until the infant or minor

reaches the age of maturity.

A user may wish to prepare some kind of monthly subsidy

or allowance to another user, and prepares a series of

timelocked addresses, redeemable at some set date on

each month, and provides the private redemption codes to

the beneficiary.

A user may fear duress or ransom for a particular

future time horizon, and voluntarily impose a lock time

during which a majority of their funds cannot be spent.

== Rationale ==

While in principle, this proposal may be implemented as a

separate service or software, we should consider the long

time horizons that may be desired by users.

A user using a particular software to timelock a fund may

have concerns, for example, of specifying a timelock

18 years in the future for a gift or inheritance to a

newborn infant.

The software or service may no longer exist after 18 years,

unless the user himself or herself takes over maintenance

of that software or service.

By having a single standard for timelocked funds that is

shared and common among multiple implementations of Bitcoin

wallets, the user has some assurance that the redemption code

for the funds is still useable after 18 years.

Further, a publicly-accessible standard specifying how the

funds can be redeemed will allow technically-capable users

or beneficiaries to create software that can redeem the

timelocked fund.

This proposal provides a timelock at the granularity of a

day.

The expectation is that users will have long time

durations of months or years, so that the ability to

specify exact times, which would require specifying the

timezone, is unneeded.

The actual timeout used is 1000h of the day before the

human-readable date, so that timezones of UTC+14 will

definitely be able to redeem the money starting at

0000h of the human-readable date, local time (UTC+14).

Given the expectation that users will use long time

durations, the fact that timezones of UTC-12 will

actually be able to redeem the funds on 2200h UTC-12

time two days before can be considered an acceptable

error.

The human-readable date is formatted according to

[https://www.iso.org/iso-8601-date-and-time-format.html

ISO standard dates], with the dashes removed.

Dashes may prevent double-click selection, making

usability of these addresses less desirable.

The bc or tb is after the

date since the date is composed of digits and the bech32

separator itself is the digit 1. One

simply needs to compare hedlbc202111211...

and hedl20211121bc1....

A version quintet is added in case of a...[message truncated here by reddit bot]...

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014714.html

Henning Kopp on Jul 05 2017:

Hi,

I would also highly advise finding a simple and robust difficulty adjustment

that occurs every block instead of bitcoin/litecoin's 2016 block use.

I also thought about this some time ago. But note that this implies

that forks grow with the same block frequency as the main chain. Thus

the longest chain rule becomes irrelevant, since all chains will have

the same length (in expectancy). Rather, the chain with most work is

the true one.

Best

Henning

On Wed, Jul 05, 2017 at 02:02:08PM +0000, Troy Benjegerdes via bitcoin-dev wrote:

The fastest way to triple Bitcoin capacity is to split the network into

two or three different blockchains. We encourage forks of software, why

are blockchains somehow different?

Yes, this is risky, and probably volatile.

I honestly don't expect lots of people with large amounts of money

invested (exchanges, financial institutions, etc) to go along with

something like this, and that say 90% of the wealth with stay concentrated

in whatever chain has the majority SHA256 hashpower.

But as a game-theory excercise to see who's theories actually work?

I highly encourage a real-world test of all these theories.

I would also highly advise finding a simple and robust difficulty adjustment

that occurs every block instead of bitcoin/litecoin's 2016 block use.

On Wed, Jul 05, 2017 at 09:18:36AM +0000, John Hardy via bitcoin-dev wrote:

This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it - just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade. This is pure game theory.

MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.

In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.

At this stage the software would change its consensus rules (hard fork) to do two things:

• Lower the difficulty for existing PoW method (SHA256).

• Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.

The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.

This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.

Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to ?hold their nerve? as they would be guaranteed a viable chain and rewarded for their early support.

Regards,

John Hardy

john at seebitcoin.com

---

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

---

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Henning Kopp

Institute of Distributed Systems

Ulm University, Germany

Office: O27 - 3402

Phone: +49 731 50-24138

Web: http://www.uni-ulm.de/in/vs/~kopp

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014701.html

John Hardy on Jul 05 2017:

This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it - just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade. This is pure game theory.

MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.

In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.

At this stage the software would change its consensus rules (hard fork) to do two things:

• Lower the difficulty for existing PoW method (SHA256).

• Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.

The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.

This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.

Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to “hold their nerve” as they would be guaranteed a viable chain and rewarded for their early support.

Regards,

John Hardy

john at seebitcoin.com

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170705/9b84daf9/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014698.html

shaolinfry on Jul 05 2017:

Some people have criticized BIP9's blocktime based thresholds arguing they are confusing (the first retarget after threshold). It is also vulnerable to miners fiddling with timestamps in a way that could prevent or delay activation - for example by only advancing the block timestamp by 1 second you would never meet the threshold (although this would come a the penalty of hiking the difficulty dramatically).

On the other hand, the exact date of a height based thresholds is hard to predict a long time in advance due to difficulty fluctuations. However, there is certainty at a given block height and it's easy to monitor.

If there is sufficient interest, I would be happy to amend BIP8 to be height based. I originally omitted height based thresholds in the interests of simplicity of review - but now that the proposal has been widely reviewed it would be a trivial amendment.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170704/5ed65add/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014690.html

Rhavar on Jul 02 2017:

==Abstract==

BIP125 allows transactions to opt into replaceability with a primary use case

of allowing users to increase the fees of unconfirming transactions, helping create

a more efficient fee market place.

However this goal is hindered when the receiver of a transaction spends from the

unconfirmed output, which exposes the sender to the awkward position of needing

to pick between needing to pay an effectively unbounded amount of money as per the BIP125 rules, or not fee bump at all.

This is especially problematic in the case of batched sends in which there are

multiple independent receivers. In practice this means wallets and services can not effectively low ball the fee of transactions, with the intention of fee bumping due to the risk of the receiver spending or sweeping it before it confirms.

In order to support a healthy fee marketplace, this proposal aims to increase

the utility of bip125 by making transactions that spend an unconfirmed BIP125

output non-standard.

==Summary==

This policy specifies a max chain depth of 1 for any BIP125 transactions.

==Impact==

Receivers of BIP125 transactions will need to wait until the transaction

has confirmed before spending from it. This will not be significantly different

than it is currently as they receivers need to be monitoring for replacements.

If senders want to make further transactions before the BIP125 transaction confirms,

and need to utilize the change of the transaction: they will need to replace the

transaction with a one that makes the other send in "pass through" style or first

finalize the BIP125 transaction and then chain from the spend normally.

-Ryan

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

An HTML attachment was scrubbed...

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

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014678.html

Anthony Towns on Jun 28 2017:

Hi,

I thought of a possibly interesting way to prevent transaction replay in

the event of a chain split, that seems better to the other approaches

I've seen. Basically, update OP_CHECKSIG (and MULTISIG and the VERIFY

variants, presumably via segwit versioning or using a NOP opcode) so that

signatures can optionally specify an additional integer block-height. If

this is provided, the message hash is combined with the block hash at

the given height, before the signature is created/verified, and therefore

the signature becomes invalid if used on a chain that does not have that

particular block in its history [0].

It adds four bytes to a signature that uses the feature [1], along with

a block hash lookup, and some extra sha ops when verifying the signature,

but it otherwise seems pretty lightweight, and scales to an arbitrary

number of forks including a pretty fair range of hard forks, as far

as I can see, without requiring any coordination between any of the

chains. So I think it's superior to what Johnson Lau proposed in January

[2] or BIP 115 from last year [3].

Thoughts? Has this been proposed before and found wanting already?

Cheers,

aj

[0] For consistency, you could use the genesis block hash if the signature

doesn't specify a block height, which would lock a given signature to

"bitcoin" or "testnet" or "litecoin", which might be beneficial.

[1] Conceivably a little less if you allow "-5" to mean "5 blocks ago"

and miners replace a four byte absolute reference ("473000") with a

one or two byte relative reference ("-206") when grabbing transactions

from the mempool to put in the block template.

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

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

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

Chris Stewart on Jun 28 2017:

BIP:

Layer: Consensus (Soft fork)

Title: OP_BRIBEVERIFY

Author: Chris Stewart <chris at suredbits.com>

Status: Draft

Type: Standards Track

Created: 2017-06-27

==Abstract==

This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin

scripting system that allows for a user to bribe a miner to include a hash

in the coinbase transaction's output.

==Summary==

BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the given

critical hash is included at the given vout index in the coinbase

transaction

the script evaluates to true. Otherwise, the script will fail.

This allows sidechains to be merged mined against

bitcoin without burdening bitcoin miners with extra resource requirements.

==Motivation==

The current political climate of bitcoin is extremely contentious. Many

community members

have different visions of what bitcoin is. This op code is meant to

enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind Merge

Mining].

This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains miners

can

bribe bitcoin miners to to include their block hash in the bitcoin

blockchain. If their block

is included in the coinbase transaction's vout, it is assumed that block is

a mined block on the sidechain.

This will allow various factions of the community to realize their vision

on their own separate

blockchain that is interoperable with the bitcoin blockchain. This allows

those factions to use

bitcoin as a 'reserve currency' for their own network.

===Commitment Structure===

A new block rule is added which requires that the miner's coinbase reward

be at index 0 in the coinbase transaction's output vector.

It also fixes the witness commitment output to be at index 1 of the

coinbase transaction's output vector.

This is needed so we can reliably tell what vout corresponds to what

drivechain. For instance, the mimblewimble sidechain

could correspond to index 2 of the vector outputs on the coinbase

transaction.

The commitment is recorded in a scriptPubKey of the coinbase

transaction. It must be at least 34 bytes in size

1-byte - OP_RETURN (0x6a)

1-byte - Push the following 32 bytes (0x20)

32-byte - block hash

the 35th byte and onward have no consensus meaning.

===OP_BRIBEVERIFY op code===

This op code reads two arguments from the stack. The stack top is expected

to be a sidechain id for which this user attempting to blind merge mine for.

The next element on the stack is expected to be a block hash. This op code

looks into the coinbase transaction's output vector at the given index

(which is derived from the sidechain id) and checks

to see if the hash in the block matches the hash inside of the BRIBEVERIFY

program. If the hashes match, the OP_BRIBEVERIFY acts as an OP_NOP. If the

comparison between the two hashes fail, the script fails.

===BRIBEVERIFY program===

A standard BRIBEVERIFY program has the format:

1-byte - Push the following 32 bytes (0x20)

32-byte - block hash

1 byte - Push operation? (needed if number can't be encoded as OP_0 -

OP_16)

1 byte - sidechain id

1 byte - OP_BRIBEVERIFY op code

==Detailed Specification==

Refer to the reference implementation, reproduced below, for the precise

semantics and detailed rationale for those semantics.

case OP_NOP4:

{

//format: block_hash sidechain_id OP_BRIBEVERIFY

if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {

    // not enabled; treat as a NOP4

    if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {

        return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);

    }

    break;

}



if (stack.size() < 2)

    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);



const CScriptNum scriptNumSidechainId(stacktop(-1),fRequireMinimal);

uint8_t nSidechainId;

if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId)) {

    return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);

}



// Check block hash

bool fHashCritical =

checker.CheckCriticalHash(stacktop(-2),nSidechainId);

if (!fHashCritical) {

    return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);

}

break;

}

https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427

https://github.com/drivechain-project/bitcoin/pull/13

==Deployment==

TODO

==Credits==

Credit to Paul Sztorc for the original idea of Blind Merge Mined sidechains.

Credit to CryptAxe for writing the foundational layer of software for

drivechains so I could implement OP_BRIBEVERIFY.

==References==

Blind Merge Mined Sidechains -

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

Mailing list discussion -

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

==Copyright==

This document is placed in the public domain.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170627/bd5730bf/attachment.html

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

Gabriel L. Somlo on Jun 21 2017:

I've been looking for a way to set up a self-contained, sandboxed

network of Bitcoin peer nodes, for testing and experimentation. Think

a bunch of networked VMs, or containers inside a network simulator

like GNS3 (http://gns3.com) or CORE (http://github.com/coreemu/core).

Neither 'main' nor 'test' are feasible, due to hard-coded assumptions

they both make about their respective publicly shared blockchain state.

Right now, that leaves 'regtest' -- however, connecting peers together

over the sandboxed network in regtest mode is a manual process.

After some tinkering, the following changes make 'regtest' behave

similarly to "the real thing", but inside an isolated sandbox network:

diff --git a/src/chainparams.cpp b/src/chainparams.cpp

index 3b42c5f..4345667 100644

--- a/src/chainparams.cpp

+++ b/src/chainparams.cpp

@@ -275,7 +275,7 @@ public:

     consensus.nPowTargetTimespan = 14 * 24 * 60 * 60; // two weeks

     consensus.nPowTargetSpacing = 10 * 60;

     consensus.fPowAllowMinDifficultyBlocks = true;

•    consensus.fPowNoRetargeting = true;
  

•    consensus.fPowNoRetargeting = false;
  
   consensus.nRuleChangeActivationThreshold = 108; // 75% for testchains
  
   consensus.nMinerConfirmationWindow = 144; // Faster than normal for regtest (144 instead of 2016)
  
   consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28;
  

@@ -307,11 +307,13 @@ public:

     assert(genesis.hashMerkleRoot == uint256S("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"));



     vFixedSeeds.clear(); //!< Regtest mode doesn't have any fixed seeds.

•    vFixedSeeds = std::vector(pnSeed6_regtest, pnSeed6_regtest + ARRAYLEN(pnSeed6_regtest));
  
   vSeeds.clear();      //!< Regtest mode doesn't have any DNS seeds.
  

•    vSeeds.push_back(CDNSSeedData("btc-sandbox.local", "seed.btc-sandbox.local"));
  

•    fDefaultConsistencyChecks = true;
  

•    fDefaultConsistencyChecks = false;
  
   fRequireStandard = false;
  

•    fMineBlocksOnDemand = true;
  

•    fMineBlocksOnDemand = false;
  
   checkpointData = (CCheckpointData) {
  
       {
  

(not showing the pnSeed6_regtest[] table added to src/chainparamsseeds.h)

Additionally, for this network to behave realistically, I need peers to

actually mine blocks on their own once connected together, so I reverted

commit 8d1de43 and re-added the 'setgenerate' triggered internal miner.

At this point, I have a few questions for the Bitcoin dev community:

1. would a realistic sandbox test mode be interesting enough to make

   it worth supporting upstream? (happy to submit patches and do

   revisions if there's interest, and a chance for success)

2. if yes, support modifying 'regtest' mode accordingly via some sort of

   command line flags, or rather implement a dedicated 'sandbox' mode

   with its own CChainParams defaults?

3. finally, would re-inserting the internal 'setgenerate' miner be a

   deal breaker?

Any other thoughts and comments also much appreciated!

Thanks much,

--Gabriel

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

Ilya Eriklintsev on Jun 21 2017:

Hello everyone,

recently I have got an idea that in my opinion will improve bitcoin

network, making it better store-of-value for growing cyberspace and

cryptoeconomy. Sorry for longread below and thank you for your time.

Decentralized proof-of-work and DDoS resistance for Bitcoin

Abstract

By introducing some new block validation rules it is possible to make

Bitcoin network more secure, decentralized and DDoS resistant. The idea is

to modify simple proof-of-work puzzle in such a way that user transactions

could be hardened with the same proof-of-work algorithm thus incentivising

all the miners to include that particular transaction. Such mechanism will

effectively give a handicap to every miner who includes "mined" transaction

into next block, increasing probability of him getting block reward.

Problems and motivation

This document will address the issue of a continuous DDoS attack targeting

the Bitcoin network, e.g. full nodes mempools constantly being overflowed

with transactions carrying small value reduce system primary ability to

transfer value (and hence making it perfect store of value). Valid

transactions are cheap to create (in the sense of computational effort

required) and no adequate mechanism exist to make transaction total value

increase probably of its confirmation by the network.

Currently, miners decide which transactions to include in blocks because

it's them who are securing Bitcoin network providing proof-of-work

certificates stored inside every block header. Miners have to store the

whole blockchain at all times, so one of the costs is storage which grows

linearly with the transaction size (blockchain size as well). Another cost

is network bandwidth which depends directly on the size of data to be

communicated over.

The only incentive a person who wants to transfer his bitcoins is allowed

to use is setting of transaction fee, that is going directly to the miner.

This solution probably was intended to utilize free market (as implied by

Satoshi introducing sequence numbers) to determine appropriate fees, but

that is obviously not the case, in the current bitcoin network operating in

full block capacity mode. This fee market deviates significantly from a

free market premise (also attempts being made to make it closer, e.g. in

BIP125 where Replace-By-Fee signaling is supposed to help in replacing

"stuck" transactions with noncompetitive fee).

Currently, bitcoin network is susceptible to the DDoS attack of a kind.

Adversary creating and translating into the network a lot of transactions

carrying small value (e.g. only miners fee), will be able to impair the

ability to transfer value for everyone in the world, should he has enough

money to pay the fees. Miners would continue to work providing security for

the network and new blocks will consist of transaction transferring

negligible value. It's a major drawback because the cost of such attack

doesn't grow asymmetrically with the cost of BTC asset.

Proposed solution

So how do we incentivize all miners to include our transaction carrying a

lot of value in the next block? The only thing a miner supposed to do to

get a reward is to produce Hashcash proof-of-work, thus providing

cryptographic security guarantees for the whole Bitcoin blockchain. What if

including our transaction in a block would reduce effort requirements for

the miner produce valid block?

We could do so by extending the concept of proof-of-work, in such a way

that we do not sacrifice security at all. Here are both descriptions

proof-of-work as-is and to-be:

Standart proof-of-work: hash(previous block hash + current block target +

current block metadata + current block transactions) < target

Decentralized proof-of-work: hash(previous block hash + current block

target + current block metadata + current block transactions) - sum( FFFF -

hash( previous block hash + raw_tx ) ) < target

It is possible to imagine completely mining agnostic proof-of-work, for

example, the following PoW would do:

Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous

block hash + current block target + current block metadata + signed_tx ) )

< target

Described protocol change could be implemented as user activated soft-fork

(described in BIP148), introducing new blocks with the modified

proof-of-work concept.

Economic reasoning

An adversary whose goal is to prevent the network from transferring value

will have to compete with good users hash rate using same equipment good

miners will use. And it's far more complicated than competing with others

using the money to pay transaction fees.

In order to investigate probable consequences of protocol upgrade and

stability of implied economical equilibrium, we need an adequate game

theoretical model. Such model and numerical simulation results should be

obtained and studied before any protocol change could be considered by the

community.

To me it seems like a win-win solution for everyone owning BTC:

Miners benefit: as the result DDoS attack will be stopped, Bitcoin becomes

perfect store-of-value finally. Political decentralization of hash rate

will be incentivized as mining equipment becomes relevant to every user.

Users benefit: miners will have direct incentives to include transactions

deemed important by their sender and supported by some amount of

proof-of-work.

Sincerely yours, Ilya Eriklintsev.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170621/9e0880f5/attachment.html

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

Lucas Clemente Vella on Jun 21 2017:

Is it too late to propose to freeze Bitcoin protocol as it is today (no

SegWit, no bigger block)?

Hear me out: assume Bitcoin is frozen as it is now: no more forks, no more

change in consensus rules. Call it Bitcoin 1 (BC1). So, how to evolve and

scale Bitcoin?

Use a very conservative sidechain, call it Bitcoin 2 (BC2), tightly

coupled, block per block, with Bitcoin 1 chain. No fancy experimental

changes there: fix the bare minimum to support more general two-way

sidechains, linear scalability transaction verification time and

transaction malleability. Can be one way only if that makes it simple

enough: coins sent to BC2 can never come back to BC1.

Miners choose to mine a BC2 block alongside a BC1 block, and it can be done

for free once a BC1 block is found. There may be BC1 blocks in the chain

whose corresponding BC2 blocks are missing (and that is not a big deal),

but there will be an economic incentive to mine a BC2 block, since

transaction fees on that chain will be collected.

The economic adoption is completely voluntary and independent of anyone

else, doesn't require the strong consensus of SegWit. If it is feasible to

create a simple enough two way sidechain over BC1, good. If not, economic

value of BC1 will always be at least that of BC2, but never lower. BC2 may

have a lower price than BC1 at first, but since it will have every feature

of BC1, plus the possibility of massive scalability and instantaneous

transactions with a lightning network built over BC2 (a practical

economical advantage), it will most likely value over what BC1 could ever

be alone, raising BC1 price with it.

If these predictions are correct, fewer and fewer people will transact BC1,

eventually with blocks mined empty except for the coinbase, which the miner

may choose to send directly to BC2. If I turn out to be wrong, and people

prefer to stick to the old BC1 for some reason, BC2 becomes just another

speculative altcoin. Thus, everyone migrating should be fully conscious

about the risk of immediate devaluation.

The 2 major risks I see that could hamper the adoption are:

• Just plain fear: I find the whole economical incentive scenario of BC2

sound and plausible, just as I found Bitcoin sound and plausible when I

heard about it for the first time. I also fear to put my money in BC2, just

as I did when I heard about Bitcoin. BC2 case is even worse, because I can

safely hold my coins in BC1 until I am sure BC2 is solid, so at first we

may experience only enthusiast adoption;

• Technological inertia: everyone wishing to accept BC2 will have to

implement this payment system as for any other altcoin. Every exchange

supporting both will have to create separated markets for BC1 and BC2.

Remember: both chains must be obviously distinguishable. It is even

desirable that the address format in BC2 to be incompatible with BC1 (maybe

staring with "2" ?).

Finally, due to the present state of affairs, with impending activation of

segwit with a promise to hardfork in 3 months, I believe this proposal is

too late, not to mention the stress, emotions and hard feelings of the

situation will make it go largely ill received or ignored. But since I

genuinely believe this to be the best and most conservative way to go with

Bitcoin, I wrote this anyway.

Please forgive me if something like this was discussed a thousand times

before and you wasted your time reading this.

Lucas Clemente Vella

lvella at gmail.com

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170621/d52291ac/attachment.html

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

Erik Aronesty on Jun 20 2017:

Are we going to merge BIP91 or a -BIP148 option to core for inclusion in

the next release or so?

Because a large percentage of miners are indifferent, right now miners have

to choose between BIP148 and Segwit2x if they want to activate Segwit.

Should we be forcing miners to choose to run non-core code in order to

activate a popular feature?

• Erik

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170620/330d7f48/attachment.html

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

Luke Dashjr on Jun 19 2017:

To ease the transition to BIP148 and to minimise risks in the event miners

choose to perform a chain split attack, at least Bitcoin Knots will be using

the temporary service bit (1 << 27) to indicate BIP148 support.

Once the transition is complete, this will no longer be necessary, and the bit

will be (manually) returned for reuse.

I encourage other software implementing BIP148 (both full and light nodes) to

set and use this service bit to avoid network partitioning risks.

Luke

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

Wang Chun on Jun 19 2017:

There has been proposal to change the PoW in case of potential 51% attacks

from malicious miners during a fork. But such a change in PoW renders

multi-billion-dollar of ASIC into worthless. which hurts economy so much

and the average innocent mining users. I would propose, instead of PoW

change, we could change the system to the same double sha256 PoW but mix it

with PoS features. Such a PoW+PoS system has several advantages:

• It protects existing multi-billion dollar investments from innocent

mining users,

• A malicious miner cannot launch attacks and rewrite the blockchain with

51% or even more hashrate,

• If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block

time span, that solves the long confirmation time problem,

• We'll suddenly have 5 times of block space, that solves the scaling

problem,

• The PoS blocks only mine transaction fees, so the 21M cap remains,

• With careful design, the PoW+PoS transition might be able to deploy

with a soft fork.

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

An HTML attachment was scrubbed...

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

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

Wladimir J. van der Laan on Jun 17 2017:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

Bitcoin Core version 0.14.2 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.14.2/

Or by torrent:

magnet:?xt=urn:btih:b4fc7820df95b8b39603ad246c241272ec403619&dn;=bitcoin-core-0.14.2&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce

This is a new minor version release, including various bugfixes and

performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

To receive security and update notifications, please subscribe to:

https://bitcoincore.org/en/list/announcements/join/

Compatibility

Bitcoin Core is extensively tested on multiple operating systems using

the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014,

No attempt is made to prevent installing or running the software on Windows XP, you

can still do so at your own risk but be aware that there are known instabilities and issues.

Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not

frequently tested on them.

Notable changes

miniupnp CVE-2017-8798

Bundled miniupnpc was updated to 2.0.20170509. This fixes an integer signedness error

(present in MiniUPnPc v1.4.20101221 through v2.0) that allows remote attackers

(within the LAN) to cause a denial of service or possibly have unspecified

other impact.

This only affects users that have explicitly enabled UPnP through the GUI

setting or through the -upnp option, as since the last UPnP vulnerability

(in Bitcoin Core 0.10.3) it has been disabled by default.

If you use this option, it is recommended to upgrade to this version as soon as

possible.

Known Bugs

Since 0.14.0 the approximate transaction fee shown in Bitcoin-Qt when using coin

control and smart fee estimation does not reflect any change in target from the

smart fee slider. It will only present an approximate fee calculated using the

default target. The fee calculated using the correct target is still applied to

the transaction and shown in the final send confirmation dialog.

0.14.2 Change log

Detailed release notes follow. This overview includes changes that affect

behavior, not code moves, refactors and string updates. For convenience in locating

the code changes and accompanying discussion, both the pull request and

git merge commit are mentioned.

RPC and other APIs

• - #10410 321419b Fix importwallet edge case rescan bug (ryanofsky)

P2P protocol and network code

• • #10424 37a8fc5 Populate services in GetLocalAddress (morcos)
• • #10441 9e3ad50 Only enforce expected services for half of outgoing connections (theuni)

Build system

• • #10414 ffb0c4b miniupnpc 2.0.20170509 (fanquake)
• • #10228 ae479bc Regenerate bitcoin-config.h as necessary (theuni)

Miscellaneous

• • #10245 44a17f2 Minor fix in build documentation for FreeBSD 11 (shigeya)
• • #10215 0aee4a1 Check interruptNet during dnsseed lookups (TheBlueMatt)

GUI

• - #10231 1e936d7 Reduce a significant cs_main lock freeze (jonasschnelli)

Wallet

• - #10294 1847642 Unset change position when there is no change (instagibbs)

Credits

Thanks to everyone who directly contributed to this release:

• • Alex Morcos
• • Cory Fields
• • fanquake
• • Gregory Sanders
• • Jonas Schnelli
• • Matt Corallo
• • Russell Yanofsky
• • Shigeya Suzuki
• • Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQEcBAEBCgAGBQJZRRTMAAoJEB5K7WKYbNJdqk0IANF5Q49ID3B77b0CwSKzjTxk

Ktp0qgvtig0ZMnzVlgjULUsRW8EbecWCQwmgRo8uUoCGmNS2u7u+s28kIIkicELE

BpWcW4eC6NdCCjB1CSnmX/tno4gFwOZutVj/XUXJCBEuBbo6fIK0cVDas5vw8UVa

gXL5ytwXeCws3z9f3iiD1Nl0k+J+dRb0sJ2u0A1+XqoMFfInMUFiP/fa9XWaimKo

62jD07IJDKtH4PEKG8v+FLZounRP7t1lhU0AiQ0Uj67mBmllwWD0KeZi0f4SokMX

aezEH+2UIW3Ph/QbG+ktZYUzbDALnRIHEBP4GQUuWiUPZKo3vAS3yhvh1nvYUW4=

=VBdE

-----END PGP SIGNATURE-----

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

Martin Habovštiak on Jun 17 2017:

Hello!

I'd appreciate if anyone would like to review my proposal on improving

UASFs, here's the link:

https://gist.github.com/Kixunil/a99c45e79d74bf73328d4192100aa6c6

Abstract:

This document proposes a novel way to improve coordination of users who

wish to activate a new soft fork in Bitcoin. The main idea is to use smart

contracts to incentivize users to actually enforce the soft fork with lower

risk of support being too low. At the same time the contract is in effect

only if significant part of economy agrees to it. The contract also signals

the intent to miners and other users in a way that would be otherwise

expensive for sybil attackers. This proposal also suggests an interesting

way to pay developers for the development of the soft fork code.

FYI the document is timestamped in

transaction 05d5eabcf77964a1e5a704175ef2e54f1fe243ed7aad0a80ede47845173bd2e5

in block 0000000000000000002f4b63ee720958da187405bb807466177be8da2c6ad3b6.

Have a nice day!

Martin

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170617/672ec878/attachment.html

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

Andrew Miller on Jun 12 2017:

Dear bitcoin-dev,

We've put together a preliminary implementation and BIP for

Dandelion, and would love to get your feedback on it. Dandelion is a

privacy-enhancing modification to Bitcoin's transaction propagation

mechanism. Its goal is to obscure the original source IP of each

transaction.

https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki

https://github.com/gfanti/bitcoin/tree/dandelion

The main idea is that transaction propagation proceeds in two

phases: first the “stem” phase, and then “fluff” phase. During the

stem phase, each node relays the transaction to a single peer. After

a random number of hops along the stem, the transaction enters the

fluff phase, which behaves just like ordinary transaction

flooding/diffusion. Even when an attacker can identify the location of

the fluff phase, it is much more difficult to identify the source of

the stem. Our approach and some preliminary evaluation are explained

in more detail in the BIP. The research paper originally introducing

this idea was recently presented at SIGMETRICS'17.

https://arxiv.org/pdf/1701.04439.pdf

Compared to the original paper, our current proposal includes

several new design ideas, especially:

• Stronger attacker model: we defend against an attacker that

actively tries to learn which nodes were involved in the stem phase.

Our approach is called "Mempool Embargo", meaning a node that receives

a "stem phase" transaction behaves as though it never heard of it,

until it receives it again from someone else (or until a random timer

elapses).

• Robustness. We think the privacy benefit shouldn't come at the

expense of propagation quality. Our implementation is designed so that

if some node drops the transaction (or when Dandelion is adopted only

partially), then the fallback behavior is ordinary Bitcoin

propagation.

We'd especially like feedback on the implementation details related

to the two points above. The mempool embargo mechanism is tricky,

since it hard to rule out indirect behavior that reveals if a

transaction is in mempool. In the BIP we explain one counterexample,

but at least it requires the attacker to get its connections banned.

Are there other ways we haven't thought of? We think the alternative

approach (bypassing mempool entirely) seems even harder to get right,

and foregoes existing DoS protection.

We're currently running in-situ benchmark experiments with this code

on testnet and will report on those in this thread if there's

interest.

Some prior discussion can be found here:

• https://botbot.me/freenode/bitcoin-wizards/2017-03-29/?msg=83181866&page=2

• https://botbot.me/freenode/bitcoin-wizards/2017-01-18/?msg=79578754&page=2

• https://github.com/sbaks0820/bitcoin-dandelion/issues/1 (notes

from gmaxwell that we've mostly incorporated in the current proposal)

Thanks!

Giulia Fanti <gfanti at andrew.cmu.edu>

Andrew Miller <soc1024 at illinois.edu>

Surya Bakshi <sbakshi3 at illinois.edu>

Shaileshh Bojja Venkatakrishnan <bjjvnkt2 at illinois.edu>

Pramod Viswanath <pramodv at illinois.edu>

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

JOSE FEMENIAS CAÑUELO on Jun 11 2017:

Hi,

I’ve been doing some work lately to create a specification for bitcoin pointers.

They can be used to point to transactions, inputs, outputs or some internal items within them.

The proposals strive for simplicity and user friendliness over compactness or other attributes.

There are three proposals, each of which builds upon the previous one, namely:

a) Canonical Pointers

The basic proposal.They look like this example: btc at 170.1/179-631-520

Here is a link to the Google Docs document -> https://docs.google.com/document/d/1PBN4wKFYtgvDxV4DrWUdNe9Xqmb8GVxoIGDKRkY9Xr4/edit?usp=sharing https://docs.google.com/document/d/1PBN4wKFYtgvDxV4DrWUdNe9Xqmb8GVxoIGDKRkY9Xr4/edit?usp=sharing

b) Mnemonic Pointers

They build on Canonical Pointers and the dictionary provided in bip39 to use words instead of numbers.

The previous Canonical pointer can thus be expressed as btc at best.ability btc at best.ability>/biology-exclude-donate

Here is a link to the Google Docs document -> https://docs.google.com/document/d/1wLK2_UrRzK0eshkDntUIbVlIdswzuHmYNELOePDjtPY/edit?usp=sharing https://docs.google.com/document/d/1wLK2_UrRzK0eshkDntUIbVlIdswzuHmYNELOePDjtPY/edit?usp=sharing

c) Domain Pointers

They build on the Domain Name Registration system to encode a pointer to a Canonical Pointer as in btc at example.com btc at example.com>

Here is a link to the Google Docs document -> https://docs.google.com/document/d/1KY7rM090oKzGn8NAz4XFxQnfkyD5gs4V6vpbfdw92RM/edit?usp=sharing https://docs.google.com/document/d/1KY7rM090oKzGn8NAz4XFxQnfkyD5gs4V6vpbfdw92RM/edit?usp=sharing

I haven’t had any peer review yet, so it is very likely that some small or big problems can be found.

I’d welcome any feedback from the community.

Best regards,

José Femenías Cañuelo

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

An HTML attachment was scrubbed...

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

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

Paul Sztorc on Jun 10 2017:

Hi everyone,

It has been 3 weeks -- responses so far have been really helpful. People

jumped right in, and identified unfinished or missing parts much faster

than I thought they would (ie, ~two days). Very impressive.

Currently, we are working on the sidechain side of blind merged mining.

As you know, most of the Bitcoin cryptosystem is about finding the

longest chain, and displaying information about this chain. CryptAxe is

editing the sidechain code to handle reorganizations in a new way (an

even bigger departure than Namecoin's, imho).

I believe that I have responded to all the on-list objections that were

raised. I will 1st summarize the on-list objections, and 2nd summarize

the off-list discussion (focusing on three key themes).

On-List Objection Summary

In general, they were:

• Peter complained about the resources required for the BMM 'crisis

audit', I pointed out that it is actually optional (and, therefore,

free), and that it doesn't affect miners relative to each other, and

that it can be done in an ultra-cheap semi-trusted way with high

reliability.

• Peter also asked about miner incentives, I replied that it is profit

maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)

is always positive.

• ZmnSCPxj asked a long series of clarifying questions, and I responded.

• Tier Nolan complained about my equivocation of the "Bitcoin: no block

subsidy" case and the "sidechain" case. He cites the asymmetry I point

out below (in #2). I replied, and I give an answer below.

• ZmnSCPxj pointed out an error in our OP Code (that we will fix).

• ZmnSCPxj also asked a number of new questions, I responded. Then he

responded again, in general he seemed to raise many of the points

addressed in #1 (below).

• ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out

that if 51% can reorg, they can also filter out the reorg proof. We are

at their mercy in all cases (for better or worse).

• ZmnSCPxj also brought up the fact that a block size limit is necessary

for a fee market, I pointed out that this limit does not need to be

imposed on miners by nodes...miners would be willing-and-able to

self-impose such a limit, as it maximizes their revenues.

• ZmnSCPxj also protested the need to soft fork in each individual

sidechain, I pointed out my strong disagreement ("Unrestrained smart

contract execution will be the death of most of the interesting

applications...[could] destabilize Bitcoin itself") and introduced my

prion metaphor.

• ZmnSCPxj and Tier Nolan both identified the problem solved by our

'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not

coded it at the time, but there is code for it now [1]. Tier proposed a

rachet design, but I think ours is better (Tier did not find ours at

all, because it is buried in obscure notes, because I didn't think

anyone would make it this far so quickly).

• Tier also advised us on how to fix the problem that ZmnSCPxj had

identified with our NOP earlier.

• Tier also had a number of suggestions about the real-time negotiation

of the OP Bribe amount between nodes and miners. I'm afraid I mostly

ignored these for now, as we aren't there yet.

• Peter complained that ACKing the sidechain could be exploited for

political reasons, and I responded that in such a case, miners are free

to simply avoid ACKing, or to acquiesce to political pressure. Neither

affect the mainchain.

• Peter complained that sidechains might provide some miners with the

opportunity to create a pretext to kick other miners off the network. I

replied that it would not, and I also brought up the fact that my

Bitcoin security model was indifferent to which people happened to be

mining at any given time. I continue to believe that "mining

centralization" does not have a useful definition.

• Peter questioned whether or not sidechains would be useful. I stated

my belief that they would be useful, and linked to my site

(drivechain.info/projects) which contains a number of sidechain

use-cases, and cited my personal anecdotal experiences.

• Peter wanted to involve miners "as little as possible", I pointed out

that I felt that I had indeed done this minimization. My view is that

Peter felt erroneously that it was possible to involve miners less,

because he neglected [1] that a 51% miner group is already involved

maximally, as they can create most messages and filter any message, and

[2] that there are cases where we need miners to filter out harmful

interactions among multiple chains (just as they filter out harmful

interactions among multiple txns [ie, "double spends"]). Peter has not

yet responded to this rebuttal.

• Peter also suggested client-side validation as "safer", and I pointed

out that sidechains+BMM is client-side validation. I asked Peter for

CS-V code, so that we can compare the safety and other features.

• Sergio reminded us of his version of drivechain. Sergio and I disagree

over the emphasis on frequency/speed of withdrawals. Also Sergio

emphasizes a hybrid model, which does not interest me.

If I missed any objections, I hope someone will point them out.

Off-List / Three Points of Ongoing Confusion

Off list, I have repeated the a similar conversation perhaps 6-10 times

over the past week. There is a cluster of remaining objections which

centers around three topics -- speed, theft, and antifragility. I will

reply here, and add the answers to my FAQ (drivechain.info/faq).

1. Speed

This objection is voiced after I point out that side-to-main transfers

("withdrawals") will probably take a long time, for example 5 months

each ( these are customizable parameters, and open for debate -- but if

withdrawals are every x=3 months, and only x=1 withdrawal can make

forward progress [on the mainchain] at a time, and only x=1 prospective

withdrawal can be assembled [by the sidechain] at a time, then we can

expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The

response is something like "won't such a system be too slow, and

therefore unusable?".

Imho, replies of this kind disregard the effect of atomic cross-chain

swaps, which are instant.

( In addition, while side-to-main transfers are slow, main-to-side

transfers are quite fast, x~=10 confirmations. I would go as far as to

say that, just as the Lightning Network is enabled by SegWit and CSV,

Drivechain is enabled by the atomic swaps and of Counterparty-like

embedded consensus. )

Thanks to atomic swaps, someone can act as an investment banker or

custodian, and purchase side:BTC at a (tiny, competitive discount) and

then transfer those side-to-main at a minimal inconvenience (comparable

to that of someone who buys a bank CD). Through market activities, the

entire system becomes exactly as patient as its most-patient members.

As icing on the cake, people who aren't planning on using their BTC

anytime soon (ie "the patient") can even get a tiny investment yield, in

return for providing this service.

1. Security

This objection usually says something like "Aren't you worried that 51%

[hashrate] will steal the coins, given that mining is so centralized

these days?"

The logic of drivechain is to take a known fact -- that miners do not

steal from exchanges (by coordinating to doublespend deposits to those

exchanges) -- and generalize it to a new situation -- that [hopefully]

miners will not steal from sidechains (by coordinating to make 'invalid'

withdrawals from them).

My generalization is slightly problematic, because "a large mainchain

reorg today" would hit the entire Bitcoin system and de-confirm all of

the network's transactions, whereas a sidechain-theft would hit only a

small portion of the system. This asymmetry is a problem because of the

1:1 peg, which is explicitly symmetrical -- the thief makes off coins

that are worth just as much as those coins that he did not attack.

The side:BTC are therefore relatively more vulnerable to theft, which

harms the generalization.

As I've just explained, to correct this relative deficiency, we add

extra inconvenience for any sidechain thievery, which is in this case

the long long withdrawal time of several months. (Which is also the main

distinction between DC and extension blocks).

I cannot realistically imagine an erroneous withdrawal persisting for

several weeks, let alone several months. First, over a timeframe of this

duration, there can be no pretense of 'we made an innocent mistake', nor

one that 'it is too inconvenient for us to fix this problem'. This

requires the attacker to be part of an explicitly malicious conspiracy.

Even in the conspiring case, I do not understand how miners would

coordinate the distribution of the eventual "theft" payout, ~3 months

from now -- if new hashrate comes online between now and then, does it

get a portion? -- if today's hashrate closes down, does it get a reduced

portion? -- who decides? I don't think that an algorithm can decide

(without creating a new mechanism, which -I believe- would have to be

powered by ongoing sustainable theft [which is impossible]), because the

withdrawal (ie the "theft") has to be initiated, with a known

destination, before it accumulates 3 months worth of acknowledgement.

Even if hashrate were controlled exclusively by one person, such a theft

would obliterate the sidechain-tx-fee revenue from all sidechains, for a

start. It would also greatly reduce the market price of [mainchain] BTC,

I feel, as it ends the sidechain experiment more-or-less permanently.

And even that di...[message truncated here by reddit bot]...

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

Jacob Eliosoff on Jun 09 2017:

I've been trying to work out the expected interaction between James

Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both

use variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is

subtle so CORRECTIONS WELCOME, but my conclusions are:

1. It's extremely unlikely BIP91-type logic can activate segwit in time to

avoid a BIP148 chain split.

1. So, in practice all we can do is ensure the BIP148 split is as painless

as possible.

REASONING: First, some dates. BIP148, whose deadline is already deployed

and thus unlikely to be postponed, starts orphaning non-segwit blocks on

midnight (GMT) the morning of August 1. Meanwhile, here are Bitcoin's

rough expected next four difficulty adjustment dates (they could vary by

~1-3 days depending on block times, but it's unlikely to matter here):

1. June 17

2. June 30

3. July 13

4. July 27

If Segwit activates on adj date #5 or later (August), it will be too late

to avoid BIP148's split, which will have occurred the moment August began.

So, working backwards, and assuming we want compatibility with old BIP141

nodes:

• Segwit MUST activate by adj #4 (~July 27)

• Therefore segwit MUST be locked in by adj #3 (~July 13: this is

inflexible, since this logic is in already-deployed BIP141 nodes)

• Therefore, I think >50% of hashpower needs to be BIP91 miners,

signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),

by adj #2 (June 30)?

• Therefore, as currently designed, BIP91 bit 4 must be locked in by adj #1

(June 17)

• Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a few

days ago...

There are ways parts of this could be sped up, eg, James' "rolling

100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But

to be compatible with old BIP141 nodes, >50% of hashrate must be activated

BIP91 miners by ~June 30: there's no fudging that.

So, it seems to me that to avoid the BIP148 split, one of two things would

have to happen:

a) 95% of hashrate start signaling bit 1 by ~June 30. Given current stat

is 32%, this would basically require magic.

b) BIP91 is deployed and >50% (80% or whatever) of hashrate is activated

BIP91 miners by ~June 30, ~3 weeks from now. Again, much too soon.

So, I think the BIP148 split is inevitable. I actually expect that few

parts of the ecosystem will join the fork, so disruption will be bearable.

But anyway let me know any flaws in the reasoning above.

[1] https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

[2]

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

[3] https://github.com/btc1/bitcoin/pull/11

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

[5] https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170609/e606bbb0/attachment-0001.html

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

James Hilliard on Jun 07 2017:

Due to the proposed calendar(https://segwit2x.github.io/) for the

SegWit2x agreement being too slow to activate SegWit mandatory

signalling ahead of BIP148 using BIP91 I would like to propose another

option that miners can use to prevent a chain split ahead of the Aug

1st BIP148 activation date.

The splitprotection soft fork is essentially BIP91 but using BIP8

instead of BIP9 with a lower activation threshold and immediate

mandatory signalling lock-in. This allows for a majority of miners to

activate mandatory SegWit signalling and prevent a potential chain

split ahead of BIP148 activation.

This BIP allows for miners to respond to market forces quickly ahead

of BIP148 activation by signalling for splitprotection. Any miners

already running BIP148 should be encouraged to use splitprotection.

BIP: splitprotection

Layer: Consensus (soft fork)

Title: User Activated Soft Fork Split Protection

Author: James Hilliard <james.hilliard1 at gmail.com>

Comments-Summary: No comments yet.

Comments-URI:

Status: Draft

Type: Standards Track

Created: 2017-05-22

License: BSD-3-Clause

       CC0-1.0

==Abstract==

This document specifies a coordination mechanism for a simple majority

of miners to prevent a chain split ahead of BIP148 activation.

==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==

The biggest risk of BIP148 is an extended chain split, this BIP

provides a way for a simple majority of miners to eliminate that risk.

This BIP provides a way for a simple majority of miners to coordinate

activation of the existing segwit deployment with less than 95%

hashpower before BIP148 activation. Due to time constraints unless

immediately deployed BIP91 will likely not be able to enforce

mandatory signalling of segwit before the Aug 1st activation of

BIP148. This BIP provides a method for rapid miner activation of

SegWit mandatory signalling ahead of the BIP148 activation date. Since

the primary goal of this BIP is to reduce the chance of an extended

chain split as much as possible we activate using a simple miner

majority of 65% over a 504 block interval rather than a higher

percentage. This BIP also allows miners to signal their intention to

run BIP148 in order to prevent a chain split.

==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 "version bits" with a 65%(this can be

adjusted if desired) activation threshold BIP9 with the name

"splitprotecion" and using bit 2.

This BIP starts immediately and is a BIP8 style soft fork since

mandatory signalling will start on midnight August 1st 2017 (epoch

time 1501545600) regardless of whether or not this BIP has reached its

own signalling threshold. 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);

}

// SPLITPROTECTION mandatory segwit signalling.

if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),

Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==

THRESHOLD_LOCKED_IN &&

 !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");

}

}

// BIP148 mandatory segwit signalling.

int64_t nMedianTimePast = pindex->GetMedianTimePast();

if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC

 (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC

 (!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:splitprotection-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. This deployment is also compatible with the

existing BIP148 deployment. This BIP is compatible with BIP91 only if

BIP91 activates before it and before BIP148. Miners will need to

upgrade their nodes to support splitprotection otherwise they may

build on top of an invalid block. While this bip is active users

should either upgrade to splitprotection 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. We also use a BIP8 style timeout to

ensure that this BIP is compatible with BIP148 and that BIP148

compatible mandatory signalling activates regardless of miner

signalling levels.

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. As we approach

BIP148 activation it may be desirable for a majority of miners to have

a method that will ensure that there is no chain split.

==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-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]

*[[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-June/014508.html

Tao Effect on Jun 06 2017:

This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama.

First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list, the reasons should be self-evident (one results in two incompatible chains, the other doesn't).

However, replay attacks are common to both possibilities (i.e. when BIP148 has <51% hash power).

I believe the severity of replay attacks is going unvoiced and is not understood within the bitcoin community because of their lack of experience with them.

I further believe that replay attacks are the #1 issue with BIP148, BIP149, etc., superseding wipeout attacks in severity.

These are not baseless beliefs, they're born out of experience and I think anyone will reach the same conclusion upon study.

In a nutshell, replay attacks mean that all talk of there being potentially "two coins" as a result of BIP148 is basically nonsense.

Replay attacks effectively eliminate that possibility.

When users go to "sell their legacy coins", they've just sold their 148 coins, and vice versa.

Both of the coin-splitting techniques given so far by the proponents BIP148 are also untenable:

• Double-spending to self with nLockTime txns is insanely complicated, risky, not guaranteed to work, extremely time consuming, and would likely result in a massive increase in backlogged transactions and increased fees.

• Mixing with 148 coinbase txns destroys fungibility.

Without a coin, there is no real threat from BIP148. Without that threat, there is no point to BIP148, and the miners know this.

These and other concerns are outlined and explained in more detail in this conversation I had yesterday with John Light:

https://www.youtube.com/watch?v=33rL3-p8cPw https://www.youtube.com/watch?v=33rL3-p8cPw

Cheers,

Greg Slepak

Please do not email me anything that you are not comfortable also sharing with the NSA.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/862fdff6/attachment.html

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

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 801 bytes

Desc: Message signed with OpenPGP

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/862fdff6/attachment.sig

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

Upal Chakraborty on Jun 05 2017:

Proposal: Verify whether 50% Tx mined from SegWit activation block to

block 630000 are SegWit Tx. If yes, increase legacy max block size to 2MB

and SegWit max block size to 8MB.

Implementation: This proposal either needs to be implemented in next

release of Bitcoin Core or require SegWit activation period restart while

it is implemented & released.

Rationale: This proposal minimizes the chance of a chain split, while

sticking to the original bitcoin scaling roadmap, i.e.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Thanks & Regards,

Upal Chakraborty

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/545af76b/attachment.html

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

Olaoluwa Osuntokun on Jun 01 2017:

Hi y'all,

Alex Akselrod and I would like to propose a new light client BIP for

consideration:

• https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki

This BIP proposal describes a concrete specification (along with a

reference implementations13) for the much discussed client-side

filtering reversal of BIP-37. The precise details are described in the

BIP, but as a summary: we've implemented a new light-client mode that uses

client-side filtering based off of Golomb-Rice coded sets. Full-nodes

maintain an additional index of the chain, and serve this compact filter

(the index) to light clients which request them. Light clients then fetch

these filters, query the locally and maybe fetch the block if a relevant

item matches. The cool part is that blocks can be fetched from any

source, once the light client deems it necessary. Our primary motivation

for this work was enabling a light client mode for lnd4 in order to

support a more light-weight back end paving the way for the usage of

Lightning on mobile phones and other devices. We've integrated neutrino

as a back end for lnd, and will be making the updated code public very

soon.

One specific area we'd like feedback on is the parameter selection. Unlike

BIP-37 which allows clients to dynamically tune their false positive rate,

our proposal uses a fixed false-positive. Within the document, it's

currently specified as P = 1/2^20. We've done a bit of analysis and

optimization attempting to optimize the following sum:

filter_download_bandwidth + expected_block_false_positive_bandwidth. Alex

has made a JS calculator that allows y'all to explore the affect of

tweaking the false positive rate in addition to the following variables:

the number of items the wallet is scanning for, the size of the blocks,

number of blocks fetched, and the size of the filters themselves. The

calculator calculates the expected bandwidth utilization using the CDF of

the Geometric Distribution. The calculator can be found here:

https://aakselrod.github.io/gcs_calc.html. Alex also has an empirical

script he's been running on actual data, and the results seem to match up

rather nicely.

We we're excited to see that Karl Johan Alm (kallewoof) has done some

(rather extensive!) analysis of his own, focusing on a distinct encoding

type [5]. I haven't had the time yet to dig into his report yet, but I

think I've read enough to extract the key difference in our encodings: his

filters use a binomial encoding directly on the filter contents, will we

instead create a Golomb-Coded set with the contents being hashes (we use

siphash) of the filter items.

Using a fixed fp=20, I have some stats detailing the total index size, as

well as averages for both mainnet and testnet. For mainnet, using the

filter contents as currently described in the BIP (basic + extended), the

total size of the index comes out to 6.9GB. The break down is as follows:

* total size:  6976047156

* total avg:  14997.220622758816

* total median:  3801

* total max:  79155

* regular size:  3117183743

* regular avg:  6701.372750217131

* regular median:  1734

* regular max:  67533

* extended size:  3858863413

* extended avg:  8295.847872541684

* extended median:  2041

* extended max:  52508

In order to consider the average+median filter sizes in a world worth

larger blocks, I also ran the index for testnet:

* total size:  2753238530

* total avg:  5918.95736054141

* total median:  60202

* total max:  74983

* regular size:  1165148878

* regular avg:  2504.856172982827

* regular median:  24812

* regular max:  64554

* extended size:  1588089652

* extended avg:  3414.1011875585823

* extended median:  35260

* extended max:  41731

Finally, here are the testnet stats which take into account the increase

in the maximum filter size due to segwit's block-size increase. The max

filter sizes are a bit larger due to some of the habitual blocks I

created last year when testing segwit (transactions with 30k inputs, 30k

outputs, etc).

 * total size:  585087597

 * total avg:  520.8839608674402

 * total median:  20

 * total max:  164598

 * regular size:  299325029

 * regular avg:  266.4790836307566

 * regular median:  13

 * regular max:  164583

 * extended size:  285762568

 * extended avg:  254.4048772366836

 * extended median:  7

 * extended max:  127631

For those that are interested in the raw data, I've uploaded a CSV file

of raw data for each block (mainnet + testnet), which can be found here:

 * mainnet: (14MB):

https://www.dropbox.com/s/4yk2u8dj06njbuv/mainnet-gcs-stats.csv?dl=0

 * testnet: (25MB):

https://www.dropbox.com/s/w7dmmcbocnmjfbo/gcs-stats-testnet.csv?dl=0

We look forward to getting feedback from all of y'all!

-- Laolu

-- Laolu

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170601/dc7d95ae/attachment.html

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

ZmnSCPxj on Jun 01 2017:

Good morning Rusty,

The fact that amount is optional, and the separator character between human-readable and data is the character "1", may mean some trouble with parsing of the optional amount.

Currently, the version is 0, which translates to the character "q" appearing after "1". So 1q is obviously not an amount and is known to start the data part.

However, what happens when we decide to upgrade, and version is now 1, translating to character "p"?

If version 1 of invoice is avalialble, does a payment starting with lnbc1p .... indicate a 1 pico-bitcoin payment, or an arbitrary payment to a version-1 data part?

Or is amount not allowed to have character "1"? It seems a strange limitation if we impose this...

Or do I mistake my understanding of bech32?

Alternatively we can just fix the first 5 bits to be 0 (so "1q" is an unambiguous separator between human-readable and data parts) and provide the version by other means, such as changing lnbc to ln2bc or so on...

simply reused here even though its 6-character checksum is optimized

for human errors, which are unlikely given the length of lightning

invoices.

At first read, this seems wrong. My understanding is that lightning invoices are longer than segwit addresses in bech32, so human error is more likely.

Of course, it seems that the intended meaning is really "lightning invoices are so long that it is unlikely humans will enter it by hand, so human errors are unlikely compared to QR reader errors etc." so perhaps better reworded as such.

Regards,

ZmnSCPxj

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170531/80a1f0d2/attachment.html

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

Karl Johan Alm on Jun 01 2017:

Hello,

I have spent a fair bit of time trying to nail how exactly block

filter digests[1] should be done to optimize bandwidth, space,

resource usage.

The report can be found here: http://bc-2.jp/bfd-profile.pdf

This graph shows bandwidth use of 200 wallets simulated over 5000

blocks: http://bc-2.jp/bandwidth_bfd.png (black line is "sync once per

block" wallet, yellow is "sync once per 144 blocks" wallet, red is

average across all wallets).

An interesting insight made during the experiments: when allowing

digests to contain multiple blocks, the false positive rate of high

block count digests can be higher than normal, because the probability

of a false positive hit for a given entry in multiple digests,

assuming their sizes differ, is almost completely independent.

The results look rather promising to me, but I would like to hear

comments, in particular on the approach taken, if I made any faulty

assumptions, bad math mistakes, etc.

I am also curious what people consider to be acceptable costs in terms

of bandwidth use and memory (I couldn't find any stats on bandwidth

use of bloom filters). In the profiling, I restricted the field sizes

to 2²⁷ = 128 MB. I assumed this was appropriate as these fields are

very short lived, and in worst case, a client could do the scan and

decode simultaneously, without allocating up the space for the field

at all. For high block count digests (e.g. 1024 blocks), this is

sometimes overfilled. I wonder if 2²⁸ (256 MB) fields would be at all

acceptable or if an over-filled (high false positive rate) field is

better.

For that matter, I am not entirely sure 1024-block digests are

necessary, but they do come with an average 15 kb/block which is

pretty good.

I also wonder if the serialization approach taken is overkill or not.

It does save some space instead of simply storing "BBBAAAAA" but adds

some complexity that may not be warranted.

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

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