[bitcoin-dev] CVE-2018-17144 disclosure (inflation vulnerability) (copy-paste)

[Bryan Bishop via bitcoin-dev]

It has been informed to me that the writeup for the recent
vulnerability was not distributed to this mailing list. Please find
details at the following blog post:

https://bitcoincore.org/en/2018/09/20/notice/

I believe a release notice was posted but not information about the bug,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016413.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016414.html

There was also further discussion here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016424.html

Also, around the time those emails were sent, there was a mailing list
moderator queue bug and nobody was able to approve emails including
myself. This bug was subsequently resolved by Linux Foundation.

The remainder of this email is copy-paste from the bitcoincore.org
page linked above.

=== Full disclosure ===

CVE-2018-17144, a fix for which was released on September 18th in
Bitcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of
Service component and a critical inflation vulnerability. It was
originally reported to several developers working on Bitcoin Core, as
well as projects supporting other cryptocurrencies, including ABC and
Unlimited on September 17th as a Denial of Service bug only, however
we quickly determined that the issue was also an inflation
vulnerability with the same root cause and fix.

In order to encourage rapid upgrades, the decision was made to
immediately patch and disclose the less serious Denial of Service
vulnerability, concurrently with reaching out to miners, businesses,
and other affected systems while delaying publication of the full
issue to give times for systems to upgrade. On September 20th a post
in a public forum reported the full impact and although it was quickly
retracted the claim was further circulated.

At this time we believe over half of the Bitcoin hashrate has upgraded
to patched nodes. We are unaware of any attempts to exploit this
vulnerability.

However, it still remains critical that affected users upgrade and
apply the latest patches to ensure no possibility of large
reorganizations, mining of invalid blocks, or acceptance of invalid
transactions occurs.

=== Technical details ===

In Bitcoin Core 0.14, an optimization was added (Bitcoin Core PR
#9049) which avoided a costly check during initial pre-relay block
validation that multiple inputs within a single transaction did not
spend the same input twice which was added in 2012 (PR #443). While
the UTXO-updating logic has sufficient knowledge to check that such a
condition is not violated in 0.14 it only did so in a sanity check
assertion and not with full error handling (it did, however, fully
handle this case twice in prior to 0.8).

Thus, in Bitcoin Core 0.14.X, any attempts to double-spend a
transaction output within a single transaction inside of a block will
result in an assertion failure and a crash, as was originally
reported.

In Bitcoin Core 0.15, as a part of a larger redesign to simplify
unspent transaction output tracking and correct a resource exhaustion
attack the assertion was changed subtly. Instead of asserting that the
output being marked spent was previously unspent, it only asserts that
it exists.

Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts
to double-spend a transaction output within a single transaction
inside of a block where the output being spent was created in the same
block, the same assertion failure will occur (as exists in the test
case which was included in the 0.16.3 patch). However, if the output
being double-spent was created in a previous block, an entry will
still remain in the CCoin map with the DIRTY flag set and having been
marked as spent, resulting in no such assertion. This could allow a
miner to inflate the supply of Bitcoin as they would be then able to
claim the value being spent twice.

=== Timeline ===

Timeline for September 17, 2018: (all times UTC)

14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg
Maxwell, Wladimir Van Der Laan of Bitcoin Core, deadalnix of Bitcoin
ABC, and sickpig of Bitcoin Unlimited.
15:15 Greg Maxwell shares the original report with Cory Fields, Suhas
Daftuar, Alex Morcos and Matt Corallo
17:47 Matt Corallo identifies inflation bug
19:15 Matt Corallo first tries to reach slushpool CEO to have a line
of communication open to apply a patch quickly
19:29 Greg Maxwell timestamps the hash of a test-case which
demonstrates the inflation vulnerability
(a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350)
20:15 John Newbery and James O’Beirne are informed of the
vulnerability so they can assist in alerting companies to a pending
patch for a DoS vulnerability
20:30 Matt Corallo speaks with slushpool CTO and CEO and shares patch
with disclosure of the Denial of Service
20:48 slushpool confirmed upgraded
21:08 Alert was sent to Bitcoin ABC that a patch will be posted
publicly by 22:00
21:30 (approx) 

Re: [bitcoin-dev] [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set

[CryptAxe via bitcoin-dev]

Feel free to take a look at my implementation of UTXO loading (for core
~0.16.99) here:
https://github.com/DriveNetTESTDRIVE/DriveNet/commit/60189ea9a23865180e25207ecf66f95d84f642c6


Note that this has consensus implications, and that there are bugs (some of
which are fixed in later commits to that repository)


On Tue, Sep 25, 2018 at 4:56 PM Damian Williamson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A fairly decent rework would be needed but it seems that the idea has
> merit initially.
>
>
> As it is now, it is not only that a utxo exists but, that the transaction
> it references and the block it is within can also be fully validated.
>
>
> So, if a utxo block set type existed then by consensus every so often a
> bunch of blocks containing just the validated utxo set to a given height,
> say 100,000 blocks below the current blockheight, and necessary header data
> could be appended onto the valid chain and nodes would be free to drop all
> preceding blocks. I suspect that many wouldn't and that even many new nodes
> would still desire to download the full blockchain but, for the use case
> you mention it would make sense.
>
>
> If done [right/wrong] it may even make Satoshi's fortune spendable.
> Something to watch out for.
> --
> *From:* bitcoin-discuss-boun...@lists.linuxfoundation.org <
> bitcoin-discuss-boun...@lists.linuxfoundation.org> on behalf of Dave
> Scotese via bitcoin-discuss 
> *Sent:* Wednesday, 26 September 2018 1:46:54 AM
> *To:* Bitcoin Discuss
> *Subject:* Re: [bitcoin-discuss] Proposal to replace full blockchain with
> recent history plus UTXO Set
>
> The image at imgur and the pastebin both reference block 542324 but the
> correct block is 542322.  As the pastebin shows, the decimal and hex
> representations I gave for the block height did not match, and this is
> why.  If you use the Merkle root for block 542322 instead of 542324, you'll
> be able to see the correct Game of Life play out and make the apron image.
>
> Dave.
>
> On Sun, Sep 23, 2018 at 11:38 AM Dave Scotese 
> wrote:
>
> I thought I didn't have access to the dev list and so intended to post the
> following proposal to this discussion list, but used the wrong email
> address.  Anyway, my email did get into the dev list (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016420.html)
> but I'll repeat it here:
>
> I've been working on an idea that relieves full nodes of storing the
> entire blockchain. Open source software generally relies on the fact that
> "enough" people agree that it's secure. Bitcoin software works that way
> too. So if you understand enough to see that a UTXO set is valid at a
> certain block height, and there are enough other people who agree and that
> set is recognizable by humans, then we can use that UTXO set and ditch the
> blockchain that existed up to that point. It would save a lot of storage
> and make it a lot easier to run a full node.
>
> Have you reviewed the source code from which your wallets were compiled?
> At some point, we all trust third parties, but generally (at least among
> people who understand Bitcoin) they are large composite groups so that no
> small group or individual can profit from cheating.
>
> I look forward to answering any concerns and also to any offers of help.
> I used block 542324 of the Bitcoin blockchain to make a memorable
> experience using the game of life. I wrote a script for the open-source
> Game-of-Life software Golly and shared it in the paste at
> https://pastebin.com/k5Ssc0qk. It produces the image at
> https://imgur.com/a/rwIQuVz. If someone can tell me how to get a UTXO Set
> from the bitcoin client, I'll send them $50 of bitcoin. Then I could get
> the SHA256 hash of that set and try to make a recognizable checkpoint for
> the Bitcoin blockchain. If someone runs Golly and shares a video of the
> game playing out (into the apron-shaped image), I'll send them $50 of
> bitcoin too.
>
> In a few decades when the blockchain has grown to a few terabytes and the
> UTXO Set is still just a few gigabytes, I'd like to see more people start
> running full nodes without the hassle of a long wait and loads of storage
> space. That's what stops me from running one.
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy  and Meme Racing
>  (in alpha).
> I'm the webmaster for The Voluntaryist 
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante .
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list

Re: [bitcoin-dev] [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set

[Damian Williamson via bitcoin-dev]

A fairly decent rework would be needed but it seems that the idea has merit 
initially.


As it is now, it is not only that a utxo exists but, that the transaction it 
references and the block it is within can also be fully validated.


So, if a utxo block set type existed then by consensus every so often a bunch 
of blocks containing just the validated utxo set to a given height, say 100,000 
blocks below the current blockheight, and necessary header data could be 
appended onto the valid chain and nodes would be free to drop all preceding 
blocks. I suspect that many wouldn't and that even many new nodes would still 
desire to download the full blockchain but, for the use case you mention it 
would make sense.


If done [right/wrong] it may even make Satoshi's fortune spendable. Something 
to watch out for.


From: bitcoin-discuss-boun...@lists.linuxfoundation.org 
 on behalf of Dave Scotese 
via bitcoin-discuss 
Sent: Wednesday, 26 September 2018 1:46:54 AM
To: Bitcoin Discuss
Subject: Re: [bitcoin-discuss] Proposal to replace full blockchain with recent 
history plus UTXO Set

The image at imgur and the pastebin both reference block 542324 but the correct 
block is 542322.  As the pastebin shows, the decimal and hex representations I 
gave for the block height did not match, and this is why.  If you use the 
Merkle root for block 542322 instead of 542324, you'll be able to see the 
correct Game of Life play out and make the apron image.

Dave.

On Sun, Sep 23, 2018 at 11:38 AM Dave Scotese 
mailto:dscot...@litmocracy.com>> wrote:
I thought I didn't have access to the dev list and so intended to post the 
following proposal to this discussion list, but used the wrong email address.  
Anyway, my email did get into the dev list 
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016420.html)
 but I'll repeat it here:

I've been working on an idea that relieves full nodes of storing the entire 
blockchain. Open source software generally relies on the fact that "enough" 
people agree that it's secure. Bitcoin software works that way too. So if you 
understand enough to see that a UTXO set is valid at a certain block height, 
and there are enough other people who agree and that set is recognizable by 
humans, then we can use that UTXO set and ditch the blockchain that existed up 
to that point. It would save a lot of storage and make it a lot easier to run a 
full node.

Have you reviewed the source code from which your wallets were compiled? At 
some point, we all trust third parties, but generally (at least among people 
who understand Bitcoin) they are large composite groups so that no small group 
or individual can profit from cheating.

I look forward to answering any concerns and also to any offers of help.   I 
used block 542324 of the Bitcoin blockchain to make a memorable experience 
using the game of life. I wrote a script for the open-source Game-of-Life 
software Golly and shared it in the paste at https://pastebin.com/k5Ssc0qk. It 
produces the image at https://imgur.com/a/rwIQuVz. If someone can tell me how 
to get a UTXO Set from the bitcoin client, I'll send them $50 of bitcoin. Then 
I could get the SHA256 hash of that set and try to make a recognizable 
checkpoint for the Bitcoin blockchain. If someone runs Golly and shares a video 
of the game playing out (into the apron-shaped image), I'll send them $50 of 
bitcoin too.

In a few decades when the blockchain has grown to a few terabytes and the UTXO 
Set is still just a few gigabytes, I'd like to see more people start running 
full nodes without the hassle of a long wait and loads of storage space. That's 
what stops me from running one.


--
I like to provide some work at no charge to prove my value. Do you need a 
techie?
I own Litmocracy and Meme 
Racing (in alpha).
I'm the webmaster for The Voluntaryist which now 
accepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal to replace full blockchain with recent history plus UTXO Set

[Dave Scotese via bitcoin-dev]

 The image at imgur and the pastebin both reference block 542324 but the
correct block is 542322.  As the pastebin shows, the decimal and hex
representations I gave for the block height did not match, and this is
why.  If you use the Merkle root for block 542322 instead of 542324, you'll
be able to see the correct Game of Life play out and make the apron image.

Dave.

On Fri, Sep 21, 2018 at 6:49 PM Dave Scotese 
wrote:

> I've been working on an idea that relieves full nodes of storing the
> entire blockchain. Open source software generally relies on the fact that
> "enough" people agree that it's secure. Bitcoin software works that way
> too. So if you understand enough to see that a UTXO set is valid at a
> certain block height, and there are enough other people who agree and that
> set is recognizable by humans, then we can use that UTXO set and ditch the
> blockchain that existed up to that point. It would save a lot of storage
> and make it a lot easier to run a full node.
>
> Have you reviewed the source code from which your wallets were compiled?
> At some point, we all trust third parties, but generally (at least among
> people who understand Bitcoin) they are large composite groups so that no
> small group or individual can profit from cheating.
>
> I look forward to answering any concerns and also to any offers of help.   I
> used block 542324 of the Bitcoin blockchain to make a memorable experience
> using the game of life. I wrote a script for the open-source Game-of-Life
> software Golly and shared it in the paste at https://pastebin.com/k5Ssc0qk.
> It produces the image at https://imgur.com/a/rwIQuVz. If someone can tell
> me how to get a UTXO Set from the bitcoin client, I'll send them $50 of
> bitcoin. Then I could get the SHA256 hash of that set and try to make a
> recognizable checkpoint for the Bitcoin blockchain. If someone runs Golly
> and shares a video of the game playing out (into the apron-shaped image),
> I'll send them $50 of bitcoin too.
>
> In a few decades when the blockchain has grown to a few terabytes and the
> UTXO Set is still just a few gigabytes, I'd like to see more people start
> running full nodes without the hassle of a long wait and loads of storage
> space. That's what stops me from running one.
>
>

-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Trivia on the history of compact fraud proofs and anti censorship.

[Gregory Maxwell via bitcoin-dev]

It's generally not /too/ important where ideas come from, even in our
open source non-patent encumbering world the only compensation people
get for sharing a good idea is the credit they receive. Most of the
time people are still happy to see their ideas further developed, even
if credit isn't sufficiently given.

But I'm particularly disappointed when attribution gets withheld in
the furtherance of political attaks. In some cases people have adopted
public positions that e.g. Bitcoin developers don't care about
scalability and then show that, by comparison, they care by publishing
work explaining/elaborating the scaling work of Bitcoin devs, but to
maintain consistency with their claims go through an extended effort
to avoid attributing them.

In two cases so far, I've painstakingly walked through an idea with a
political opponent in the Bitcoin space in private, only to have them
turn around and present the ideas I argued into their heads as novel
inventions without a shred of credit to me or the Bitcoin development
community.

One of them was the case of Peter R and the subchains paper, which I
previously forwarded to the list the correspondence between myself and
him where I argued the concept of preconsensus as part of his disproof
of the orphaning-controls-capacity claim.

The other is on compact fraud proofs with Justus Ranvier (again, a BU
person). I promptly complained directly to Justus when I saw him doing
it. I'm now forwarding to the list for posterity, because after almost
two years and several pings, I was never even given a response.

This came up to my attention today because V. Buterin published a
paper on lite client security ( https://arxiv.org/pdf/1809.09044.pdf )
that was apparently unaware of proposals from our community on sampled
anti-withholding[1]. ... and this paper cites Justus' writeup as both
the only example of fraud proofs previously, and evidence that
sampling coded data was not previously considered.

[1] e.g. https://download.wpsoftware.net/bitcoin/wizards/2015-04-18.html
starting at "The improvement we have is this". Error coded
anti-withholding been discussed many times-- and I've been pretty
bummed that I've been unable to excite people much about the idea,
hopefully that will change with the eth hype machine behind it--, but
this particular citation is while not the earliest or clearest
description, perfect for this case since the context is that it's a
complaint that the same author was failing to cite our communities
past efforts on fraud proofs, and as a result they weren't aware of
the state of the art like anti-withholding.

-- Forwarded message -
From: Gregory Maxwell 
Date: Fri, Nov 25, 2016 at 9:46 PM
Subject: A plea for ethical behavior
To: Justus Ranvier 


https://www.reddit.com/r/btc/comments/5evvth/fraud_proofs/

I spent _hours_ explaining how this technology would work to you on
reddit in private message, walking you through arguments on it.
Pointing out some of the details.

I also originally introduced the idea of compact fraud proofs to the
community (though the general idea was that of Bitcoin's creator,
without the compact-- just the unworkable kind) and was the first
person to enumerate the missing components for it.

Yet, the idea here is attribute solely to you, leaving me erased from history.

This isn't right.  It is especially offensive because the same parties
affiliated with BU use this plagiarism as a proof point that they are
scaling innovators while I am not, -- the height of absurdity when
they do it with ideas I invented and introduced to them.

Mike Hearn didn't have the integrity to credit Matt for the invention
of thinblocks; instead he was happy to have other people misrepresent
the history, I think you are a better person than him and hope you
will say something.

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

Re: [bitcoin-dev] URI scheme with optional bech32 address

[shiva sitamraju via bitcoin-dev]

Hi,

I am not sure why this wasn't discussed more but it seemed like a very good
idea to me
https://www.reddit.com/r/Bitcoin/comments/9iivej/its_been_like_a_year_and_bech32_adoption_remains/

QR code is very important for network wide adoption. The problem is bech32
qr code isn't backward compatible and noone is going to show two QR codes.
Everyone is going safe with P2SH address qr code.

Example of proposed URI. I want not sure of technically best encoding, but
this is just for ideas

bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?bech32=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?keyhash=a70aa2014fbc2151e0a5da78a8dead358d3af384
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?amount=0.123=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy

As merchants/exchanges adopt this QR code, wallets that support bech32 can
chose to autopay to bech32 address  (for lower tx fee). This can create a
network effect as more people start using bech32 and when we reach enough
wallet adoption, people can shift to just showing bech32 QR codes


-- 
Shiva S
CEO @ Blockonomics 
Decentralized and Permissionless Payments
Join us on Telegram 
View our Welcome Guide

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