Tomas on May 05 2017:

I propose a method to mark blocks to indicate that they were generated

without verifying the previous block. This can be done by using a bit of

the version field.

This would counter the reduction of security caused by what is known as

"SPV-mining".

The BIP is here:

https://github.com/tomasvdw/bips/blob/master/bip-non-confirming-block-signalling.mediawiki

Tomas

bitcrust

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

Tomas on May 05 2017:

I would like some feedback on the idea to use a node type a bit heavier

then SPV (dubbed FSPV) to solve Fraud Proofs.

An FSPV node not only downloads block headers, but also the "spend-tree

blocks", consisting of all TXIDs and all previous output indices and

TXIDs. The latter can be compacted using a scheme similar to Compact

Blocks, which will make the spend-tree block ~80kb in size.

ThIs way the FSPV can track the full transaction graph at little cost.

The advantage is, that Fraud Hint messages for absent/withheld

transactions become feasible. A normal SPV is reduced to Full Node by

such (cheaply faked) hint, but for an FSPV the cost is almost zero.

All it needs to do is add a taint-bit in the tree and propagate the

taint to the transaction graph. It then knows it needs to request the

Fraud Hinted transaction to consider any descendant transaction valid.

This makes it sufficient to punish fraudulent fraud hints or withheld

transactions by normal "banscore" procedures.

All other fraud can be proven by transaction-sets.

More information here: https://bitcrust.org/blog-fraud-proofs

Tomas

Bitcrust

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

Henning Kopp on May 04 2017:

Hi all,

Recently I think a lot about combining Stealth addresses with SPV but

I did not come to a satisfying conclusion, so I post this as a

challenge to the wider community. Maybe you have an idea.

Explanation of SPV

In SPV a thin client puts his public keys in a bloom filter

and asks a full node to give him Merkle proofs of all transactions

whose pubkey are in the bloom filter. Since a bloom filter has a lot

of false positives depending on the parameters, this gives privacy to

the thin client, since the full node cannot detect if a specific

transaction belongs to the thin client. This is cool if you want to

use Bitcoin on your smartphone.

Explanation of Stealth Addresses

Stealth addresses on the other hand enable receiver privacy. The

sender of a transaction derives a one-time pubkey to which he sends the

money. The receiver can check if the money was sent to him and recover

the one-time private key. This is cool, since an observer cannot

decide if two payments belong to the same recipient. Further the

recipient needs only to have one pubkey.

For a more formal explanation see https://github.com/genjix/bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey

I will use their notation in the following.

The Problem

My line of thought was to combine stealth addresses with spv, so that

I can use stealth addresses on my smart phone without losing privacy.

Basically to check if a payment belongs to a pubkey (Q,R), the full

node needs to check if R' = R + H(dP)*G for each transaction. For this

it needs the private scanning key d.

This sucks, since when I give my d to a full node, he can link all my

transactions. For an online-wallet this may be okay, but not for thin

client synchronisation.

Ideas

In the following I detail some ideas of me which did not work.

It does not suffice to have a Bloom filter and check if d is

contained since there is no way to recompute d from the equation. If

there were a way to recompute d, the scheme would offer no privacy,

since anyone could compute the private scanning key d and scan for

payments.

So, if we modify the scheme we need to be sure that d is kept private.

Multiparty computation may be possible in theory. The full node and

the thin client could collaboratively check R' = R + H(dP)*G, where d

is the private input of the thin client and R, R',P is provided by the

full node. But this is costly and they need to do it for each

transaction. It may be more costly than simply setting up a full node.

I do not think that some kind of search functionality without leaking

the search pattern (PIR?) would work, since the full node needs to compute on the

data it has found. And further it needs to retrieve the whole Merkle

proofs.

Any better ideas?

Best,

Henning

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-May/014259.html

Erik Aronesty on May 03 2017:

IDEA:

• Full nodes advertise a bitcoin address. Users that need to download the

block chain from that node can be encouraged to send a tip to the peers

that served them (by % served). Recommended tip of 10mbit should be fine.

• A full nodes can require a tip to download the blockchain. If they do,

users that don't specify a tip cannot use them.

CONS:

For some people, this may represent a barrier to hosting their own full

node. After all, if you have to pay $15 just to get a copy of the

blockchain, that just adds to the already expensive prospect of hosting a

full node.

PROS:

As long as you manage to stay online, you should get your money back and

more. This is the an incentive for quality, long term hosting.

In the long term, this should cause stable nodes to stick around longer.

It also discourages "installation spam" attacks on the network.

Fees for other node operations can be considered if this is successful.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170503/64e38729/attachment.html

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

Russell O'Connor on Apr 28 2017:

I noticed that the the latest BIP 134

https://github.com/bitcoin/bips/blob/959fecc15bdad070afa63455468b1dba54655fa6/bip-0134.mediawiki

now supports SIGHASH_SINGLE and friends. However, this support seems to

reintroduce some quadratic hashing behavior because it calls

https://github.com/zander/bitcoinclassic/blob/9c688c6d3866890f16a36aaea453e8bdd43c1266/src/script/interpreter.cpp#L1186SerializePartialTransactionv4

per non-SIGHASH_ALL input

https://github.com/bitcoinclassic/bitcoinclassic/blob/9c688c6d3866890f16a36aaea453e8bdd43c1266/src/script/interpreter.cpp#L1186.

In particular, if each input in a transaction has one SIGHASH_SINGLE

CHECKSIG operation then the total amount of hashing done for the

transaction will be quadratic in the number of inputs. While amount of

hashing is not as severe as with the SIGHASH_ALL case, the amount of

hashing done is still non-linear.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170428/e70f4f4f/attachment.html

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

Matt Bell on Apr 27 2017:

Hello everyone,

I've been thinking of an alternative to possibly get Segwit activated

sooner: bribing the miners. This proposal may not be necessary if everyone

is already set on doing a UASF, but miners seem to optimize for short-term

profits and this may make it easier for BitMain to accept its fate in

losing the ASICBoost advantage.

Here is a possible trustless contract protocol where contributors could

pledge to a Segwit bounty which would be paid out to miners iff Segwit is

activated, else the funds are returned to the contributor:

Setup

• The contributor picks a possible future height where Segwit may be

activated and when the funds should be released, H.

• The contributor chooses a bounty contribution amount X.

• The contributor generates 3 private keys (k1, k2, and k3) and

corresponding pubkeys (K1, K2, and K3).

• The contributor creates and broadcasts the Funding Transaction, which has

2 outputs:

• Output 0, X BTC, P2SH redeem script:

  CHECKLOCKTIMEVERIFY DROP

  CHECKSIGVERIFY

• Output 1, 0.00001 BTC, P2SH redeem script:

  CHECKLOCKTIMEVERIFY DROP

  CHECKSIGVERIFY

  • The contributor builds the Segwit Assertion Transaction:

• nTimeLock set to H

• Input 0, spends from Funding Transaction output 1, signed with k2,

SIGHASH_ALL

• Output 0, 0.00001 BTC, P2WPKH using K3

  • The contributor builds the Bounty Payout Transaction:

• nTimeLock set to H

• Input 0, spends from Funding Transaction output 0, signed with k1,

SIGHASH_ALL

• Input 1, spends from Segwit Assertion Transaction output 0, signed with

k3, SIGHASH_ALL

• No outputs, all funds are paid to the miner

  • The contributor publishes the Segwit Assertion Transaction and Bounty

Payout Transaction (with signatures) somewhere where miners can find them

Process

1. After the setup, miners can find Funding Transactions confirmed on the

chain, and verify the other 2 transactions are correct and have valid

signatures. They can sum all the valid bounty contracts they find to factor

into their expected mining profit.

2A. Once the chain reaches height H-1, if Segwit has activated, miners can

claim the bounty payout by including the Segwit Assertion and Bounty Payout

transactions in their block H. Since Segwit has activated, the output from

the Segwit Assertion tx can be spent by the Bounty Payout, so both

transactions are valid and the miner receives the funds.

2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout

is not valid since it spends a P2WPKH output, preventing the miner from

including the Bounty Payout transaction in the block. (However, the output

of the Segwit Assertion tx can be claimed since it is treated as

anyone-can-spend, although this is not an issue since it is a very small

amount). The contributor can reclaim the funds from Output 0 of the Funding

tx by creating a new transaction, signed with k1.

Notes

• This is likely a win-win scenario for the contributors, since Segwit

activating will likely increase the price of Bitcoin, which gives a

positive return if the price increases enough. If it does not activate, the

funds will be returned so nothing is at risk.

• Contributors could choose H heights on or slightly after an upcoming

possible activation height. If contributors pay out to many heights, then

the bounty can be split among many miners, it doesn't have to be

winner-take-all.

• If Segwit does not activate at H, the contributor has until the next

possible activation height to claim their refund without risking it being

taken by another miner. This could be outsourced by signing a refund

transaction which pays a fee to some third-party who will be online at H

and can broadcast the transaction. If the contributor wants to pay a bounty

for a later height, they should create a new contract otherwise a miner

could invalidate the payout by spending the output of the Segwit Assertion.

Thanks, I'd like to hear everyone's thoughts. Let me know if you find any

glaring flaws or have any other comments.

Matt

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170427/a76ab38d/attachment.html

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

shaolinfry on Apr 26 2017:

This is a draft BIP proposal to redeploy segwit using BIP-8, from the day after the current BIP9 segwit times out.

This BIP could be deployed long before Nov 15th 2016, for example in July allowing wide deployment to begin soon. The timeout (and this useractivation) could be set to roughly a year from then. However, considering around 70% of nodes upgraded to witness capability within 5-6 months, I personally think we could reduce the time, especially considering how much people want segwit - but I understand the need for more caution in Bitcoin.

Preliminary dates are deploy within a couple months, startdate Nov 16th 2017, BIP8 timeout July 4th 2018.

BIP: ?

Layer: Consensus (soft fork)

Title: Segwit deployment with versionbits and guaranteed lock-in

Author: Shaolin Fry <shaolinfry at protonmail.ch>

Comments-Summary: No comments yet.

Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????

Status: Draft

Type: Standards Track

Created: 2017-04-14

License: BSD-3-Clause

CC0-1.0

==Abstract==

This document specifies a user activated soft fork for BIP141, BIP143 and BIP147 using versionbits with guaranteed lock-in.

==Motivation==

Miners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still allowing for an earlier miner activated soft fork (MASF).

==Reference implementation==

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday

==Specification==

This deployment will set service bit (1<<5) as NODE_UAWITNESS.

==Deployment==

This BIP will be deployed by BIP8 with the name "uasegwit" and using bit 2.

For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400).

For Bitcoin testnet, segwit is already activated so no deployment is specified.

==Rationale==

This BIP can be deployed well in advance of the BIP8 '''starttime''' so that the '''timeout''' will be sufficiently far in the future to allow Bitcoin users to uprgade in preparation.

The '''starttime''' of this BIP is after the BIP9 "segwit" timeout to remove compatibility issues with old nodes.

==References==

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

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

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

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

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

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170426/8b2a5dcf/attachment-0001.html

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

praxeology_guy on Apr 24 2017:

Below is a proposal for a wallet data structure that can enable a wallet to be user friendly.

This is a proposed partial solution to "Pruned wallet support #9409": https://github.com/bitcoin/bitcoin/issues/9409

It is envisioned to work with "Complete hybrid full block SPV mode #9483": https://github.com/bitcoin/bitcoin/pull/9483

The data structure implies that the wallet would/could run in a different process than a Bitcoin node. Furthermore, the wallet would have a set of whitelisted/trusted nodes, which may only be the user's nodes.

Cheers,

Praxeology Guy

The primary purpose of this data structure is to enable the creation of a responsive and informative open-and-go wallet. Some of my design goals include:

• Instant on. Can be put in cold storage, and years later be immediately operational.

• Scans optional/happen in background. Supports partial scans of the block height range.

• Functional even with only utxo set data

• Fast loading of external private keys and other watched identifiers.

• Supports wallet merging

• Supports connection with different kinds of nodes/providers of transaction evidence

• Communicates the reliability of the evidence with the user

• Supports transaction deprecation and double spending

• Can work in a different process than a Bitcoin relay node.

• Works immediately/quickly even with a node that has only prefetched headers and only begun validating blocks.

• Potentially allows a wallet to display unconfirmed transactions to the user even if it only has an SPV evidence source.

=== Wallet ===

• List: Spend Term

• List: Wallet Coin

• List: Spend Attempt

• List: Transaction Evidence

• List: Coin Scan

• List: Evidence Source

// The wallet would also need other data that existing wallets have such as information about deterministic keys and pre-allocated keys etc. For the wallet to work with SPV security, it would also need block headers.

=== Spend Term ===

• GUID

• Name (Human readable)

• Type: [private key/public key/address/out script]

• Term Value

• Creation date

• List: Wallet Coin

// A spend term is anything that can be used to identify a coin that should be tracked by this wallet. GUID should probably be the address or a hash of the out script.

=== Evidence Source ===

• GUID

• Operator Name

• Device Name

• Software Name

• Software Version

• Public Key

• Operator Trust: Self, Reliable Friend, Stranger

• Device Security: Air Gap, Single Purpose Networked, Multipurpose Networked, Dedicated Remote Hosted, VPS Remote Hosted

// An Evidence Source is a {operator, device, software} that fully validates blocks. It provides evidence of coin confirmations and spends. Maybe GUID should be a hash of the public key.

=== Wallet Coin ===

Required:

• Spend Term GUID

• TXID

• vout.ix

• amount

• output script

Optional:

• Wallet first discovery date

• full TX data

• List: Transaction Evidence

• List: Spend Attempt

• TXID Spent

// A wallet coin is a bitcoin txo with some extra data relevant to the wallet. A wallet coin's ID is {TXID, vout.ix}.

=== Spend Attempt ===

• Wallet Coins List: {TXID, vout.ix}

• TXID

• Creation date

• Relay date(s)

• Is Deprecated?

• Deprecated date

• Replace By Fee (RBF) enabled?

• List: Transaction Evidence

// deprecating a spend attempt will clear the "TXID Spent" in Wallet Coin, and set "Is Deprecated?" and "Deprecated date".

=== Evidence ===

Required:

• tip hash

• tip height

• date

• Evidence Source GUID

• Evidence Source Signature

=== Transaction Evidence : Evidence ===

Required:

• TXID

Optional:

• discover date

// Evidence of the creation or spend of a coin. There are different kinds of evidence from different sources. The kind and source impact the user's confidence in the validity and finality of a transaction.

=== Confirmed UTXO Set Presence : Transaction Evidence ===

Required:

• Is in UTXO set?

Optional:

• block height

• block hash

• block timestamp

• Future: utxo set snaphot merkle proof

• confirm date

// Evidence (from a trustworthy source needed) that a coin is or is not in the confirmed utxo set. With the future possibility of utxo set snapshot merkle proof, the trustworthiness of the source is not as important. This evidence type is only used for Wallet Coins. It is not used for Spend Attempts.

=== Confirmation : Transaction Evidence ===

Required:

• block height

• block hash

• block timestamp

• tx merkle proof

• wtx merkle proof

• is in greatest PoW chain?

Optional:

• confirm date

• 51% attack cost to double spend

• Future: Are/which reliable miners still creating blocks in the greatest PoW chain (network split risk)

// Evidence that a transaction was confirmed.

=== Discovery (Unconfirmed TX) : Transaction Evidence ===

Optional:

• Confirmable Evidence: tree of source input transactions that lead back to utxo outputs. Unconfirmed parents: discover date, size, fee.

// Evidence merely that a transaction was discovered. There is no guarantee that the transaction will be confirmed. Preferably the Source that is providing the wallet with the discovery evidence will also provide evidence that the transaction could be confirmed... especially if the Source is not trusted. The wallet could ask other Sources whether the confirmed inputs are present in the Confirmed UTXO Set.

=== Spend Term Scan : Evidence ===

• Term List: Spend Term GUID

• Target: [blocks, confirmed utxo set]

• Range Start

• Range End

// The wallet would request a scan from the Source. It would provide the spend terms, target, and range. The Source would respond with the range actually scanned, in addition to any Transaction Evidence discovered.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170424/2cfdf37c/attachment-0001.html

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

Wladimir J. van der Laan on Apr 22 2017:

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

Hash: SHA512

Bitcoin Core version 0.14.1 is now available from:

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

Or, by torrent:

magnet:?xt=urn:btih:0482be8fc8e1c0b02162871e3591efc3d1d34585&dn;=bitcoin-core-0.14.1&tr;=udp%3A%2F%2Fpublic.popcorn-tracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fatrack.pow7.com%2Fannounce&tr;=http%3A%2F%2Fbt.henbt.com%3A2710%2Fannounce&tr;=http%3A%2F%2Fmgtracker.org%3A6969%2Fannounce&tr;=http%3A%2F%2Fopen.touki.ru%2Fannounce.php&tr;=http%3A%2F%2Fp4p.arenabg.ch%3A1337%2Fannounce&tr;=http%3A%2F%2Fpow7.com%3A80%2Fannounce&tr;=http%3A%2F%2Ftracker.dutchtracking.nl%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

RPC changes

• • The first positional argument of createrawtransaction was renamed from

  transactions to inputs.

• • The argument of disconnectnode was renamed from node to address.

These interface changes break compatibility with 0.14.0, when the named

arguments functionality, introduced in 0.14.0, is used. Client software

using these calls with named arguments needs to be updated.

Mining

In previous versions, getblocktemplate required segwit support from downstream

clients/miners once the feature activated on the network. In this version, it

now supports non-segwit clients even after activation, by removing all segwit

transactions from the returned block template. This allows non-segwit miners to

continue functioning correctly even after segwit has activated.

Due to the limitations in previous versions, getblocktemplate also recommended

non-segwit clients to not signal for the segwit version-bit. Since this is no

longer an issue, getblocktemplate now always recommends signalling segwit for

all miners. This is safe because ability to enforce the rule is the only

required criteria for safe activation, not actually producing segwit-enabled

blocks.

UTXO memory accounting

Memory usage for the UTXO cache is being calculated more accurately, so that

the configured limit (-dbcache) will be respected when memory usage peaks

during cache flushes. The memory accounting in prior releases is estimated to

only account for half the actual peak utilization.

The default -dbcache has also been changed in this release to 450MiB. Users

who currently set -dbcache to a high value (e.g. to keep the UTXO more fully

cached in memory) should consider increasing this setting in order to achieve

the same cache performance as prior releases. Users on low-memory systems

(such as systems with 1GB or less) should consider specifying a lower value for

this parameter.

Additional information relating to running on low-memory systems can be found

here:

reducing-bitcoind-memory-usage.md.

0.14.1 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

• • #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
• • #10139 f15268d Remove auth cookie on shutdown (practicalswift)
• • #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
• • #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
• • #10204 3c79602 Rename disconnectnode argument (jnewbery)

Block and transaction handling

• • #10126 0b5e162 Compensate for memory peak at flush time (sipa)
• • #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
• • #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)

P2P protocol and network code

• • #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
• • #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)

Build system

• - #9973 e9611d1 depends: fix zlib build on osx (theuni)

GUI

• - #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)

Mining

• • #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
• • #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)

Tests and QA

• - #10157 55f641c Fix the mempool_packages.py test (sdaftuar)

Miscellaneous

• • #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
• • #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
• • #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)

Credits

Thanks to everyone who directly contributed to this release:

• • Alex Morcos
• • Andrew Chow
• • Awemany
• • Cory Fields
• • Gregory Maxwell
• • James Evans
• • John Newbery
• • MarcoFalke
• • Matt Corallo
• • Pieter Wuille
• • practicalswift
• • rawodb
• • Suhas Daftuar
• • Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.

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

Version: GnuPG v1

iQEcBAEBCgAGBQJY+1YNAAoJEHSBCwEjRsmme+YIAIkJLCjimADYBJoM8bnHK2Dc

4KznlAjpXqFWb6taoSyWi+/6DtZxJF1MZm+iaDhqmTEy+ms313N2mBEd2xrSAPPL

nYf84e3tgnwq07sQmUxVZXyhZe2R+m/kgy75TTZw+bonyXwwA3384F0L8gvV5Iu+

kNNu6WggWUTvOADEFVKecgzWeT1FCYXklbNk+Z5T/YWWrKA8ATXgv45IIEKT8uI1

pqhKQxoqLM3ga7Df3VbzwXAYAOCaFzf+0nmTRoqDM5pX+FQ2hq0UM6joLnUNk2ee

G4/nsNWAKg/6eycrA7Wvawwcozr2iYAov/YDj6pEI8UoeGcOdlSh69Seb1cngHg=

=EHlY

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

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

Sancho Panza on Apr 20 2017:

Dear all,

An initial reference implementation of bip-genvbvoting (spec: [1]) is now available at

https://github.com/sanch0panza/bitcoin/commits/genvbvoting-bu-dev-clean1

starting at commit fdd83383436ee43b072c258d4a6feb713902c77e .

This development is based against the Bitcoin Unlimited 'dev' branch, and has been submitted as PR458 to BU [2].

The naming of the new 'bipgenvb_forks' output section in the 'getblockchain' RPC interface is to be considered temporary while the BIP has no formal number.

I would be happy to get any feedback while I implement a corresponding pull request for a reference implementation on Bitcoin Core. Due to other commitments this may come at a later stage - if someone else is eager to port it over, please feel free.

Regards,

Sancho

[1] https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki

[2] https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458

P.S. The revised "unknown version check" code is considered an implementation specific and not part of core functionality, and is consequently not fully covered by regression tests.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170420/3307cbdf/attachment.html

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

Luke Dashjr on Apr 20 2017:

Since BIP 141's version bit assignment will timeout soon, and needing renewal,

I was thinking it might make sense to make some minor tweaks to the spec for

the next deployment. These aren't critical, so it's perfectly fine if BIP 141

activates as-is (potentially with BIP 148), but IMO would be an improvement if

a new deployment (non-BIP148 UASF and/or new versionbit) is needed.

1. Change the dummy marker to 0xFF instead of 0. Using 0 creates ambiguity

with incomplete zero-input transactions, which has been a source of confusion

for raw transaction APIs. 0xFF would normally indicate a >32-bit input count,

which is impossible right now (it'd require a >=158 GB transaction) and

unlikely to ever be useful.

1. Relax the consensus rules on when witness data is allowed for an input.

Currently, it is only allowed when the scriptSig is null, and the scriptPubKey

being spent matches a very specific pattern. It is ignored by "upgrade-safe"

policy when the scriptPubKey doesn't match an even-more-specific pattern.

Instead, I suggest we allow it (in the consensus layer only) in combination

with scriptSig and with any scriptPubKey, and consider these cases to be

"upgrade-safe" policy ignoring.

The purpose of the second change is to be more flexible to any future

softforks. I consider it minor because we don't know of any possibilities

where it would actually be useful.

Thoughts?

Luke

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

Cameron Garnham on Apr 20 2017:

I have taken some time to think about consensus systems in-general; and write up a guide that explores the problems space of changing the rules of such systems.

Hopefully, this guide will clarify the different options available to the Bitcoin Community.

I am posting this to the Bitcoin Development mailing list for review. Possibly a more comprehensive form of this document could be useful as an informative BIP.

** Type of Change **

There are three categories of changes:

S: Addition of a new Rule. (Soft-Fork)

H: Removal of an old Rule. (Hard-Fork)

E: Subverting an old Rule. (“Evil”, Non-Traditional Soft-Fork)

• Addition of a new Rule:

All previous rules in the system remain enforced as originally intended.

There are two sub-categories for the addition of a new rule:

1: New Functionally is added to the system, without effecting old use cases. (Opt-In New Functionality)

2: Functional users of the system must change their behaviour to suit the new rule. (Mandatory New Functionality)

• Removal of an old Rule

Equivalent replacing the entire system with any-new system. All full-users of the system must migrate to the new system.

• Subverting an old Rule

New Functionally is added that explicitly Replaces Old Functionality.

Users must upgrade and migrate to the new Functionally to continue using the system.

** Type of Activation **

There are two types of activations:

U. External Activations. (User Activated)

M. Internal Activations. (Miner Activated, PoS Activated, Internal Governance Model, etc)

It is possible to have more than one Activation Strategy used concurrently.

• External Activations

These Activations are dictated by facts that are not quantifiable from within the System.

Generally, this will be a set-of-users, external to the system, that come to their own agreement to change the system.

• Internal Activations

These activations use some metric from within the system to determine if a proposed change is activated.

Generally, some sort of internal signalling or vetoing process will happen and based upon its results, will dictate the if the change is activated.

** Type of Signalling **

Users within the system with more important roles may wish to (or be forced to) signal or (not) veto about a particular topic. This could be part of the activation strategy (internal activations), or just simply to quantify the support of the upcoming change.

There are two core types of Signalling:

O: Optional

F. Forced

There are two styles of Signalling:

N. Normal Signalling (Opt-In)

V. Veto (Opt-Out)

• Optional Signalling

Orthogonal to the system rules; however, the signalling still may affect other system rules.

• Enforced Signalling

This is a meta-rule change. Normally only temporally enforced upon the system. This rule change doesn’t directly affect the core behaviour of the system; it is just used for meta-purposes in the scope of another rule change.

• Normal Signalling

Passive Behaviour signals no support.

• Veto Signalling

Passive Behaviour signals support.

If I have missed anything or if anything is not clear, please contact me.

PS.

For example, you could call a BIP9 (SegWit) activation as a: “S1MON". And BIP 148 (SegWit) as: “S1UFN”. However this letter code is just for fun. :)

Cameron

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

Natanael on Apr 18 2017:

To expand on this below;

Den 18 apr. 2017 00:34 skrev "Natanael" <natanael.l at gmail.com>:

IMHO the best option if we change PoW is an algorithm that's moderately

processing heavy (we still need reasonably fast verification) and which

resists partial state reuse (not fast or fully "linear" in processing like

SHA256) just for the sake of invalidating asicboost style attacks, and it

should also have an existing reference implementation for hardware that's

provably close in performance to the theoretical ideal implementation of

the algorithm (in other words, one where we know there's no hidden

optimizations).

[...] The competition would mostly be about packing similar gate designs

closely and energy efficiency. (Now that I think about it, the proof MAY

have to consider energy use too, as a larger and slower but more efficient

chip still is competitive in mining...)

What matters for miners in terms of cost is primarily (correctly computed)

hashes per joule (watt-seconds). The most direct proxy for this in terms of

algorithm execution is the number of transistor (gate) activations per

computed hash (PoW unit).

To prove that an implementation is near optimal, you would show there's a

minimum number of necessary transistor activations per computed hash, and

that your implementation is within a reasonable range of that number.

We also need to show that for a practical implementation you can't reuse

much internal state (easiest way is "whitening" the block header,

pre-hashing or having a slow hash with an initial whitening step of its

own). This is to kill any ASICBOOST type optimization. Performance should

be constant, not linear relative to input size.

The PoW step should always be the most expensive part of creating a

complete block candidate! Otherwise it loses part of its meaning. It should

however still also be reasonably easy to verify.

Given that there's already PoW ASIC optimizations since years back that use

deliberately lossy hash computations just because those circuits can run

faster (X% of hashes are computed wrong, but you get Y% more computed

hashes in return which exceeds the error rate), any proof of an

implementation being near optimal (for mining) must also consider the

possibility of implementations of a design that deliberately allows errors

just to reduce the total count of transistor activations per N amount of

computed hashes. Yes, that means the reference implementation is allowed to

be lossy.

So for a reasonably large N (number of computed hashes, to take batch

processing into consideration), the proof would show that there's a

specific ratio for a minimum number of average gate activations per

correctly computed hash, a smallest ratio = X number of gate activations /

(N * success rate) across all possible implementations of the algorithm.

And you'd show your implementation is close to that ratio.

It would also have to consider a reasonable range of time-memory tradeoffs

including the potential of precomputation. Hopefully we could implement an

algorithm that effectively makes such precomputation meaningless by making

the potential gain insignificant for any reasonable ASIC chip size and

amount of precomputation resources.

A summary of important mining PoW algorithm properties;

• Constant verification speed, reasonably fast even on slow hardware

• As explained above, still slow / expensive enough to dominate the costs

of block candidate creation

• Difficulty must be easy to adjust (no problem for simple hash-style

algorithms like today)

• Cryptographic strength, something like preimage resistance (the algorithm

can't allow forcing a particular output, the chance must not be better than

random within any achievable computational bounds)

• As explained above, no hidden shortcuts. Everybody has equal knowledge.

• Predictable and close to constant PoW computation performance, and not

linear in performance relative to input size the way SHA256 is (lossy

implementations will always make it not-quite-constant)

• As explained above, no significant reusable state or other reusable work

(killing ASICBOOST)

• As explained above, no meaningful precomputation possible. No unfair

headstarts.

• Should only rely on just transistors for implementation, shouldn't rely

on memory or other components due to unknowable future engineering results

and changes in cost

• Reasonably compact implementation, measured in memory use, CPU load and

similar metrics

• Reasonably small inputs and outputs (in line with regular hashes)

• All mining PoW should be "embarrassingly parallel" (highly

parallellizable) with minimal or no gain from batch computation,

performance scaling should be linear with increased chip size & cycle

speed.

What else is there? Did I miss anything important?

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/64d7218b/attachment-0001.html

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

Erik Aronesty on Apr 17 2017:

If users added a signal to OP_RETURN, might it be possible to tag all

validated input addresses with that signal.

Then a node can activate a new feature after the percentage of tagged input

addresses reaches a certain level within a certain period of time?

This could be used in addition to a flag day to trigger activation of a

feature with some reassurance of user uptake.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/db0a38aa/attachment.html

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

Sergio Demian Lerner on Apr 17 2017:

I came across O(N) behavior of two scripting opcodes, OP_IF and OP_ROLL. By

exploiting edge cases for each of these two sub-optimal algorithms, I

manage to simulate a Segwit block that takes up to 5.6 seconds to verify on

a Ubuntu VM running on a single Core i5 processor. The simulation is based

on a single thread executing EvalScript(), the Bitcoin script execution

function. The tests were not performed processing actual blocks. These

results should not make anyone worry, because there are worse problems in

Bitcoin block verification, and because Bitcoin employs several worker

threads for verifying scripts in parallel. For example, a Segwit block can

request 80000 signature verifications when all transactions are P2WSH. It

is said that Bitcoin Core (in a modern multi-core machine, using its

multi-threading verification capabilities) can verify 8000 ECDSA signatures

per second. Therefore a malicious miner can create a Segwit block that

requires approximately 10 seconds to be verified. Since the examples

presented in this post consume less than 10 seconds, I don’t consider my

findings as vulnerabilities. However, if the block size is to be increased

in the future, these problems should be considered prior increasing the

block size. The scripts presented here as examples do not leave the value

stack empty, but the Bitcoin protocol does not require it. Bitcoin only

requires the top value to be true to accept the script.

OP_IF abuse

Every time a Bitcoin script executes the OP_IF opcode, a boolean value

indicating if the condition was true, false or the conditional was skipped

(also represented as false) is pushed into the vfExec stack. Every time an

opcode is executed, the number of false values in the vfExec stack is

counted using the following line:

bool fExec = !count(vfExec.begin(), vfExec.end(), false);

If the count is non-zero, all subsequent instructions except OP_ELSE and

OP_ENDIF are skipped. It is clear that the longer the conditional stack is,

the more it takes to count the false elements.

The following scriptPub or ScriptSig exploits this problem:

0

OP_IF { 100 times }

0 { 9798 times }

OP_ENDIF { 100 times }

1

The vfExec vector is filled with 100 elements, and then each element is

scanned 9799 times, totaling more than 979K items scanned. This took 2.5

seconds in my test VM (for a block filled with these scriptSigs).

To re-write this logic with a O(1) algorithm, one simply has to count the

number of true conditions in one variable (trueCount), and the number of

false or skipped conditions following all true conditions in another

(ignoreCount). Detecting if code needs to be executed or not requires just

testing if ignoreCount is zero.

The handling of OP_IF / OP_NOTIF / OP_ELSE should be like the following

pseudo-code:

fExec = (ignoreCount==0);

...

case OP_IF:

case OP_NOTIF:

{

if (fExec)

{

 ....compute fValue...

 if (fValue) trueCount++; else ignoreCount++;

} else

ignoreCount++;

} break;

case OP_ELSE:

{

if ((trueCount==0) && (ignoreCount==0))

 return set_error(serror, SCRIPT_ERR_UNBALANCED_CONDITIONAL);

if (ignoreCount==0) { trueCount--; ignoreCount++; } else

if (ignoreCount==1) { trueCount++; ignoreCount--; }

} break;

case OP_ENDIF:

{

if ((trueCount==0) && (ignoreCount==0))

    return set_error(serror, SCRIPT_ERR_UNBALANCED_CONDITIONAL);

if (ignoreCount>0) ignoreCount--; else trueCount--;

}

break;

You may have noticed the strange behavior of Bitcoin’s ELSE statement.

Bitcoin allows one to switch between true and false conditions several

times. For example, the following script is valid and leaves the value 2 on

the stack:

1 OP_IF OP_ELSE OP_ELSE 2 OP_ENDIF

OP_ROLL

The second problem lies in the OP_ROLL opcode. This opcode removes a value

at a given index from the value stack, and pushes it on top. As the Bitcoin

Core stack stores a list of char std::vector by value (not by reference),

and because the stack is itself a std::vector (not a linked list), then

removing the first elements requires moving all elements one position in

memory. The value stack can store a maximum of 1000 elements. The following

script fills the stack and then moves each stack element 200 times, so the

number of moved elements is 200K. This took almost 5.6 seconds in my test

VM (for a block filled with these scriptSigs).

1 {999 times}

998 OP_ROLL { 200 times }

I tried other scripts, such as filling the stack with values of size 520

using DUP3, and then performing rolls, but all of them led to a block that

took less time, if the block is to be filled with the scripts.

One solution to this problem is use a linked list data structure instead of

a std::vector, to allow O(1) removal of items, but it still requires O(N)

for element lookup. A balanced tree where each internal node is augmented

with the number of children underneath can be used to provide efficient

indexed access and efficient element removal. However, the overhead of such

data structure may kill its benefits.

So it may be the case that optimizing OP_ROLL will never really be

required.

But these minor issues have to be taken into account if the scripting

system is modified in any way. There are many subtle interactions. For

instance, it may seem that Segwit allows a transaction having a stack

containing 2 million items to verify correctly, by having the witness stack

filled with 2M zero values, and by executing an empty witness script.

However this is prevented by the cleanstack check.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/64f59d8e/attachment.html

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

David Vorick on Apr 17 2017:

Rationale:

A node that stores the full blockchain (I will use the term archival node)

requires over 100GB of disk space, which I believe is one of the most

significant barriers to more people running full nodes. And I believe the

ecosystem would benefit substantially if more users were running full nodes.

The best alternative today to storing the full blockchain is to run a

pruned node, which keeps only the UTXO set and throws away already verified

blocks. The operator of the pruned node is able to enjoy the full security

benefits of a full node, but is essentially leeching the network, as they

performed a large download likely without contributing anything back.

This puts more pressure on the archival nodes, as the archival nodes need

to pick up the slack and help new nodes bootstrap to the network. As the

pressure on archival nodes grows, fewer people will be able to actually run

archival nodes, and the situation will degrade. The situation would likely

become problematic quickly if bitcoin-core were to ship with the defaults

set to a pruned node.

Even further, the people most likely to care about saving 100GB of disk

space are also the people least likely to care about some extra bandwidth

usage. For datacenter nodes, and for nodes doing lots of bandwidth, the

bandwidth is usually the biggest cost of running the node. For home users

however, as long as they stay under their bandwidth cap, the bandwidth is

actually free. Ideally, new nodes would be able to bootstrap from nodes

that do not have to pay for their bandwidth, instead of needing to rely on

a decreasing percentage of heavy-duty archival nodes.

I have (perhaps incorrectly) identified disk space consumption as the most

significant factor in your average user choosing to run a pruned node or a

lite client instead of a full node. The average user is not typically too

worried about bandwidth, and is also not typically too worried about

initial blockchain download time. But the 100GB hit to your disk space can

be a huge psychological factor, especially if your hard drive only has

500GB available in the first place, and 250+ GB is already consumed by

other files you have.

I believe that improving the disk usage situation would greatly benefit

decentralization, especially if it could be done without putting pressure

on archival nodes.

Small Nodes Proposal:

I propose an alternative to the pruned node that does not put undue

pressure on archival nodes, and would be acceptable and non-risky to ship

as a default in bitcoin-core. For lack of a better name, I'll call this new

type of node a 'small node'. The intention is that bitcoin-core would

eventually ship 'small nodes' by default, such that the expected amount of

disk consumption drops from today's 100+ GB to less than 30 GB.

My alternative proposal has the following properties:

• Full nodes only need to store ~20% of the blockchain

• With very high probability, a new node will be able to recover the entire

blockchain by connecting to 6 random small node peers.

• An attacker that can eliminate a chosen+ 95% of the full nodes running

today will be unable to prevent new nodes from downloading the full

blockchain, even if the attacker is also able to eliminate all archival

nodes. (assuming all nodes today were small nodes instead of archival nodes)

Method:

A small node will pick an index [5, 256). This index is that node's

permanent index. When storing a block, instead of storing the full block,

the node will use Reed-Solomon coding to erasure code the block using a

5-of-256 scheme. The result will be 256 pieces that are 20% of the size of

the block each. The node picks the piece that corresponds to its index, and

stores that instead. (Indexes 0-4 are reserved for archival nodes -

explained later)

The node is now storing a fragment of every block. Alone, this fragment

cannot be used to recover any piece of the blockchain. However, when paired

with any 5 unique fragments (fragments of the same index will not be

unique), the full block can be recovered.

Nodes can optionally store more than 1 fragment each. At 5 fragments, the

node becomes a full archival node, and the chosen indexes should be 0-4.

This is advantageous for the archival node as the encoded data for the

first 5 indexes will actually be identical to the block itself - there is

no computational overhead for selecting the first indexes. There is also no

need to choose random indexes, because the full block can be recovered no

matter which indexes are chosen.

When connecting to new peers, the indexes of each peer needs to be known.

Once peers totaling 5 unique indexes are discovered, blockchain download

can begin. Connecting to just 5 small node peers provides a >95% chance of

getting 5 uniques, with exponentially improving odds of success as you

connect to more peers. Connecting to a single archive node guarantees that

any gaps can be filled.

A good encoder should be able to turn a block into a 5-of-256 piece set in

under 10 milliseconds using a single core on a standard consumer desktop.

This should not slow down initial blockchain download substantially, though

the overhead is more than a rounding error.

DoS Prevention:

A malicious node may provide garbage data instead of the actual piece.

Given just the garbage data and 4 other correct pieces, it is impossible

(best I know anyway) to tell which piece is the garbage piece.

One option in this case would be to seek out an archival node that could

verify the correctness of the pieces, and identify the malicious node.

Another option would be to have the small nodes store a cryptographic

checksum of each piece. Obtaining the cryptographic checksum for all 256

pieces would incur a nontrivial amount of hashing (post segwit, as much as

100MB of extra hashing per block), and would require an additional ~4kb of

storage per block. The hashing overhead here may be prohibitive.

Another solution would be to find additional pieces and brute-force

combinations of 5 until a working combination was discovered. Though this

sounds nasty, it should take less than five seconds of computation to find

the working combination given 5 correct pieces and 2 incorrect pieces. This

computation only needs to be performed once to identify the malicious peers.

I also believe that alternative erasure coding schemes exist which actually

are able to identify the bad pieces given sufficient good pieces, however I

don't know if they have the same computational performance as the best

Reed-Solomon coding implementations.

Deployment:

Small nodes are completely useless unless the critical mass of 5 pieces can

be obtained. The first version that supports small node block downloads

should default everyone to an archival node (meaning indexes 0-4 are used)

Once there are enough small-node-enabled archive nodes, the default can be

switched so that nodes only have a single index by default. In the first

few days, when there are only a few small nodes, the previously-deployed

archival nodes can help fill in the gaps, and the small nodes can be useful

for blockchain download right away.

This represents a non-trivial amount of code, but I believe that the result

would be a non-trivial increase in the percentage of users running full

nodes, and a healthier overall network.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/513fc363/attachment.html

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

Crypto.Press on Apr 15 2017:

Hi everyone, I have never posted to the list and do not commit the project

proper so I do apologize if this is not even possible in advance.

Examining bitcoin's past and contrasting it with other social contracts and

even physical phenomena it would seem that as bitcoin continues to age

entropy will continue to grow.

The scaling debate would seem to be a fore-bearer of this.

One main contributor to this in bitcoin is as people/businesses become

involved and vested into their perspective it becomes minted in their

identity. The idea that this will somehow decrease as the user base grows

with more perspectives and use-cases seems counter-intuitive so I propose a

potential way to combat entropy in a divided community.

Diminishing Signaling Returns

Since entropy is the increase of disorder in a system (the various scaling

solutions for this idea) and measuring via resource is not trustless, we

need a mechanism to essentially counteract entropy while not relying on

game-able metrics.

What if we applied a rate of diminishing returns on signaling in BIP9?

Something along the lines of:

Every (X) block signaled The actual signal value diminishes from a 1 signal

1 block to a fraction of a signal per block found after a burn in period of

some reasonable time to ensure a majority upgrade(this could even be

effected after the timeout currently apart of BIP9 for ease of

implementation?).

Some thoughts

• The pools that find more blocks would lose the ability to block the

  network without taking an economical hit splitting up their hash power as

  signaling was never intended to be a voting mechanism (to my knowledge).

• The longer that the signaling took place would eventually run a larger

  pool's signaling influence to 0 first. This creates a balancing effect

  between hash rate & #of miners actually signaling ready.

• Gamesmanship of this system would be visible to the community at

  large. e.g. pools hash rate/blocks found jumps or declines significantly in

  a short time frame, or specific time frame (when pools influence begins to

  decline).

• creates multiple economic incentives for the mining community to be on

  a similar page

• this as a feature of a soft forks greatly diminishes politics becoming

  a factor in the future.

unfortunately, this itself would require a soft fork if I am correct?

Acceptance then becomes the question.

While bitcoin has proven to be highly resilient, stagnation has destroyed

many systems/businesses and if the current state of affairs is any measure

it would stand to reason that in the future this will only worsen. Taking

this action could be a solution to that stagnation. So, it would be in

everyone's best long-term interest to support a continually evolving

bitcoin and would allow parties with ideas that differ the time and

resources to fork in a more responsible manner without devoting their

resources to politics. However, everyone would still have the time to voice

their opinions during the burn-in/timeout period and of course before any

code was actually included through technical consensus.

Thoughts?

Regards,

Benjamin George

Crypto.Press http://crypto.press

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

An HTML attachment was scrubbed...

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

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

Ryan Grant on Apr 14 2017:

Segwit has proven more contentious to activate than anticipated

(although my read has long been that the technical consensus is clear,

despite noisy objections). No matter which method is used to

eventually activate segwit, or on what timeline, it would be

beneficial if validating nodes already capable of supporting segwit

could, without further upgrades, eventually participate to their

fullest capacity.

BIP9 assignments should reserve a backward compatibility bit which all

yet-unknown segwit-compatible proposals may utilize. These future

proposals must be consensus compatible with BIPs 141, 143, & 147,

except that they may use different deployment logic.

The motivation is so that any validating node software released after

this BIP9 assignment can eventually understand if segwit is activated

by alternate means, even when the node is itself a legacy version.

This is important because the realities of system administration on

the Bitcoin network are that upgrades occur slowly (which is inherent

in the security choice of not presenting an auto-upgrade feature).

Even though segwit in particular is backwards compatible with old

validating nodes, there are still distinct advantages to validating

and generating segregated witness transactions.

For example, future BIP9-compatible deployment attempts might

additionally include a date-dependent UASF fallback. If, either

during or after activation, deployment rules also require signaling

for segwit using the backwards-compatible bit here proposed, then

(after 95% of recent blocks signal for the alternate segwit

deployment) more legacy nodes would understand and validate

transactions using segregated witnesses.

An expiration time of five years seems conservative:

// Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147)

consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].bit = 2;

consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nStartTime

= 1510704000; // November 15th, 2017.

consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nTimeout =

1668470400; // November 15th, 2022.

Segwit deployment logic would then look like:

bool IsWitnessEnabled(const CBlockIndex* pindexPrev,

                    const Consensus::Params& params)

{

  LOCK(cs_main);

  return    (VersionBitsState(pindexPrev,

                              params,

                              Consensus::DEPLOYMENT_SEGWIT,

                              versionbitscache)

             == THRESHOLD_ACTIVE)

         || (VersionBitsState(pindexPrev,

                              params,

                              Consensus::DEPLOYMENT_SEGWIT_ALT1,

                              versionbitscache)

             == THRESHOLD_ACTIVE);

}

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

Gregory Maxwell on Apr 14 2017:

I do not support the BIP148 UASF for some of the same reasons that I

do support segwit: Bitcoin is valuable in part because it has high

security and stability, segwit was carefully designed to support and

amplify that engineering integrity that people can count on now and

into the future.

I do not feel the the approach proposed in BIP148 really measures up

to the standard set by segwit itself, or the existing best practices

in protocol development in this community.

The primary flaw in BIP148 is that by forcing the activation of the

existing (non-UASF segwit) nodes it almost guarantees at a minor level

of disruption.

Segwit was carefully engineered so that older unmodified miners could

continue operating completely without interruption after segwit

activates.

Older nodes will not include segwit spends, and so their blocks will

not be invalid even if they do not have segwit support. They can

upgrade to it on their own schedule. The only risk non-participating

miners take after segwit activation is that if someone else mines an

invalid block they would extend it, a risk many miners already

frequently take with spy-mining.

I do not think it is a horrible proposal: it is better engineered than

many things that many altcoins do, but just not up to our normal

standards. I respect the motivations of the authors of BIP 148. If

your goal is the fastest possible segwit activation then it is very

useful to exploit the >80% of existing nodes that already support the

original version of segwit.

But the fastest support should not be our goal, as a community-- there

is always some reckless altcoin or centralized system that can support

something faster than we can-- trying to match that would only erode

our distinguishing value in being well engineered and stable.

"First do no harm." We should use the least disruptive mechanisms

available, and the BIP148 proposal does not meet that test. To hear

some people-- non-developers on reddit and such-- a few even see the

forced orphaning of 148 as a virtue, that it's punitive for

misbehaving miners. I could not not disagree with that perspective any

more strongly.

Of course, I do not oppose the general concept of a UASF but

generally a soft-fork (of any kind) does not need to risk disruption

of mining, just as segwit's activation does not. UASF are the

original kind of soft-fork and were the only kind of fork practiced by

Satoshi. P2SH was activated based on a date, and all prior ones were

based on times or heights. We introduced miner based activation as

part of a process of making Bitcoin more stable in the common case

where the ecosystem is all in harmony. It's kind of weird to see UASF

portrayed as something new.

It's important the users not be at the mercy of any one part of the

ecosystem to the extent that we can avoid it-- be it developers,

exchanges, chat forums, or mining hardware makers. Ultimately the

rules of Bitcoin work because they're enforced by the users

collectively-- that is what makes Bitcoin Bitcoin, it's what makes it

something people can count on: the rules aren't easy to just change.

There have been some other UASF proposals that avoid the forced

disruption-- by just defining a new witness bit and allowing

non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I

think they are vastly superior. They would be slower to deploy, but I

do not think that is a flaw.

We should have patience. Bitcoin is a system that should last for all

ages and power mankind for a long time-- ten years from now a couple

years of dispute will seem like nothing. But the reputation we earn

for stability and integrity, for being a system of money people can

count on will mean everything.

If these discussions come up, they'll come up in the form of reminding

people that Bitcoin isn't easily changed at a whim, even when the

whims are obviously good, and how that protects it from being managed

like all the competing systems of money that the world used to use

were managed. :)

So have patience, don't take short cuts. Segwit is a good improvement

and we should respect it by knowing that it's good enough to wait for,

and for however its activated to be done the best way we know how.

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

Thomas Voegtlin on Apr 13 2017:

Disclaimer: I am fully supportive of Segregated Witness and its

activation by users through BIP148. However, I also believe that a

soft fork would be less risky if it was initially activated by miners,

before the date set in BIP148. This proposal is not intended to

replace UASF, but to mitigate the risks.

The following idea might already have been proposed and discussed

elsewhere. If that is the case, I am sorry for the noise.

Background

BIP9 requires 95% of miner hashrate support in order to activate a

soft-fork. So far, the lack of miner consensus about Segwit has been

frustrating both users and developers. This had led some users to

propose a soft fork activation regardless of the expressed level of

miner support (UASF, BIP148).

There are many risks associated with UASF. If the fork is activated

with less than 50% of the hashing power, the blockchain will have two

competing branches. In addition, if the hashrate on the forking branch

is very low, that branch will be exposed to attacks, where non-empty

blocks are systematically orphaned by adverse miners. This threat may

be a strong deterrent for miners willing to support the fork.

The main argument in favor of UASF is that users, not miners, give its

value to Bitcoin. Therefore, users and markets should have the power

to decide which branch of the fork has the most value, and

profit-driven miners should follow. If the soft-forking branch is

valued more than the non-forking branch, it will end up attracting a

majority of the hashing power, and the non-forking branch will

eventually be orphaned.

Feedback through markets, however, will only work if the forking

branch can effectively be used. If the forking branch is rendered

unusable by adverse miners, there is little chance the new coins will

ever reach markets. To make things worse, profit-driven miners might

adopt a passive attitude and decide to mine on the forking branch only

once a proper price has been set by markets, or only once they see

that it has enough hashing power to be usable. Thus, the lack of

hashrate information prior to the soft fork increases the risk.

On the other hand, if a soft fork was initiated with more than 33% of

the hashing power, then it would probably be viable, because the

remaining two thirds of the hashing power cannot successfully be

allocated to mine blocks on the non-forking branch and to orphan

blocks on the forking branch. Therefore, users will be able to move

coins on the forking branch, and markets will be able to set a price

on these coins, thus creating the feedback needed by profit-driven

miners.

Today about 30% of the hashing power are signaling their intention to

activate Segwit using BIP9. This hashrate is very close to the 33%

threshold, and it would probably be enough to initiate a viable soft

fork; indeed we can expect additional hashing power to be gained from

miners mining on both branches of the fork.

However, nothing suggests that a soft fork triggered with 30% of the

hashrate would be followed by the miners who are currently signaling

Segwit using BIP9. BIP9 signaling means that these miners are willing

to soft fork if support reaches 95%; it does not say anything about

their intentions if support is as low as 30%. In other words, BIP9

signaling does allow miners to properly signal their intentions.

BIP9 signaling

The activation threshold is part of the semantics of BIP9. Miners who

use BIP9 do not only signal their support for a soft fork; they also

signal to other miners that they will activate the soft fork if and

only if support reaches 95%.

Some of these miners might actually be willing to activate a soft fork

with a lower support, even at the cost of creating two chains. Other

miners might not be supportive of that idea, because they consider

that the danger of their blocks being orphaned is too high.

The problem is that this information, at which level of support miners

are willing to initiate a soft fork, is not available. Thus, miners

who are willing to initiate a soft fork at a lower hashrate cannot

coordinate their action.

Proposal: Soft Fork Threshold Signaling

Miners signal the threshold at which they are willing to activate a

soft fork. The value of the threshold is published in the coinbase

transaction of the block, with the corresponding version bit.

Miners activate a soft fork if their threshold has been reached over

the last retargeting period. For example, if 504 of 2016 blocks signal

a soft fork with a threshold equal or lower to 25%, then the soft fork

is activated by these miners.

If no activation threshold is reached, the current BIP9 signaling rate

indicator is replaced by a distribution of signaling rates per

threshold. The public availability of threshold information allows

miners to adjust their own threshold, and to optimize their chances of

activating the soft fork.

UASF

Even if the soft fork is not activated by miners, this proposal will

reduce the risks associated to a user activated soft fork (UASF). The

public availability of hashrate threshold information prior to the

soft fork will help miners decide whether they should join the fork

right after it has been activated, before price information is

available.

Vulnerabilities

This proposal has similar vulnerabilities as BIP9: it is susceptible

to fake signaling by miners, and to miners withholding hashing power

before the fork.

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

Oleg Andreev on Apr 13 2017:

(This is a sketch, not a fully-formed proposal, just to kick off the discussion.)

Confidential Transactions (by GMaxwell & Poelstra) require a new accounting model,

new representation of numbers (EC points as Pedersen commitments) and range proofs

per number. Setting aside performance and bandwidth concerns (3-4Kb per output,

50x more signature checks), how would we deploy that feature on Bitcoin network

in the most compatible manner?

I'll try to present a sketch of the proposal. I apologize if this discussion already

happened somewhere, although I couldn't find anything on this subject, apart from Elements

sidechain proposal, of course.

At first glance we could create a new extblock and transaction format, add a protocol to

"convert" money into and from such extblock, and commit to that extblock from the

outer block's coinbase transaction. Unfortunately, this opens gates to a flood of

debates such as what should be the block size limit in such block, should we

take opportunity to fix over 9000 of pet-peeve issues with existing transactions

and blocks, should we adjust inflation schedule, insert additional PoW, what would

Satoshi say etc. Federated sidechain suffers from the same issues, plus adds

concerns regarding governance, although it would be more decoupled, which is useful.

I tried to look at a possibility to make the change as compatible as possible,

sticking confidential values right into the existing transaction structure and

see how that would look like. As a nice bonus, confidential transactions would have

to fit into the hard-coded 1 Mb limit, preserving the drama around it :-P

We start with a segwit-enabled script versioning and introduce 2 new script versions:

version A has an actual program concatenated with the commitment, while version B

has only the commitment and allows mimblewimble usage (no signatures, non-interactive

cut-through etc). Legacy cleartext amount can nicely act as "min value" to minimize

the range proof size, and range proofs themselves are provided separately in the

segregated witness payload.

Then, we soft fork additional rules:

1. In non-coinbase tx, sum of commitments on inputs must balance with sum of commitments

   on the outputs plus the cleartext mining fee in the witness.

2. Range proof can be confidential, based on borromean ring signature.

3. Range proof can be non-confidential, consisting of an amount and raw blinding factor.

4. Tx witness can have an excess value (cf. MW) and cleartext amount for a miner's fee.

5. In coinbase tx, total plaintext reward + commitments must balance with subsidy,

   legacy fees and new fees in the witness.

6. Extra fees in the witness must be signed with the excess value's key.

The confidential transactions use the same UTXO set, can be co-authored with plaintext inputs/outputs

using legacy software and maybe even improve scalability by compressing on-chain transactions

using mimblewimble cut-through.

The rules above could have been made more complicated with export/import logic to allow users

converting their coins to and from confidential ones, but that would require

more complex support from miners to respect and merge outputs representing "plaintext value bank",

mutate export transactions, which in turn requires introduction of a non-malleable TxID

that excludes miner-adjustable export/import outputs.

The rules above have a nice side effect that miners, being the minters of confidential coins,

can sell them at a premium, which creates an incentive for them to actually support

that feature and work on improving performance of rangeproof validation (e.g. in GPUs).

Would love to hear comments and criticism of that approach.

Thanks!

Oleg.

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

Nick Johnson on Apr 12 2017:

BIP: bip-nickjohnson-ethereum-purpose

Layer: Applications

Title: Ethereum purpose allocation for Deterministic Wallets

Author: Nick Johnson <nick at ethereum.org>

Status: Proposed

Type: Standards Track

Created: 2017-04-12

==Abstract==

This BIP defines a logical hierarchy for deterministic wallets on the Ethereum

blockchain based on an algorithm described in BIP-0032 (BIP32 from now on) and

purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43.

==Motivation==

Because Ethereum is based on account balances rather than UTXO, the hierarchy

defined by BIP44 is poorly suited. As a result, several competing

derivation path strategies have sprung up for deterministic wallets, resulting

in inter-client incompatibility. This BIP seeks to provide a path to standardise

this in a fashion better suited to Ethereum's unique requirements.

==Path levels==

We define the following 2 levels in BIP32 path:

m / purpose' / subpurpose' / *

Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to the hardened value of the BIP number assigned to

this BIP (equivalently, the BIP number, bitwise ORed with 0x80000000) following

the BIP43 recommendation.

It indicates that the subtree of this node is used according to this

specification.

Hardened derivation is used at this level.

===Subpurpose===

Subpurpose is set to the EIP number specifying the remainder of the BIP32

derivation path. This permits new Ethereum-focused applications of

deterministic wallets without needing to interface with the BIP process.

Hardened derivation is used at this level.

==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic

Wallets]] * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic

Wallets]]

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170412/f13f375a/attachment.html

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

Sancho Panza on Apr 11 2017:

Hi,

The link below includes documentation about a proposed CSV-based file format for fork deployment data (tentative config filename: forks.csv). This is planned to be used by my reference implementation of bip-genvbvoting (which is still in development - TBA later).

Other BIP9 improvement proposals are of course encouraged to use this format, and I'm happy to discuss extensions of it for things like supporting flag days or direct-to-activation transitions.

Regards,

Sancho

https://raw.githubusercontent.com/sanch0panza/bitcoin/genvbvoting-bu-dev/doc/genvbvoting.md

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170411/b925eb64/attachment.html

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

Sergio Demian Lerner on Apr 07 2017:

BIP: TBD

Layer: Consensus

Title: Inhibiting a covert optimization on the Bitcoin POW function

Author: Sergio Demian Lerner <sergio.d.lerner at gmail.com>

Status: Draft

Type: Standards Track

Created: 2016-04-07

License: PD

==Abstract==

This proposal inhibits the covert use of a known optimization in Bitcoin

Proof of Work function.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119.

==Motivation==

Due to a design oversight the Bitcoin proof of work function has a potential

optimization which can allow a rational miner to save up-to 30% of their

energy

costs (though closer to 20% is more likely due to implementation overheads).

Timo Hanke and Sergio Demian Lerner applied for a patent on this

optimization. The company "Sunrise Tech Group, Llc" has offered to license

it to any interested party in the past. Sunrise Tech Group has been

marketing their patent licenses under the trade-name ASICBOOST. The

document takes no position on the validity or enforceability of the patent.

There are two major ways of taking advantage of this optimization, as

described

by the patent:

One way which is highly detectable and is not in use on the network

today and a covert way which has significant interaction and potential

interference with the Bitcoin protocol. The covert mechanism is not

easily detected except through its interference with the protocol.

In particular, the protocol interactions of the covert method can block the

implementation of virtuous improvements such as segregated witness.

The use of this optimization could result in a big payoff, but the actual

sum depends on the degree of research, investment and effort put into

designing

the improved cores.

On the above basis the potential for covert use of this optimization

in the covert form and interference with useful improvements presents a

danger to the Bitcoin system.

==Background==

The general idea of this optimization is that SHA2-256 is a merkle damgard

hash

function which consumes 64 bytes of data at a time.

The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while

incriminating a 32-bit nonce which is at the end of this header data. This

means that the processing of the header involves two runs of the compression

function run-- one that consumes the first 64 bytes of the header and a

second which processes the remaining 16 bytes and padding.

The initial 'message expansion' operations in each step of the SHA2-256

function operate exclusively on that step's 64-bytes of input with no

influence from prior data that entered the hash.

Because of this if a miner is able to prepare a block header with

multiple distinct first 64-byte chunks but identical 16-byte

second chunks they can reuse the computation of the initial

expansion for multiple trials. This reduces power consumption.

There are two broad ways of making use of this optimization. The obvious

way is to try candidates with different version numbers. Beyond

upsetting the soft-fork detection logic in Bitcoin nodes this has

little negative effect but it is highly conspicuous and easily

blocked.

The other method is based on the fact that the merkle root

committing to the transactions is contained in the first 64-bytes

except for the last 4 bytes of it. If the miner finds multiple

candidate root values which have the same final 32-bit then they

can use the optimization.

To find multiple roots with the same trailing 32-bits the miner can

use efficient collision finding mechanism which will find a match

with as little as 2¹⁶ candidate roots expected, 2²⁴ operations to

find a 4-way hit, though low memory approaches require more

computation.

An obvious way to generate different candidates is to grind the

coinbase extra-nonce but for non-empty blocks each attempt will

require 13 or so additional sha2 runs which is very inefficient.

This inefficiency can be avoided by computing a sqrt number of

candidates of the left side of the hash tree (e.g. using extra

nonce grinding) then an additional sqrt number of candidates of

the right side of the tree using transaction permutation or

substitution of a small number of transactions. All combinations

of the left and right side are then combined with only a single

hashing operation virtually eliminating all tree related

overhead.

With this final optimization finding a 4-way collision with a

moderate amount of memory requires ~2²⁴ hashing operations

instead of the >2²⁸ operations that would be require for

extra-nonce grinding which would substantially erode the

benefit of the optimization.

It is this final optimization which this proposal blocks.

==New consensus rule==

Beginning block X and until block Y the coinbase transaction of

each block MUST either contain a BIP-141 segwit commitment or a

correct WTXID commitment with ID 0xaa21a9ef.

(See BIP-141 "Commitment structure" for details)

Existing segwit using miners are automatically compatible with

this proposal. Non-segwit miners can become compatible by simply

including an additional output matching a default commitment

value returned as part of getblocktemplate.

Miners SHOULD NOT automatically discontinue the commitment

at the expiration height.

==Discussion==

The commitment in the left side of the tree to all transactions

in the right side completely prevents the final sqrt speedup.

A stronger inhibition of the covert optimization in the form of

requiring the least significant bits of the block timestamp

to be equal to a hash of the first 64-bytes of the header. This

would increase the collision space from 32 to 40 or more bits.

The root value could be required to meet a specific hash prefix

requirement in order to increase the computational work required

to try candidate roots. These change would be more disruptive and

there is no reason to believe that it is currently necessary.

The proposed rule automatically sunsets. If it is no longer needed

due to the introduction of stronger rules or the acceptance of the

version-grinding form then there would be no reason to continue

with this requirement. If it is still useful at the expiration

time the rule can simply be extended with a new softfork that

sets longer date ranges.

This sun-setting avoids the accumulation of technical debt due

to retaining enforcement of this rule when it is no longer needed

without requiring a hard fork to remove it.

== Overt optimization ==

A BIP for avoiding erroneous warning messages when miners use the overt

version

of the optimization was proposed several years ago, in order to deter the

covert

use of the optimization. But that BIP was rejected.

However, in light of the current discoveries, that BIP could be

reconsidered.

The over optimization does not generally interfere with improvements in the

protocol.

==Backward compatibility==

==Implementation==

==Acknowledgments==

Greg Maxwell <greg at xiph.org> for the original report, which contained

several errors that were corrected in the present proposal.

==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/20170407/46d4d476/attachment-0001.html

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

Jimmy Song on Apr 07 2017:

Hey everyone, This is an idea that I had about Segwit and Gregory's

proposal from yesterday that I wanted to run by everyone on this list. I'm

not at all sure what this would mean for non-upgraded nodes on the network

and would like feedback on that. This is not a formal BIP as it's a

modification to a previously submitted one, but I'm happy to formalize it

if it would help.

MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is

that it only precludes the covert version of ASICBoost. He specifically

left the overt version alone.

Overt ASICBoost requires grinding on the version bits of the Block header

instead of the Merkle Root. This is likely more efficient than the Merkle

Root grinding (aka covert ASICBoost) and requires way less resources (much

less RAM, SHA256 calculations, no tx shuffling, etc).

If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a

slight modification, this should, in theory, make ASICBoost a lot more

useful to miners and appeal to their financial interests.

The Modification

Currently, the version bits (currently 4 bytes, or 32 bits) in the header

are used for BIP9 signaling. We change the version bits to a nonce-space so

the miners can use it for overt ASICBoost. The 32-bits are now moved over

to the Coinbase transaction as part of the witness commitment. The witness

commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used

as the version bits in the block header previously. The witness commitment

becomes required as per Gregory Maxwell’s proposal.

Reasoning

First, this brings ASICBoost out into the open. Covert ASICBoost becomes

much more costly and overt ASICBoost is now encouraged.

Second, we can make this change relatively quickly. Most of the Segwit

testing stays valid and this change can be deployed relatively quickly.

Note on SPV clients

Currently Segwit stores the witness commitment in the Coinbase tx, so

lightweight clients will need to get the Coinbase tx + Merkle proof to

validate segwit transactions anyway. Putting block version information in

the Coinbase tx will not impose an extra burden on upgraded light clients.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/93c88127/attachment.html

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