This (non-technical) topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=2206674.0

This topic has been moved to Mining (Altcoins).

https://bitcointalk.org/index.php?topic=1864920.0

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release candidate 1 of a new major bitcoin Core release, version 0.14.0, has
been made available.

This is a release candidate for a new major version release, including new
features, various bugfixes and performance improvements.

Preliminary release notes for the release can be found here:

    https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md

Binaries can be downloaded from:

    https://bitcoin.org/bin/bitcoin-core-0.14.0/test.rc1/

Source code can be found on github under the signed tag

    https://github.com/bitcoin/bitcoin/tree/v0.14.0rc1

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.14.0 final, otherwise
a new rc will be made available after these are solved.

Please report bugs using the issue tracker at github:

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJYqYjyAAoJEHSBCwEjRsmmyjwH/3J4ML+yUgj7j6hGr9/cQm4T
5I1lcGNIeh12qlJV/0ZlOI4U1gi+PgDUlGVflKWNN87h/S6XebGE5ovjF1bNZEed
KRB/gQTXQIg4v/rObslibs8W1LESGB6Ttif7icvUZ7uMFqP7N76tMOEQM8WGK6NZ
6v0fqTC15RoEkv+/y5ZwSYPm5F+ZT0JEBXMIIQ873nQ45JckJ3+aU4i321gn0KDk
kBm348wYqOqdEpQ7hpbMPStoXMrfsijM00FK5/98F5LTLubbf0a0+cdZDVak1t44
roLA2dfh3cYHFncEBFO4nJ71iSnbaqgfx9HRilfCF5O4zfDcZgWRKkUTHft1Z9o=
=2z+P
-----END PGP SIGNATURE-----

0.13.2 is out and here is the release announcement:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bitcoin Core version 0.13.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.13.2/>

Or by bittorrent:

  magnet:?xt=urn:btih:746697d03db3ff531158b1133bab5d1e4cef4e5a&dn=bitcoin-core-0.13.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&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F

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

Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.

In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.

We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.

No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.

- From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes
===============

Change to wallet handling of mempool rejection
- -----------------------------------------------

When a newly created transaction failed to enter the mempool due to
the limits on chains of unconfirmed transactions the sending RPC
calls would return an error.  The transaction would still be queued
in the wallet and, once some of the parent transactions were
confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt
mempool insertion at the same time transaction rebroadcast is
attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool
can be abandoned with the previously existing abandontransaction RPC
(or in the GUI via a context menu on the transaction).


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

### Consensus
- - #9293 `e591c10` [0.13 Backport #9053] IBD using chainwork instead of height and not using header timestamp (gmaxwell)
- - #9053 `5b93eee` IBD using chainwork instead of height and not using header timestamps (gmaxwell)

### RPC and other APIs
- - #8845 `1d048b9` Don't return the address of a P2SH of a P2SH (jnewbery)
- - #9041 `87fbced` keypoololdest denote Unix epoch, not GMT (s-matthew-english)
- - #9122 `f82c81b` fix getnettotals RPC description about timemillis (visvirial)
- - #9042 `5bcb05d` [rpc] ParseHash: Fail when length is not 64 (MarcoFalke)
- - #9194 `f26dab7` Add option to return non-segwit serialization via rpc (instagibbs)
- - #9347 `b711390` [0.13.2] wallet/rpc backports (MarcoFalke)
- - #9292 `c365556` Complain when unknown rpcserialversion is specified (sipa)
- - #9322 `49a612f` [qa] Don't set unknown rpcserialversion (MarcoFalke)

### Block and transaction handling
- - #8357 `ce0d817` [mempool] Fix relaypriority calculation error (maiiz)
- - #9267 `0a4aa87` [0.13 backport #9239] Disable fee estimates for a confirm target of 1 block (morcos)
- - #9196 `0c09d9f` Send tip change notification from invalidateblock (ryanofsky)

### P2P protocol and network code
- - #8995 `9ef3875` Add missing cs_main lock to ::GETBLOCKTXN processing (TheBlueMatt)
- - #9234 `94531b5` torcontrol: Explicitly request RSA1024 private key (laanwj)
- - #8637 `2cad5db` Compact Block Tweaks (rebase of #8235) (sipa)
- - #9058 `286e548` Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (ryanofsky)
- - #8865 `4c71fc4` Decouple peer-processing-logic from block-connection-logic (TheBlueMatt)
- - #9117 `6fe3981` net: don't send feefilter messages before the version handshake is complete (theuni)
- - #9188 `ca1fd75` Make orphan parent fetching ask for witnesses (gmaxwell)
- - #9052 `3a3bcbf` Use RelevantServices instead of node_network in AttemptToEvict (gmaxwell)
- - #9048 `9460771` [0.13 backport #9026] Fix handling of invalid compact blocks (sdaftuar)
- - #9357 `03b6f62` [0.13 backport #9352] Attempt reconstruction from all compact block announcements (sdaftuar)
- - #9189 `b96a8f7` Always add default_witness_commitment with GBT client support (sipa)
- - #9253 `28d0f22` Fix calculation of number of bound sockets to use (TheBlueMatt)
- - #9199 `da5a16b` Always drop the least preferred HB peer when adding a new one (gmaxwell)

### Build system
- - #9169 `d1b4da9` build: fix qt5.7 build under macOS (theuni)
- - #9326 `a0f7ece` Update for OpenSSL 1.1 API (gmaxwell)
- - #9224 `396c405` Prevent FD_SETSIZE error building on OpenBSD (ivdsangen)

### GUI
- - #8972 `6f86b53` Make warnings label selectable (jonasschnelli) (MarcoFalke)
- - #9185 `6d70a73` Fix coincontrol sort issue (jonasschnelli)
- - #9094 `5f3a12c` Use correct conversion function for boost::path datadir (laanwj)
- - #8908 `4a974b2` Update bitcoin-qt.desktop (s-matthew-english)
- - #9190 `dc46b10` Plug many memory leaks (laanwj)

### Wallet
- - #9290 `35174a0` Make RelayWalletTransaction attempt to AcceptToMemoryPool (gmaxwell)
- - #9295 `43bcfca` Bugfix: Fundrawtransaction: don't terminate when keypool is empty (jonasschnelli)
- - #9302 `f5d606e` Return txid even if ATMP fails for new transaction (sipa)
- - #9262 `fe39f26` Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs)

### Tests and QA
- - #9159 `eca9b46` Wait for specific block announcement in p2p-compactblocks (ryanofsky)
- - #9186 `dccdc3a` Fix use-after-free in scheduler tests (laanwj)
- - #9168 `3107280` Add assert_raises_message to check specific error message (mrbandrews)
- - #9191 `29435db` 0.13.2 Backports (MarcoFalke)
- - #9077 `1d4c884` Increase wallet-dump RPC timeout (ryanofsky)
- - #9098 `ecd7db5` Handle zombies and cluttered tmpdirs (MarcoFalke)
- - #8927 `387ec9d` Add script tests for FindAndDelete in pre-segwit and segwit scripts (jl2012)
- - #9200 `eebc699` bench: Fix subtle counting issue when rescaling iteration count (laanwj)

### Miscellaneous
- - #8838 `094848b` Calculate size and weight of block correctly in CreateNewBlock() (jnewbery)
- - #8920 `40169dc` Set minimum required Boost to 1.47.0 (fanquake)
- - #9251 `a710a43` Improvement of documentation of command line parameter 'whitelist' (wodry)
- - #8932 `106da69` Allow bitcoin-tx to create v2 transactions (btcdrak)
- - #8929 `12428b4` add software-properties-common (sigwo)
- - #9120 `08d1c90` bug: Missed one "return false" in recent refactoring in #9067 (UdjinM6)
- - #9067 `f85ee01` Fix exit codes (UdjinM6)
- - #9340 `fb987b3` [0.13] Update secp256k1 subtree (MarcoFalke)
- - #9229 `b172377` Remove calls to getaddrinfo_a (TheBlueMatt)

Credits
=======

Thanks to everyone who directly contributed to this release:

- - Alex Morcos
- - BtcDrak
- - Cory Fields
- - fanquake
- - Gregory Maxwell
- - Gregory Sanders
- - instagibbs
- - Ivo van der Sangen
- - jnewbery
- - Johnson Lau
- - Jonas Schnelli
- - Luke Dashjr
- - maiiz
- - MarcoFalke
- - Masahiko Hyuga
- - Matt Corallo
- - matthias
- - mrbandrews
- - Pavel Janík
- - Pieter Wuille
- - randy-waterhouse
- - Russell Yanofsky
- - S. Matthew English
- - Steven
- - Suhas Daftuar
- - UdjinM6
- - Wladimir J. van der Laan
- - wodry

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJYa2IbAAoJEHSBCwEjRsmmiQsIALbkHVVwO7nViQKH1Ub2qpD4
TplOuAP0/4vYotizuI12Gqdnu8SjPmhKwAgIXhVinE6TS4OzGNjy+6LtWGzpcpud
B1pcziZ72Mlfxdbdd1UhDMWEjoBumS9RmXMSqzTlMVlHRv4iiISzdaAROu1jHvdF
YTsnmKXB8OvcXOecxRMY9LrnpSzLALM2MYTDmYwlhhExHIA8ZqI2niky6GCfyfDi
KD7bgfIFJzlgFTpAdhQXOXtWoRV5iHqN7T29ot8Y+yIhVCRhHYXS93Z50GKbkqYV
MXsVAkpZF3qqcKYSPFjbif7faMdrMqcEiII6QhXdDTRGI/35IfuTDbWzzQlnVyY=
=ncCY
-----END PGP SIGNATURE-----

This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=1708364.0

This topic has been moved to Investigations.

https://bitcointalk.org/index.php?topic=456691.0

Privacy and fungiblity are essential components for any money-like system.
Without them, your transactions leak information about your private
activities and leave you at risk of discriminatory treatment. Without them your security is reduced due to selective targeting and your commercial negotiations can be undermined.

They're important and were consideration's in Bitcoin's design since day one. But Bitcoin's initial approach to preserving privacy and fungiblity -- pseudonymous addresses-- is limited, and full exploitation of it requires less convenient usage patterns that have fallen out of favor.

There are many technologies people have been working on to improve fungiblity and privacy in different ways-- coinjoins[url=http://and [url=https://bitcointalk.org/index.php?topic=321228.0]swaps] and [url=https://bitcointalk.org/index.php?topic=321228.0]swaps, confidential
transactions, encrypted/committed transactions, schnorr
multisignature, MAST, better wallet input selection logic, private wallet scanning, tools for address reuse avoidance, P2P encryption], ECDH-derived addresses, P2P surveillance resistance, to name a few.

Having some more in-the-field examples will help prioritize these efforts. So I'm asking here for more examples of where privacy and fungiblity loss have hurt Bitcoin users or just discouraged Bitcoin use-- and, if known, the specifics about how those situations came about.

Please feel free to provide links to other people's examples too, and also feel free to contact me privately ( gmaxwell@blockstream.com GPG: 0xAC859362B0413BFA ).

I also posted this question on Reddit, but though I might get a broader audience here.

There is still a steady flow of high-s transactions hitting the network. The only reason they get mined now is because of some people running special nodes that mutate them to make them acceptable.

Is anyone interested in trying to find the sources?

Here is a list of txids for transactions which appear to have originally been high-S (these are the IDs for the mutated forms that had a chance to get confirmed):


 66cd25ffa2166484f5cca506af1fecb72a1702868baac9f687a6d99a4c320a8f
 4218f7fbd078676cc947f9f65a797152a2264d4ab3b97c7e385988f520141cba
 f0e4bd7e94d13e3dbdf99eb4cbecc2ff06447f9e63b918c59d1507dc8244c5fe
 b21b260817a6bc2431d92f1829c875631df264051a443304542bf1e2d66cb1a3
 5b35bf06f7d662ccc56d8feb52db43d2b4d6f9136d0e13c887dccf237f5a2969
 cacdd00567c30b3e48e49174fb320efbc5aeb270162242a84a205031e68ba382
 cce6b2dd89c42afe1eab3a4dcc560453515cfbd0bf0060c454b0f30340a1598f
 3adcdc564692f00fbb1792e90b8cc3858629b7cca4723a70a704942e447f559d
 b214a090f663c203d07470911089d6f43effbe89dbe5105078e7e9cb7a23f4f8
 463697ba3de7cdf664eec32f733afaafd4420602fac732f7f38a1bd4c042e896
 0a47f478e15c3b380a36c5b814a5c8024f11c502969640f5d941e7dbad6de340
 1cc6fa4c37ac0e74b74b9d5f51aecaa90887bcf94c64258621e01c730ee7fd51
 55192be1a7510c541b02f4db8d4ef5a30339efebf46886ac15526c51d3fbc13d
 12fe77b2b4a698894534c2e77f6d11df205ccf21568e61c16046ebd1ae09b047
 4bf5108b3cced77e9906bd94b87977a8df2438ba2a3a19ba2e1518666c764983
 24390b6848a18bfd30ffbd3e10861515022fea2e30c0cd1ceca777740c7a86ee
 ae53552694144e5a4d840408bd79a62c8746aef4bbc155adf0652c2ea287bdc8
 18d3b40b6638f18e6d1eb5a0b8ca00fcebf64d7604ba5e28af7ff28b49efc977
 7482c567f20dc8672aabe828587e2ce59f6200352b17776503fd13ed3308751f
 58f381eea35ca53be31bd3f5e7080200563660661a2596b1e9ffc272cebeebcb
 c8a6fd916c87ab821815061be9403e10c9c4bac9be36ad7ed912af59abbb4687
 e6ebbd64b839e43d8f7976c13ed07d4fabf004341b0cc13ab2a13f2197ea6bd8
 3729f405cd54916c15988e0921ab309b438728462144ebad61c9f136b10bb58a
 b4afc58224de92107831f47703a4149a801651318f88dbcb8fa9074df3c3162d
 70f1bd6097a4e840f1b0dbdcf263e8cac37fb6105f7b2d0b8fade1f0590d5e5d
 4a9fda6c59b0f17d5438c43fbcfd0023252ff0a86df6e6c20de5ce7bd13983e5
 4a030272358cfb001b376a15e9526225f3714e25b53dbc3f2a13445cdf947ed3
 78239f7808d73021dab9b85ad3abd467b3add4ee03db26d4b6ce1ad1c7abbf60
 f6e5f4e0d4e5727cc5f386c61cdc4c68db4e58db6f7223b2a11fe2e88c8abef2
 47172a10a0718a804c01fff443c5fe6a23f7c763c9a66f5b9971d6bfbdcd0a90
 616ada60080bf656665cb5f32e58fb09d8aa47d156bc29a6bf88ed583990a5c1
 660e09824fe2cf7ca150c085dcbbb2318a3c30b5a0730b5d02eb466b1c7861d7
 6354cf56426648da423c9628fe0826f4e793e9d3a741eda11f106d475ab2d27d
 be5dfe6f2d2fa6b52e824fce271850ab29b1b6898149e33b35e954a0e69a6161
 0dc49684545fb8fa9c791003e70decffec4eab67113b88d7b91bae86600e1f15
 5688d81403121d5609cb39fb62a51d35ee0ecce53a9deb2b4fa62af8fef25926
 2c092e6ba01356699fea40c482c96a519ef1ddc2fbae7da8b04ef724ce9f926e
 fbfd74b5d79ecb35366f4e8d4b8576de7b851ed0758f190a029e6c3fd6ad23fe
 cd926bdc5e2b8c1224b4741466421ea6ae1da0ceb1ace6c7e670d3a31525038a
 97ef4772cc23c39e3cc281dc54474ef49d9f6b93dda3d8d461bb6d07c135bf80
 78450676ae8c2c7e4940ded64a04cf67fbbfc47c912a51c7c8c40a1d5220b769
 32392686c71458c624ca5734244aaf5fe153f92d1a61983ed3717bb1fc329f1b
 1dc72d720c2134632d69f2b6a51f5472634e40f016a68b79425606db42551030
 59732273a5aa07742e85a3add9f1e63d653127df5862e77e89b68f0a9d9c779f
 2bf130de8e1fe22973da372d8b3d21a989d3748aecc9e904699ff05d8f293e31
 881f11442cedfaf3added561eb47f09522b94390e198b5a676b1c7c31c341ba2
 e07d46acec0b936fbfbf4b43f1ada13e1f5bbc9c39319945b35736946fa27c19
 fe2e08e07cdd4b7a9fc70841899af6d59d52b180b4a7d01adf5fe0a1a8a3fdcd
 c2f17bf1c93fb12e3f0e3d54c817f98ad2d68d3e8bb10c1297a92652cebf9f29
 a20f805a45e3c3fbd6e4ea711e68ff2df519490cf7da984c9e4b4740b86ef7fb
 413bd5a599b3f95cee98b0def130fcde7af464fa2122305bf076e60ec523bdc2
 9fdaead9aded7d21dafe5966fa8457ba06eb08b56b863bf2fb507c23c4e37312
 d296caef92e30dbdf52008e2339614ebcd7bceee491a8aac3a46f2bb6a88933e
 fce8acc2d75481901be94d6fd7cfbac4de225e0399556143b49dabbc839e7137
 16b8753d85402e52d154acc07b46d4a416efdba04c9fccaa6e4272446844c1f4
 dcb9aac101988dac9f7b09fc9572830119d241c070d00504f7370e3fd2822e2f
 ab22fba4ffc4dff2820cd01c3e451015b608330d8607327d47aca2eb01125e2a
 88fff8d5fad5e8a3fadee2c4d94b9df3cd8a8dcf3665507c46c32194970f5fbd
 e133b675014146aef7363d492114aec0cc8ee74d800db6d743139a9cb03467cd
 ebd6aebc248dfdfa7af46f19d35f930e643eb3675b6606f1ef5468d84de12315
 533e8c8a49bb39d06226229d3a8e31e67f7fd906a501f192c265d212ae573eff
 8d2b48449687376a464d872a0ca89321535be66691fe504b2ded0774b58548c4
 d237e25e67c78763ec9a68aa3fee055c434155f0d764ca685f37a867ea94a3ea
 007628d3b19d8802946dccebb0eab96935f8c6e11eadd00d9537cb9a9be30491
 faf207a88c6601fc9e637097ee44e775b9610af792b86269dadefdbecab89f89
 f1bfacd6bd3cd18bc55fd6b819843e054b33f6654a87a45c5cefa54349e56b93
 7c25df8d0f98520995b644a17b120679afb6ba083e94ec19667cae09496e6c36
 285f0131b80fadd60e191272e8a2be8760bab8ae2ebf33cdf4721f2938c78760
 700358899649d129dcb45f49474047a6831fea1cb0cb3ccf8eb9593605c9e16d
 cbb261f050dc4a1f248f944acfeac8667db378d4029e3db72c60319af7c516f9
 a06df3f0b737f8ec013d2f64cf4c5bf6b4572f960e0775634ff8b4ecf99d6b49
 42f1905292d8f62d06467a6bbb8a21fb4f354afcb4703520e75cc2c3062a26e1
 ee8a9a7c98af7729efcd419d978ee22ca28f0a1ef28c52fa39f511b1df751eb1
 314daa27edcce90eeda259e14e763bf23832202334ea047031e2c97389608096
 b24efbcc282941055bdc4efe918784045467f2e5b7f7d7f7e0e2fc797a99a0ff
 c8dcfbeaecd894c5c4bb2ea304c0edc33098e123bded906bef500f42d9af12c7
 ad80e0452a88dfdeac137d7d8bb5176a215709bd3f833815ad66ffc3efc02361
 eaf23f317ba9db8f00a3e971c3d58707a756a5dc7a31f0d41dd7ddac01bf55f4
 c1d3592866cabb91d06ab8f285aded45d6d9131b34fc0eb131e7f21c66c1a34d
 bfe36e4d6af62571a26596a0671c3701997c4b612bf9ffda4c48ca8ffca92a20
 37025dfe5cd66c3ddd30a334d31e4f32618bd68b187e60e5872ed769246fad43
 077619db4bbda76b0dbae8f78f365ac0d605d8f83ce70641669226d4f1ba5bb2
 053667aadffee3a96782e025af297bf832402879e1f3767e73fd98f128b40e65
 ca065d660b2fd47cdd82d650cb30cca1e29aafb45f67c32e6c3e66d00c935270

This topic has been moved to Project Development.

https://bitcointalk.org/index.php?topic=1484936.0

I am happy to announce the first successful Zero-Knowledge Contingent Payment (ZKCP) on the Bitcoin network.

ZKCP is a transaction protocol that allows a buyer to purchase information from a seller using Bitcoin in a manner which is private, scalable, secure, and which doesn’t require trusting anyone: the expected information is transferred if and only if the payment is made. The buyer and seller do not need to trust each other or depend on arbitration by a third party.

Imagine a movie-style “briefcase swap” (one party with a briefcase full of cash, another containing secret documents), but without the potential scenario of one of the cases being filled with shredded newspaper and the resulting exciting chase scene.

An example application would be the owners of a particular make of e-book reader cooperating to purchase the DRM master keys from a failing manufacturer, so that they could load their own documents on their readers after the vendor’s servers go offline. This type of sale is inherently irreversible, potentially crosses multiple jurisdictions, and involves parties whose financial stability is uncertain–meaning that both parties either take a great deal of risk or have to make difficult arrangement. Using a ZKCP avoids the significant transactional costs involved in a sale which can otherwise easily go wrong.

In today’s transaction I purchased a solution to a 16x16 Sudoku puzzle for 0.10 BTC from Sean Bowe, a member of the Zcash team, as part of a demonstration performed live at Financial Cryptography 2016 in Barbados. I played my part in the transaction remotely from California.

The transfer involved two transactions:

    8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e
    200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae

Almost all of the engineering work behind this ZKCP implementation was done by Sean Bowe, with support from Pieter Wuille, myself, and Madars Virza.


Read more, including technical details and links to the software at https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/

[88%]

Bitcoin Core 0.12 introduced a new blocksonly setting.  When set to blocksonly a node behaves normally but sends and receives no lose transactions; instead it handles only complete blocks. There are many applications for nodes where only confirmed transactions are interesting, and a node which still verifies and forwards blocks still contributes to network health-- less, perhaps, than one that relays transactions: but it also consumes fewer resources to begin with. An additional downside they don't get the latency advantages of signature caching since every transaction they see is totally new to them-- this isn't something miners should use.

How much less bandwidth does blocksonly use in practice?  I recently measured this using two techniques: Once by instrumenting a node to measure bandwidth used for blocks vs all other traffic, and again by repeatedly running in both modes for a day and monitoring the hosts total network usage; both modes gave effectively the same result.

How much is the savings?  Blocksonly reduced the node's bandwidth usage by 88%.

A significant implication of this is that any scheme for bandwidth reduction which works by using already relayed transactions to reduce the size of transmitted blocks can _AT MOST_ reduce the overall bandwidth usage by 12%-- assuming that differential compression achieved an "infinity-fold" improvement. (An example of Amdahl's law)

Why does relay use so much bandwidth?  The fundamental reason for this is because relay in the Bitcoin Protocol is linear in the number of transactions and the number of peers. (E.g. bandwidth is a function of Transactions * Peers).  The protocol uses an 'efficient' INV scheme --- but this scheme only reduces the bandwidth by a constant factor:  For every transaction a 36 byte long INV is sent (or received) from _every_ peer, and the full transaction is only sent once. Since the INV is a significant fraction of the transaction size (e.g. 36 bytes vs 300) this means that every 10 or so peers uses just as much bandwidth as sending the full transaction every time would take.

For the subset of nodes where blocksonly meets their needs it's available now and gives pretty much the greatest possible bandwidth savings. Full stop. For blocks the INV process is much more efficient because the ratio of INV size to a megabyte block is so large. But what can we do for all the other cases?

In the literature there are schemes for quite efficient gossip but there seems to be a trade-off between efficiency and attack robustness (for example, you could arrange nodes in a minimum spanning tree rooted at some super node(s) which would be optimal for repeated bandwidth but insanely unreliable and vulnerable to attacks). Even the simple INV scheme is vulnerable to attack: peers can delay transactions by INVing but then sending the data only after a long delay.  With ephemeral anonymous peers, attack resistance is very important to us-- but fortunately we don't need to achieve optimal efficiency.

One possible scheme I've been discussing (and working on) for a while is mempool reconciliation. My work here was originally motivated by the desire to avoid relay costs for transactions which are just going to be quickly replace or fall below the relay threshold, but this can also be applied to drastically reduce relay costs.

The idea is this, at random intervals a node will ask one of it's peers for a sketch of the top X MBytes of it's mempool. In it's request it could also signal that it's interested only in transactions whos ancestor feerate is over some minimum threshold, along with information about the size and feerate of its own mempool.  The returned sketch is an IBLT (see this reddit post for an EL5 explanation that I created for IBLT) of some size estimated by the sender based on the information sent by the requester.  Unlike the efficient block transmission IBLT proposals, this IBLT only transmits transaction IDs-- which will avoid the fragmentation overhead needed in sending whole transactions.

The requester then attempts to reconstruct the IDs using the content of it's own mempool.  If it is unable to reconstruct all of the IDs, it requests from another random peer with a different seed.

When the node has multiple IBLTs it can use the partial solutions from each of them to help solve the other ones.

As it learns new txids that it was previously unaware of it then fetches them via getdata. When it completes a reconstruction it can INV any missing transactions towards the peers that didn't have them.

(To avoid IBLT batching delays slowing transaction propagation too much, two peers can be elected to receive INVs for every transaction immediately; similar to the existing trickle-for-privacy scheme).

Most of the academic literature on IBLTs is concerned about parameter selections that minimize the asymptotic overhead (size of IBLT vs set difference) for perfect reconstruction of the set.  These parameters, however, result in quite high probabilities for complete failure.  In our case, being able to recover some of a set is fine both because mempools don't need to be completely consistent, and requests to other peers will help recover the missing entries.

A similar pattern happened (for the same reason) in the invention of fountain codes-- (one can approximately think of a IBLT as the dual of a fountain code). To achieve better odds of reconstruction, the order of nodes in the graph (isomorphic to the number of hash buckets in IBLT) should be randomly selected from a special distribution, instead of a constant. The effect is that the mixture of node orders reduces the probability that a decode gets stuck, because it is more likely that there will be be some entries that have the optimal density.  For IBLT this can be done by using the hash of the set member to pick the number of buckets for that set just like it is used to pick which buckets are used.

But right now I'm not aware of any research on what these optimal order distributions would look like for IBLTs given assumptions around capacity ratios... so I think there is a fair amount of basic science that needs to be worked out in order to really nail down a good design.  I've been trying to work on making more progress here for a couple months, but the toxic environment makes the grind a little difficult. I thought I would checkpoint my thinking here in the hope that someone would have some more thoughts to contribute.

In any case, this scheme would avoid the quadratic-like behavior of relay bandwidth. It would let nodes trade latency off vs relay overhead, and it would allow for a graceful way of handling the highest priority transactions first. -- transactions a dozen or more blocks deep in the mempool are not going to get mined any time soon, so if they have lower relay latency from reconciling them less frequently that is no great harm. I believe it could do so without substantial increases in vulnerability to attack. The same software infrastructure could also be used for bandwidth minimized block transfer for nodes that do have mempools (otherwise blocksonly gives optimal bandwidth gains), though latency minimization is much better accomplished via techniques like Matt's efficient block relay protocol-- since the most important thing to minimize latency is to minimize roundtrips.

Back in 2013 an Anonymous Author wrote a brief paper on using BLS signatures to achieve a kind of non-interactive coinjoin.  I jumped on it right away, pointing out that it also could have useful anti-censorship properties. (Edit: Paper link is down, a copy is available from Andrew Poelstra.)

The core property it depends on is that fact that for a BLS signature one can take a collection of {message, pubkey, signature} tuples and merge their signatures: {[message1, message2, ...], [pubkey1, pubkey2, ...], signature}, in a way which is infeasible to unmerge them without knowing the components, and still be able to verify the result. Via a clever trick that involves signing per input and per output, the authorship of inputs and outputs can be unlinked. I have a sidechain implementation of this that I've been working on-- like coinjoin generally it composes well with CT, but I'm unsure of what to do about the performance (more below).

Another application of these aggregatable signatures which has come up from time to time in #bitcoin-wizards is using them to reduce blocksize  ("2013-09-13 21:38 < gmaxwell> sipa: I'm mildly excited about this pairing crypto aggregate signature idea. Not because of the anonymity stuff, but because it makes scalable relay fees viable. and can also reduce transaction sizes in the non-anonymous case"), since you'd save the sizes of the free standing signatures. Aggregate BLS signatures could even be made compatible with 'efficient' fraud proofs, though the cost of doing probably makes it not a win. (You would do a merkel sum tree over the interior computation, which aggregates the partial signatures as products in a 3kbit field; which would make it possible to show a block had an invalid aggregate signature with a compact proof).

The main downside of this are two fold-- the BLS signatures involve Pairing Cryptography-- less mature security assumptions than plain ECC signatures, and more importantly they're slow to verify: On hardware that can verify 70,000 secp256k1 signatures per second (or 140,000/s with batched Schnorr) they could only process about 8,000 BLS signature per second, with state of the art parameter selection and software.  So, while bandwidth would be reduced, the capacity of most nodes wouldn't be increased much because they'd be bottlenecked on signatures.  (And, right now, signature validation is extensively cached in Bitcoin-- and the aggregation would move validation back on the critical path).

[I've had some conversations about Dan Boneh about using multi-exponentiation like optimizations in computing the required product of parings here-- but it's likely that the performance improvement that this would get would only be on the order of 2x.]

Adam Back was asking me about this again today and I pointed him to the prior discussions regarding the performance limits.  Then he suggested just using Schnorr multi-signature instead of the BLS signatures. The idea is that if you have inputs with pubkeys P and P2  you can combine them and to form a P+P2 pubkey and sign with that to prove authorization with both keys.  When this had previously been discussed the fact that someone malicious could set their P2 to P3-P and then sign the aggregate with just P3 seemed to kill it.

But actually a few months ago Pieter Wuille solved this as a side effect of his key tree multi-signature work,  He suggested instead that to combine P and P2, you use P*H(P) + P2*H(P2); this doesn't inhibit signing, but it makes it impossible to create a pubkey as a linear combination of other pre-existing pubkeys. Pieter has an implementation of this as part of the Libsecp256k1 multi-signature work: https://github.com/bitcoin/secp256k1/pull/322

So the way we could use this to improve scalability in Bitcoin would be to add a OP_GROUPCHECKSIGVERIFY (and perhaps a multi-version of it) as part of a new segwit script typecode that takes as input sighash flags and a pubkey.  The script operation would push a the pubkey onto a transaction scoped 'signature stack'  and the sighash-masked transaction hash onto a transaction scoped hash stack.

After all inputs are processed the pubkeys on the stack would be combined to a new Pubkey as P = P1*H(H(all_Pn) || P1) + P2*H(H(all_Pn) || P2) + ..., and a root message hash computed-- then an additional group signature witness at the end of the transaction would contain a signature of the root with P.

Verification speed would be similar to individual inputs with batch schnorr (the multiplication with H() can be folded into the multi-exp in verification), so this is more of a space savings than a speedup; but the size of the transaction would be reduced by 41% asymptotically-- without any new security assumptions or performance hit. The main limit is that a transaction must have many inputs to fully realize that benefit.

Unlike other past shared signature proposals based on exploiting pubkey reuse, there is no advantage in this design in reusing public keys; so it also doesn't create a new privacy moral hazard for the network.

Critically, multiple distinct users could cooperate to securely produce a single large transaction with a two round protocol which may make it reasonable to get _many_ inputs in a single transaction-- but unlike the BLS signatures they must interact in order to merge their signatures.  Effectively this would be a CoinJoin, with a big space (and thus fee) savings for the CoinJoin users.

Even without combining multiple users this approach would make it much more economical for a single user to sweep up txout dust which would be an important improvement on its own. For block 400083 if all transactions used this (but with no increase in CoinJoin, or even behavioral changes to prefer sendmany over chains of transactions which we would expect if this actually existed; and also ignoring multisig use, which would further improve this figure) I compute this would reduce the size of the block by 172050 bytes out of 897956 or a 19% reduction which is substantial fraction of the asymptotic result. [Edit: A scan of 2016 recent blocks with accurate counting for multisig, shows the actual reduction for existing usage patterns would be 30%]

In effect this could achieve at least half the asymptotic gain while having no negative performance impact (10x-17x better performance than BLS) and no new strong cryptographic security assumptions. To me it seems like a no brainer improvement that Bitcoin is almost sure to eventually adopt once implemented.

At my local hardware surplus place a bunch of gen 1 Avalon boards showed up.

Among them was a board that had none of the Avalon silk screening.

There were also a couple of  interesting mod-wires.



Due to lazyness I haven't dug up my batch 1 museum pieces to see if it looked like these.


(if anyone wants some dusty mining boards for $20/ea)

I thought I'd leave a note for posterity related to the reoccurring scheme of using mid-state compression to avoid sending coinbase transactions; as it seems to get reinvented from time to time.  This has been discussed several times scattered about in various places, and I thought it useful to put the folklore understanding in one place.

In Bitcoin today various schemes like P2Pool or UTXO set commitments are suggested that require adding some mandatory data to a coinbase transaction.  To prove the mandatory data is present you must then transmit the whole coinbase transaction.  Coinbase transactions can be large, e.g. in p2pool and Eligius like pools that pay directly or for other reasons. In theory, a coinbase transaction can be upto the size of the whole block.

The reoccurring optimization is to put your mandatory data at the end of the coinbase transaction, and then send a sha256 midstate. The receiver can then complete the hashing with the mandatory data and verify agreement.

I personally think this design is inadvisable because it peels back the black box of the already fragile merkle-damgård construction and may open some novel prefix-extension attacks that no one has thought to check sha2 for... but if it is done, implementations _must_ be very careful to avoid complications from serialization capture. E.g. if you require your last commitment to be a free standing output "OP_RETURN PUSH(data)" someone can instead make their final output "OP_RETURN [other stuff] PUSH__8+4+data+size", and then that output will consume the appended commitment, and then it's possible to send a misleading midstate proof, that would be parsed differently by a midstate only client and implementations that work with the whole coinbase transaction; opening up the avenue to attacks.

Another way of saying it is that due to the use of variable length fields the transaction serialization cannot be read backwards, and so no application using midstate compression-- which inherently hides the front of transaction-- can have any dependency on the serialized structure beyond "ends with these bytes"..

For commitment applications, these problems can be avoided like p2pool does by making your rule be specific to the last N bytes of the transaction (your commitment + nlocktime), regardless of what comes before them (e.g. embedded in another output is fine)... but I  still think it's best to avoid this construction entirely.

This topic has been moved to Micro Earnings.

https://bitcointalk.org/index.php?topic=1244371.0

This topic has been moved to Services.

https://bitcointalk.org/index.php?topic=1239079.0

This topic has been moved to Technical Support.

https://bitcointalk.org/index.php?topic=1241613.0

This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=1178973.0

This topic has been moved to Services.

https://bitcointalk.org/index.php?topic=1184053.0

This topic has been moved to Electrum.

https://bitcointalk.org/index.php?topic=1182264.0