From tomz at freedommail.ch  Mon Aug  1 09:30:22 2016
From: tomz at freedommail.ch (Tom)
Date: Mon, 01 Aug 2016 11:30:22 +0200
Subject: [bitcoin-dev] Introducing Flexible Transactions.
Message-ID: <1543956.nUE2O3xsdf@garp>

I've been asked one question quite regularly and recently with more force.
The question is about Segregated Witness and specifically what a hard
fork based version would look like.


This is available online at my blog;
  http://zander.github.io/posts/Flexible_Transactions/

But I'll publish the actual text here as well, hoping to hear from others in 
the Bitcoin industry what they think about this approach.




Segregated Witness (or SegWit for short) is complex. It tries to solve
quite a lot of completely different and not related issues and it tries to
do this in a backwards compatible manner. Not a small feat!

So, what exactly does SegWit try to solve? We can find info of that in the
[benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/) document.

* Malleability Fixes
* Linear scaling of sighash operations
* Signing of input values
* Increased security for multisig via pay-to-script-hash (P2SH)
* Script versioning
* Reducing UTXO growth
* Compact fraud proofs

As mentioned above, SegWit tries to solve these problems in a backwards
compatible way. This requirement is there only because the authors of
SegWit set themselves this requirement. They set this because they wished
to use a softfork to roll out this protocol upgrade.
**This post is going to attempt to answer the question if that is indeed
the best way of solving these problems.**


Starting with Malleability, the problem is that a transaction between being
created by the owner of the funds and being mined in a block is possible to
change in such a way that it still is valid, but the transaction identifier
(TX-id) has been changed. But before we dive into the deep, lets have some
general look at the transaction data first.

If we look at a
[Transaction](http://bitcoinfactswiki.github.io/Transaction) as it is
today, we notice some issues.

<table>
<tr><td colspan=2>Version</td><td>4 bytes</td></tr>
<tr><td colspan=2>Number of inputs</td><td>VarInt (between 1 and 9 
bytes)</td></tr>
<tr><td rowspan=5 class=vertical>inputs</td><td>Prev transaction 
hash</td><td>32 bytes.
            <font color="red">Stored in reverse</font></td></tr>
<tr><td>Prev transaction index</td><td>4 bytes</td></tr>
<tr><td>TX-in script length</td><td><font color=red>Compact-
int</font></td></tr>
<tr><td>TX-in script</td><td>This is the witness data</td></tr>
<tr><td>Sequence-no/<a 
href="https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki">CSV</a>
  </td><td>4 bytes</td></tr>
<tr><td colspan=2>Number of outputs</td><td>VarInt (between 1 and 9 
byte)</td></tr>
<tr><td rowspan=3 class=vertical>outputs</td><td>Value</td><td>Var 
int</td></tr>
<tr><td>TX-out script length</td><td><font color=red>Compact-
int</font></td></tr>
<tr><td>TX-out script</td><td>bytearray</td></tr>
<tr><td colspan=2>NLockTime</td><td>4 bytes</td></tr>
</table>
</table>

The original transaction format as designed by
[Satoshi Nakamoto](http://bitcoinfactswiki.github.io/Satoshi_Nakamoto/)
had a 4 byte version. This design approach is common in the industry and
the way that this is used is that a new version is defined whenever any
field in the data structure needs changing.  In Bitcoin we have not done
this and we are still at version 1.

What Bitcoin has done instead is make small, semi backwards-compatible, 
changes.
For instance the [CHECKSEQUENCEVERIFY]
(http://bitcoinfactswiki.github.io/Script/#Locktime)
feature repurposes the sequence field as a way to add data
that would not break old clients.  Incidentally, this specific change
(described in BIP68)
is not backwards compatible in the main clients as it depends on a
transaction version number being greater than 1, they all check for
Standard transactions and say that only version 1 is standard.

The design of having a version number implies that the designer wanted to
use hard forks for changes. A new client is required to know how to parse a
newly designed data structure, this should be obvious. So the idea is to
change the version number and so older clients would know they can't parse
this new transaction version. To keep operating, everyone would have to
upgrade to a client that supports this new transaction version.

Lets look at why we would want to change the version; I marked some items in
red that are confusing. Most specifically is that numbers are stored in 3
different, incompatible formats in transactions. Not really great and
certainly a source of bugs.

Transactions are cryptographically signed by the owner of the coin so
others can validate that he is actually allowed to move the coins.
The signature is stored in the `TX-in-script`.  
Crypto-geeks may have noticed something weird that goes against any
textbooks knowledge.  What this is is that a digital
signature has to be placed outside of the thing it signs. This is because
a digital signature protects against changes. But a signature itself would
cause this change. So you have to store the signature outside the thing you
sign.

Bitcoin's creator did something smart with how transactions are actually
signed so the signature actually doesn't have to be outside the
transaction. It works. Mostly. But we want it to work flawlessly
because currently this being too smart causes the dreaded malleability
issues where people have been known to lose money.


## What about SegWit?

SegWit actually solves only one of these items. It moves the signature out
of the transaction. SegWit doesn't fix any of the other problems in Bitcoin
transactions, it also doesn't change the version after making the
transaction's-meaning essentially unable to be understood by old clients.

Old clients will stop being able to check the SegWit type of transaction,
because the authors of SegWit made it so that SegWit transactions just have
a sticker of "All-Ok" on the car while moving the real data to the trailer,
knowing that the old clients will ignore the trailer.

SegWit wants to keep the data-structure of the transaction unchanged and it
tries to fix the data structure of the transaction.  This causes friction
as you can't do both at the same time, so there will be a non-ideal
situation and hacks are to be expected.

The problem, then, is that SegWit introduces more technical debt, a term
software developers use to say the system-design isn't done and needs
significant more work.  And the term 'debt' is accurate as over time
everyone that uses transactions will have to understand the defects to work
with this properly. Which is quite similar to paying interest.

Using a Soft fork means old clients will stop being able to validate
transactions, or even parses them fully. But these old clients are
themselves convinced they are doing full validation.

## Can we improve on that?

I want to suggest a way to **one-time** change the data-structure of the
transaction so it becomes much more future-proof and fix the issues it
gained over time as well. Including the malleability issue. It turns out
that this new data-structure makes all the other issues that SegWit fixes
quite trivial to fix.

I'm going to propose an upgrade I called;

> **Flexible Transactions**

Last weekend I wrote a little app (sources [here]
(http://zander.github.io/scaling/transactions))
that reads a transaction and then writes it out in a new format I've
designed for Bitcoin. Its based on ideas I've used for some time in other
projects as well, but this is the first open source version.

The basic idea is to change the transaction to be much more like modern
systems like JSON, HTML and XML. Its a 'tag' based format and has various
advantages over the closed binary-blob format.  
For instance if you add a new field, much like tags in HTML, your old
browser will just ignore that field making it backwards compatible and
friendly to future upgrades.

Further advantages;

* Solving the malleability problem becomes trivial.
* tag based systems allow you to skip writing of unused or default values.
* Since we are changing things anyway, we can default to use only var-int
  encoded data instead of having 3 different types in transactions.
* Adding a new tag later, (for instance ScriptVersion) is easy and doesn't
  require further changes to the transaction data structure. All old clients
  can still make sense of all the known data.
* The actual transaction turns out to be about 3% shorter average (calculated
  over 200K transactions)
* Where SegWit adds a huge amount of technical debt, my Flexible
  Transactions proposal instead amortizes a good chunk of technical debt.

An average **Flexible Transaction** will look like this;

<table>
<tr><td colspan=2>TxStart (Version)</td><td>0x04</td>
<td rowspan=5 class="vertical">TX-ID data</td></tr>
<tr><td rowspan=2 class=vertical>inputs</td><td>TX-ID I try to spent</td><td>1 
+ 32 bytes</td></tr>
<tr><td>Index in prev TX-ID</td><td>varint</td></tr>
<tr><td rowspan=2 class=vertical>outputs</td><td>TX-out Value (in 
Satoshis)</td><td>VarInt</td></tr>
<tr><td>TX-out script</td><td>bytearray</td></tr>
<tr><td>inputs</td><td>TX-in-script (Witness data)<td>bytearray</td>
    <td rowspan=2 class=vertical>WID-data</td></tr>
<tr><td colspan=2>TxEnd</td><td>0x2C</td></tr>
</table>

Notice how the not used tags are skipped. The `NLockTime` and the
`Sequence` were not used, so they are skipped in the transaction.

The Flexible Transaction proposal uses a list of tags. Like JSON; `"Name:"
"Value"`. Which makes the content very flexible and extensible. Just
instead of using text, Flexible Transactions use a binary format.

The biggest change here is that the `TX-in-script` (aka the witness data) is
moved to be at the end of the transaction. When a wallet generates this new
type of transaction they will append the witness data at the end but the
transaction ID is calculated by hashing the data that ends before the
witness data.

The witness data typically contains a public key as well as a signature.
In the Flexible Transactions proposal the signature is made by signing exactly
the same set of data as is being hashed to generate the TX-input. Thereby
solving the malleability issue. If someone would change the transaction, it
would invalidate the signature.

I took 187000 recent transactions and checked what this change would do to
the size of a transaction with my test app I linked to above.

* Transactions went from a average size of 1712 bytes to 1660 bytes and a
  median size of 333 to 318 bytes.
* Transactions can be pruned (removing of signatures) after they have been
  confirmed. Then the size goes down to an average of 450 bytes or a median
  of 101 bytes
* In contrary to SegWit new transactions get smaller for all clients with this
  upgrade.
* Transactions, and blocks, where signatures are removed can expect up to
  75% reduction in size.

## Broken OP_CHECKSIG scripting instruction

To actually fix the malleability issues at its source we need to fix this
instruction. But we can't change the original until we decide to make a
version 2 of the Script language.  
This change is not really a good trigger to do a version two, and it
would be madness to do that at the same time as we roll out a new format of
the transaction itself. (too many changes at the same time is bound to
cause issues)

This means that in order to make the Flexible Transaction proposal actually
work we need to use one of the NOP codes unused in Script right now and
make it do essentially the same as OP_CHECKSIG, but instead of using the
overly complicated manner of deciding what it will sign, we just define it
to sign exactly the same area of the transaction that we also use to create
the TX-ID. (see right most column in the above table)

This new opcode should be relatively easy to code and it becomes really
easy to clean up the scripting issues we introduce in a future version of
script.

## So, how does this compare to SegWit.

First of all, introducing a new version of a transaction doesn't mean we
stop supporting the current version. So all this is perfectly backwards
compatible because clients can just continue making old style transactions.
Naturally, with the problems that had, but nobody will end up stuck.

Using a tagged format for a transaction is a one time hard fork to upgrade
the protocol and allow many more changes to be made with much lower impact
on the system in the future.  There are parallels to SegWit, it strives for
the same goals, after-all. But where SegWit tries to adjust a static
memory-format by re-purposing existing fields, Flexible transactions presents
a coherent simple design that removes lots of conflicting concepts.

Most importantly, years after Flexible transactions has been introduced we
can continue to benefit from the tagged system to extend and fix issues we
find then we haven't thought of today. In the same, consistent, concepts.

We can fit more transactions in the same (block) space similarly to SegWit, 
the
signatures (witness part) can be pruned by full nodes without causing any
security implications in both solutions.  What SegWit doesn't do is
allowing unused features to not use space. So if a transaction doesn't use
NLockTime (which is near 100% of them) they will take space in SegWit but
not in this proposal. Expect your transactions to be smaller and thus lower
fee!

On size, SegWit proposes to gain 60% space. Which is by removing the
signatures minus the overhead introduced.  In my tests Flexible
transactions showed 75% gain.

SegWit also describes changes how data is stored in the block. It creates
an extra 'branch' in the merkle tree.  The Flexible Transactions proposal
is in essence solving the same problem as SegWit and the same solution for
blocks can be applied.  Which means we can have that merkle tree solution
as well. No change.


At the start of the blog I mentioned a list of advantages that the authors
of SegWit included.  It turns out that those advantages themselves are
completely not related to each other and they each have a very separate
solution to their individual problems. The tricky part is that due to the
requirement of old clients staying forwards-compatible they are forced to
push them all into the one 'fix'.

Lets go over them individually;


### Malleability Fixes

Using this new version of a transaction data-structure solves all forms of
known malleability.

### Linear scaling of sighash operations

This has been fixed in the BIP109 2MB hardfork quite some months ago.

### Signing of input values

This is included in this proposal.

### Increased security for multisig via pay-to-script-hash (P2SH)

The *Flexible transactions* proposal outlined in this document makes many
of the additional changes in SegWit really easy to add at a later time.
This change is one of them.

Bottom line, changing the security with a bigger hash in SegWit is only
included in SegWit because SegWit didn't solve the transaction versioning
problem making it trivial to do separately.  
With flexible transactions this change can now be done at any time in the
future with minimal impact.

### Script versioning

Notice that this *only* introduces the versioning byte. It doesn't actually
introduce a new version of script.  
This is an excellent example where tagged formats shine brighter than a
static memory format that SegWit uses because adding such a versioning tag
is much cleaner and much easier and less intrusive to do with
flexible transactions. Just add a new tag that defaults to version 1 so the
old transactions not having the tag stay consistent.

Imagine having to include "body background=white" in each and every html
page because it was not allowed to leave it out. Thats what SegWit does
right now. Even though it doesn't actually support changing it yet.

### Reducing UTXO growth

I suggest you read this 
[point](https://bitcoincore.org/en/2016/01/26/segwit-benefits/#reducing-utxo-growth)
for yourself, its rather interestingly technical and I'm sure many will not
fully grasp the idea.  The bottom line of that they are claiming the
UTXO database will avoid growing because SegWit doesn't allow more
customers to be served.

I don't even know how to respond to such a solution. Its throwing out the
baby with the bath water.

Database technology has matured immensely over the last 20 years, the
database is tiny in comparison to what free and open source databases can
do today. Granted, the UTXO database is slightly unfit for a normal SQL
database, but telling customers to go elsewhere has never worked out for
products in the long term.

### Compact fraud proofs

Again, not really included in SegWit, just started as a basis. The exact
same basis is suggested for flexible transactions, and as such this is
identical.

### What do we offer that SegWit doesn't offer?

* A transaction becomes extensible. Future modifications are cheap.
* A transaction gets smaller. Using less features also takes less space.
* We only use one instead of 3 types of encodings for integers.
* We remove technical debt and simplify implementations. SegWit does the
  opposite.

## Conclusions

SegWit has some good ideas and some needed fixes. Stealing all the good
ideas and improving on them can be done, but require a hard fork. This post
shows that the advantages are quite significant and certainly worth it.

We introduced a tagged data structure. Conceptually like JSON and XML in
that it is flexible, but the proposal is a compact and fast binary format.
Using the Flexible Transaction data format allows many future
innovations to be done cleanly in a consistent and, at a later stage, a
more backwards compatible manner than SegWit is able to do, even if given
much more time. We realize that separating the fundamental issues that
SegWit tries to fix all in one go, is possible and each becomes much lower
risk to Bitcoin as a system.

After SegWit has been in the design stage for a year and still we find
show-stopping issues, delaying the release, I would argue that dropping
the requirement of staying backwards compatible should be on the table.

The introduction of the *Flexible Transaction* upgrade has big benefits
because the transaction design becomes extensible.
A hardfork is done once to allow us to do soft upgrades in the future.

The Flexible transaction solution lowers the amount of changes required in
the entire ecosystem. Not just for full nodes. Especially considering that
many tools and wallets use shared libraries between them to actually create
and parse transactions.

The Flexible Transaction upgrade proposal should be considered by anyone
that cares about the protocol stability because its risk of failures
during or after upgrading is several magnitudes lower than SegWit is and
it removes technical debt that will allow us to innovate better into the
future.

Flexible transactions are smaller, giving significant savings after pruning
over SegWit.


Thanks

From pindar.wong at gmail.com  Tue Aug  2 01:49:56 2016
From: pindar.wong at gmail.com (Pindar Wong)
Date: Tue, 2 Aug 2016 08:49:56 +0700
Subject: [bitcoin-dev] ScalingBitcoin 2015: Retarget - Call For Proposals
	Now Open
Message-ID: <CAM7BtUp79oApAPJXqDAvDrCM+4mVYumSGp1vm20dsEC=LpuZfQ@mail.gmail.com>

Dear All,

The Call for Proposals (CFP) for 'Scaling Bitcoin 2016: Retarget' is now
open.

Please see https://scalingbitcoin.org for details.

*Important Dates*

Sept 2nd - Deadline for submissions to the CFP
Sept 23rd - Deadline for applicant acceptance notification

See you in Milan! (October 8th and 9th)

Ciao! :)

p.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160802/d876b20f/attachment.html>

From nicolas.dorier at gmail.com  Tue Aug  2 05:21:49 2016
From: nicolas.dorier at gmail.com (Nicolas Dorier)
Date: Mon, 1 Aug 2016 22:21:49 -0700
Subject: [bitcoin-dev] BIP Number Request: Open Asset
In-Reply-To: <CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
References: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
	<201605260353.06939.luke@dashjr.org>
	<20160705174636.GA24068@fedora-21-dvm>
	<201607060122.20593.luke@dashjr.org>
	<CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
Message-ID: <CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>

Sorry, I completely forgot about having submitted the BIP as I was busy at
this time.
Thanks for the review.

Open Asset is actually not an abandoned project and is a protocol already
used in production with multiple implementation.
Wallet: https://www.coinprism.com/
Implementation C#: https://github.com/NicolasDorier/NBitcoin with heavy
documentation (
https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_asset/colored_coins.html
)
Implementation Ruby: https://github.com/haw-itn/openassets-ruby/
Usage stats: http://opreturn.org/

Concerning whether or not we can put my name in the BIP, I'll ask the
original author that I know personally.

> Quite a bit ugly, giving a meaning to an input's pubkey script like that.
> But more problematically: how can this work with other pubkey scripts?
> Particularly relevant now that this old script format is being deprecated.
> Another possible problem is that I don't see a way to provably guarantee
an
> asset issuance is final.

Yes, with open asset it is not possible to do provably limited issuance.
The scriptPubKey can be anything, not necessarily P2PK.
If you can spend the scriptPubkey, then you are the issuer.

> And the assets attached to its inputs are destroyed? Or?

Correct, if you spend a colored output incorrectly, it is effectively
destroyed.

> Is it intentional that the first case is "parsable", and the second
"valid"?
> I think these need to be better specified; for example, it is not so
clear how
> to reach if the OAP version number is something other than 1: is that
> parsable? valid?

The terminology is correct we are parsing PUSHDATA, if there is a parsable
pushdata, the output is considered valid.
If there is multiple valid output, then we take the first one.

> What determines the asset id? How would one issue and/or transfer multiple
> asset ids in the same transaction?

You can't issue more than one asset type in a transaction. (as the asset
issued is defined by the scriptPubKey of the first input)
For multiple transfer it is possible, imagine a transaction with the
following 3 inputs and 6 outputs:

Inputs: {0, 10a, 20b}
Outputs: {5, OP_RETURN; 7; 3; 11; 9)

Inputs1: 0
Inputs2: Enqueue 10a in the queue ( {10a} )
Input3: Enqueue 20b in the queue ( { 20b, 10a} )

Output1: Before OP_RETURN, so is issuance whose color is defined by the
scriptPubKey of Input1. (say c)
Output2: No color (marker)
Output3: Dequeue 7a ( {20b, 3a} ), color output with a.
Output4: Dequeue 3a ( {20b} ), color output with a
Output5: Dequeue 11b ( {9b} ), color output with b
Output5: Dequeue 9b ( {0} ), color output with b

Finally, outputs color are
Outputs: {5c, OP_RETURN; 7a; 3a; 11b; 9b)

> What if I have a transaction with 5 outputs, the marker output at
position 3,
> and all 4 other outputs are to receive assets? Does the marker output get
> skipped in the list (ie, the list is 4 elements long) or must it be set to
> zero quantity (ie, the list is 5 elements long)?

Marker output is skipped (explained in the example)

> Addresses are not used for spending bitcoins, only for receiving them.
The way
> this BIP uses inputs' pubkey script is extremely unusual and probably a
bad
> idea.

Actually there is no "issuance address", just the AssetId is defined by the
scriptPubKey of the issuer.

> As I understand it, this would require address reuse to setup, which is
not
> supported behaviour and insecure.

Yes, it requires address reuse for issuing.

> Won't an older client then accidentally destroy assets?

Correct. Actually we prevent users sending asset to wallet which does not
support OA via another address scheme described in another document (
https://github.com/OpenAssets/open-assets-protocol/blob/master/address-format.mediawiki
)

As said, Open Asset is not a draft proposal and is already used in the wild
since 2014. We can't easily modify the protocol by now for improving it.

PS:
https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki
is
more readable than a mail.

Nicolas,

On Tue, Jul 5, 2016 at 7:14 PM, James MacWhyte <macwhyte at gmail.com> wrote:

> I'm curious to hear the answers to the questions Luke asked earlier. I
> also read through the documentation and wasn't convinced it was thought out
> well enough to actually build something on top of, but there's no reason it
> can't get a number as a work-in-progress.
>
> I hope it does continue to get worked on, though. The lack of response or
> discussion worries me that it might become an abandoned project.
>
> On Tue, Jul 5, 2016, 18:32 Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tuesday, July 05, 2016 5:46:36 PM Peter Todd wrote:
>> > On Thu, May 26, 2016 at 03:53:04AM +0000, Luke Dashjr via bitcoin-dev
>> wrote:
>> > > On Thursday, May 26, 2016 2:50:26 AM Nicolas Dorier via bitcoin-dev
>> wrote:
>> > > >   Author: Flavien Charlon <flavien at charlon.net>
>> >
>> > What's the status of this BIP? Will it be assigned?
>>
>> I was waiting for clarification on the Author thing, but Nicholas hasn't
>> responded yet. I am unaware of any reason NOT to assign it, and there
>> appear
>> to be no objections, so let's call it BIP 160.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160801/7028265d/attachment.html>

From kanzure at gmail.com  Tue Aug  2 07:20:08 2016
From: kanzure at gmail.com (Bryan Bishop)
Date: Tue, 2 Aug 2016 02:20:08 -0500
Subject: [bitcoin-dev] A conversation with Dan Boneh (2016-08-01)
Message-ID: <CABaSBaxxQW+C+QAL+uYE4htPTFUz9fDdgEHbDmnSpP1Vh8fLDg@mail.gmail.com>

Some Bitcoin developers and miners went to visit with Dan Boneh at Stanford
earlier today, and I thought I would share what we talked about.

Transcript:
http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/

Topics discussed include elliptic curve crypto, ECDSA, Schnorr signatures,
signature aggregation, BLS signature schemes, pairing crypto, group
signatures, block-level signature aggregation, transaction-level signature
aggregation, post-quantum crypto, quantum mining ASICs, provable solvency
schemes, scrypt password hashing, and balloon hashing.

(I would include the text directly but it's nearly 60 kilobytes in size and
past the point where I am presently comfortable with gunking up other
mailboxes.)

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160802/31e6d043/attachment-0001.html>

From erik at q32.com  Tue Aug  2 14:53:59 2016
From: erik at q32.com (Erik Aronesty)
Date: Tue, 2 Aug 2016 10:53:59 -0400
Subject: [bitcoin-dev] BIP Number Request: Open Asset
In-Reply-To: <CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>
References: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
	<201605260353.06939.luke@dashjr.org>
	<20160705174636.GA24068@fedora-21-dvm>
	<201607060122.20593.luke@dashjr.org>
	<CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
	<CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>
Message-ID: <CAJowKgJys93VTFuGA3ydcuqxcx_O6r0D7715Kgfyc+SP4P8J9A@mail.gmail.com>

> As said, Open Asset is not a draft proposal and is already used in the
wild since 2014. We can't easily modify the protocol by now for improving
it.

You can, however, provide a new OA2.0 protocol that improves upon these
issues, and assure that upgraded wallets maintain support for both
versions.

It seems like OA's stance has *always *been to focus on integration, rather
than fixing the core protocol and then, by virtue of having the largest
integration, saying things like "it's too late to turn back now".    Colu
and Chromaway/EPOBC also have stuff "in the wild".

I would love to see an RFC-style standard "multiple-colored-coin-protocol"
written by reps from all of the major protocols and that meta-merges the
features of these implementations - in collaboration with feedback from
core developers that understand the direction the protocol will be taking
and the issues to avoid.   HTTP/TCP/IP MCCP/BTC

As it stands, investors have to install multiple wallets to deal with these
varying implementations.   Merging them into one "meta-specification"
fairly soon might be in the best interests of the community and of future
shareholders.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160802/f8abe85e/attachment.html>

From alex.mizrahi at gmail.com  Tue Aug  2 17:25:50 2016
From: alex.mizrahi at gmail.com (Alex Mizrahi)
Date: Tue, 2 Aug 2016 20:25:50 +0300
Subject: [bitcoin-dev] BIP Number Request: Open Asset
In-Reply-To: <CAJowKgJys93VTFuGA3ydcuqxcx_O6r0D7715Kgfyc+SP4P8J9A@mail.gmail.com>
References: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
	<201605260353.06939.luke@dashjr.org>
	<20160705174636.GA24068@fedora-21-dvm>
	<201607060122.20593.luke@dashjr.org>
	<CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
	<CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>
	<CAJowKgJys93VTFuGA3ydcuqxcx_O6r0D7715Kgfyc+SP4P8J9A@mail.gmail.com>
Message-ID: <CAE28kUSaTsQ4qyGK5t5D1KiEF3yf4LEjkFvy+SiGxDK5VeAo9Q@mail.gmail.com>

>
> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>

We actually tried to do that in 2014-2015, but that effort have failed...
Nobody was really interested in collaboration, each company only cared
about it's own product.
Especially Colu, they asked everyone for requirements, and then developed a
new protocol completely on their own without taking anyone's input.

I'm not sure that merging the protocols makes sense, as some protocols
value simplicity, and a combined protocol cannot have this feature.

I don't think there is much interest in a merged colored coin protocol now.
Colu is moving away from colored coins, as far as I can tell.
CoinSpark is now doing MultiChain closed-source private blockchain.
CoinPrism also seems to be largely disinterested in colored coins.

We (ChromaWay) won't mind replacing EPOBC with something better, our
software could always support multiple different kernels so adding a new
protocol isn't a big deal for us.

So if somebody is interested in a new protocol please ping me.

One of ideas I have is to decouple input-output mapping/multiplexing from
coloring.
So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
outputs 0, 1 and 2".
In this case it will be possible to create more advanced protocols (e.g.
with support for 'smart contracts' and whatnot) while also keeping them
compatible with old ones to some extent, e.g. a wallet can safely engage in
p2ptrade or CoinJoin transactions without understanding all protocols used
in a transaction.


> - in collaboration with feedback from core developers that understand the
> direction the protocol will be taking and the issues to avoid.
>

Core developers generally dislike things like colored coins, so I doubt
they are going to help.

Blockstream is developing a sidechain with user-defined assets, so I guess
they see it as the preferred way of doing things:
https://elementsproject.org/elements/asset-issuance/


> As it stands, investors have to install multiple wallets to deal with
> these varying implementations.
>

Actually this can be solved without making a new "merged protocol": one can
just implement a wallet which supports multiple protocols.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160802/2da95a58/attachment.html>

From marc at rupy.se  Wed Aug  3 09:53:51 2016
From: marc at rupy.se (Marc Larue)
Date: Wed, 3 Aug 2016 11:53:51 +0200 (CEST)
Subject: [bitcoin-dev] Fees and Accounts
Message-ID: <alpine.LNX.2.00.1608031152530.359@rupy.se>

Hi,

I have 2 problems with bitcoind that separately are not a problem but
together they make the platform unusable for many projects.

If I have accounts I need to make sure the account holders do not 
overcharge their account. To do this I can now use "createrawtransaction() 
+ fundrawtransaction() + signrawtransaction()" and then make sure the
transaction can be paid by an account.

But since you deprecated the accounts and there is no
sendrawtransactionfrom() method; I either have to build my own account
system (this is no picknick btw, since you need to track all incoming 
funds to all addresses and having an integrated account system in bitcoind 
is 100% necessary to do this effectively).

Or I might be able to go ahead and speculate that you will not be able to
untangle the account code and hack my bitcoind to have a sendfrom with a
fixed fee parameter that overrides the size multiplication and I just do
the math before I send hoping that the transactions go through (this is 
bad but better than having accounts overcharge because they send dust that 
induce high fees).

I understand the privacy problems with using accounts for off-chain
microstransactions but currently it's the best workable option.

I hope you understand that I'm not trolling here, I have been mining since
2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I descovered
that once transactions will require fees (back then they didn't) and that
your system is not able to handle fees with accounts, I stopped developing
everything related to bitcoin.

There are probably 100s if not 1000s of developers in the same situation.

You can't just deprecate accounts like that because nobody likes the code.
Without accounts bitcoind is only a person-to-person manual client.

To build many-to-many automatic "organisations" on top of bitcoind you 
need accounts and you need fees that are predictable.

Kind Regards,

/marc

From matthew at roberts.pm  Wed Aug  3 18:16:20 2016
From: matthew at roberts.pm (Matthew Roberts)
Date: Thu, 4 Aug 2016 04:16:20 +1000
Subject: [bitcoin-dev] BIP clearing house addresses
Message-ID: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>

In light of the recent hack: what does everyone think of the idea of
creating a new address type that has a reversal key and settlement layer
that can be used to revoke transactions?

You could specify so that transactions "sent" from these addresses must
receive N confirmations before they can't be revoked, after which the
transaction is "settled" and the coins become redeemable from their
destination output. A settlement phase would also mean that a transaction's
progress was publicly visible so transparent fraud prevention and auditing
would become possible by anyone.

The reason why I bring this up is existing OP codes and TX types don't seem
suitable for a secure clearing mechanism; Nlocktimed TXs won't work for
this since you can't know ahead of time when and where a withdrawal needs
to be made, plus there's still the potential for key mismanagement; Similar
problems with OP_CHECKLOCKTIMEVERIFY apply too ? unless you keep a private
key around on the server which would defeat the purpose. The main use case
here, would be specifically to improve centralized exchange security by
making it impossible for a hot wallet to be raided all at once.

Thoughts?

Some existing background:

http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
-- Proposed the basic idea for a time-based clearing house but using
blockchains directly, this is a much better idea than my own.

roberts.pm/timechain -- My original paper written in 2015 which proposed a
similar idea for secure wallet design but implemented using time-locked
ECDSA keys. Obviously a blockchain would work better for this.

Other -- if the idea has already been brought up by other people, I
apologize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/fe4335fb/attachment.html>

From macwhyte at gmail.com  Wed Aug  3 18:33:41 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Wed, 03 Aug 2016 18:33:41 +0000
Subject: [bitcoin-dev] Fees and Accounts
In-Reply-To: <alpine.LNX.2.00.1608031152530.359@rupy.se>
References: <alpine.LNX.2.00.1608031152530.359@rupy.se>
Message-ID: <CAH+Axy5jSRVbAw_MaJArYp9_nTB8Ws6QZ5hoq4rfBZw80RciFA@mail.gmail.com>

>From what I've seen, most people build their own account system separately
(including fee management) and just use bitcoind to send, receive, and
verify transactions. It's not meant to be a drop-in solution for running an
entire bitcoin deposit and withdrawal system, it just provides the bare
tools required to build your own. If you need a pre-built solution, there
are companies that provide those types of services as a platform (BitGo,
for example).

On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> I have 2 problems with bitcoind that separately are not a problem but
> together they make the platform unusable for many projects.
>
> If I have accounts I need to make sure the account holders do not
> overcharge their account. To do this I can now use "createrawtransaction()
> + fundrawtransaction() + signrawtransaction()" and then make sure the
> transaction can be paid by an account.
>
> But since you deprecated the accounts and there is no
> sendrawtransactionfrom() method; I either have to build my own account
> system (this is no picknick btw, since you need to track all incoming
> funds to all addresses and having an integrated account system in bitcoind
> is 100% necessary to do this effectively).
>
> Or I might be able to go ahead and speculate that you will not be able to
> untangle the account code and hack my bitcoind to have a sendfrom with a
> fixed fee parameter that overrides the size multiplication and I just do
> the math before I send hoping that the transactions go through (this is
> bad but better than having accounts overcharge because they send dust that
> induce high fees).
>
> I understand the privacy problems with using accounts for off-chain
> microstransactions but currently it's the best workable option.
>
> I hope you understand that I'm not trolling here, I have been mining since
> 2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I descovered
> that once transactions will require fees (back then they didn't) and that
> your system is not able to handle fees with accounts, I stopped developing
> everything related to bitcoin.
>
> There are probably 100s if not 1000s of developers in the same situation.
>
> You can't just deprecate accounts like that because nobody likes the code.
> Without accounts bitcoind is only a person-to-person manual client.
>
> To build many-to-many automatic "organisations" on top of bitcoind you
> need accounts and you need fees that are predictable.
>
> Kind Regards,
>
> /marc
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160803/dce3245a/attachment.html>

From kanzure at gmail.com  Wed Aug  3 18:41:27 2016
From: kanzure at gmail.com (Bryan Bishop)
Date: Wed, 3 Aug 2016 13:41:27 -0500
Subject: [bitcoin-dev] Mimblewimble: non-interactive coinjoin,
 signature aggregation and confidential transactions
Message-ID: <CABaSBaz-=G-PG6XMs9roNmz7WHrWYTXH22_-H1boLd+TMtq5Eg@mail.gmail.com>

Someone dropped this document in -wizards the other day:
http://5pdcbgndmprm4wud.onion/mimblewimble.txt
http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble.txt

Some commentary:
http://gnusha.org/bitcoin-wizards/2016-08-02.log
http://gnusha.org/bitcoin-wizards/2016-08-03.log
https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_and_better/

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160803/136b7b2b/attachment.html>

From tier.nolan at gmail.com  Wed Aug  3 23:55:00 2016
From: tier.nolan at gmail.com (Tier Nolan)
Date: Thu, 4 Aug 2016 00:55:00 +0100
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
Message-ID: <CAE-z3OU+9hB7xFqYsn1-enuonxHB8E415P_Mf3b93p9MpYugjQ@mail.gmail.com>

On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism;
>

I think reversing transactions is not likely to be acceptable.  You could
add an opcode that requires that an output be set to something.

[target script] SPENDTO

This would require that [target script] is the script for the corresponding
output.  This is a purely local check.

For example, if SPENDTO executes as part of the script for input 3, then it
checks that output 3 uses the given script as its scriptPubKey.  The value
of input 3 and output 3 would have to be the same too.

This allows check sequence verify to be used to lock the spending script
for a while.  This doesn't allow reversal, but would give a 24 hour window
where the spenders can reverse the transaction.

[IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
key> CHECKSIG] SPENDTO <live public key2> CHECKSIG

Someone with the live public key can create a transaction that spends the
funds to the script in the square brackets.

Once that transaction hits the blockchain, then someone with the <offline
protected key> has 24 hours to spend the output before the person with the
live keys can send the funds onward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/3e551535/attachment-0001.html>

From macwhyte at gmail.com  Thu Aug  4 00:59:11 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Thu, 04 Aug 2016 00:59:11 +0000
Subject: [bitcoin-dev] Fees and Accounts
In-Reply-To: <alpine.LNX.2.00.1608032202340.4704@rupy.se>
References: <alpine.LNX.2.00.1608031152530.359@rupy.se>
	<CAH+Axy5jSRVbAw_MaJArYp9_nTB8Ws6QZ5hoq4rfBZw80RciFA@mail.gmail.com>
	<alpine.LNX.2.00.1608032202340.4704@rupy.se>
Message-ID: <CAH+Axy7HE7+spU+7Ken5akgrQFecV_VtjwPCbpJv0xvkGBrkqQ@mail.gmail.com>

> Most people?

I'm talking about services that are built to handle multiple accounts, like
exchanges and payment processors.


> You realize that you need to set up bitcoind to make an
> external request on every reception of funds on any address in the whole
> system.
>
No, you don't. You can write a script that repeatedly asks bitcoind for the
block height, and when it increments you know a new block has been
confirmed. So then you request the transaction list from the latest block,
and check each confirmed transaction against your database of receive/watch
addresses. If there is a match, you record the transaction info in your
database so you can use it as an input later to create a spend transaction.

You could also use something like Bitpay's Insight to make interfacing with
bitcoind easier.


> It can't possibly scale, also we don't have the time to build an account
> system for every bitcoind service. Imagine the loss of time, it's huge and
> grows exponentially with adoption, or rather there is no adoption!
>
What are you trying to build?


> Also external systems are not be trusted, specially not bitgo, did you
> read any news in the last 24 hours?
>
I prefer to wait until all facts are in before I pass judgement. I think
BitGo is an excellent company with a great track record. If used properly,
they are extremely secure. If you are worried about storing funds there
long time, don't--just use them to detect incoming payments and move your
funds elsewhere for long term storage.


> /m
>
> On Wed, 3 Aug 2016, James MacWhyte wrote:
>
> >
> > From what I've seen, most people build their own account system
> separately
> > (including fee management) and just use bitcoind to send, receive, and
> > verify transactions. It's not meant to be a drop-in solution for running
> an
> > entire bitcoin deposit and withdrawal system, it just provides the bare
> > tools required to build your own. If you need a pre-built solution, there
> > are companies that provide those types of services as a platform (BitGo,
> for
> > example).
> >
> >
> > On Wed, Aug 3, 2016, 11:25 Marc Larue via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >       Hi,
> >
> >       I have 2 problems with bitcoind that separately are not a
> >       problem but
> >       together they make the platform unusable for many projects.
> >
> >       If I have accounts I need to make sure the account holders do
> >       not
> >       overcharge their account. To do this I can now use
> >       "createrawtransaction()
> >       + fundrawtransaction() + signrawtransaction()" and then make
> >       sure the
> >       transaction can be paid by an account.
> >
> >       But since you deprecated the accounts and there is no
> >       sendrawtransactionfrom() method; I either have to build my own
> >       account
> >       system (this is no picknick btw, since you need to track all
> >       incoming
> >       funds to all addresses and having an integrated account system
> >       in bitcoind
> >       is 100% necessary to do this effectively).
> >
> >       Or I might be able to go ahead and speculate that you will not
> >       be able to
> >       untangle the account code and hack my bitcoind to have a
> >       sendfrom with a
> >       fixed fee parameter that overrides the size multiplication and I
> >       just do
> >       the math before I send hoping that the transactions go through
> >       (this is
> >       bad but better than having accounts overcharge because they send
> >       dust that
> >       induce high fees).
> >
> >       I understand the privacy problems with using accounts for
> >       off-chain
> >       microstransactions but currently it's the best workable option.
> >
> >       I hope you understand that I'm not trolling here, I have been
> >       mining since
> >       2011 on FPGAs and built bitcoinbankbook.com 2 years ago. When I
> >       descovered
> >       that once transactions will require fees (back then they didn't)
> >       and that
> >       your system is not able to handle fees with accounts, I stopped
> >       developing
> >       everything related to bitcoin.
> >
> >       There are probably 100s if not 1000s of developers in the same
> >       situation.
> >
> >       You can't just deprecate accounts like that because nobody likes
> >       the code.
> >       Without accounts bitcoind is only a person-to-person manual
> >       client.
> >
> >       To build many-to-many automatic "organisations" on top of
> >       bitcoind you
> >       need accounts and you need fees that are predictable.
> >
> >       Kind Regards,
> >
> >       /marc
> >       _______________________________________________
> >       bitcoin-dev mailing list
> >       bitcoin-dev at lists.linuxfoundation.org
> >       https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/f3ae45ea/attachment.html>

From luke at dashjr.org  Thu Aug  4 03:27:34 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Thu, 4 Aug 2016 03:27:34 +0000
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
Message-ID: <201608040327.36571.luke@dashjr.org>

On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev 
wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?

This isn't something that makes sense at the address, since it represents the 
recipient and not the sender. Transactions are not sent from addresses ever.

> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a transaction's
> progress was publicly visible so transparent fraud prevention and auditing
> would become possible by anyone.

This is already possible. Just nLockTime your withdrawls for some future 
block. Don't sign any transaction that isn't nLockTime'd at least N blocks 
beyond the present tip.

Luke

From matthew at roberts.pm  Thu Aug  4 02:07:06 2016
From: matthew at roberts.pm (Matthew Roberts)
Date: Thu, 4 Aug 2016 12:07:06 +1000
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAE-z3OU+9hB7xFqYsn1-enuonxHB8E415P_Mf3b93p9MpYugjQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<CAE-z3OU+9hB7xFqYsn1-enuonxHB8E415P_Mf3b93p9MpYugjQ@mail.gmail.com>
Message-ID: <CAAEDBiF=xzOodTZ++WrRhESFqyvE+p0hVCx657WgocRtY5yG3g@mail.gmail.com>

This would honestly work. It forces the attacker to go through with the
clearing phase which simultaneously makes it possible to "cancel" the TX
through another logic branch before the timeout occurs. I'd say that would
meet the needs of a clearing mechanism / fraud prevention system for an
exchange perfectly while requiring minimal changes to the software.

Very, very smart idea. A++, would read again.

On Thu, Aug 4, 2016 at 9:55 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The reason why I bring this up is existing OP codes and TX types don't
>> seem suitable for a secure clearing mechanism;
>>
>
> I think reversing transactions is not likely to be acceptable.  You could
> add an opcode that requires that an output be set to something.
>
> [target script] SPENDTO
>
> This would require that [target script] is the script for the
> corresponding output.  This is a purely local check.
>
> For example, if SPENDTO executes as part of the script for input 3, then
> it checks that output 3 uses the given script as its scriptPubKey.  The
> value of input 3 and output 3 would have to be the same too.
>
> This allows check sequence verify to be used to lock the spending script
> for a while.  This doesn't allow reversal, but would give a 24 hour window
> where the spenders can reverse the transaction.
>
> [IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
> key> CHECKSIG] SPENDTO <live public key2> CHECKSIG
>
> Someone with the live public key can create a transaction that spends the
> funds to the script in the square brackets.
>
> Once that transaction hits the blockchain, then someone with the <offline
> protected key> has 24 hours to spend the output before the person with the
> live keys can send the funds onward.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/4eda2f65/attachment.html>

From matthew at roberts.pm  Thu Aug  4 04:53:18 2016
From: matthew at roberts.pm (Matthew Roberts)
Date: Thu, 4 Aug 2016 14:53:18 +1000
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<201608040327.36571.luke@dashjr.org>
	<CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
Message-ID: <CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>

>This is already possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at least N blocks
beyond the present tip.

The problem with nLockTimed transactions is a centralized exchange isn't
going to know ahead of time where those locked transactions need to go or
the amount that needs to be signed so you will end up having to keep the
private key around. If there was a way to create these transactions offline
with special SIG_HASH flags (and I don't think there is) there's nothing
about nLockTime that forces that the transactions be broadcast straight
away and plus: since the TXs aren't confirmed until the lock-time expires
they can be overwritten anyway.

I think given the requirements that a centralized exchange has: TierNolan's
idea is the best so far. Essentially, you have a new type of output script
that forces the redeemer to use a designated output script template in the
redeeming transaction, meaning that you can actually force people to send
coins into another transaction with "relative lock-timed" outputs. The new
transaction can then only be redeemed at the destination after the relative
lock-time expires OR it can be moved before-hand to a designated off-line
recovery address. This is much better than creating a new transaction
system, IMO.

>And the refund TXN would need to be able to go to a new address entirely.

Agreed.

On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83 at gmail.com>
wrote:

> "This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip."
>
> This would have prevented the Bitfinex hack if BitGo did this, but it
> wouldn't have helped if the Bitfinex offline key had been compromised
> instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
> by Bitfinex's hot key and BitGo's key, they required 2 of 2.
>
> If I'm understanding correctly, what Matthew is proposing is a new type of
> UTXO that is only valid to be spent as an nLockTime transaction and can be
> reversed by some sort of RBF-type transaction within that time period, I
> believe.
>
> But I don't think this will work. What do you do if the keys are
> compromised?  What's to stop the attacker from locking the coins up
> indefinitely by repeatedly broadcasting a refund transaction each time you
> try to spend to an uncompromised address?
>
> You'd need a third distinct key required for the refund TXN that's
> separate from the keys used to sign the initial nLockTime TXN.  And the
> refund TXN would need to be able to go to a new address entirely.
>
> On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
>> wrote:
>> > In light of the recent hack: what does everyone think of the idea of
>> > creating a new address type that has a reversal key and settlement layer
>> > that can be used to revoke transactions?
>>
>> This isn't something that makes sense at the address, since it represents
>> the
>> recipient and not the sender. Transactions are not sent from addresses
>> ever.
>>
>> > You could specify so that transactions "sent" from these addresses must
>> > receive N confirmations before they can't be revoked, after which the
>> > transaction is "settled" and the coins become redeemable from their
>> > destination output. A settlement phase would also mean that a
>> transaction's
>> > progress was publicly visible so transparent fraud prevention and
>> auditing
>> > would become possible by anyone.
>>
>> This is already possible. Just nLockTime your withdrawls for some future
>> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
>> beyond the present tip.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/9a441ba6/attachment-0001.html>

From hozer at hozed.org  Wed Aug  3 21:13:20 2016
From: hozer at hozed.org (Troy Benjegerdes)
Date: Wed, 3 Aug 2016 21:13:20 +0000
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
Message-ID: <20160803211320.GA18597@hostname.unassigned>

On Thu, Aug 04, 2016 at 04:16:20AM +1000, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?

I think many of us who think about human - computer interactions see the
need for a well defined process to roll back unexpected behavior in a computer
system. My 2014 era proposal is https://bitbucket.org/tmagik/catoshi/issues/24

The fundamental assumption around cryptocoins is you have a secret (private
key) known only by you. Currently in bitcoin if that assumption changes, the
response is blame the user. 'Incompetence, etc, etc'

This is bad business. For any cryptocurrency to really get mass market, we
need to provide our users with key revocation, to be used when the assumption
about being the only holder of a secret is broken.

I think there's a hardfork-worthy choice here:

1) implement reversal/revocation as an add-on feature
2) implement reversal/revocation as a fundamental that every address gets.

Ethereum made a quick hardfork choice to reverse a *single* instance of
unexpected behavior, and looks a lot like a bank bailout. We have the chance
to learn from this mistake, and, apparently, make a lot of money trading
on both sides of the hardfork.

> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a transaction's
> progress was publicly visible so transparent fraud prevention and auditing
> would become possible by anyone.
> 
> The reason why I bring this up is existing OP codes and TX types don't seem
> suitable for a secure clearing mechanism; Nlocktimed TXs won't work for
> this since you can't know ahead of time when and where a withdrawal needs
> to be made, plus there's still the potential for key mismanagement; Similar
> problems with OP_CHECKLOCKTIMEVERIFY apply too ??? unless you keep a private
> key around on the server which would defeat the purpose. The main use case
> here, would be specifically to improve centralized exchange security by
> making it impossible for a hot wallet to be raided all at once.
> 
> Thoughts?
> 
> Some existing background:
> 
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
> 
> roberts.pm/timechain -- My original paper written in 2015 which proposed a
> similar idea for secure wallet design but implemented using time-locked
> ECDSA keys. Obviously a blockchain would work better for this.
> 
> Other -- if the idea has already been brought up by other people, I
> apologize.

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


From andrew.johnson83 at gmail.com  Thu Aug  4 03:49:26 2016
From: andrew.johnson83 at gmail.com (Andrew Johnson)
Date: Wed, 3 Aug 2016 23:49:26 -0400
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <201608040327.36571.luke@dashjr.org>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<201608040327.36571.luke@dashjr.org>
Message-ID: <CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>

"This is already possible. Just nLockTime your withdrawls for some future
block. Don't sign any transaction that isn't nLockTime'd at least N blocks
beyond the present tip."

This would have prevented the Bitfinex hack if BitGo did this, but it
wouldn't have helped if the Bitfinex offline key had been compromised
instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
by Bitfinex's hot key and BitGo's key, they required 2 of 2.

If I'm understanding correctly, what Matthew is proposing is a new type of
UTXO that is only valid to be spent as an nLockTime transaction and can be
reversed by some sort of RBF-type transaction within that time period, I
believe.

But I don't think this will work. What do you do if the keys are
compromised?  What's to stop the attacker from locking the coins up
indefinitely by repeatedly broadcasting a refund transaction each time you
try to spend to an uncompromised address?

You'd need a third distinct key required for the refund TXN that's separate
from the keys used to sign the initial nLockTime TXN.  And the refund TXN
would need to be able to go to a new address entirely.

On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
> wrote:
> > In light of the recent hack: what does everyone think of the idea of
> > creating a new address type that has a reversal key and settlement layer
> > that can be used to revoke transactions?
>
> This isn't something that makes sense at the address, since it represents
> the
> recipient and not the sender. Transactions are not sent from addresses
> ever.
>
> > You could specify so that transactions "sent" from these addresses must
> > receive N confirmations before they can't be revoked, after which the
> > transaction is "settled" and the coins become redeemable from their
> > destination output. A settlement phase would also mean that a
> transaction's
> > progress was publicly visible so transparent fraud prevention and
> auditing
> > would become possible by anyone.
>
> This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160803/c004566c/attachment.html>

From erik at q32.com  Thu Aug  4 12:43:34 2016
From: erik at q32.com (Erik Aronesty)
Date: Thu, 4 Aug 2016 08:43:34 -0400
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<201608040327.36571.luke@dashjr.org>
	<CAAy62_JGZ0srYK4DKb5DOb5hz2OjvS6wXtnAnoAj9+KvEGTsDg@mail.gmail.com>
	<CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>
Message-ID: <CAJowKgJXAJSJc=AiBSYWFBTRYk539hpQt-Q=xetCv3YhdhvQ1Q@mail.gmail.com>

https://www.reddit.com/r/Bitcoin/comments/4w016b/use_of_payment_channels_to_mitigate_exchange_risk/

On Thu, Aug 4, 2016 at 12:53 AM, Matthew Roberts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> >This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> The problem with nLockTimed transactions is a centralized exchange isn't
> going to know ahead of time where those locked transactions need to go or
> the amount that needs to be signed so you will end up having to keep the
> private key around. If there was a way to create these transactions offline
> with special SIG_HASH flags (and I don't think there is) there's nothing
> about nLockTime that forces that the transactions be broadcast straight
> away and plus: since the TXs aren't confirmed until the lock-time expires
> they can be overwritten anyway.
>
> I think given the requirements that a centralized exchange has:
> TierNolan's idea is the best so far. Essentially, you have a new type of
> output script that forces the redeemer to use a designated output script
> template in the redeeming transaction, meaning that you can actually force
> people to send coins into another transaction with "relative lock-timed"
> outputs. The new transaction can then only be redeemed at the destination
> after the relative lock-time expires OR it can be moved before-hand to a
> designated off-line recovery address. This is much better than creating a
> new transaction system, IMO.
>
> >And the refund TXN would need to be able to go to a new address entirely.
>
> Agreed.
>
> On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83 at gmail.com
> > wrote:
>
>> "This is already possible. Just nLockTime your withdrawls for some future
>> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
>> beyond the present tip."
>>
>> This would have prevented the Bitfinex hack if BitGo did this, but it
>> wouldn't have helped if the Bitfinex offline key had been compromised
>> instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
>> by Bitfinex's hot key and BitGo's key, they required 2 of 2.
>>
>> If I'm understanding correctly, what Matthew is proposing is a new type
>> of UTXO that is only valid to be spent as an nLockTime transaction and can
>> be reversed by some sort of RBF-type transaction within that time period, I
>> believe.
>>
>> But I don't think this will work. What do you do if the keys are
>> compromised?  What's to stop the attacker from locking the coins up
>> indefinitely by repeatedly broadcasting a refund transaction each time you
>> try to spend to an uncompromised address?
>>
>> You'd need a third distinct key required for the refund TXN that's
>> separate from the keys used to sign the initial nLockTime TXN.  And the
>> refund TXN would need to be able to go to a new address entirely.
>>
>> On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
>>> wrote:
>>> > In light of the recent hack: what does everyone think of the idea of
>>> > creating a new address type that has a reversal key and settlement
>>> layer
>>> > that can be used to revoke transactions?
>>>
>>> This isn't something that makes sense at the address, since it
>>> represents the
>>> recipient and not the sender. Transactions are not sent from addresses
>>> ever.
>>>
>>> > You could specify so that transactions "sent" from these addresses must
>>> > receive N confirmations before they can't be revoked, after which the
>>> > transaction is "settled" and the coins become redeemable from their
>>> > destination output. A settlement phase would also mean that a
>>> transaction's
>>> > progress was publicly visible so transparent fraud prevention and
>>> auditing
>>> > would become possible by anyone.
>>>
>>> This is already possible. Just nLockTime your withdrawls for some future
>>> block. Don't sign any transaction that isn't nLockTime'd at least N
>>> blocks
>>> beyond the present tip.
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/dffea869/attachment.html>

From pete at petertodd.org  Fri Aug  5 19:54:16 2016
From: pete at petertodd.org (Peter Todd)
Date: Fri, 5 Aug 2016 12:54:16 -0700
Subject: [bitcoin-dev] Progress On Hardfork Proposals Following The Segwit
 Blocksize Increase
Message-ID: <20160805195416.GA1015@fedora-21-dvm>

Repost by request from my blog, apologies for the somewhat screwy formatting!


---
layout: post
title:  "Progress On Hardfork Proposals Following The Segwit Blocksize Increase"
date:   2016-08-05
tags:
- bitcoin
- hardfork
- segwit
---

With segwit getting close to its initial testnet release in Bitcoin Core
v0.13.0 - expected to be followed soon by a mainnet release in Bitcoin Core
v0.13.1 - I thought it'd be a good idea to go over work being done on a
potential hard-fork to follow it, should the Bitcoin community decide to accept
the segwit proposal.

First of all, to recap, in addition to many other improvements such as fixing
transaction malleability, fixing the large transaction signature verification
DoS attack, providing a better way to upgrade the scripting system in the
future, etc. segwit increases the maximum blocksize to 4MB. However, because
it's a soft-fork - a backwards compatible change to the protocol - only witness
(signature) data can take advantage of this blocksize increase; non-witness
data is still limited to 1MB total per block. With current transaction patterns
it's expected that blocks post-segwit won't use all 4MB of serialized data
allowed by the post-segwit maximum blocksize limit.

Secondly, there's two potential upgrades to the Bitcoin protocol that will
further reduce the amount of witness data most transactions need: [Schnorr
signatures](https://bitcoinmagazine.com/articles/the-power-of-schnorr-the-signature-algorithm-to-increase-bitcoin-s-scale-and-privacy-1460642496) and [BLS aggregate signatures](http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/).
Basically, both these improvements allow multiple signatures to be combined,
the former on a per-transaction level, and the latter on a per-block level.

[Last February](https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff)
some of the mining community and some of the developer community got together to discuss potential
hard-forks, with the aim of coming up with a reasonable proposal to take to the
wider community for further discussion and consensus building. Let's look at
where that effort has lead.

## Ethereum: Lessons to be learned

But first, Ethereum. Or as some have quipped, the Etherea:

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">The Battle for Etherea. <a href="https://t.co/2ATQRQRXnH">https://t.co/2ATQRQRXnH</a></p>&mdash; Samson Mow (@Excellion) <a href="https://twitter.com/Excellion/status/759677608753627136">July 31, 2016</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

If you've been following the crypto-currency space at all recently, you
probably know that the Ethereum community has split in two following a very
controversial hard-fork to the Ethereum protocol, To make a long story short, a
unintended feature in a smart-contract called "The DAO" was exploited by a
as-yet-unknown individual to drain around $50 million worth of the Ethereum
currency from the contract. While "white-hat attackers" did manage to recover a
majority of the funds in the DAO, a hard-fork was proposed to rewrite the
Ethereum ledger to recover all funds - an action that many, [including myself](/2016/ethereum-dao-bailout-vote),
have described as a bailout.

The result has been a big mess. This isn't the place to talk about all the
drama that's followed in depth, but I think it's fair to say that the Ethereum
community found out the hard way that just because you give a new protocol the
same name as an existing protocol, that doesn't force everyone to use it. As of
writing, what a month ago was called "Ethereum" - Ethereum Classic - has 20% of
the hashing power as the bailout chain, and peaked only two or three days ago
at around 30%. As for market cap, while the combined total for the two chains
is similar to the one chain pre-fork, this is likely misleading: there's
probably a lot of coins on both chains that aren't actually accessible and
don't represent liquid assets on the market. Instead, there's a good chance a
significant amount of value has been lost.

In particular, both chains have suffered significantly from transaction replay
issues. Basically, due to the way the Ethereum protocol is designed - in
particular the fact that Ethereum isn't based on a UTXO model - when the
Ethereum chain split transactions on one chain were very often valid on another
chain. Both attacks and accidents can lead to transactions from one chain
ending up broadcast to others, leading to unintentional spends. This wasn't an
unexpected problem:

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">.<a href="https://twitter.com/petertoddbtc">@petertoddbtc</a> we knew it would happen weeks before launch, we didn&#39;t want to implement replay-protection b.c. of implementation complexity</p>&mdash; Vlad Zamfir (@VladZamfir) <a href="https://twitter.com/VladZamfir/status/759552287157133313">July 31, 2016</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

...and it's lead to costly losses. Among others Coinbase has lost [an unknown amount of
funds](https://twitter.com/eiaine/status/758560296017416194) that they may [have to buy back](https://twitter.com/brian_armstrong/status/760991445352386560). Even worse, BTC-e [lost pretty much their entire balance](https://www.reddit.com/r/EthereumClassic/comments/4v2d6j/btce_dear_clients_btces_official_standpoint_on/d5v2f3t)
of original Ethereum coins - apparently becoming insolvent - and instead of
returning customer funds, they decided to [declare the original Ethereum chain a scam](https://btc-e.com/news/230) instead.

A particularly scary thing about this kind of problem is that it can lead to
artificial demand for a chain that would otherwise die: for all we know
Coinbase has been scrambling behind the scenes to buy replacement ether to make
up for the ether that it lost due to replay issues.

More generally, the fact that the community split shows the difficulty - and
unpredictability - of achieving consensus, maintaining consensus, and
measuring consensus. For instance, while the Ethereum community did do a coin
vote [as I suggested](/2016/ethereum-dao-bailout-vote), turnout was extremely
low - around 5% - with a significant minority in opposition (and note that
exchanges' coins were blacklisted from the vote due to technical reasons).
Additionally, the miner vote also had low turnout, and again, significant
minority opposition.

With regard to [drama](https://twitter.com/petertoddbtc/status/761506592827125760) resulting
from a coin split, something I think not many in the technical community had
considered, is that exchanges can have perverse incentives to encourage it. The
split resulted in significant trading volume on the pre-fork, status quo,
Ethereum chain, which of course is very profitable for exchanges. The second
exchange to list the status-quo chain was Poloniex, who have over 100
Bitcoin-denominated markets for a very wide variety of niche currencies - their
business is normally niche currencies that don't necessarily have wide appeal.

Finally, keep in mind that while this has been bad for Ethereum, it'd be even
worse for Bitcoin: unlike Ethereum, Bitcoin actually has non-trivial usage in
commerce, by users who aren't necessarily keeping up to date with the latest
drama^H^H^H^H^H news. We need to proceed carefully with any
non-backwards-compatible changes if we're to keep those users informed, and
protect them from sending and receiving coins on chains that they didn't mean
too.


## Splitting Safely

So how can we split safely? Luke Dashjr has written both a
[BIP](https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki), and
[preliminary code](https://github.com/luke-jr/bitcoin/compare/bc94b87?luke-jr:hardfork2016)
to do a combination of a hard-fork, and a soft-fork.

This isn't a new idea, in fact Luke [posted it](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.html)
to the bitcoin-dev mailing list last February, and it's been known as an option
for years prior; I personally mentioned it [on this blog](/2016/forced-soft-forks) last January.

The idea is basically that we do a hard-fork - an incompatible rule change - by
"wrapping" it in a soft-fork so that all nodes are forced to choose one chain
or the other. The new soft-forked rule-set is simple: no transactions are
allowed at all. Assuming that a majority of hashing power chooses to adopt the
fork, nodes that haven't made a decision are essentially 51% attacked and will
follow an empty chain, unable to make any transactions at all.

For those who choose not to adopt the hard-fork, they need to themselves do a
hard-fork to continue transacting. This can be as simple as blacklisting the
block where the two sides diverged, or something more complex like a
proof-of-work change.

On the plus side, Luke's proposal maximizes safety in many respects: so long as
a majority of hashing power adopts the fork no-one will accidentally accept
funds from a chain that they didn't intend too.


### Giving Everyone A Voice

It's notable that what Luke calls a "soft-hardfork" has also been called a
"forced soft-fork" by myself, as well as an "evil fork" by many others - what
name you give it is a matter of perspective. From a technical point of view,
the idea is a 51% attack against those who choose not to support the new
protocol; it's notable that when I pointed this out to some miners they were
very concerned about the precedent this could set if done badly.

Interestingly, due to implementation details Ethereum hard-fork was similar to
Luke's suggestion: pre-fork Ethereum clients would generally fail to start due
to an implementation flaw - in most cases - so everyone was forced to get new
software. Yet, Ethereum still split into two economically distinct coins.

This shows that attempting to kill an unwanted side of a split chain via 51%
attack isn't a panacea: people can and will choose to use the chain they want
to if there's controversy. So we'd be wise to try to achieve broad community
consensus first.

Interestingly, Tom Harding's [Hard fork opt-out bits](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html)
proposal can also be used to measure consent. Basically, as an anti-replay
mechanism, wallets could begin (un)setting a nSequence bit in transaction
inputs that a hard-fork would make _invalid_, while simultaneously a soft-fork
would make (un)setting a different bit invalid already; the hard-fork would
make that second bit _valid_ (users of nLockTime would (un)set neither bit,
making their transactions valid on both chains). This allows us to easily
measure readiness for a fork by looking at what percentage of transactions are
setting the anti-replay bit correctly - a sign that their running software that
is ready for a future hard-fork.

Secondly, I've been working on coming up with more concrete mechanisms based on
signaling/voting proportional to coins held, in particular, out-of-band
mechanisms based on signed messages and probabilistic sampling that could
potentially offer better privacy and censorship resistance, and give "hodlers"
who aren't necessarily doing frequent transactions a voice as well. My recent
work on [making TXO commitments more practical](/2016/delayed-txo-commitments)
is part of that effort.


### UTXO Size

Segwit's witness-data-discount has the important effect of discouraging the
creation of new UTXOs, in favor of spending existing ones, hopefully resulting
in [reduced UTXO set growth](https://bitcoincore.org/en/2016/01/26/segwit-benefits/#reducing-utxo-growth).
As a full copy of the UTXO set is (currently) a mandatory requirement for
running a full node, even with pruning, it's important that we keep UTXO growth
rates sustainable.

Matt Corallo has been doing work on finding better ways to properly account for
the cost to the network as a whole of UTXO creation, and he has told me he'll
be publishing that work soon. In addition, I've been working on a longer-term
solution in the form of [TXO commitments](/2016/delayed-txo-commitments), which
hopefully can eliminate the problem entirely, by allowing UTXO's to be
archived, shifting the burden of storing them to wallets rather than all
Bitcoin nodes. Additionally, Bram Cohen has been [working on](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012758.html)
making the necessary data structures for TXO commitments faster in of
themselves by optimizing cache access patterns.


### Block Propagation Latency

A significant concern with any blocksize increase - including segwit - is that
the higher bandwidth requirements will encourage centralization of hashing
power due to the disproportionate effect higher latency has on stale rates
between large and small miners. Matt Corallo has done a significant amount of
work recently on mitigating this effect with his [compact blocks](https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) - to be
released in v0.13.0 - and his next-gen block relay network
[FIBRE](http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/).

Additionally, I've been [doing research](http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/) to better
understanding the limitations of these approaches in adversarial,
semi-adversarial, and "uncaring" scenarios.


### Anti-Replay

I mentioned Tom Harding's work, above; I'll also mention that Gregory Maxwell
proposed a generic - and very robust - solution to anti-replay: have
transactions commit to a recent but not too recent (older than ~100 blocks or so) block hash.
While this has some potential downsides in a large reorg - transactions may
become permanently invalid due to differing block hashes - so long as the block
hashes committed too aren't too recently the idea does very robustly fix replay
attacks across chains, in a way that's completely generic no matter how many
forks happen. For example, a reasonable way to deploy would be to have wallet's
refuse to make transactions for the first day or two after a hard-fork, and
then use a post-fork blockhash in all transactions to ensure they can't be
replayed on an unwanted chain.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160805/6460c660/attachment.sig>

From s7r at sky-ip.org  Sat Aug  6 10:39:33 2016
From: s7r at sky-ip.org (s7r)
Date: Sat, 6 Aug 2016 13:39:33 +0300
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
Message-ID: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>

Hi,

I can clearly see some advantages for such a feature, but it's kind of
in conflict with Bitcoin's fundamental design. This design might be
problematic when it comes to hacks/thefts, but it's what gives Bitcoin
strength and make it differentiate from other currencies:

* reversal of transactions is impossible
* keep private keys private and safe. Lose them, it's like losing cash,
you can just forget about it.
* while we try hard to make 0-conf as safe as possible (if there's no
RBF flag on the transaction), we make it almost impossible or very very
expensive to reverse a confirmed transaction.

Also, we don't have a clear way to properly decide a good settlement
period length. It doesn't fix the problem any more than nLockTime fixes
it -- you can't know ahead of time when a withdraw needs to be made.
Fair enough, but even if the withdraw is made with a settlement layer,
will the user be able to spend it further immediately? Who will accept
such an input and treat it as a payment if it can be reversed during the
settlement layer? So, if you can't know ahead of time when a withdraw
needs to be made (nLockTime) how can you know ahead of time+settlement
period when a transaction needs to be declared irrevocable?

The linked page describes that merchants will never accept payments from
'vaults', and it will take 24 hours for coins to be irreversible moved
outside the 'vault'. This covers the part "is the user able to spend a
transaction with settlement layer" but it has security properties equal
to nLockTime = 24 hours - you can't benefit and use the coins
immediately and in 24 hours price might go up or down in an undesirable
way for a certain user. It however raises a lot of other questions: what
if the attacker manages to steal both the private key and vault key (we
have strong reasons to assume this can happen: if you can't keep a
private key safe, why would you be able to keep the vault key any
safer?) and starts a race with the actual user to unlock and lock back
the vault?

I think this is a wrong approach. hacks and big losses are sad, but all
the time users / exchanges are to blame for wrong implementations or
terrible security practices.

Thanks!

On 8/3/2016 9:16 PM, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?
> 
> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a
> transaction's progress was publicly visible so transparent fraud
> prevention and auditing would become possible by anyone.
> 
> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism; Nlocktimed TXs won't work
> for this since you can't know ahead of time when and where a withdrawal
> needs to be made, plus there's still the potential for key
> mismanagement; Similar problems with OP_CHECKLOCKTIMEVERIFY apply too ?
> unless you keep a private key around on the server which would defeat
> the purpose. The main use case here, would be specifically to improve
> centralized exchange security by making it impossible for a hot wallet
> to be raided all at once.
> 
> Thoughts?
> 
> Some existing background:
> 
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
> 
> roberts.pm/timechain <http://roberts.pm/timechain> -- My original paper
> written in 2015 which proposed a similar idea for secure wallet design
> but implemented using time-locked ECDSA keys. Obviously a blockchain
> would work better for this.
> 
> Other -- if the idea has already been brought up by other people, I
> apologize.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160806/e7d9caab/attachment.sig>

From tier.nolan at gmail.com  Sat Aug  6 11:13:52 2016
From: tier.nolan at gmail.com (Tier Nolan)
Date: Sat, 6 Aug 2016 12:13:52 +0100
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
Message-ID: <CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>

On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> * reversal of transactions is impossible
>

I think it would be more accurate to say that the requirement is that
reversal doesn't happen unexpectedly.

If it is clear in the script that reversal is possible, then obviously the
recipient can take that into consideration.


> * keep private keys private and safe. Lose them, it's like losing cash,
> you can just forget about it.
>

Key management is a thing.  Managing risk by keeping some keys offline is
an important part of that.


> * while we try hard to make 0-conf as safe as possible (if there's no
> RBF flag on the transaction), we make it almost impossible or very very
> expensive to reverse a confirmed transaction.
>

BitGo has an "instant" system where they promise to only sign one
transaction for a given output.  If you trust BitGo, then this is safe from
double spending, since a double spender can't sign two transactions.

If BitGo had actually implemented a daily withdrawal limit, then their
system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
could have been withdrawn before manual intervention was required (with
offline keys).

Who will accept
> such an input and treat it as a payment if it can be reversed during the
> settlement layer?


Obviously, if a payment is reversible, then you treat it as a reversible
payment.  The protection here relates to moving coins from the equivalent
of cold storage to hot storage.

It is OK if it takes longer, since security is more important than
convenience for coins in cold storage.


> The linked page describes that merchants will never accept payments from
> 'vaults', and it will take 24 hours for coins to be irreversible moved
> outside the 'vault'.


This relates to the reserves held by the exchange.  A portion of the funds
are in hot storage with live keys.  These funds can be stolen by anyone who
gets access to the servers.  The remaining funds are held in cold storage
and they cannot be accessed unless you have the offline keys.  These funds
are supposed to be hard to reach and require manual intervention.

I think this is a wrong approach. hacks and big losses are sad, but all
> the time users / exchanges are to blame for wrong implementations or
> terrible security practices.
>

Setting up offline keys to act as firebreaks is part of good security
practices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160806/7bcdc140/attachment-0001.html>

From cp368202 at ohiou.edu  Sat Aug  6 14:15:22 2016
From: cp368202 at ohiou.edu (Chris Priest)
Date: Sat, 6 Aug 2016 07:15:22 -0700
Subject: [bitcoin-dev] *Changing* the blocksize limit
Message-ID: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>

Because the blocksize limit is denominated in bytes, miners choose
transactions to add to a block based on fee/byte ratio. This mean that
if you make a transaction with a lot of inputs, your transaction will
be very big, an you'll have a to pay a lot in fees to get that
transaction included in a block.

For a long time I have been of the belief that it is a flaw in bitcoin
that you have to pay more to move coins that are sent to you via small
value UTXOs, compared to coins sent to you through a single high
values UTXO. There are many legitimate uses of bitcoin where you get
the money is very small increments (such as microtransactions). This
is the basis for my "Wildcard inputs" proposal now known as BIP131.
This BIP was rejected because it requires a database index, which
people thought would make bitcoin not scale, which I think is complete
malarkey, but it is what it is. It has recently occurred to me a way
to achieve the same effect without needing the database index.

If the blocksize limit was denominated in outputs, miners would choose
transactions based on maximum fee per output. This would essentially
make it free to include an input to a transaction.

If the blocksize limit were removed and replaced with a "block output
limit", it would have multiple positive effects. First off, like I
said earlier, it would incentivize microtransactions. Secondly it
would serve to decrease the UTXO set. As I described in the text of
BIP131, as blocks fill up and fees rise, there is a "minimum
profitability to include an input to a transaction" which increases.
At the time I wrote BIP131, it was something like 2 cents: Any UTXO
worth less than 2 cents was not economical to add to a transaction,
and therefore likely to never be spent (unless blocks get bigger and
fee's drop). This contributes to the "UTXO bloat problem" which a lot
of people talk about being a big problem.

If the blocksize limit is to be changed to a block output limit, the
number the limit is set to should be roughly the amount of outputs
that are found in 1MB blocks today. This way, the change should be
considered non-controversial. I think its silly that some people think
its a good thing to keep usage restricted, but again, it is what it
is.

Blocks can be bigger than 1MB, but the extra data in the block will
not result in more people using bitcoin, but rather existing users
spending inputs to decrease the UTXO set.

It would also bring about data that can be used to determine how to
scale bitcoin in the future. For instance, we have *no idea* how the
network will handle blocks bigger than 1MB, simply because the network
has never seen blocks bigger than 1MB. People have set up private
networks for testing bigger blocks, but thats not quite the same as
1MB+ blocks on the actual live network. This change will allow us to
see what actually happens when bigger blocks gets published.

Why is this change a bad idea?

From luke at dashjr.org  Sat Aug  6 18:52:55 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Sat, 6 Aug 2016 18:52:55 +0000
Subject: [bitcoin-dev] *Changing* the blocksize limit
In-Reply-To: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>
References: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>
Message-ID: <201608061852.56738.luke@dashjr.org>

This is exactly what segwit does...

On Saturday, August 06, 2016 2:15:22 PM Chris Priest via bitcoin-dev wrote:
> Because the blocksize limit is denominated in bytes, miners choose
> transactions to add to a block based on fee/byte ratio. This mean that
> if you make a transaction with a lot of inputs, your transaction will
> be very big, an you'll have a to pay a lot in fees to get that
> transaction included in a block.
> 
> For a long time I have been of the belief that it is a flaw in bitcoin
> that you have to pay more to move coins that are sent to you via small
> value UTXOs, compared to coins sent to you through a single high
> values UTXO. There are many legitimate uses of bitcoin where you get
> the money is very small increments (such as microtransactions). This
> is the basis for my "Wildcard inputs" proposal now known as BIP131.
> This BIP was rejected because it requires a database index, which
> people thought would make bitcoin not scale, which I think is complete
> malarkey, but it is what it is. It has recently occurred to me a way
> to achieve the same effect without needing the database index.
> 
> If the blocksize limit was denominated in outputs, miners would choose
> transactions based on maximum fee per output. This would essentially
> make it free to include an input to a transaction.
> 
> If the blocksize limit were removed and replaced with a "block output
> limit", it would have multiple positive effects. First off, like I
> said earlier, it would incentivize microtransactions. Secondly it
> would serve to decrease the UTXO set. As I described in the text of
> BIP131, as blocks fill up and fees rise, there is a "minimum
> profitability to include an input to a transaction" which increases.
> At the time I wrote BIP131, it was something like 2 cents: Any UTXO
> worth less than 2 cents was not economical to add to a transaction,
> and therefore likely to never be spent (unless blocks get bigger and
> fee's drop). This contributes to the "UTXO bloat problem" which a lot
> of people talk about being a big problem.
> 
> If the blocksize limit is to be changed to a block output limit, the
> number the limit is set to should be roughly the amount of outputs
> that are found in 1MB blocks today. This way, the change should be
> considered non-controversial. I think its silly that some people think
> its a good thing to keep usage restricted, but again, it is what it
> is.
> 
> Blocks can be bigger than 1MB, but the extra data in the block will
> not result in more people using bitcoin, but rather existing users
> spending inputs to decrease the UTXO set.
> 
> It would also bring about data that can be used to determine how to
> scale bitcoin in the future. For instance, we have *no idea* how the
> network will handle blocks bigger than 1MB, simply because the network
> has never seen blocks bigger than 1MB. People have set up private
> networks for testing bigger blocks, but thats not quite the same as
> 1MB+ blocks on the actual live network. This change will allow us to
> see what actually happens when bigger blocks gets published.
> 
> Why is this change a bad idea?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

From matthew at roberts.pm  Sun Aug  7 05:35:49 2016
From: matthew at roberts.pm (Matthew Roberts)
Date: Sun, 7 Aug 2016 15:35:49 +1000
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
Message-ID: <CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>

I'm wondering if we're fully on the same page here. What I was thinking was
that this protection mechanism would be applied to the coins in the hot
wallet (I wasn't talking about moving coins from the cold wallet to the hot
wallet -- though such a mechanism is also needed.)

With the hot wallet you would have an output script that only allowed coins
to be sent to a new transaction whose output script was then only
redeemable after N confirmations (the output is relative time-locked) but
which can also be recovered to a fixed fail-safe address before the
time-lock is reached (exactly like TierNolan already listed only the
time-locked destination shouldn't be completely fixed.) So the private key
for this hot wallet can still sign valid transactions to withdraw coins to
any known destination and these transactions still reach the blockchain.

The key difference from a regular transaction is that the destination only
has access to the coins -after- the relative time-lock is reached (N blocks
after first confirm) so everyone knows where withdrawals are suppose to be
going and how many coins are being withdrawn at any given time. Deposits to
the hot wallet would therefore need to be encumbered by the same protection
so that from then on this time-lock to redeem coins can be applied to every
new transaction trying to move coins (withdrawn by a user of the exchange
or sent to the cold wallet.)

Notice we don't care about the destination in the TX script for the hot
wallet because to process user's withdrawals we can't know ahead of time
where they need to be sent (so it isn't possible to use a fixed address
here ? though you might want to remove the clearing phase and set a fixed
address for coins sent from the hot wallet to the cold wallet.) The benefit
here comes from being able to see what withdrawals are being cleared,
matching those up to our expectations, and being able to "cancel"
withdrawals if they look suspicious, and you get the benefits for transfers
made from the hot wallet to the cold wallet and visa-versa.


This approach is good for a number of crucial services:

1. Wallets could be built that grouped coins into different "accounts" with
different time-frames required for clearing / unlocking coins. Your savings
or investment account would say -- take up to a week to clear -- whereas
your everyday account used for smaller purchases (with less money) would
only take a few hours. This could all be linked up to services that
notified you of your money being moved + made any phone calls needed to
verify any larger transfers.

The service could also be entrusted with the ?cancellation? key which can
only be used to move money to your offline fail-safe address. This would be
quite an interesting way to mitigate fraud without the user having to be
trusted to do anything (except I suppose ? not storing their recovery keys
online ? but this could be partially solved with BIP 32-style ?master?
public keys + hardware wallets + multi-sig, N factor auth, etc ...)

2. Gambling websites that process a lot of Bitcoins also have a hot wallet
which could be better protected by this.

3. Various other e-commerce websites also accept Bitcoins directly. (Deep
web markets come to mind -- hey, people breaking the law need good security
too.)

4. Provable dead man's switches on the protocol level is another idea -- no
need to keep special time-locked transactions around and rely on them to be
broadcast = more reliable escrow services.

5. And obviously exchange hot (and cold) wallets - enemy number 1.

I hope that makes sense. I think I initially managed to confuse a lot of
people by talking about revoking transactions / ?settlement layers?, etc.
But IMO: all of this needs to take place on the blockchain with a new set
of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
the general idea would still work.


tl; dr, A pseudo-reversal mechanism for transactions would mean that stolen
private keys were no longer such an issue. This is desperately needed for
exchanges, wallets, and other services that are forced to manage private
keys, and whose users (I argue) already expect for this to be possible (or
at least will when they're hacked.)




On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
>> * reversal of transactions is impossible
>>
>
> I think it would be more accurate to say that the requirement is that
> reversal doesn't happen unexpectedly.
>
> If it is clear in the script that reversal is possible, then obviously the
> recipient can take that into consideration.
>
>
>> * keep private keys private and safe. Lose them, it's like losing cash,
>> you can just forget about it.
>>
>
> Key management is a thing.  Managing risk by keeping some keys offline is
> an important part of that.
>
>
>> * while we try hard to make 0-conf as safe as possible (if there's no
>> RBF flag on the transaction), we make it almost impossible or very very
>> expensive to reverse a confirmed transaction.
>>
>
> BitGo has an "instant" system where they promise to only sign one
> transaction for a given output.  If you trust BitGo, then this is safe from
> double spending, since a double spender can't sign two transactions.
>
> If BitGo had actually implemented a daily withdrawal limit, then their
> system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
> could have been withdrawn before manual intervention was required (with
> offline keys).
>
> Who will accept
>> such an input and treat it as a payment if it can be reversed during the
>> settlement layer?
>
>
> Obviously, if a payment is reversible, then you treat it as a reversible
> payment.  The protection here relates to moving coins from the equivalent
> of cold storage to hot storage.
>
> It is OK if it takes longer, since security is more important than
> convenience for coins in cold storage.
>
>
>> The linked page describes that merchants will never accept payments from
>> 'vaults', and it will take 24 hours for coins to be irreversible moved
>> outside the 'vault'.
>
>
> This relates to the reserves held by the exchange.  A portion of the funds
> are in hot storage with live keys.  These funds can be stolen by anyone who
> gets access to the servers.  The remaining funds are held in cold storage
> and they cannot be accessed unless you have the offline keys.  These funds
> are supposed to be hard to reach and require manual intervention.
>
> I think this is a wrong approach. hacks and big losses are sad, but all
>> the time users / exchanges are to blame for wrong implementations or
>> terrible security practices.
>>
>
> Setting up offline keys to act as firebreaks is part of good security
> practices.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160807/c4d377f1/attachment-0001.html>

From erik at q32.com  Sun Aug  7 22:59:34 2016
From: erik at q32.com (Erik Aronesty)
Date: Sun, 7 Aug 2016 18:59:34 -0400
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
	<CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
Message-ID: <CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>

I still feel like you're better off getting rid of "hot wallets" and use
lightning-esqe networks to route orders.  I don't think either speed or
flexibility is an issue there.

IMO, the point of Bitcoin is to avoid the centralization that seems to be
happening on the network now.   By making "hot wallets" more "secure", we
encourage things to keep heading downhill with massive centralized
crappy-security exchanges.

Because, ultimately, there's no security that will prevent an inside job.
And all of these thefts have, in my opinion, been at least partly inside
jobs.

And centralization is the actually demon that needs slaying here.

A client-side library with P2P order routing, tether.to + bitcoin ....  and
you've got a decentralized exchange... with orders matched to users
directly, and channel-trades executed instantly.   And "market makers"
running nodes to facilitate routing, etc.

No center... nothing to shut down or sue... and no one holds your funds.
That's a real Bitcoin exchange.



On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I'm wondering if we're fully on the same page here. What I was thinking
> was that this protection mechanism would be applied to the coins in the hot
> wallet (I wasn't talking about moving coins from the cold wallet to the hot
> wallet -- though such a mechanism is also needed.)
>
> With the hot wallet you would have an output script that only allowed
> coins to be sent to a new transaction whose output script was then only
> redeemable after N confirmations (the output is relative time-locked) but
> which can also be recovered to a fixed fail-safe address before the
> time-lock is reached (exactly like TierNolan already listed only the
> time-locked destination shouldn't be completely fixed.) So the private key
> for this hot wallet can still sign valid transactions to withdraw coins to
> any known destination and these transactions still reach the blockchain.
>
> The key difference from a regular transaction is that the destination only
> has access to the coins -after- the relative time-lock is reached (N blocks
> after first confirm) so everyone knows where withdrawals are suppose to be
> going and how many coins are being withdrawn at any given time. Deposits to
> the hot wallet would therefore need to be encumbered by the same protection
> so that from then on this time-lock to redeem coins can be applied to every
> new transaction trying to move coins (withdrawn by a user of the exchange
> or sent to the cold wallet.)
>
> Notice we don't care about the destination in the TX script for the hot
> wallet because to process user's withdrawals we can't know ahead of time
> where they need to be sent (so it isn't possible to use a fixed address
> here ? though you might want to remove the clearing phase and set a fixed
> address for coins sent from the hot wallet to the cold wallet.) The benefit
> here comes from being able to see what withdrawals are being cleared,
> matching those up to our expectations, and being able to "cancel"
> withdrawals if they look suspicious, and you get the benefits for transfers
> made from the hot wallet to the cold wallet and visa-versa.
>
>
> This approach is good for a number of crucial services:
>
> 1. Wallets could be built that grouped coins into different "accounts"
> with different time-frames required for clearing / unlocking coins. Your
> savings or investment account would say -- take up to a week to clear --
> whereas your everyday account used for smaller purchases (with less money)
> would only take a few hours. This could all be linked up to services that
> notified you of your money being moved + made any phone calls needed to
> verify any larger transfers.
>
> The service could also be entrusted with the ?cancellation? key which can
> only be used to move money to your offline fail-safe address. This would be
> quite an interesting way to mitigate fraud without the user having to be
> trusted to do anything (except I suppose ? not storing their recovery keys
> online ? but this could be partially solved with BIP 32-style ?master?
> public keys + hardware wallets + multi-sig, N factor auth, etc ...)
>
> 2. Gambling websites that process a lot of Bitcoins also have a hot wallet
> which could be better protected by this.
>
> 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
> web markets come to mind -- hey, people breaking the law need good security
> too.)
>
> 4. Provable dead man's switches on the protocol level is another idea --
> no need to keep special time-locked transactions around and rely on them to
> be broadcast = more reliable escrow services.
>
> 5. And obviously exchange hot (and cold) wallets - enemy number 1.
>
> I hope that makes sense. I think I initially managed to confuse a lot of
> people by talking about revoking transactions / ?settlement layers?, etc.
> But IMO: all of this needs to take place on the blockchain with a new set
> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
> the general idea would still work.
>
>
> tl; dr, A pseudo-reversal mechanism for transactions would mean that
> stolen private keys were no longer such an issue. This is desperately
> needed for exchanges, wallets, and other services that are forced to manage
> private keys, and whose users (I argue) already expect for this to be
> possible (or at least will when they're hacked.)
>
>
>
>
> On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> * reversal of transactions is impossible
>>>
>>
>> I think it would be more accurate to say that the requirement is that
>> reversal doesn't happen unexpectedly.
>>
>> If it is clear in the script that reversal is possible, then obviously
>> the recipient can take that into consideration.
>>
>>
>>> * keep private keys private and safe. Lose them, it's like losing cash,
>>> you can just forget about it.
>>>
>>
>> Key management is a thing.  Managing risk by keeping some keys offline is
>> an important part of that.
>>
>>
>>> * while we try hard to make 0-conf as safe as possible (if there's no
>>> RBF flag on the transaction), we make it almost impossible or very very
>>> expensive to reverse a confirmed transaction.
>>>
>>
>> BitGo has an "instant" system where they promise to only sign one
>> transaction for a given output.  If you trust BitGo, then this is safe from
>> double spending, since a double spender can't sign two transactions.
>>
>> If BitGo had actually implemented a daily withdrawal limit, then their
>> system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
>> could have been withdrawn before manual intervention was required (with
>> offline keys).
>>
>> Who will accept
>>> such an input and treat it as a payment if it can be reversed during the
>>> settlement layer?
>>
>>
>> Obviously, if a payment is reversible, then you treat it as a reversible
>> payment.  The protection here relates to moving coins from the equivalent
>> of cold storage to hot storage.
>>
>> It is OK if it takes longer, since security is more important than
>> convenience for coins in cold storage.
>>
>>
>>> The linked page describes that merchants will never accept payments from
>>> 'vaults', and it will take 24 hours for coins to be irreversible moved
>>> outside the 'vault'.
>>
>>
>> This relates to the reserves held by the exchange.  A portion of the
>> funds are in hot storage with live keys.  These funds can be stolen by
>> anyone who gets access to the servers.  The remaining funds are held in
>> cold storage and they cannot be accessed unless you have the offline keys.
>> These funds are supposed to be hard to reach and require manual
>> intervention.
>>
>> I think this is a wrong approach. hacks and big losses are sad, but all
>>> the time users / exchanges are to blame for wrong implementations or
>>> terrible security practices.
>>>
>>
>> Setting up offline keys to act as firebreaks is part of good security
>> practices.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160807/528041a5/attachment.html>

From tier.nolan at gmail.com  Mon Aug  8 09:56:24 2016
From: tier.nolan at gmail.com (Tier Nolan)
Date: Mon, 8 Aug 2016 10:56:24 +0100
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiF1F1FkBXWQn_JgE0cr-aeVRAi29ETow0Sg95DO2MBGWQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
	<CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
	<CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>
	<CAAEDBiF1F1FkBXWQn_JgE0cr-aeVRAi29ETow0Sg95DO2MBGWQ@mail.gmail.com>
Message-ID: <CAE-z3OXkvZdr2AqQyySdZWmtpoED8yp=K1HXfNSc5pd9anLh3w@mail.gmail.com>

On Mon, Aug 8, 2016 at 1:48 AM, Matthew Roberts <matthew at roberts.pm> wrote:

> Not everyone who uses centralized exchanges are there to obtain the
> currency though. A large portion are speculators who need to be able to
> enter and exit complex positions in milliseconds and don't care about
> decentralization, security, and often even the asset that they're buying.
>

Centralized exchanges also allow for things like limit orders.  You don't
even have to be logged in and they can execute trades.  This couldn't be
done with channels.

> Try telling everyone who currently uses Btc-e to go do their margin
> trading over lightning channels, for example.
>

Using channels and a centralized exchange gets many of the benefits of a
distributed exchange.

The channel allows instant funding while allowing the customer to have full
control over the funds.  The customer could fund the channel and then move
money to the exchange when needed.

Even margin account holders might like the fact that it is clear which
funds are under their direct control and which funds are held by the
exchange.

If they are using bitcoin funds as collateral for a margin trade, then
inherently the exchange has to have control over those funds.  A 2 of 3
system where the customer, exchange and a 3rd party arbitration agency
holds keys might be acceptable to the exchange.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/7634409e/attachment-0001.html>

From erik at q32.com  Mon Aug  8 10:09:24 2016
From: erik at q32.com (Erik Aronesty)
Date: Mon, 8 Aug 2016 06:09:24 -0400
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAAEDBiF1F1FkBXWQn_JgE0cr-aeVRAi29ETow0Sg95DO2MBGWQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
	<CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
	<CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>
	<CAAEDBiF1F1FkBXWQn_JgE0cr-aeVRAi29ETow0Sg95DO2MBGWQ@mail.gmail.com>
Message-ID: <CAJowKgKUCXo7fD_R73c2cGcet+GzrRR6-=H1uOpAHzqsbbTDxw@mail.gmail.com>

I'm not convinced you need to hold people's funds to provide those
features. Maybe the millisecond thing.   But 99 out of 100 traders would
accept a 100 millisecond latency in exchange for 0 counterparty risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/436cdea4/attachment.html>

From tier.nolan at gmail.com  Mon Aug  8 11:01:57 2016
From: tier.nolan at gmail.com (Tier Nolan)
Date: Mon, 8 Aug 2016 12:01:57 +0100
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAJowKgKUCXo7fD_R73c2cGcet+GzrRR6-=H1uOpAHzqsbbTDxw@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
	<CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
	<CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>
	<CAAEDBiF1F1FkBXWQn_JgE0cr-aeVRAi29ETow0Sg95DO2MBGWQ@mail.gmail.com>
	<CAJowKgKUCXo7fD_R73c2cGcet+GzrRR6-=H1uOpAHzqsbbTDxw@mail.gmail.com>
Message-ID: <CAE-z3OVSP7rvV7SJXJNkUw40mxfrVv-u3vgBZ5d5ZvtKs=w+iw@mail.gmail.com>

With channels and the exchange acting as hub, you can do instant trades
between altcoins.

This doesn't work with fiat accounts.  A "100% reserve" company could issue
fiat tokens.  The exchange could then trade those tokens.

This eliminates the counter-party risk for the exchange.  If the exchange
dies, you still have your (alt)coins and also fiat tokens.

There is still risk that the token company could go bankrupt though.  This
could be mitigated by that company requiring only "cashing out" tokens to
accounts which have been verified.

The company could set up a blockchain where it signed the blocks rather
than mining and could get money from transaction fees and also minting fees
(say it charges 1% for minting new tokens)

I wonder what how the law would work for that.  It isn't actually doing
trading, it is just issuing tokens and redeeming them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/bba6a71c/attachment.html>

From matthew at roberts.pm  Mon Aug  8 00:48:52 2016
From: matthew at roberts.pm (Matthew Roberts)
Date: Mon, 8 Aug 2016 10:48:52 +1000
Subject: [bitcoin-dev] BIP clearing house addresses
In-Reply-To: <CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
	<0b314ab7-b5ec-3468-15d7-37e07a6b592c@sky-ip.org>
	<CAE-z3OUJBVn8Ogc8gCZbJ0V_JV1UQjk0FSBjguzwgZ5kTjBTtA@mail.gmail.com>
	<CAAEDBiGWuV+6cXzbs0eAUNFZJ4KWFGUF7oeCTEKkGGjmrTB-cw@mail.gmail.com>
	<CAJowKgK4EckX86M6Gt-XYCuwOdSwcVtHZW8oYZn-AC55gYqUZQ@mail.gmail.com>
Message-ID: <CAAEDBiF1F1FkBXWQn_JgE0cr-aeVRAi29ETow0Sg95DO2MBGWQ@mail.gmail.com>

Not everyone who uses centralized exchanges are there to obtain the
currency though. A large portion are speculators who need to be able to
enter and exit complex positions in milliseconds and don't care about
decentralization, security, and often even the asset that they're buying.

Try telling everyone who currently uses Btc-e to go do their margin trading
over lightning channels, for example. They're not going to want to do that
because these exchanges are already meeting their needs perfectly well, and
like I argued before -- it would be very hard to do that as efficiently
with any other design (there are major drawbacks for traders with a
decentralized exchange.)

Like it or not, these exchanges play an integral role in the current
Bitcoin eco-system since they allow us to most efficiently discover price
and help improve liquidity. A decentralized exchange isn't going to stop
any more centralized exchanges from being hacked even if they are more
secure simply because traders don't want to use them.

(Sorry for the duplicate message Erik, I haven't used many mailing lists
before. I think I have the hang of it now though :) )

On Mon, Aug 8, 2016 at 8:59 AM, Erik Aronesty <erik at q32.com> wrote:

> I still feel like you're better off getting rid of "hot wallets" and use
> lightning-esqe networks to route orders.  I don't think either speed or
> flexibility is an issue there.
>
> IMO, the point of Bitcoin is to avoid the centralization that seems to be
> happening on the network now.   By making "hot wallets" more "secure", we
> encourage things to keep heading downhill with massive centralized
> crappy-security exchanges.
>
> Because, ultimately, there's no security that will prevent an inside
> job.   And all of these thefts have, in my opinion, been at least partly
> inside jobs.
>
> And centralization is the actually demon that needs slaying here.
>
> A client-side library with P2P order routing, tether.to + bitcoin ....
> and you've got a decentralized exchange... with orders matched to users
> directly, and channel-trades executed instantly.   And "market makers"
> running nodes to facilitate routing, etc.
>
> No center... nothing to shut down or sue... and no one holds your funds.
> That's a real Bitcoin exchange.
>
>
>
> On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I'm wondering if we're fully on the same page here. What I was thinking
>> was that this protection mechanism would be applied to the coins in the hot
>> wallet (I wasn't talking about moving coins from the cold wallet to the hot
>> wallet -- though such a mechanism is also needed.)
>>
>> With the hot wallet you would have an output script that only allowed
>> coins to be sent to a new transaction whose output script was then only
>> redeemable after N confirmations (the output is relative time-locked) but
>> which can also be recovered to a fixed fail-safe address before the
>> time-lock is reached (exactly like TierNolan already listed only the
>> time-locked destination shouldn't be completely fixed.) So the private key
>> for this hot wallet can still sign valid transactions to withdraw coins to
>> any known destination and these transactions still reach the blockchain.
>>
>> The key difference from a regular transaction is that the destination
>> only has access to the coins -after- the relative time-lock is reached (N
>> blocks after first confirm) so everyone knows where withdrawals are suppose
>> to be going and how many coins are being withdrawn at any given time.
>> Deposits to the hot wallet would therefore need to be encumbered by the
>> same protection so that from then on this time-lock to redeem coins can be
>> applied to every new transaction trying to move coins (withdrawn by a user
>> of the exchange or sent to the cold wallet.)
>>
>> Notice we don't care about the destination in the TX script for the hot
>> wallet because to process user's withdrawals we can't know ahead of time
>> where they need to be sent (so it isn't possible to use a fixed address
>> here ? though you might want to remove the clearing phase and set a fixed
>> address for coins sent from the hot wallet to the cold wallet.) The benefit
>> here comes from being able to see what withdrawals are being cleared,
>> matching those up to our expectations, and being able to "cancel"
>> withdrawals if they look suspicious, and you get the benefits for transfers
>> made from the hot wallet to the cold wallet and visa-versa.
>>
>>
>> This approach is good for a number of crucial services:
>>
>> 1. Wallets could be built that grouped coins into different "accounts"
>> with different time-frames required for clearing / unlocking coins. Your
>> savings or investment account would say -- take up to a week to clear --
>> whereas your everyday account used for smaller purchases (with less money)
>> would only take a few hours. This could all be linked up to services that
>> notified you of your money being moved + made any phone calls needed to
>> verify any larger transfers.
>>
>> The service could also be entrusted with the ?cancellation? key which can
>> only be used to move money to your offline fail-safe address. This would be
>> quite an interesting way to mitigate fraud without the user having to be
>> trusted to do anything (except I suppose ? not storing their recovery keys
>> online ? but this could be partially solved with BIP 32-style ?master?
>> public keys + hardware wallets + multi-sig, N factor auth, etc ...)
>>
>> 2. Gambling websites that process a lot of Bitcoins also have a hot
>> wallet which could be better protected by this.
>>
>> 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
>> web markets come to mind -- hey, people breaking the law need good security
>> too.)
>>
>> 4. Provable dead man's switches on the protocol level is another idea --
>> no need to keep special time-locked transactions around and rely on them to
>> be broadcast = more reliable escrow services.
>>
>> 5. And obviously exchange hot (and cold) wallets - enemy number 1.
>>
>> I hope that makes sense. I think I initially managed to confuse a lot of
>> people by talking about revoking transactions / ?settlement layers?, etc.
>> But IMO: all of this needs to take place on the blockchain with a new set
>> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
>> the general idea would still work.
>>
>>
>> tl; dr, A pseudo-reversal mechanism for transactions would mean that
>> stolen private keys were no longer such an issue. This is desperately
>> needed for exchanges, wallets, and other services that are forced to manage
>> private keys, and whose users (I argue) already expect for this to be
>> possible (or at least will when they're hacked.)
>>
>>
>>
>>
>> On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> * reversal of transactions is impossible
>>>>
>>>
>>> I think it would be more accurate to say that the requirement is that
>>> reversal doesn't happen unexpectedly.
>>>
>>> If it is clear in the script that reversal is possible, then obviously
>>> the recipient can take that into consideration.
>>>
>>>
>>>> * keep private keys private and safe. Lose them, it's like losing cash,
>>>> you can just forget about it.
>>>>
>>>
>>> Key management is a thing.  Managing risk by keeping some keys offline
>>> is an important part of that.
>>>
>>>
>>>> * while we try hard to make 0-conf as safe as possible (if there's no
>>>> RBF flag on the transaction), we make it almost impossible or very very
>>>> expensive to reverse a confirmed transaction.
>>>>
>>>
>>> BitGo has an "instant" system where they promise to only sign one
>>> transaction for a given output.  If you trust BitGo, then this is safe from
>>> double spending, since a double spender can't sign two transactions.
>>>
>>> If BitGo had actually implemented a daily withdrawal limit, then their
>>> system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
>>> could have been withdrawn before manual intervention was required (with
>>> offline keys).
>>>
>>> Who will accept
>>>> such an input and treat it as a payment if it can be reversed during the
>>>> settlement layer?
>>>
>>>
>>> Obviously, if a payment is reversible, then you treat it as a reversible
>>> payment.  The protection here relates to moving coins from the equivalent
>>> of cold storage to hot storage.
>>>
>>> It is OK if it takes longer, since security is more important than
>>> convenience for coins in cold storage.
>>>
>>>
>>>> The linked page describes that merchants will never accept payments from
>>>> 'vaults', and it will take 24 hours for coins to be irreversible moved
>>>> outside the 'vault'.
>>>
>>>
>>> This relates to the reserves held by the exchange.  A portion of the
>>> funds are in hot storage with live keys.  These funds can be stolen by
>>> anyone who gets access to the servers.  The remaining funds are held in
>>> cold storage and they cannot be accessed unless you have the offline keys.
>>> These funds are supposed to be hard to reach and require manual
>>> intervention.
>>>
>>> I think this is a wrong approach. hacks and big losses are sad, but all
>>>> the time users / exchanges are to blame for wrong implementations or
>>>> terrible security practices.
>>>>
>>>
>>> Setting up offline keys to act as firebreaks is part of good security
>>> practices.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/39344b7f/attachment.html>

From dev at jonasschnelli.ch  Mon Aug  8 15:00:51 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Mon, 8 Aug 2016 17:00:51 +0200
Subject: [bitcoin-dev] Authentication BIP
Message-ID: <57A89EA3.4020101@jonasschnelli.ch>

Hi

As already mentioned in the recent BIP151 thread
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html),
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.

The proposed authentication BIP does require BIP151.

The propose BIP does assume, node operators want to build trusted
connections for various reasons.

BIPs mediawiki github page available here:
https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/auth_bip?expand=1

===================================================

  BIP: ???
  Title: Peer Authentication
  Author: Jonas Schnelli <dev at jonasschnelli.ch>
  Status: Draft
  Type: Standards Track
  Created: 2016-03-23

== Abstract ==

This BIP describes a way how peers can authenticate ? without opening
fingerprinting possibilities ? to other peers to guarantee ownership
and/or allowing to access additional or limited services.

== Motivation ==

We assume peer operators want to limit the access of different services
or increase datastream priorities to a selective subset of peers. Also
we assume peers want to connect to specific peers to broadcast or filter
transactions (or similar action that reveals sensitive informations) and
therefore they want to authenticate the remote peer and make sure that
they have not connected to a MITM.

Benefits with peer authentication:
* Peers could detect MITM attacks when connecting to known peers
* Peers could allow resource hungry transaction filtering only to
specific peers
* Peers could allow access to sensitive information that can lead to
node fingerprinting (fee estimation)
* Peers could allow custom message types (private extensions) to
authenticated peers

A simple authentication scheme based on elliptic cryptography will allow
peers to identify each other and selective allow access to restricted
services or reject the connection if the identity could not be verified.

== Specification ==

The authentication scheme proposed in this BIP uses ECDSA, ___secrets
will never be transmitted___.

___Authentication initialization must only happen if encrypted channels
have been established (according to BIP-151 [1]).___

The ___encryption-session-ID___ is available once channels are encrypted
(according to BIP-151 [1]).

The identity-public-keys used for the authentication must be pre-shared
over a different channel (Mail/PGP, physical paper exchange, etc.). This
BIP does not cover a "trust on first use" (TOFU) concept.

The authentication state must be kept until the encryption/connection
terminates.

Only one authentication process is allowed per connection.
Re-authenticate require re-establishing the connection.

=== Known-peers and authorized-peers database ===
Each peer that supports p2p authentication must provide two users
editable "databases"

# ___known-peers___ contains known identity-public-keys together with a
network identifier (IP & port), similar to the "known-host" file
supported by openssh.
# ___authorized-peers___ contains authorized identity-public-keys

=== Local identity key management ===
Each peer can configure one identity-key (ECC, 32 bytes) per listening
network interface (IPv4, IPv6, tor).
The according identity-public-key can be shared over a different channel
with other node-operators (or non-validating clients) to grant
authorized access.

=== Authentication procedure ===
Authentication after this BIP will require both sides to authenticate.
Signatures/public-keys will only be revealed if the remote peer could
prove that they already know the remote identity-public-key.

# -> Requesting peer sends `AUTHCHALLENGE` (hash)
# <- Responding peer sends `AUTHREPLY` (signature)
# -> Requesting peer sends `AUTHPROPOSE` (hash)
# <- Responding peer sends `AUTHCHALLENGE` (hash)
# -> Requesting peer sends `AUTHREPLY` (signature)

For privacy reasons, dropping the connection or aborting during the
authentication process must not be possible.

=== `AUTHCHALLENGE` message ===
A peer can send an authentication challenge to see if the responding
peer can produce a valid signature with the expected responding peers
identity-public-key by sending an `AUTHCHALLENGE`-message to the remote
peer.

The responding peer needs to check if the hash matches the hash
calculated with his own local identity-public-key. Fingerprinting the
requesting peer is not possible.

32bytes challenge-hash `hash(encryption-session-ID || challenge_type ||
remote-peers-expected-identity-public-key)`

`challenge_type` is a single character. `i` if the
`AUTHCHALLENGE`-message is the first, requesting challenge or `r` if
it's the second, remote peers challenge message.

=== `AUTHREPLY` message ===
A peer must reply an `AUTHCHALLENGE`-message with an `AUTHREPLY`-message.


| 64bytes || signature || normalized comp.-signature || A signature of
the encryption-session-ID done with the identity-key


If the challenge-hash from the `AUTHCHALLENGE`-message did not match the
local authentication public-key, the signature must contain 64bytes of
zeros.

The requesting peer can check the responding peers identity by checking
the validity of the sent signature against with the pre-shared remote
peers identity-public-key.

If the signature was invalid, the requesting peer must still proceed
with the authentication by sending an `AUTHPROPOSE`-message with 32
random bytes.

=== `AUTHPROPOSE` message ===
A peer can propose authentication of the channel by sending an
`AUTHPROPOSE`-message to the remote peer.

If the signature sent in `AUTHREPLY` was invalid, the peer must still
send an `AUTHPROPOSE`-message containing 32 random bytes.

The `AUTHPROPOSE` message must be answered with an
`AUTHCHALLENGE`-message ? even if the proposed requesting-peers
identity-public-key has not been found in the authorized_peers database.
In case of no match, the responding `AUTHCHALLENGE`-message must
contains 32 bytes of zeros.


| 32bytes || auth-propose-hash || hash || `hash(encryption-session-ID


== Post-Authentication Re-Keying ==

After the second `AUTHREPLY` message (requesting peers signature ->
responding peer), both clients must re-key the symmetric encryption
according to BIP151 while using ___a slightly  different re-key key
derivation hash___.

They both re-key with `hash(encryption-session-ID ||
old_symmetric_cipher_key || requesting-peer-identity-public-key ||
responding-peer-identity-public-key)`

== Identity-Addresses ==
The peers should display/log the identity-public-key as an
identity-address to the users, which is a base58-check encoded
ripemd160(sha256) hash. The purpose of this is for better visual
comparison (logs, accept-dialogs).
The base58check identity byte is `0x0F` followed by an identity-address
version number (=`0xFF01`).

An identity address would look like
`TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA` and can be interpreted as a remote
peers fingerprint.

== Compatibility ==

This proposal is backward compatible. Non-supporting peers will ignore
the new `AUTH*` messages.

== Example of an auth interaction ==

Before authentication (once during peer setup or upgrade)
# Requesting peer and responding peer create each an identity-keypair
(standard ECC priv/pubkey)
# Requesting and responding peer share the identity-public-key over a
different channel (PGP mail, physical exchange, etc.)
# Responding peer stores requesting peers identity-public-key in its
authorized-peers database (A)
# Requesting peer stores responding peers identity-public-key in its
known-peers database together with its IP and port (B)

Encryption
# Encrypted channels must be established (according to BIP-151 [1])

Authentication
# Requesting peer sends an `AUTHCHALLENGE` message
  AUTHCHALLENGE:
    [32 bytes, hash(encryption-session-ID || "i" ||
<remote-peers-expected-identity-public-key>)]

# Responding peer does create the same hash `(encryption-session-ID ||
"i" || <remote-peers-expected-identity-public-key>)` with its local
identity-public-key
# If the hash does not match, response with an `AUTHREPLY` message
containing 64bytes of zeros.
# In case of a match, response with an `AUTHREPLY` message
  AUTHREPLY:
    [64 bytes normalized compact ECDSA signature (H)] (sig of the
encryption-session-ID done with the identity-key)

# Requesting peer does verify the signature with the
`remote-peers-identity-public-key`
# If the signature is invalid, requesting peer answers with an
`AUTHREPLY` message containing 32 random bytes
# In case of a valid signature, requesting peer sends an `AUTHPROPOSE`
message
  AUTHPROPOSE:
    [32 bytes, hash(encryption-session-ID || "p" ||
<client-identity-public-key>)]

# Responding peer iterates over authorized-peers database (A), hashes
the identical data and looks for a match.
# If the hash does not match, responding peer answer with an
`AUTHCHALLENGE` message containing 32 bytes of zeros.
# In case of a match, responding peer sends an `AUTHCHALLENGE` message
with the hashed client public-key
  AUTHCHALLENGE:
    [32 bytes, hash(encryption-session-ID || "r" ||
<client-identity-public-key>)]
# Requesting peer sends an `AUTHREPLY` message containing 64 bytes of
zeros if server failed to authenticate
# Otherwise, response with signature in the `AUTHREPLY` message
  AUTHREPLY:
    [64 bytes normalized compact ECDSA signature (H)] (sig of the
encryption-session-ID done with the identity-key)
# Responding peer must verify the signature and can grant access to
restricted services.
# Both peers re-key the encryption after BIP151 including the
requesting-peer-identity-public-key and responding-peer-identity-public-key

== Disadvantages ==

The protocol may be slow if a peer has a large authorized-peers database
due to the requirement of iterating and hashing over all available
authorized peers identity-public-keys.

== Reference implementation ==

== References ==

* [1] [[bip-0151.mediawiki|BIP 151: Peer-to-Peer Communication Encryption]]

== Acknowledgements ==
* Gregory Maxwell and Pieter Wuille for most of the ideas in this BIP.

== Copyright ==
This work is placed in the public domain.






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/e83bc378/attachment-0001.sig>

From tony991 at gmail.com  Mon Aug  8 15:30:21 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Mon, 8 Aug 2016 18:30:21 +0300
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
Message-ID: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>

This is a proposal about hiding the entire content of bitcoin
transactions.  It goes farther than CoinJoin and ring signatures, which
only obfuscate the transaction graph, and Confidential Transactions, which
only hide the amounts.

The central idea of the proposed design is to hide the entire inputs and
outputs, and publish only the hash of inputs and outputs in the
blockchain.  The hash can be published as OP_RETURN.  The plaintext of
inputs and outputs is sent directly to the payee via a private message, and
never goes into the blockchain.  The payee then calculates the hash and
looks it up in the blockchain to verify that the hash was indeed published
by the payer.

Since the plaintext of the transaction is not published to the public
blockchain, all validation work has to be done only by the user who
receives the payment.

To protect against double-spends, the payer also has to publish another
hash, which is the hash of the output being spent.  We?ll call this hash *spend
proof*.  Since the spend proof depends solely on the output being spent,
any attempt to spend the same output again will produce exactly the same
spend proof, and the payee will be able to see that, and will reject the
payment.  If there are several outputs consumed by the same transaction,
the payer has to publish several spend proofs.

To prove that the outputs being spent are valid, the payer also has to send
the plaintexts of the earlier transaction(s) that produced them, then the
plaintexts of even earlier transactions that produced the outputs spent in
those transactions, and so on, up until the issue (similar to coinbase)
transactions that created the initial private coins.  Each new owner of the
coin will have to store its entire history, and when he spends the coin, he
forwards the entire history to the next owner and extends it with his own
transaction.

If we apply the existing bitcoin design that allows multiple inputs and
multiple outputs per transaction, the history of ownership transfers would
grow exponentially.  Indeed, if we take any regular bitcoin output and try
to track its history back to coinbase, our history will branch every time
we see a transaction that has more than one input (which is not uncommon).
After such a transaction (remember, we are traveling back in time), we?ll
have to track two or more histories, for each respective input.  Those
histories will branch again, and the total number of history entries grows
exponentially.  For example, if every transaction had exactly two inputs,
the size of history would grow as 2^N where N is the number of steps back
in history.

To avoid such rapid growth of ownership history (which is not only
inconvenient to move, but also exposes too much private information about
previous owners of all the contributing coins), we will require each
private transaction to have exactly one input (i.e. to consume exactly one
previous output).  This means that when we track a coin?s history back in
time, it will no longer branch.  It will grow linearly with the number of
transfers of ownership.  If a user wants to combine several inputs, he will
have to send them as separate private transactions (technically, several
OP_RETURNs, which can be included in a single regular bitcoin transaction).

Thus, we are now forbidding any coin merges but still allowing coin
splits.  To avoid ultimate splitting into the dust, we will also require
that all private coins be issued in one of a small number of
denominations.  Only integer number of ?banknotes? can be transferred, the
input and output amounts must therefore be divisible by the denomination.
For example, an input of amount 700, denomination 100, can be split into
outputs 400 and 300, but not into 450 and 250.  To send a payment, the
payer has to pick the unspent outputs of the highest denomination first,
then the second highest, and so on, like we already do when we pay in cash.

With fixed denominations and one input per transaction, coin histories
still grow, but only linearly, which should not be a concern in regard to
scalability given that all relevant computing resources still grow
exponentially.  The histories need to be stored only by the current owner
of the coin, not every bitcoin node.  This is a fairer allocation of
costs.  Regarding privacy, coin histories do expose private transactions
(or rather parts thereof, since a typical payment will likely consist of
several transactions due to one-input-per-transaction rule) of past coin
owners to the future ones, and that exposure grows linearly with time, but
it is still much much better than having every transaction immediately on
the public blockchain.  Also, the value of this information for potential
adversaries arguably decreases with time.

There is one technical nuance that I omitted above to avoid distraction.
 Unlike regular bitcoin transactions, every output in a private payment
must also include a blinding factor, which is just a random string.  When
the output is spent, the corresponding spend proof will therefore depend on
this blinding factor (remember that spend proof is just a hash of the
output).  Without a blinding factor, it would be feasible to pre-image the
spend proof and reveal the output being spent as the search space of all
possible outputs is rather small.

To issue the new private coin, one can burn regular BTC by sending it to
one of several unspendable bitcoin addresses, one address per denomination.
 Burning BTC would entitle one to an equal amount of the new private coin,
let?s call it *black bitcoin*, or *BBC*.

Then BBC would be transferred from user to user by:
1. creating a private transaction, which consists of one input and several
outputs;
2. storing the hash of the transaction and the spend proof of the consumed
output into the blockchain in an OP_RETURN (the sender pays the
corresponding fees in regular BTC)
3. sending the transaction, together with the history leading to its input,
directly to the payee over a private communication channel.  The first
entry of the history must be a bitcoin transaction that burned BTC to issue
an equal amount of BCC.

To verify the payment, the payee:
1. makes sure that the amount of the input matches the sum of outputs, and
all are divisible by the denomination
2. calculates the hash of the private transaction
3. looks up an OP_RETURN that includes this hash and is signed by the
payee.  If there is more than one, the one that comes in the earlier block
prevails.
4. calculates the spend proof and makes sure that it is included in the
same OP_RETURN
5. makes sure the same spend proof is not included anywhere in the same or
earlier blocks (that is, the coin was not spent before).  Only transactions
by the same author are searched.
6. repeats the same steps for every entry in the history, except the first
entry, which should be a valid burning transaction.

To facilitate exchange of private transaction data, the bitcoin network
protocol can be extended with a new message type.  Unfortunately, it lacks
encryption, hence private payments are really private only when bitcoin is
used over tor.

There are a few limitations that ought to be mentioned:
1. After user A sends a private payment to user B, user A will know what
the spend proof is going to be when B decides to spend the coin.
 Therefore, A will know when the coin was spent by B, but nothing more.
 Neither the new owner of the coin, nor its future movements will be known
to A.
2. Over time, larger outputs will likely be split into many smaller
outputs, whose amounts are not much greater than their denominations.
You?ll have to combine more inputs to send the same amount.  When you want
to send a very large amount that is much greater than the highest available
denomination, you?ll have to send a lot of private transactions, your
bitcoin transaction with so many OP_RETURNs will stand out, and their
number will roughly indicate the total amount.  This kind of privacy
leakage, however it applies to a small number of users, is easy to avoid by
using multiple addresses and storing a relatively small amount on each
address.
3. Exchanges and large merchants will likely accumulate large coin
histories.  Although fragmented, far from complete, and likely outdated, it
is still something to bear in mind.

No hard or soft fork is required, BBC is just a separate privacy preserving
currency on top of bitcoin blockchain, and the same private keys and
addresses are used for both BBC and the base currency BTC.  Every BCC
transaction must be enclosed into by a small BTC transaction that stores
the OP_RETURNs and pays for the fees.

Are there any flaws in this design?

Originally posted to BCT https://bitcointalk.org/index.php?topic=1574508.0,
but got no feedback so far, apparently everybody was consumed with bitfinex
drama and now mimblewimble.

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/e3c67d56/attachment.html>

From henning.kopp at uni-ulm.de  Mon Aug  8 15:47:07 2016
From: henning.kopp at uni-ulm.de (Henning Kopp)
Date: Mon, 8 Aug 2016 17:47:07 +0200
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
Message-ID: <20160808154707.GB2196@banane.informatik.uni-ulm.de>

Hi Tony,

I see some issues in your protocol.

1. How are mining fees handled?

2. Assume Alice sends Bob some Coins together with their history and
Bob checks that the history is correct. How does the hash of the txout
find its way into the blockchain?

Regarding the blinding factor, I think you could just use HMAC.

All the best
Henning


On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev wrote:
> This is a proposal about hiding the entire content of bitcoin
> transactions.  It goes farther than CoinJoin and ring signatures, which
> only obfuscate the transaction graph, and Confidential Transactions, which
> only hide the amounts.
> 
> The central idea of the proposed design is to hide the entire inputs and
> outputs, and publish only the hash of inputs and outputs in the
> blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> inputs and outputs is sent directly to the payee via a private message, and
> never goes into the blockchain.  The payee then calculates the hash and
> looks it up in the blockchain to verify that the hash was indeed published
> by the payer.
> 
> Since the plaintext of the transaction is not published to the public
> blockchain, all validation work has to be done only by the user who
> receives the payment.
> 
> To protect against double-spends, the payer also has to publish another
> hash, which is the hash of the output being spent.  We?ll call this hash *spend
> proof*.  Since the spend proof depends solely on the output being spent,
> any attempt to spend the same output again will produce exactly the same
> spend proof, and the payee will be able to see that, and will reject the
> payment.  If there are several outputs consumed by the same transaction,
> the payer has to publish several spend proofs.
> 
> To prove that the outputs being spent are valid, the payer also has to send
> the plaintexts of the earlier transaction(s) that produced them, then the
> plaintexts of even earlier transactions that produced the outputs spent in
> those transactions, and so on, up until the issue (similar to coinbase)
> transactions that created the initial private coins.  Each new owner of the
> coin will have to store its entire history, and when he spends the coin, he
> forwards the entire history to the next owner and extends it with his own
> transaction.
> 
> If we apply the existing bitcoin design that allows multiple inputs and
> multiple outputs per transaction, the history of ownership transfers would
> grow exponentially.  Indeed, if we take any regular bitcoin output and try
> to track its history back to coinbase, our history will branch every time
> we see a transaction that has more than one input (which is not uncommon).
> After such a transaction (remember, we are traveling back in time), we?ll
> have to track two or more histories, for each respective input.  Those
> histories will branch again, and the total number of history entries grows
> exponentially.  For example, if every transaction had exactly two inputs,
> the size of history would grow as 2^N where N is the number of steps back
> in history.
> 
> To avoid such rapid growth of ownership history (which is not only
> inconvenient to move, but also exposes too much private information about
> previous owners of all the contributing coins), we will require each
> private transaction to have exactly one input (i.e. to consume exactly one
> previous output).  This means that when we track a coin?s history back in
> time, it will no longer branch.  It will grow linearly with the number of
> transfers of ownership.  If a user wants to combine several inputs, he will
> have to send them as separate private transactions (technically, several
> OP_RETURNs, which can be included in a single regular bitcoin transaction).
> 
> Thus, we are now forbidding any coin merges but still allowing coin
> splits.  To avoid ultimate splitting into the dust, we will also require
> that all private coins be issued in one of a small number of
> denominations.  Only integer number of ?banknotes? can be transferred, the
> input and output amounts must therefore be divisible by the denomination.
> For example, an input of amount 700, denomination 100, can be split into
> outputs 400 and 300, but not into 450 and 250.  To send a payment, the
> payer has to pick the unspent outputs of the highest denomination first,
> then the second highest, and so on, like we already do when we pay in cash.
> 
> With fixed denominations and one input per transaction, coin histories
> still grow, but only linearly, which should not be a concern in regard to
> scalability given that all relevant computing resources still grow
> exponentially.  The histories need to be stored only by the current owner
> of the coin, not every bitcoin node.  This is a fairer allocation of
> costs.  Regarding privacy, coin histories do expose private transactions
> (or rather parts thereof, since a typical payment will likely consist of
> several transactions due to one-input-per-transaction rule) of past coin
> owners to the future ones, and that exposure grows linearly with time, but
> it is still much much better than having every transaction immediately on
> the public blockchain.  Also, the value of this information for potential
> adversaries arguably decreases with time.
> 
> There is one technical nuance that I omitted above to avoid distraction.
>  Unlike regular bitcoin transactions, every output in a private payment
> must also include a blinding factor, which is just a random string.  When
> the output is spent, the corresponding spend proof will therefore depend on
> this blinding factor (remember that spend proof is just a hash of the
> output).  Without a blinding factor, it would be feasible to pre-image the
> spend proof and reveal the output being spent as the search space of all
> possible outputs is rather small.
> 
> To issue the new private coin, one can burn regular BTC by sending it to
> one of several unspendable bitcoin addresses, one address per denomination.
>  Burning BTC would entitle one to an equal amount of the new private coin,
> let?s call it *black bitcoin*, or *BBC*.
> 
> Then BBC would be transferred from user to user by:
> 1. creating a private transaction, which consists of one input and several
> outputs;
> 2. storing the hash of the transaction and the spend proof of the consumed
> output into the blockchain in an OP_RETURN (the sender pays the
> corresponding fees in regular BTC)
> 3. sending the transaction, together with the history leading to its input,
> directly to the payee over a private communication channel.  The first
> entry of the history must be a bitcoin transaction that burned BTC to issue
> an equal amount of BCC.
> 
> To verify the payment, the payee:
> 1. makes sure that the amount of the input matches the sum of outputs, and
> all are divisible by the denomination
> 2. calculates the hash of the private transaction
> 3. looks up an OP_RETURN that includes this hash and is signed by the
> payee.  If there is more than one, the one that comes in the earlier block
> prevails.
> 4. calculates the spend proof and makes sure that it is included in the
> same OP_RETURN
> 5. makes sure the same spend proof is not included anywhere in the same or
> earlier blocks (that is, the coin was not spent before).  Only transactions
> by the same author are searched.
> 6. repeats the same steps for every entry in the history, except the first
> entry, which should be a valid burning transaction.
> 
> To facilitate exchange of private transaction data, the bitcoin network
> protocol can be extended with a new message type.  Unfortunately, it lacks
> encryption, hence private payments are really private only when bitcoin is
> used over tor.
> 
> There are a few limitations that ought to be mentioned:
> 1. After user A sends a private payment to user B, user A will know what
> the spend proof is going to be when B decides to spend the coin.
>  Therefore, A will know when the coin was spent by B, but nothing more.
>  Neither the new owner of the coin, nor its future movements will be known
> to A.
> 2. Over time, larger outputs will likely be split into many smaller
> outputs, whose amounts are not much greater than their denominations.
> You?ll have to combine more inputs to send the same amount.  When you want
> to send a very large amount that is much greater than the highest available
> denomination, you?ll have to send a lot of private transactions, your
> bitcoin transaction with so many OP_RETURNs will stand out, and their
> number will roughly indicate the total amount.  This kind of privacy
> leakage, however it applies to a small number of users, is easy to avoid by
> using multiple addresses and storing a relatively small amount on each
> address.
> 3. Exchanges and large merchants will likely accumulate large coin
> histories.  Although fragmented, far from complete, and likely outdated, it
> is still something to bear in mind.
> 
> No hard or soft fork is required, BBC is just a separate privacy preserving
> currency on top of bitcoin blockchain, and the same private keys and
> addresses are used for both BBC and the base currency BTC.  Every BCC
> transaction must be enclosed into by a small BTC transaction that stores
> the OP_RETURNs and pays for the fees.
> 
> Are there any flaws in this design?
> 
> Originally posted to BCT https://bitcointalk.org/index.php?topic=1574508.0,
> but got no feedback so far, apparently everybody was consumed with bitfinex
> drama and now mimblewimble.
> 
> Tony

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

From tony991 at gmail.com  Mon Aug  8 16:03:28 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Mon, 8 Aug 2016 19:03:28 +0300
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <20160808154707.GB2196@banane.informatik.uni-ulm.de>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
Message-ID: <CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>

Hi Henning,

1. The fees are paid by the enclosing BTC transaction.
2. The hash is encoded into an OP_RETURN.

> Regarding the blinding factor, I think you could just use HMAC.
How exactly?

Tony


2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:

> Hi Tony,
>
> I see some issues in your protocol.
>
> 1. How are mining fees handled?
>
> 2. Assume Alice sends Bob some Coins together with their history and
> Bob checks that the history is correct. How does the hash of the txout
> find its way into the blockchain?
>
> Regarding the blinding factor, I think you could just use HMAC.
>
> All the best
> Henning
>
>
> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> wrote:
> > This is a proposal about hiding the entire content of bitcoin
> > transactions.  It goes farther than CoinJoin and ring signatures, which
> > only obfuscate the transaction graph, and Confidential Transactions,
> which
> > only hide the amounts.
> >
> > The central idea of the proposed design is to hide the entire inputs and
> > outputs, and publish only the hash of inputs and outputs in the
> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > inputs and outputs is sent directly to the payee via a private message,
> and
> > never goes into the blockchain.  The payee then calculates the hash and
> > looks it up in the blockchain to verify that the hash was indeed
> published
> > by the payer.
> >
> > Since the plaintext of the transaction is not published to the public
> > blockchain, all validation work has to be done only by the user who
> > receives the payment.
> >
> > To protect against double-spends, the payer also has to publish another
> > hash, which is the hash of the output being spent.  We?ll call this hash
> *spend
> > proof*.  Since the spend proof depends solely on the output being spent,
> > any attempt to spend the same output again will produce exactly the same
> > spend proof, and the payee will be able to see that, and will reject the
> > payment.  If there are several outputs consumed by the same transaction,
> > the payer has to publish several spend proofs.
> >
> > To prove that the outputs being spent are valid, the payer also has to
> send
> > the plaintexts of the earlier transaction(s) that produced them, then the
> > plaintexts of even earlier transactions that produced the outputs spent
> in
> > those transactions, and so on, up until the issue (similar to coinbase)
> > transactions that created the initial private coins.  Each new owner of
> the
> > coin will have to store its entire history, and when he spends the coin,
> he
> > forwards the entire history to the next owner and extends it with his own
> > transaction.
> >
> > If we apply the existing bitcoin design that allows multiple inputs and
> > multiple outputs per transaction, the history of ownership transfers
> would
> > grow exponentially.  Indeed, if we take any regular bitcoin output and
> try
> > to track its history back to coinbase, our history will branch every time
> > we see a transaction that has more than one input (which is not
> uncommon).
> > After such a transaction (remember, we are traveling back in time), we?ll
> > have to track two or more histories, for each respective input.  Those
> > histories will branch again, and the total number of history entries
> grows
> > exponentially.  For example, if every transaction had exactly two inputs,
> > the size of history would grow as 2^N where N is the number of steps back
> > in history.
> >
> > To avoid such rapid growth of ownership history (which is not only
> > inconvenient to move, but also exposes too much private information about
> > previous owners of all the contributing coins), we will require each
> > private transaction to have exactly one input (i.e. to consume exactly
> one
> > previous output).  This means that when we track a coin?s history back in
> > time, it will no longer branch.  It will grow linearly with the number of
> > transfers of ownership.  If a user wants to combine several inputs, he
> will
> > have to send them as separate private transactions (technically, several
> > OP_RETURNs, which can be included in a single regular bitcoin
> transaction).
> >
> > Thus, we are now forbidding any coin merges but still allowing coin
> > splits.  To avoid ultimate splitting into the dust, we will also require
> > that all private coins be issued in one of a small number of
> > denominations.  Only integer number of ?banknotes? can be transferred,
> the
> > input and output amounts must therefore be divisible by the denomination.
> > For example, an input of amount 700, denomination 100, can be split into
> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
> > payer has to pick the unspent outputs of the highest denomination first,
> > then the second highest, and so on, like we already do when we pay in
> cash.
> >
> > With fixed denominations and one input per transaction, coin histories
> > still grow, but only linearly, which should not be a concern in regard to
> > scalability given that all relevant computing resources still grow
> > exponentially.  The histories need to be stored only by the current owner
> > of the coin, not every bitcoin node.  This is a fairer allocation of
> > costs.  Regarding privacy, coin histories do expose private transactions
> > (or rather parts thereof, since a typical payment will likely consist of
> > several transactions due to one-input-per-transaction rule) of past coin
> > owners to the future ones, and that exposure grows linearly with time,
> but
> > it is still much much better than having every transaction immediately on
> > the public blockchain.  Also, the value of this information for potential
> > adversaries arguably decreases with time.
> >
> > There is one technical nuance that I omitted above to avoid distraction.
> >  Unlike regular bitcoin transactions, every output in a private payment
> > must also include a blinding factor, which is just a random string.  When
> > the output is spent, the corresponding spend proof will therefore depend
> on
> > this blinding factor (remember that spend proof is just a hash of the
> > output).  Without a blinding factor, it would be feasible to pre-image
> the
> > spend proof and reveal the output being spent as the search space of all
> > possible outputs is rather small.
> >
> > To issue the new private coin, one can burn regular BTC by sending it to
> > one of several unspendable bitcoin addresses, one address per
> denomination.
> >  Burning BTC would entitle one to an equal amount of the new private
> coin,
> > let?s call it *black bitcoin*, or *BBC*.
> >
> > Then BBC would be transferred from user to user by:
> > 1. creating a private transaction, which consists of one input and
> several
> > outputs;
> > 2. storing the hash of the transaction and the spend proof of the
> consumed
> > output into the blockchain in an OP_RETURN (the sender pays the
> > corresponding fees in regular BTC)
> > 3. sending the transaction, together with the history leading to its
> input,
> > directly to the payee over a private communication channel.  The first
> > entry of the history must be a bitcoin transaction that burned BTC to
> issue
> > an equal amount of BCC.
> >
> > To verify the payment, the payee:
> > 1. makes sure that the amount of the input matches the sum of outputs,
> and
> > all are divisible by the denomination
> > 2. calculates the hash of the private transaction
> > 3. looks up an OP_RETURN that includes this hash and is signed by the
> > payee.  If there is more than one, the one that comes in the earlier
> block
> > prevails.
> > 4. calculates the spend proof and makes sure that it is included in the
> > same OP_RETURN
> > 5. makes sure the same spend proof is not included anywhere in the same
> or
> > earlier blocks (that is, the coin was not spent before).  Only
> transactions
> > by the same author are searched.
> > 6. repeats the same steps for every entry in the history, except the
> first
> > entry, which should be a valid burning transaction.
> >
> > To facilitate exchange of private transaction data, the bitcoin network
> > protocol can be extended with a new message type.  Unfortunately, it
> lacks
> > encryption, hence private payments are really private only when bitcoin
> is
> > used over tor.
> >
> > There are a few limitations that ought to be mentioned:
> > 1. After user A sends a private payment to user B, user A will know what
> > the spend proof is going to be when B decides to spend the coin.
> >  Therefore, A will know when the coin was spent by B, but nothing more.
> >  Neither the new owner of the coin, nor its future movements will be
> known
> > to A.
> > 2. Over time, larger outputs will likely be split into many smaller
> > outputs, whose amounts are not much greater than their denominations.
> > You?ll have to combine more inputs to send the same amount.  When you
> want
> > to send a very large amount that is much greater than the highest
> available
> > denomination, you?ll have to send a lot of private transactions, your
> > bitcoin transaction with so many OP_RETURNs will stand out, and their
> > number will roughly indicate the total amount.  This kind of privacy
> > leakage, however it applies to a small number of users, is easy to avoid
> by
> > using multiple addresses and storing a relatively small amount on each
> > address.
> > 3. Exchanges and large merchants will likely accumulate large coin
> > histories.  Although fragmented, far from complete, and likely outdated,
> it
> > is still something to bear in mind.
> >
> > No hard or soft fork is required, BBC is just a separate privacy
> preserving
> > currency on top of bitcoin blockchain, and the same private keys and
> > addresses are used for both BBC and the base currency BTC.  Every BCC
> > transaction must be enclosed into by a small BTC transaction that stores
> > the OP_RETURNs and pays for the fees.
> >
> > Are there any flaws in this design?
> >
> > Originally posted to BCT https://bitcointalk.org/index.
> php?topic=1574508.0,
> > but got no feedback so far, apparently everybody was consumed with
> bitfinex
> > drama and now mimblewimble.
> >
> > Tony
>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/1ce6b828/attachment.html>

From info at AndySchroder.com  Mon Aug  8 17:09:45 2016
From: info at AndySchroder.com (Andy Schroder)
Date: Mon, 8 Aug 2016 13:09:45 -0400
Subject: [bitcoin-dev] Authentication BIP
In-Reply-To: <57A89EA3.4020101@jonasschnelli.ch>
References: <57A89EA3.4020101@jonasschnelli.ch>
Message-ID: <57A8BCD9.7050402@AndySchroder.com>

On 08/08/2016 11:00 AM, Jonas Schnelli via bitcoin-dev wrote:
> # ___known-peers___ contains known identity-public-keys together with a
> network identifier (IP & port), similar to the "known-host" file
> supported by openssh.


I have mixed feelings about strictly tying the identity-public-keys with 
a network identifier. I think the purpose of this is to detect if 
someone has physically stolen and compromised my bitcoin node and placed 
it on another network under control of an attacker. This seems to be a 
bit of a benefit, however, an attacker could always spoof the original 
network identifier anyway.

I run my bitcoin node on an internet connection that does not guarantee 
a static IP address (although it usually stays the same for several 
weeks or months at a time). I'd like to be able to make secure 
connections back to my own node, even if I know the IP address may 
change from time to time. There are several reasons for wanting to this 
with a changing IP. The first is because the bandwidth on my internet 
connection with a guaranteed static IP address is considerably more 
expensive than my internet connection without a guaranteed static IP 
address. The second reason is because the DNS PTR record for my static 
IP address is personally identifiable based on other reasons/services. 
The internet connection that my bitcoin node is using without a 
guaranteed static IP address just has a PTR record that basically 
includes my IP address and ISP name. This isn't much use to the general 
public (although my ISP obviously knows who I am). The third reason is 
that I consider it a good thing from a privacy perspective if my IP 
address changes every once and a while.

Maybe a strict check option where the identity-public-keys must 
optionally match a specific network identifier would be a compromise? 
Maybe this is up to the client implementation to decide, so it should 
just be suggested in the BIP rather than required?




> # ___authorized-peers___ contains authorized identity-public-keys

Is there an option for a wildcard here? Couldn't there be a case where 
the client wants to authenticate, but the bitcoin node does not care who 
it's clients are? This would be similar to many of the http based 
bitcoin block explorer API services that are out there. The API 
operators have built up some reputation, so people use them, but they 
don't necessarily care about who their users are.







> === Local identity key management ===
> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).

What if I have bitcoind listening on multiple IPv4 interfaces? Can I 
have a different identity-key for each IPv4 interface?

Also, would it be possible to only allow this authentication on specific 
interfaces? In my example above where I have two internet connections, 
if you don't agree to loosening the tie between the network identifier 
and the identity-public-keys, maybe I would just connect my bitcoin node 
to both internet connections, but only allow a few authorized-peers on 
the static IP (which would be low bandwidth), and then not authenticate 
on the internet connection with the changing IP at all

If you don't want to increase complexity by adding these options, one 
could always accomplish the same thing by runing two instances of 
bitcoind and pairing the two over a local network, it would just be a 
waste of resources.




> == Disadvantages ==
>
> The protocol may be slow if a peer has a large authorized-peers database
> due to the requirement of iterating and hashing over all available
> authorized peers identity-public-keys.


Does openssh have this same problem?

I'm assuming this could be parallelized very easily, so it is not a huge 
problem?






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/819a2eb5/attachment-0001.sig>

From greg at xiph.org  Mon Aug  8 17:42:45 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Mon, 8 Aug 2016 17:42:45 +0000
Subject: [bitcoin-dev] Authentication BIP
In-Reply-To: <57A8BCD9.7050402@AndySchroder.com>
References: <57A89EA3.4020101@jonasschnelli.ch>
	<57A8BCD9.7050402@AndySchroder.com>
Message-ID: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>

On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have mixed feelings about strictly tying the identity-public-keys with a
[...]
> guaranteed static IP address. The second reason is because the DNS PTR

I don't see any reason that it couldn't also accept a DNS name there.

The purpose of that table is so the client knows which server ID to expect.

> I consider it a good thing from a privacy perspective if my IP address
> changes every once and a while.

And the design seeks to preserve that privacy.

> Maybe a strict check option where the identity-public-keys must optionally
> match a specific network identifier would be a compromise? Maybe this is up

The client must know the identity of the server it is expecting. The
server does not announce itself. If it did then your changing of IPs
would provide you with no privacy at all.

If the design is to provide any protection against MITM you need to
know who you expected to connect to in any case.

> I think the purpose of this is to detect if someone has physically stolen and compromised my bitcoin node and placed it on another network under control of an attacker.

Huh. No. Almost the opposite. The system is designed to inhibit
fingerprinting. You can't tell what identity key(s) a node has unless
you already know them. This means that if you don't publish your node
pubkey, no one can use it to track your node around the network.

> Is there an option for a wildcard here? Couldn't there be a case where the
> client wants to authenticate, but the bitcoin node does not care who it's
> clients are? This would be similar to many of the http based bitcoin block
> explorer API services that are out there. The API operators have built up
> some reputation, so people use them, but they don't necessarily care about
> who their users are.

Then they're just not listed in the file. The client can ask the server to
authenticate without authenticating itself.

> Does openssh have this same problem?

No. OpenSSH doesn't make an effort to protect the privacy of its users.

> I'm assuming this could be parallelized very easily, so it is not a huge
> problem?

It's not a issue because we're not aware of any usecase where a node
would have a large list of authenticated peers.

> Each peer can configure one identity-key (ECC, 32 bytes) per listening
network interface (IPv4, IPv6, tor).

I'm not aware of any reason for this limitation to exist. A node
should be able to have as many listening identities as it wants, with
a similar cost to having a large authorized keys list.

From info at AndySchroder.com  Mon Aug  8 17:54:53 2016
From: info at AndySchroder.com (Andy Schroder)
Date: Mon, 8 Aug 2016 13:54:53 -0400
Subject: [bitcoin-dev] Authentication BIP
In-Reply-To: <CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
References: <57A89EA3.4020101@jonasschnelli.ch>
	<57A8BCD9.7050402@AndySchroder.com>
	<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
Message-ID: <57A8C76D.1080405@AndySchroder.com>


On 08/08/2016 01:42 PM, Gregory Maxwell wrote:
> On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I have mixed feelings about strictly tying the identity-public-keys with a
> [...]
>> guaranteed static IP address. The second reason is because the DNS PTR
> I don't see any reason that it couldn't also accept a DNS name there.
>
> The purpose of that table is so the client knows which server ID to expect.

Okay, that may be fine. You are saying otherwise you'd have to do a 
trial and error and this tying to a network identifier just speeds 
things up? If the DNS is spoofed, it's no big deal because the 
authentication will fail anyway?



>
>> I consider it a good thing from a privacy perspective if my IP address
>> changes every once and a while.
> And the design seeks to preserve that privacy.
>
>> Maybe a strict check option where the identity-public-keys must optionally
>> match a specific network identifier would be a compromise? Maybe this is up
> The client must know the identity of the server it is expecting. The
> server does not announce itself. If it did then your changing of IPs
> would provide you with no privacy at all.

Good point.

>
> If the design is to provide any protection against MITM you need to
> know who you expected to connect to in any case.
>
>> I think the purpose of this is to detect if someone has physically stolen and compromised my bitcoin node and placed it on another network under control of an attacker.
> Huh. No. Almost the opposite. The system is designed to inhibit
> fingerprinting. You can't tell what identity key(s) a node has unless
> you already know them. This means that if you don't publish your node
> pubkey, no one can use it to track your node around the network.

Cool.

>
>> Is there an option for a wildcard here? Couldn't there be a case where the
>> client wants to authenticate, but the bitcoin node does not care who it's
>> clients are? This would be similar to many of the http based bitcoin block
>> explorer API services that are out there. The API operators have built up
>> some reputation, so people use them, but they don't necessarily care about
>> who their users are.
> Then they're just not listed in the file. The client can ask the server to
> authenticate without authenticating itself.

Simple enough.

>
>> Does openssh have this same problem?
> No. OpenSSH doesn't make an effort to protect the privacy of its users.
>
>> I'm assuming this could be parallelized very easily, so it is not a huge
>> problem?
> It's not a issue because we're not aware of any usecase where a node
> would have a large list of authenticated peers.
>
>> Each peer can configure one identity-key (ECC, 32 bytes) per listening
> network interface (IPv4, IPv6, tor).
>
> I'm not aware of any reason for this limitation to exist. A node
> should be able to have as many listening identities as it wants, with
> a similar cost to having a large authorized keys list.
>

So you are saying that you agree with me that the original text needs to 
be revised slightly or I am just misinterpreting the original text?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/35f0fa9d/attachment.sig>

From danielhoffman699 at gmail.com  Mon Aug  8 21:22:44 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Mon, 8 Aug 2016 16:22:44 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
Message-ID: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>

This is my BIP idea: a fast, robust, and standardized for representing
Bitcoin addresses over audio. It takes the binary representation of the
Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
(depending on type, 2 bit only for low quality audio like american
telephone lines), and generates a tone based upon that value. This started
because I wanted an easy way to donate to podcasts that I listen to, and
having a Shazam-esque app (or a media player with this capability) that
gives me an address automatically would be wonderful for both the consumer
and producer. Comes with error correction built into the protocol

You can see the full specification of the BIP on my GitHub page (
https://github.com/Dako300/BIP-0153).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/6d625f95/attachment.html>

From macwhyte at gmail.com  Mon Aug  8 21:41:27 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Mon, 08 Aug 2016 21:41:27 +0000
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
Message-ID: <CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>

Wouldn't you lose the ability to assume transactions in the blockchain are
verified as valid, since miners can't see the details of what is being
spent and how? I feel like this ability is bitcoin's greatest asset, and by
removing it you're creating an altcoin different enough to not be connected
to/supported by the main bitcoin project.

On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Henning,
>
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
>
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
>
> Tony
>
>
> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>
>> Hi Tony,
>>
>> I see some issues in your protocol.
>>
>> 1. How are mining fees handled?
>>
>> 2. Assume Alice sends Bob some Coins together with their history and
>> Bob checks that the history is correct. How does the hash of the txout
>> find its way into the blockchain?
>>
>> Regarding the blinding factor, I think you could just use HMAC.
>>
>> All the best
>> Henning
>>
>>
>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
>> wrote:
>> > This is a proposal about hiding the entire content of bitcoin
>> > transactions.  It goes farther than CoinJoin and ring signatures, which
>> > only obfuscate the transaction graph, and Confidential Transactions,
>> which
>> > only hide the amounts.
>> >
>> > The central idea of the proposed design is to hide the entire inputs and
>> > outputs, and publish only the hash of inputs and outputs in the
>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>> > inputs and outputs is sent directly to the payee via a private message,
>> and
>> > never goes into the blockchain.  The payee then calculates the hash and
>> > looks it up in the blockchain to verify that the hash was indeed
>> published
>> > by the payer.
>> >
>> > Since the plaintext of the transaction is not published to the public
>> > blockchain, all validation work has to be done only by the user who
>> > receives the payment.
>> >
>> > To protect against double-spends, the payer also has to publish another
>> > hash, which is the hash of the output being spent.  We?ll call this
>> hash *spend
>> > proof*.  Since the spend proof depends solely on the output being spent,
>> > any attempt to spend the same output again will produce exactly the same
>> > spend proof, and the payee will be able to see that, and will reject the
>> > payment.  If there are several outputs consumed by the same transaction,
>> > the payer has to publish several spend proofs.
>> >
>> > To prove that the outputs being spent are valid, the payer also has to
>> send
>> > the plaintexts of the earlier transaction(s) that produced them, then
>> the
>> > plaintexts of even earlier transactions that produced the outputs spent
>> in
>> > those transactions, and so on, up until the issue (similar to coinbase)
>> > transactions that created the initial private coins.  Each new owner of
>> the
>> > coin will have to store its entire history, and when he spends the
>> coin, he
>> > forwards the entire history to the next owner and extends it with his
>> own
>> > transaction.
>> >
>> > If we apply the existing bitcoin design that allows multiple inputs and
>> > multiple outputs per transaction, the history of ownership transfers
>> would
>> > grow exponentially.  Indeed, if we take any regular bitcoin output and
>> try
>> > to track its history back to coinbase, our history will branch every
>> time
>> > we see a transaction that has more than one input (which is not
>> uncommon).
>> > After such a transaction (remember, we are traveling back in time),
>> we?ll
>> > have to track two or more histories, for each respective input.  Those
>> > histories will branch again, and the total number of history entries
>> grows
>> > exponentially.  For example, if every transaction had exactly two
>> inputs,
>> > the size of history would grow as 2^N where N is the number of steps
>> back
>> > in history.
>> >
>> > To avoid such rapid growth of ownership history (which is not only
>> > inconvenient to move, but also exposes too much private information
>> about
>> > previous owners of all the contributing coins), we will require each
>> > private transaction to have exactly one input (i.e. to consume exactly
>> one
>> > previous output).  This means that when we track a coin?s history back
>> in
>> > time, it will no longer branch.  It will grow linearly with the number
>> of
>> > transfers of ownership.  If a user wants to combine several inputs, he
>> will
>> > have to send them as separate private transactions (technically, several
>> > OP_RETURNs, which can be included in a single regular bitcoin
>> transaction).
>> >
>> > Thus, we are now forbidding any coin merges but still allowing coin
>> > splits.  To avoid ultimate splitting into the dust, we will also require
>> > that all private coins be issued in one of a small number of
>> > denominations.  Only integer number of ?banknotes? can be transferred,
>> the
>> > input and output amounts must therefore be divisible by the
>> denomination.
>> > For example, an input of amount 700, denomination 100, can be split into
>> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
>> > payer has to pick the unspent outputs of the highest denomination first,
>> > then the second highest, and so on, like we already do when we pay in
>> cash.
>> >
>> > With fixed denominations and one input per transaction, coin histories
>> > still grow, but only linearly, which should not be a concern in regard
>> to
>> > scalability given that all relevant computing resources still grow
>> > exponentially.  The histories need to be stored only by the current
>> owner
>> > of the coin, not every bitcoin node.  This is a fairer allocation of
>> > costs.  Regarding privacy, coin histories do expose private transactions
>> > (or rather parts thereof, since a typical payment will likely consist of
>> > several transactions due to one-input-per-transaction rule) of past coin
>> > owners to the future ones, and that exposure grows linearly with time,
>> but
>> > it is still much much better than having every transaction immediately
>> on
>> > the public blockchain.  Also, the value of this information for
>> potential
>> > adversaries arguably decreases with time.
>> >
>> > There is one technical nuance that I omitted above to avoid distraction.
>> >  Unlike regular bitcoin transactions, every output in a private payment
>> > must also include a blinding factor, which is just a random string.
>> When
>> > the output is spent, the corresponding spend proof will therefore
>> depend on
>> > this blinding factor (remember that spend proof is just a hash of the
>> > output).  Without a blinding factor, it would be feasible to pre-image
>> the
>> > spend proof and reveal the output being spent as the search space of all
>> > possible outputs is rather small.
>> >
>> > To issue the new private coin, one can burn regular BTC by sending it to
>> > one of several unspendable bitcoin addresses, one address per
>> denomination.
>> >  Burning BTC would entitle one to an equal amount of the new private
>> coin,
>> > let?s call it *black bitcoin*, or *BBC*.
>> >
>> > Then BBC would be transferred from user to user by:
>> > 1. creating a private transaction, which consists of one input and
>> several
>> > outputs;
>> > 2. storing the hash of the transaction and the spend proof of the
>> consumed
>> > output into the blockchain in an OP_RETURN (the sender pays the
>> > corresponding fees in regular BTC)
>> > 3. sending the transaction, together with the history leading to its
>> input,
>> > directly to the payee over a private communication channel.  The first
>> > entry of the history must be a bitcoin transaction that burned BTC to
>> issue
>> > an equal amount of BCC.
>> >
>> > To verify the payment, the payee:
>> > 1. makes sure that the amount of the input matches the sum of outputs,
>> and
>> > all are divisible by the denomination
>> > 2. calculates the hash of the private transaction
>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>> > payee.  If there is more than one, the one that comes in the earlier
>> block
>> > prevails.
>> > 4. calculates the spend proof and makes sure that it is included in the
>> > same OP_RETURN
>> > 5. makes sure the same spend proof is not included anywhere in the same
>> or
>> > earlier blocks (that is, the coin was not spent before).  Only
>> transactions
>> > by the same author are searched.
>> > 6. repeats the same steps for every entry in the history, except the
>> first
>> > entry, which should be a valid burning transaction.
>> >
>> > To facilitate exchange of private transaction data, the bitcoin network
>> > protocol can be extended with a new message type.  Unfortunately, it
>> lacks
>> > encryption, hence private payments are really private only when bitcoin
>> is
>> > used over tor.
>> >
>> > There are a few limitations that ought to be mentioned:
>> > 1. After user A sends a private payment to user B, user A will know what
>> > the spend proof is going to be when B decides to spend the coin.
>> >  Therefore, A will know when the coin was spent by B, but nothing more.
>> >  Neither the new owner of the coin, nor its future movements will be
>> known
>> > to A.
>> > 2. Over time, larger outputs will likely be split into many smaller
>> > outputs, whose amounts are not much greater than their denominations.
>> > You?ll have to combine more inputs to send the same amount.  When you
>> want
>> > to send a very large amount that is much greater than the highest
>> available
>> > denomination, you?ll have to send a lot of private transactions, your
>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>> > number will roughly indicate the total amount.  This kind of privacy
>> > leakage, however it applies to a small number of users, is easy to
>> avoid by
>> > using multiple addresses and storing a relatively small amount on each
>> > address.
>> > 3. Exchanges and large merchants will likely accumulate large coin
>> > histories.  Although fragmented, far from complete, and likely
>> outdated, it
>> > is still something to bear in mind.
>> >
>> > No hard or soft fork is required, BBC is just a separate privacy
>> preserving
>> > currency on top of bitcoin blockchain, and the same private keys and
>> > addresses are used for both BBC and the base currency BTC.  Every BCC
>> > transaction must be enclosed into by a small BTC transaction that stores
>> > the OP_RETURNs and pays for the fees.
>> >
>> > Are there any flaws in this design?
>> >
>> > Originally posted to BCT
>> https://bitcointalk.org/index.php?topic=1574508.0,
>> > but got no feedback so far, apparently everybody was consumed with
>> bitfinex
>> > drama and now mimblewimble.
>> >
>> > Tony
>>
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> --
>> Henning Kopp
>> Institute of Distributed Systems
>> Ulm University, Germany
>>
>> Office: O27 - 3402
>> Phone: +49 731 50-24138
>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/0bfeb179/attachment-0001.html>

From pete at petertodd.org  Mon Aug  8 21:53:54 2016
From: pete at petertodd.org (Peter Todd)
Date: Mon, 8 Aug 2016 14:53:54 -0700
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
Message-ID: <20160808215354.GA1373@fedora-21-dvm>

On Mon, Aug 08, 2016 at 09:41:27PM +0000, James MacWhyte via bitcoin-dev wrote:
> Wouldn't you lose the ability to assume transactions in the blockchain are
> verified as valid, since miners can't see the details of what is being
> spent and how? I feel like this ability is bitcoin's greatest asset, and by
> removing it you're creating an altcoin different enough to not be connected
> to/supported by the main bitcoin project.

The fact that miners verify transactions is just an optimisation:

    https://petertodd.org/2013/disentangling-crypto-coin-mining

Preventing double-spending however is a fundemental requirement of Bitcoin, and
this proposal does prevent double-spending perfectly well (although there may
be better ways to do it).

The OP's proposal sounds quite similar to my earlier one along similar lines:

    https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/21a67947/attachment.sig>

From justin at netki.com  Mon Aug  8 22:06:05 2016
From: justin at netki.com (Justin Newton)
Date: Mon, 8 Aug 2016 15:06:05 -0700
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
Message-ID: <CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>

Daniel,
   Thanks for proposing this.  I think this could have some useful use
cases as you state.  I was wondering what you would think to adding some
additional tones to optionally denote an amount (in satoshis?).

(FYI, actual link is here:  https://github.com/Dako300/BIP )

Justin

On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> This is my BIP idea: a fast, robust, and standardized for representing
> Bitcoin addresses over audio. It takes the binary representation of the
> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
> (depending on type, 2 bit only for low quality audio like american
> telephone lines), and generates a tone based upon that value. This started
> because I wanted an easy way to donate to podcasts that I listen to, and
> having a Shazam-esque app (or a media player with this capability) that
> gives me an address automatically would be wonderful for both the consumer
> and producer. Comes with error correction built into the protocol
>
> You can see the full specification of the BIP on my GitHub page (
> https://github.com/Dako300/BIP-0153).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 

Justin W. Newton
Founder/CEO
Netki, Inc.

justin at netki.com
+1.818.261.4248
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/4ea7b965/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/4ea7b965/attachment.tiff>

From danielhoffman699 at gmail.com  Mon Aug  8 21:33:06 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Mon, 8 Aug 2016 16:33:06 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio (fixed link)
Message-ID: <CAL9WuQWubcUkj06grc=B_u8ajtOepvFn0DzGBjzVxk8kAgTZVA@mail.gmail.com>

Sorry about the last email, I deleted the repository to get rid of the BIP
number to prevent confusion. The correct address is
https://github.com/Dako300/BIP

This is my BIP idea: a fast, robust, and standardized way for representing
Bitcoin addresses over audio. It takes the binary representation of the
Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
(depending on type, 2 bit only for low quality audio like american
telephone lines), and generates a tone based upon that value. This started
because I wanted an easy way to donate to podcasts that I listen to, and
having a Shazam-esque app (or a media player with this capability) that
gives me an address automatically would be wonderful for both the consumer
and producer. Comes with error correction built into the protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/0fedf9a6/attachment-0001.html>

From danielhoffman699 at gmail.com  Mon Aug  8 22:35:32 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Mon, 8 Aug 2016 17:35:32 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
Message-ID: <CAL9WuQXoU0fE-1oFmDhPQgt-xv_ek0j6eU5mkWxwjgVS5=JSrg@mail.gmail.com>

I wouldn't worry about payment requests until I built a decoder and made
the transmission a lot faster (probably adding tones and making it 5 bits
wide), which shouldn't be hard

On Mon, Aug 8, 2016 at 5:06 PM, Justin Newton via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Daniel,
>    Thanks for proposing this.  I think this could have some useful use
> cases as you state.  I was wondering what you would think to adding some
> additional tones to optionally denote an amount (in satoshis?).
>
> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>
> Justin
>
> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is my BIP idea: a fast, robust, and standardized for representing
>> Bitcoin addresses over audio. It takes the binary representation of the
>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>> (depending on type, 2 bit only for low quality audio like american
>> telephone lines), and generates a tone based upon that value. This started
>> because I wanted an easy way to donate to podcasts that I listen to, and
>> having a Shazam-esque app (or a media player with this capability) that
>> gives me an address automatically would be wonderful for both the consumer
>> and producer. Comes with error correction built into the protocol
>>
>> You can see the full specification of the BIP on my GitHub page (
>> https://github.com/Dako300/BIP-0153).
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin at netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/f5f3271e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/f5f3271e/attachment.tiff>

From trevinhofmann at gmail.com  Mon Aug  8 22:59:25 2016
From: trevinhofmann at gmail.com (Trevin Hofmann)
Date: Mon, 8 Aug 2016 15:59:25 -0700
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
Message-ID: <CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>

Would it be feasible to transmit an entire BIP21 URI as audio? If you were
to encode any extra information (such as amount), it would be useful to
include a checksum for the entire message. This checksum could possibly be
used instead of the checksum in the address.

Trevin

On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Daniel,
>    Thanks for proposing this.  I think this could have some useful use
> cases as you state.  I was wondering what you would think to adding some
> additional tones to optionally denote an amount (in satoshis?).
>
> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>
> Justin
>
> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is my BIP idea: a fast, robust, and standardized for representing
>> Bitcoin addresses over audio. It takes the binary representation of the
>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>> (depending on type, 2 bit only for low quality audio like american
>> telephone lines), and generates a tone based upon that value. This started
>> because I wanted an easy way to donate to podcasts that I listen to, and
>> having a Shazam-esque app (or a media player with this capability) that
>> gives me an address automatically would be wonderful for both the consumer
>> and producer. Comes with error correction built into the protocol
>>
>> You can see the full specification of the BIP on my GitHub page (
>> https://github.com/Dako300/BIP-0153).
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin at netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/8f8844cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/8f8844cf/attachment-0001.tiff>

From macwhyte at gmail.com  Tue Aug  9 00:03:17 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Tue, 09 Aug 2016 00:03:17 +0000
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
Message-ID: <CAH+Axy6JiK-giXRTxENRCZbX7g0NuU=hq02O3j2Ac8HZ0ZhfFg@mail.gmail.com>

That is a good point. As you said, it puts a lot more burden on the coin
holders. One big downside would be data management. Instead of simply
backing up a single HD private key, the user would have to back up entire
histories of every output that has been sent to them if they want to secure
their funds.

It also requires them to be online to receive payments, and I think finding
a method of sending the private message containing the coin's history is
going to be a bit of a challenge. If you connect directly to the recipient
to convey the information through traditional channels, anonymity is lost.
Sending messages through the bitcoin network is one option to protect
anonymity, but without active pathfinding there's no guarantee the payee
will even get the message. I'm assuming you'd have to essentially replace
tx messages with encrypted BBC histories, and mempools are quite full as it
is.

Tony, do you have any more thoughts on exactly how users would convey the
private messages to payees?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991 at gmail.com> wrote:

> The whole point is in preventing every third party, including miners, from
> seeing the details of what is being spent and how.  The burden of
> verification is shifted to the owners of the coin (which is fair).
>
> In fact we could have miners recognize spend proofs and check that the
> same spend proof is not entered into the blockchain more than once (which
> would be a sign of double spend), but it is not required.  The coin owners
> can already do that themselves.
>
> 2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
>
>> Wouldn't you lose the ability to assume transactions in the blockchain
>> are verified as valid, since miners can't see the details of what is being
>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>> removing it you're creating an altcoin different enough to not be connected
>> to/supported by the main bitcoin project.
>>
>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Henning,
>>>
>>> 1. The fees are paid by the enclosing BTC transaction.
>>> 2. The hash is encoded into an OP_RETURN.
>>>
>>> > Regarding the blinding factor, I think you could just use HMAC.
>>> How exactly?
>>>
>>> Tony
>>>
>>>
>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>>>
>>>> Hi Tony,
>>>>
>>>> I see some issues in your protocol.
>>>>
>>>> 1. How are mining fees handled?
>>>>
>>>> 2. Assume Alice sends Bob some Coins together with their history and
>>>> Bob checks that the history is correct. How does the hash of the txout
>>>> find its way into the blockchain?
>>>>
>>>> Regarding the blinding factor, I think you could just use HMAC.
>>>>
>>>> All the best
>>>> Henning
>>>>
>>>>
>>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>>> bitcoin-dev wrote:
>>>> > This is a proposal about hiding the entire content of bitcoin
>>>> > transactions.  It goes farther than CoinJoin and ring signatures,
>>>> which
>>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>>> which
>>>> > only hide the amounts.
>>>> >
>>>> > The central idea of the proposed design is to hide the entire inputs
>>>> and
>>>> > outputs, and publish only the hash of inputs and outputs in the
>>>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>>>> > inputs and outputs is sent directly to the payee via a private
>>>> message, and
>>>> > never goes into the blockchain.  The payee then calculates the hash
>>>> and
>>>> > looks it up in the blockchain to verify that the hash was indeed
>>>> published
>>>> > by the payer.
>>>> >
>>>> > Since the plaintext of the transaction is not published to the public
>>>> > blockchain, all validation work has to be done only by the user who
>>>> > receives the payment.
>>>> >
>>>> > To protect against double-spends, the payer also has to publish
>>>> another
>>>> > hash, which is the hash of the output being spent.  We?ll call this
>>>> hash *spend
>>>> > proof*.  Since the spend proof depends solely on the output being
>>>> spent,
>>>> > any attempt to spend the same output again will produce exactly the
>>>> same
>>>> > spend proof, and the payee will be able to see that, and will reject
>>>> the
>>>> > payment.  If there are several outputs consumed by the same
>>>> transaction,
>>>> > the payer has to publish several spend proofs.
>>>> >
>>>> > To prove that the outputs being spent are valid, the payer also has
>>>> to send
>>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>>> the
>>>> > plaintexts of even earlier transactions that produced the outputs
>>>> spent in
>>>> > those transactions, and so on, up until the issue (similar to
>>>> coinbase)
>>>> > transactions that created the initial private coins.  Each new owner
>>>> of the
>>>> > coin will have to store its entire history, and when he spends the
>>>> coin, he
>>>> > forwards the entire history to the next owner and extends it with his
>>>> own
>>>> > transaction.
>>>> >
>>>> > If we apply the existing bitcoin design that allows multiple inputs
>>>> and
>>>> > multiple outputs per transaction, the history of ownership transfers
>>>> would
>>>> > grow exponentially.  Indeed, if we take any regular bitcoin output
>>>> and try
>>>> > to track its history back to coinbase, our history will branch every
>>>> time
>>>> > we see a transaction that has more than one input (which is not
>>>> uncommon).
>>>> > After such a transaction (remember, we are traveling back in time),
>>>> we?ll
>>>> > have to track two or more histories, for each respective input.  Those
>>>> > histories will branch again, and the total number of history entries
>>>> grows
>>>> > exponentially.  For example, if every transaction had exactly two
>>>> inputs,
>>>> > the size of history would grow as 2^N where N is the number of steps
>>>> back
>>>> > in history.
>>>> >
>>>> > To avoid such rapid growth of ownership history (which is not only
>>>> > inconvenient to move, but also exposes too much private information
>>>> about
>>>> > previous owners of all the contributing coins), we will require each
>>>> > private transaction to have exactly one input (i.e. to consume
>>>> exactly one
>>>> > previous output).  This means that when we track a coin?s history
>>>> back in
>>>> > time, it will no longer branch.  It will grow linearly with the
>>>> number of
>>>> > transfers of ownership.  If a user wants to combine several inputs,
>>>> he will
>>>> > have to send them as separate private transactions (technically,
>>>> several
>>>> > OP_RETURNs, which can be included in a single regular bitcoin
>>>> transaction).
>>>> >
>>>> > Thus, we are now forbidding any coin merges but still allowing coin
>>>> > splits.  To avoid ultimate splitting into the dust, we will also
>>>> require
>>>> > that all private coins be issued in one of a small number of
>>>> > denominations.  Only integer number of ?banknotes? can be
>>>> transferred, the
>>>> > input and output amounts must therefore be divisible by the
>>>> denomination.
>>>> > For example, an input of amount 700, denomination 100, can be split
>>>> into
>>>> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
>>>> > payer has to pick the unspent outputs of the highest denomination
>>>> first,
>>>> > then the second highest, and so on, like we already do when we pay in
>>>> cash.
>>>> >
>>>> > With fixed denominations and one input per transaction, coin histories
>>>> > still grow, but only linearly, which should not be a concern in
>>>> regard to
>>>> > scalability given that all relevant computing resources still grow
>>>> > exponentially.  The histories need to be stored only by the current
>>>> owner
>>>> > of the coin, not every bitcoin node.  This is a fairer allocation of
>>>> > costs.  Regarding privacy, coin histories do expose private
>>>> transactions
>>>> > (or rather parts thereof, since a typical payment will likely consist
>>>> of
>>>> > several transactions due to one-input-per-transaction rule) of past
>>>> coin
>>>> > owners to the future ones, and that exposure grows linearly with
>>>> time, but
>>>> > it is still much much better than having every transaction
>>>> immediately on
>>>> > the public blockchain.  Also, the value of this information for
>>>> potential
>>>> > adversaries arguably decreases with time.
>>>> >
>>>> > There is one technical nuance that I omitted above to avoid
>>>> distraction.
>>>> >  Unlike regular bitcoin transactions, every output in a private
>>>> payment
>>>> > must also include a blinding factor, which is just a random string.
>>>> When
>>>> > the output is spent, the corresponding spend proof will therefore
>>>> depend on
>>>> > this blinding factor (remember that spend proof is just a hash of the
>>>> > output).  Without a blinding factor, it would be feasible to
>>>> pre-image the
>>>> > spend proof and reveal the output being spent as the search space of
>>>> all
>>>> > possible outputs is rather small.
>>>> >
>>>> > To issue the new private coin, one can burn regular BTC by sending it
>>>> to
>>>> > one of several unspendable bitcoin addresses, one address per
>>>> denomination.
>>>> >  Burning BTC would entitle one to an equal amount of the new private
>>>> coin,
>>>> > let?s call it *black bitcoin*, or *BBC*.
>>>> >
>>>> > Then BBC would be transferred from user to user by:
>>>> > 1. creating a private transaction, which consists of one input and
>>>> several
>>>> > outputs;
>>>> > 2. storing the hash of the transaction and the spend proof of the
>>>> consumed
>>>> > output into the blockchain in an OP_RETURN (the sender pays the
>>>> > corresponding fees in regular BTC)
>>>> > 3. sending the transaction, together with the history leading to its
>>>> input,
>>>> > directly to the payee over a private communication channel.  The first
>>>> > entry of the history must be a bitcoin transaction that burned BTC to
>>>> issue
>>>> > an equal amount of BCC.
>>>> >
>>>> > To verify the payment, the payee:
>>>> > 1. makes sure that the amount of the input matches the sum of
>>>> outputs, and
>>>> > all are divisible by the denomination
>>>> > 2. calculates the hash of the private transaction
>>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>>>> > payee.  If there is more than one, the one that comes in the earlier
>>>> block
>>>> > prevails.
>>>> > 4. calculates the spend proof and makes sure that it is included in
>>>> the
>>>> > same OP_RETURN
>>>> > 5. makes sure the same spend proof is not included anywhere in the
>>>> same or
>>>> > earlier blocks (that is, the coin was not spent before).  Only
>>>> transactions
>>>> > by the same author are searched.
>>>> > 6. repeats the same steps for every entry in the history, except the
>>>> first
>>>> > entry, which should be a valid burning transaction.
>>>> >
>>>> > To facilitate exchange of private transaction data, the bitcoin
>>>> network
>>>> > protocol can be extended with a new message type.  Unfortunately, it
>>>> lacks
>>>> > encryption, hence private payments are really private only when
>>>> bitcoin is
>>>> > used over tor.
>>>> >
>>>> > There are a few limitations that ought to be mentioned:
>>>> > 1. After user A sends a private payment to user B, user A will know
>>>> what
>>>> > the spend proof is going to be when B decides to spend the coin.
>>>> >  Therefore, A will know when the coin was spent by B, but nothing
>>>> more.
>>>> >  Neither the new owner of the coin, nor its future movements will be
>>>> known
>>>> > to A.
>>>> > 2. Over time, larger outputs will likely be split into many smaller
>>>> > outputs, whose amounts are not much greater than their denominations.
>>>> > You?ll have to combine more inputs to send the same amount.  When you
>>>> want
>>>> > to send a very large amount that is much greater than the highest
>>>> available
>>>> > denomination, you?ll have to send a lot of private transactions, your
>>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>>>> > number will roughly indicate the total amount.  This kind of privacy
>>>> > leakage, however it applies to a small number of users, is easy to
>>>> avoid by
>>>> > using multiple addresses and storing a relatively small amount on each
>>>> > address.
>>>> > 3. Exchanges and large merchants will likely accumulate large coin
>>>> > histories.  Although fragmented, far from complete, and likely
>>>> outdated, it
>>>> > is still something to bear in mind.
>>>> >
>>>> > No hard or soft fork is required, BBC is just a separate privacy
>>>> preserving
>>>> > currency on top of bitcoin blockchain, and the same private keys and
>>>> > addresses are used for both BBC and the base currency BTC.  Every BCC
>>>> > transaction must be enclosed into by a small BTC transaction that
>>>> stores
>>>> > the OP_RETURNs and pays for the fees.
>>>> >
>>>> > Are there any flaws in this design?
>>>> >
>>>> > Originally posted to BCT
>>>> https://bitcointalk.org/index.php?topic=1574508.0,
>>>> > but got no feedback so far, apparently everybody was consumed with
>>>> bitfinex
>>>> > drama and now mimblewimble.
>>>> >
>>>> > Tony
>>>>
>>>> > _______________________________________________
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>> --
>>>> Henning Kopp
>>>> Institute of Distributed Systems
>>>> Ulm University, Germany
>>>>
>>>> Office: O27 - 3402
>>>> Phone: +49 731 50-24138
>>>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/00d83f50/attachment-0001.html>

From macwhyte at gmail.com  Tue Aug  9 00:18:21 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Tue, 09 Aug 2016 00:18:21 +0000
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
Message-ID: <CAH+Axy7BAC14eGugDVsqkRv+XU+5dL4AAv_kb7PSi61825E70w@mail.gmail.com>

One more thought about why verification by miners may be needed.

Let's say Alice sends Bob a transaction, generating output C.

A troll, named Timothy, broadcasts a transaction with a random hash,
referencing C's output as its spend proof. The miners can't tell if it's
valid or not, and so they include the transaction in a block. Now Bob's
money is useless, because everyone can see the spend proof referenced and
thinks it has already been spent, even though the transaction that claims
it isn't valid.

Did I miss something that protects against this?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991 at gmail.com> wrote:

> The whole point is in preventing every third party, including miners, from
> seeing the details of what is being spent and how.  The burden of
> verification is shifted to the owners of the coin (which is fair).
>
> In fact we could have miners recognize spend proofs and check that the
> same spend proof is not entered into the blockchain more than once (which
> would be a sign of double spend), but it is not required.  The coin owners
> can already do that themselves.
>
> 2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
>
>> Wouldn't you lose the ability to assume transactions in the blockchain
>> are verified as valid, since miners can't see the details of what is being
>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>> removing it you're creating an altcoin different enough to not be connected
>> to/supported by the main bitcoin project.
>>
>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Henning,
>>>
>>> 1. The fees are paid by the enclosing BTC transaction.
>>> 2. The hash is encoded into an OP_RETURN.
>>>
>>> > Regarding the blinding factor, I think you could just use HMAC.
>>> How exactly?
>>>
>>> Tony
>>>
>>>
>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>>>
>>>> Hi Tony,
>>>>
>>>> I see some issues in your protocol.
>>>>
>>>> 1. How are mining fees handled?
>>>>
>>>> 2. Assume Alice sends Bob some Coins together with their history and
>>>> Bob checks that the history is correct. How does the hash of the txout
>>>> find its way into the blockchain?
>>>>
>>>> Regarding the blinding factor, I think you could just use HMAC.
>>>>
>>>> All the best
>>>> Henning
>>>>
>>>>
>>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>>> bitcoin-dev wrote:
>>>> > This is a proposal about hiding the entire content of bitcoin
>>>> > transactions.  It goes farther than CoinJoin and ring signatures,
>>>> which
>>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>>> which
>>>> > only hide the amounts.
>>>> >
>>>> > The central idea of the proposed design is to hide the entire inputs
>>>> and
>>>> > outputs, and publish only the hash of inputs and outputs in the
>>>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>>>> > inputs and outputs is sent directly to the payee via a private
>>>> message, and
>>>> > never goes into the blockchain.  The payee then calculates the hash
>>>> and
>>>> > looks it up in the blockchain to verify that the hash was indeed
>>>> published
>>>> > by the payer.
>>>> >
>>>> > Since the plaintext of the transaction is not published to the public
>>>> > blockchain, all validation work has to be done only by the user who
>>>> > receives the payment.
>>>> >
>>>> > To protect against double-spends, the payer also has to publish
>>>> another
>>>> > hash, which is the hash of the output being spent.  We?ll call this
>>>> hash *spend
>>>> > proof*.  Since the spend proof depends solely on the output being
>>>> spent,
>>>> > any attempt to spend the same output again will produce exactly the
>>>> same
>>>> > spend proof, and the payee will be able to see that, and will reject
>>>> the
>>>> > payment.  If there are several outputs consumed by the same
>>>> transaction,
>>>> > the payer has to publish several spend proofs.
>>>> >
>>>> > To prove that the outputs being spent are valid, the payer also has
>>>> to send
>>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>>> the
>>>> > plaintexts of even earlier transactions that produced the outputs
>>>> spent in
>>>> > those transactions, and so on, up until the issue (similar to
>>>> coinbase)
>>>> > transactions that created the initial private coins.  Each new owner
>>>> of the
>>>> > coin will have to store its entire history, and when he spends the
>>>> coin, he
>>>> > forwards the entire history to the next owner and extends it with his
>>>> own
>>>> > transaction.
>>>> >
>>>> > If we apply the existing bitcoin design that allows multiple inputs
>>>> and
>>>> > multiple outputs per transaction, the history of ownership transfers
>>>> would
>>>> > grow exponentially.  Indeed, if we take any regular bitcoin output
>>>> and try
>>>> > to track its history back to coinbase, our history will branch every
>>>> time
>>>> > we see a transaction that has more than one input (which is not
>>>> uncommon).
>>>> > After such a transaction (remember, we are traveling back in time),
>>>> we?ll
>>>> > have to track two or more histories, for each respective input.  Those
>>>> > histories will branch again, and the total number of history entries
>>>> grows
>>>> > exponentially.  For example, if every transaction had exactly two
>>>> inputs,
>>>> > the size of history would grow as 2^N where N is the number of steps
>>>> back
>>>> > in history.
>>>> >
>>>> > To avoid such rapid growth of ownership history (which is not only
>>>> > inconvenient to move, but also exposes too much private information
>>>> about
>>>> > previous owners of all the contributing coins), we will require each
>>>> > private transaction to have exactly one input (i.e. to consume
>>>> exactly one
>>>> > previous output).  This means that when we track a coin?s history
>>>> back in
>>>> > time, it will no longer branch.  It will grow linearly with the
>>>> number of
>>>> > transfers of ownership.  If a user wants to combine several inputs,
>>>> he will
>>>> > have to send them as separate private transactions (technically,
>>>> several
>>>> > OP_RETURNs, which can be included in a single regular bitcoin
>>>> transaction).
>>>> >
>>>> > Thus, we are now forbidding any coin merges but still allowing coin
>>>> > splits.  To avoid ultimate splitting into the dust, we will also
>>>> require
>>>> > that all private coins be issued in one of a small number of
>>>> > denominations.  Only integer number of ?banknotes? can be
>>>> transferred, the
>>>> > input and output amounts must therefore be divisible by the
>>>> denomination.
>>>> > For example, an input of amount 700, denomination 100, can be split
>>>> into
>>>> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
>>>> > payer has to pick the unspent outputs of the highest denomination
>>>> first,
>>>> > then the second highest, and so on, like we already do when we pay in
>>>> cash.
>>>> >
>>>> > With fixed denominations and one input per transaction, coin histories
>>>> > still grow, but only linearly, which should not be a concern in
>>>> regard to
>>>> > scalability given that all relevant computing resources still grow
>>>> > exponentially.  The histories need to be stored only by the current
>>>> owner
>>>> > of the coin, not every bitcoin node.  This is a fairer allocation of
>>>> > costs.  Regarding privacy, coin histories do expose private
>>>> transactions
>>>> > (or rather parts thereof, since a typical payment will likely consist
>>>> of
>>>> > several transactions due to one-input-per-transaction rule) of past
>>>> coin
>>>> > owners to the future ones, and that exposure grows linearly with
>>>> time, but
>>>> > it is still much much better than having every transaction
>>>> immediately on
>>>> > the public blockchain.  Also, the value of this information for
>>>> potential
>>>> > adversaries arguably decreases with time.
>>>> >
>>>> > There is one technical nuance that I omitted above to avoid
>>>> distraction.
>>>> >  Unlike regular bitcoin transactions, every output in a private
>>>> payment
>>>> > must also include a blinding factor, which is just a random string.
>>>> When
>>>> > the output is spent, the corresponding spend proof will therefore
>>>> depend on
>>>> > this blinding factor (remember that spend proof is just a hash of the
>>>> > output).  Without a blinding factor, it would be feasible to
>>>> pre-image the
>>>> > spend proof and reveal the output being spent as the search space of
>>>> all
>>>> > possible outputs is rather small.
>>>> >
>>>> > To issue the new private coin, one can burn regular BTC by sending it
>>>> to
>>>> > one of several unspendable bitcoin addresses, one address per
>>>> denomination.
>>>> >  Burning BTC would entitle one to an equal amount of the new private
>>>> coin,
>>>> > let?s call it *black bitcoin*, or *BBC*.
>>>> >
>>>> > Then BBC would be transferred from user to user by:
>>>> > 1. creating a private transaction, which consists of one input and
>>>> several
>>>> > outputs;
>>>> > 2. storing the hash of the transaction and the spend proof of the
>>>> consumed
>>>> > output into the blockchain in an OP_RETURN (the sender pays the
>>>> > corresponding fees in regular BTC)
>>>> > 3. sending the transaction, together with the history leading to its
>>>> input,
>>>> > directly to the payee over a private communication channel.  The first
>>>> > entry of the history must be a bitcoin transaction that burned BTC to
>>>> issue
>>>> > an equal amount of BCC.
>>>> >
>>>> > To verify the payment, the payee:
>>>> > 1. makes sure that the amount of the input matches the sum of
>>>> outputs, and
>>>> > all are divisible by the denomination
>>>> > 2. calculates the hash of the private transaction
>>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>>>> > payee.  If there is more than one, the one that comes in the earlier
>>>> block
>>>> > prevails.
>>>> > 4. calculates the spend proof and makes sure that it is included in
>>>> the
>>>> > same OP_RETURN
>>>> > 5. makes sure the same spend proof is not included anywhere in the
>>>> same or
>>>> > earlier blocks (that is, the coin was not spent before).  Only
>>>> transactions
>>>> > by the same author are searched.
>>>> > 6. repeats the same steps for every entry in the history, except the
>>>> first
>>>> > entry, which should be a valid burning transaction.
>>>> >
>>>> > To facilitate exchange of private transaction data, the bitcoin
>>>> network
>>>> > protocol can be extended with a new message type.  Unfortunately, it
>>>> lacks
>>>> > encryption, hence private payments are really private only when
>>>> bitcoin is
>>>> > used over tor.
>>>> >
>>>> > There are a few limitations that ought to be mentioned:
>>>> > 1. After user A sends a private payment to user B, user A will know
>>>> what
>>>> > the spend proof is going to be when B decides to spend the coin.
>>>> >  Therefore, A will know when the coin was spent by B, but nothing
>>>> more.
>>>> >  Neither the new owner of the coin, nor its future movements will be
>>>> known
>>>> > to A.
>>>> > 2. Over time, larger outputs will likely be split into many smaller
>>>> > outputs, whose amounts are not much greater than their denominations.
>>>> > You?ll have to combine more inputs to send the same amount.  When you
>>>> want
>>>> > to send a very large amount that is much greater than the highest
>>>> available
>>>> > denomination, you?ll have to send a lot of private transactions, your
>>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>>>> > number will roughly indicate the total amount.  This kind of privacy
>>>> > leakage, however it applies to a small number of users, is easy to
>>>> avoid by
>>>> > using multiple addresses and storing a relatively small amount on each
>>>> > address.
>>>> > 3. Exchanges and large merchants will likely accumulate large coin
>>>> > histories.  Although fragmented, far from complete, and likely
>>>> outdated, it
>>>> > is still something to bear in mind.
>>>> >
>>>> > No hard or soft fork is required, BBC is just a separate privacy
>>>> preserving
>>>> > currency on top of bitcoin blockchain, and the same private keys and
>>>> > addresses are used for both BBC and the base currency BTC.  Every BCC
>>>> > transaction must be enclosed into by a small BTC transaction that
>>>> stores
>>>> > the OP_RETURNs and pays for the fees.
>>>> >
>>>> > Are there any flaws in this design?
>>>> >
>>>> > Originally posted to BCT
>>>> https://bitcointalk.org/index.php?topic=1574508.0,
>>>> > but got no feedback so far, apparently everybody was consumed with
>>>> bitfinex
>>>> > drama and now mimblewimble.
>>>> >
>>>> > Tony
>>>>
>>>> > _______________________________________________
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>> --
>>>> Henning Kopp
>>>> Institute of Distributed Systems
>>>> Ulm University, Germany
>>>>
>>>> Office: O27 - 3402
>>>> Phone: +49 731 50-24138
>>>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/09443165/attachment-0001.html>

From pete at petertodd.org  Tue Aug  9 00:46:33 2016
From: pete at petertodd.org (Peter Todd)
Date: Mon, 8 Aug 2016 17:46:33 -0700
Subject: [bitcoin-dev] BIP draft: HTLC transactions
In-Reply-To: <201607200617.40917.luke@dashjr.org>
References: <CAKazn3mKUMMz0wyqTsgbkd4mBLgvG2PXziXhgRTi4hX_ApbPhg@mail.gmail.com>
	<20160720054654.GA1420@fedora-21-dvm>
	<201607200617.40917.luke@dashjr.org>
Message-ID: <20160809004633.GA1653@fedora-21-dvm>

On Wed, Jul 20, 2016 at 06:17:39AM +0000, Luke Dashjr wrote:
> On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote:
> > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote:
> > > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
> > > in Bitcoin.
> > > 
> > > HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV
> > > can be used to recover your funds if the other party is not cooperative.
> > > These
> > > 
> > > scripts take the following general form:
> > >     [HASHOP] <digest> OP_EQUAL
> > >     OP_IF
> > >     
> > >         <seller pubkey>
> > >     
> > >     OP_ELSE
> > >     
> > >         <num> [TIMEOUTOP] OP_DROP <buyer pubkey>
> > >     
> > >     OP_ENDIF
> > >     OP_CHECKSIG
> > 
> > Note that because you're hashing the top item on the stack regardless
> > scriptSig's that satisfy HTLC's are malleable: that top stack item can be
> > changed anything in the digest-not-provided case and the script still
> > passes.
> 
> OP_SIZE
> OP_IF
>   [HASHOP] <digest> OP_EQUALVERIFY
>   <seller pubkey>
> OP_ELSE
>   <num> [TIMEOUTOP]
>   <buyer pubkey>
> OP_ENDIF
> OP_CHECKSIG

Ha! That's brilliant; good job.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/2402c688/attachment.sig>

From pete at petertodd.org  Tue Aug  9 02:21:29 2016
From: pete at petertodd.org (Peter Todd)
Date: Mon, 8 Aug 2016 19:21:29 -0700
Subject: [bitcoin-dev] *Changing* the blocksize limit
In-Reply-To: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>
References: <CAAcC9ysZdnzb9HwN_pUcdws8Dvtd5xpzoPbyHP1nNew=LeTDHg@mail.gmail.com>
Message-ID: <20160809022129.GB1858@fedora-21-dvm>

On Sat, Aug 06, 2016 at 07:15:22AM -0700, Chris Priest via bitcoin-dev wrote:
> If the blocksize limit is to be changed to a block output limit, the
> number the limit is set to should be roughly the amount of outputs
> that are found in 1MB blocks today. This way, the change should be

The largest output on testnet is a bit under 1MB, and encodes a certain
well-known love song...

In many circumstances(1) miners have an incentive to create larger blocks that
take their competitors longer to receive and validate, so protocol-level block
limits need to take all these potential DoS vectors into account; serialized
size is one of the most fundemental things that needs to be limited.

> considered non-controversial. I think its silly that some people think
> its a good thing to keep usage restricted, but again, it is what it
> is.

As mentioned above, and explained in detail in my recent blog post(1),
restrictions are needed to keep a level playing field between all miners.

1) https://petertodd.org/2016/block-publication-incentives-for-miners

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/d79e1812/attachment.sig>

From danielhoffman699 at gmail.com  Tue Aug  9 01:50:00 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Mon, 8 Aug 2016 20:50:00 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
Message-ID: <CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>

It wouldn't be feasible in the vast majority of cases, but I can't think of
a reason why it can't be built into the standard.

On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Would it be feasible to transmit an entire BIP21 URI as audio? If you were
> to encode any extra information (such as amount), it would be useful to
> include a checksum for the entire message. This checksum could possibly be
> used instead of the checksum in the address.
>
> Trevin
>
> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Daniel,
>>    Thanks for proposing this.  I think this could have some useful use
>> cases as you state.  I was wondering what you would think to adding some
>> additional tones to optionally denote an amount (in satoshis?).
>>
>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>
>> Justin
>>
>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> This is my BIP idea: a fast, robust, and standardized for representing
>>> Bitcoin addresses over audio. It takes the binary representation of the
>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>> (depending on type, 2 bit only for low quality audio like american
>>> telephone lines), and generates a tone based upon that value. This started
>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>> having a Shazam-esque app (or a media player with this capability) that
>>> gives me an address automatically would be wonderful for both the consumer
>>> and producer. Comes with error correction built into the protocol
>>>
>>> You can see the full specification of the BIP on my GitHub page (
>>> https://github.com/Dako300/BIP-0153).
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>>
>> --
>>
>> Justin W. Newton
>> Founder/CEO
>> Netki, Inc.
>>
>> justin at netki.com
>> +1.818.261.4248
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/6b858c35/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160808/6b858c35/attachment-0001.tiff>

From tony991 at gmail.com  Mon Aug  8 23:42:03 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Tue, 9 Aug 2016 02:42:03 +0300
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
Message-ID: <CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>

The whole point is in preventing every third party, including miners, from
seeing the details of what is being spent and how.  The burden of
verification is shifted to the owners of the coin (which is fair).

In fact we could have miners recognize spend proofs and check that the same
spend proof is not entered into the blockchain more than once (which would
be a sign of double spend), but it is not required.  The coin owners can
already do that themselves.

2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:

> Wouldn't you lose the ability to assume transactions in the blockchain are
> verified as valid, since miners can't see the details of what is being
> spent and how? I feel like this ability is bitcoin's greatest asset, and by
> removing it you're creating an altcoin different enough to not be connected
> to/supported by the main bitcoin project.
>
> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi Henning,
>>
>> 1. The fees are paid by the enclosing BTC transaction.
>> 2. The hash is encoded into an OP_RETURN.
>>
>> > Regarding the blinding factor, I think you could just use HMAC.
>> How exactly?
>>
>> Tony
>>
>>
>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>>
>>> Hi Tony,
>>>
>>> I see some issues in your protocol.
>>>
>>> 1. How are mining fees handled?
>>>
>>> 2. Assume Alice sends Bob some Coins together with their history and
>>> Bob checks that the history is correct. How does the hash of the txout
>>> find its way into the blockchain?
>>>
>>> Regarding the blinding factor, I think you could just use HMAC.
>>>
>>> All the best
>>> Henning
>>>
>>>
>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>> bitcoin-dev wrote:
>>> > This is a proposal about hiding the entire content of bitcoin
>>> > transactions.  It goes farther than CoinJoin and ring signatures, which
>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>> which
>>> > only hide the amounts.
>>> >
>>> > The central idea of the proposed design is to hide the entire inputs
>>> and
>>> > outputs, and publish only the hash of inputs and outputs in the
>>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>>> > inputs and outputs is sent directly to the payee via a private
>>> message, and
>>> > never goes into the blockchain.  The payee then calculates the hash and
>>> > looks it up in the blockchain to verify that the hash was indeed
>>> published
>>> > by the payer.
>>> >
>>> > Since the plaintext of the transaction is not published to the public
>>> > blockchain, all validation work has to be done only by the user who
>>> > receives the payment.
>>> >
>>> > To protect against double-spends, the payer also has to publish another
>>> > hash, which is the hash of the output being spent.  We?ll call this
>>> hash *spend
>>> > proof*.  Since the spend proof depends solely on the output being
>>> spent,
>>> > any attempt to spend the same output again will produce exactly the
>>> same
>>> > spend proof, and the payee will be able to see that, and will reject
>>> the
>>> > payment.  If there are several outputs consumed by the same
>>> transaction,
>>> > the payer has to publish several spend proofs.
>>> >
>>> > To prove that the outputs being spent are valid, the payer also has to
>>> send
>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>> the
>>> > plaintexts of even earlier transactions that produced the outputs
>>> spent in
>>> > those transactions, and so on, up until the issue (similar to coinbase)
>>> > transactions that created the initial private coins.  Each new owner
>>> of the
>>> > coin will have to store its entire history, and when he spends the
>>> coin, he
>>> > forwards the entire history to the next owner and extends it with his
>>> own
>>> > transaction.
>>> >
>>> > If we apply the existing bitcoin design that allows multiple inputs and
>>> > multiple outputs per transaction, the history of ownership transfers
>>> would
>>> > grow exponentially.  Indeed, if we take any regular bitcoin output and
>>> try
>>> > to track its history back to coinbase, our history will branch every
>>> time
>>> > we see a transaction that has more than one input (which is not
>>> uncommon).
>>> > After such a transaction (remember, we are traveling back in time),
>>> we?ll
>>> > have to track two or more histories, for each respective input.  Those
>>> > histories will branch again, and the total number of history entries
>>> grows
>>> > exponentially.  For example, if every transaction had exactly two
>>> inputs,
>>> > the size of history would grow as 2^N where N is the number of steps
>>> back
>>> > in history.
>>> >
>>> > To avoid such rapid growth of ownership history (which is not only
>>> > inconvenient to move, but also exposes too much private information
>>> about
>>> > previous owners of all the contributing coins), we will require each
>>> > private transaction to have exactly one input (i.e. to consume exactly
>>> one
>>> > previous output).  This means that when we track a coin?s history back
>>> in
>>> > time, it will no longer branch.  It will grow linearly with the number
>>> of
>>> > transfers of ownership.  If a user wants to combine several inputs, he
>>> will
>>> > have to send them as separate private transactions (technically,
>>> several
>>> > OP_RETURNs, which can be included in a single regular bitcoin
>>> transaction).
>>> >
>>> > Thus, we are now forbidding any coin merges but still allowing coin
>>> > splits.  To avoid ultimate splitting into the dust, we will also
>>> require
>>> > that all private coins be issued in one of a small number of
>>> > denominations.  Only integer number of ?banknotes? can be transferred,
>>> the
>>> > input and output amounts must therefore be divisible by the
>>> denomination.
>>> > For example, an input of amount 700, denomination 100, can be split
>>> into
>>> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
>>> > payer has to pick the unspent outputs of the highest denomination
>>> first,
>>> > then the second highest, and so on, like we already do when we pay in
>>> cash.
>>> >
>>> > With fixed denominations and one input per transaction, coin histories
>>> > still grow, but only linearly, which should not be a concern in regard
>>> to
>>> > scalability given that all relevant computing resources still grow
>>> > exponentially.  The histories need to be stored only by the current
>>> owner
>>> > of the coin, not every bitcoin node.  This is a fairer allocation of
>>> > costs.  Regarding privacy, coin histories do expose private
>>> transactions
>>> > (or rather parts thereof, since a typical payment will likely consist
>>> of
>>> > several transactions due to one-input-per-transaction rule) of past
>>> coin
>>> > owners to the future ones, and that exposure grows linearly with time,
>>> but
>>> > it is still much much better than having every transaction immediately
>>> on
>>> > the public blockchain.  Also, the value of this information for
>>> potential
>>> > adversaries arguably decreases with time.
>>> >
>>> > There is one technical nuance that I omitted above to avoid
>>> distraction.
>>> >  Unlike regular bitcoin transactions, every output in a private payment
>>> > must also include a blinding factor, which is just a random string.
>>> When
>>> > the output is spent, the corresponding spend proof will therefore
>>> depend on
>>> > this blinding factor (remember that spend proof is just a hash of the
>>> > output).  Without a blinding factor, it would be feasible to pre-image
>>> the
>>> > spend proof and reveal the output being spent as the search space of
>>> all
>>> > possible outputs is rather small.
>>> >
>>> > To issue the new private coin, one can burn regular BTC by sending it
>>> to
>>> > one of several unspendable bitcoin addresses, one address per
>>> denomination.
>>> >  Burning BTC would entitle one to an equal amount of the new private
>>> coin,
>>> > let?s call it *black bitcoin*, or *BBC*.
>>> >
>>> > Then BBC would be transferred from user to user by:
>>> > 1. creating a private transaction, which consists of one input and
>>> several
>>> > outputs;
>>> > 2. storing the hash of the transaction and the spend proof of the
>>> consumed
>>> > output into the blockchain in an OP_RETURN (the sender pays the
>>> > corresponding fees in regular BTC)
>>> > 3. sending the transaction, together with the history leading to its
>>> input,
>>> > directly to the payee over a private communication channel.  The first
>>> > entry of the history must be a bitcoin transaction that burned BTC to
>>> issue
>>> > an equal amount of BCC.
>>> >
>>> > To verify the payment, the payee:
>>> > 1. makes sure that the amount of the input matches the sum of outputs,
>>> and
>>> > all are divisible by the denomination
>>> > 2. calculates the hash of the private transaction
>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>>> > payee.  If there is more than one, the one that comes in the earlier
>>> block
>>> > prevails.
>>> > 4. calculates the spend proof and makes sure that it is included in the
>>> > same OP_RETURN
>>> > 5. makes sure the same spend proof is not included anywhere in the
>>> same or
>>> > earlier blocks (that is, the coin was not spent before).  Only
>>> transactions
>>> > by the same author are searched.
>>> > 6. repeats the same steps for every entry in the history, except the
>>> first
>>> > entry, which should be a valid burning transaction.
>>> >
>>> > To facilitate exchange of private transaction data, the bitcoin network
>>> > protocol can be extended with a new message type.  Unfortunately, it
>>> lacks
>>> > encryption, hence private payments are really private only when
>>> bitcoin is
>>> > used over tor.
>>> >
>>> > There are a few limitations that ought to be mentioned:
>>> > 1. After user A sends a private payment to user B, user A will know
>>> what
>>> > the spend proof is going to be when B decides to spend the coin.
>>> >  Therefore, A will know when the coin was spent by B, but nothing more.
>>> >  Neither the new owner of the coin, nor its future movements will be
>>> known
>>> > to A.
>>> > 2. Over time, larger outputs will likely be split into many smaller
>>> > outputs, whose amounts are not much greater than their denominations.
>>> > You?ll have to combine more inputs to send the same amount.  When you
>>> want
>>> > to send a very large amount that is much greater than the highest
>>> available
>>> > denomination, you?ll have to send a lot of private transactions, your
>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>>> > number will roughly indicate the total amount.  This kind of privacy
>>> > leakage, however it applies to a small number of users, is easy to
>>> avoid by
>>> > using multiple addresses and storing a relatively small amount on each
>>> > address.
>>> > 3. Exchanges and large merchants will likely accumulate large coin
>>> > histories.  Although fragmented, far from complete, and likely
>>> outdated, it
>>> > is still something to bear in mind.
>>> >
>>> > No hard or soft fork is required, BBC is just a separate privacy
>>> preserving
>>> > currency on top of bitcoin blockchain, and the same private keys and
>>> > addresses are used for both BBC and the base currency BTC.  Every BCC
>>> > transaction must be enclosed into by a small BTC transaction that
>>> stores
>>> > the OP_RETURNs and pays for the fees.
>>> >
>>> > Are there any flaws in this design?
>>> >
>>> > Originally posted to BCT https://bitcointalk.org/index.
>>> php?topic=1574508.0,
>>> > but got no feedback so far, apparently everybody was consumed with
>>> bitfinex
>>> > drama and now mimblewimble.
>>> >
>>> > Tony
>>>
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>> --
>>> Henning Kopp
>>> Institute of Distributed Systems
>>> Ulm University, Germany
>>>
>>> Office: O27 - 3402
>>> Phone: +49 731 50-24138
>>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/9191ca6a/attachment-0001.html>

From henning.kopp at uni-ulm.de  Tue Aug  9 07:26:35 2016
From: henning.kopp at uni-ulm.de (Henning Kopp)
Date: Tue, 9 Aug 2016 09:26:35 +0200
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
Message-ID: <20160809072635.GA2178@banane.informatik.uni-ulm.de>

Hi Tony,

> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?

I am not entirely sure if this works. You wrote:

> There is one technical nuance that I omitted above to avoid distraction.
>  Unlike regular bitcoin transactions, every output in a private payment
> must also include a blinding factor, which is just a random string.  When
> the output is spent, the corresponding spend proof will therefore depend on
> this blinding factor (remember that spend proof is just a hash of the
> output).  Without a blinding factor, it would be feasible to pre-image the
> spend proof and reveal the output being spent as the search space of all
> possible outputs is rather small.

Instead of a hash function you may use a keyed hash function (HMAC) where
the key is just the random string. They key needs to be stored in the
history of the coin to allow for verification.

Best
Henning

On Mon, Aug 08, 2016 at 07:03:28PM +0300, Tony Churyumoff wrote:
> Hi Henning,
> 
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
> 
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
> 
> Tony
> 
> 
> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
> 
> > Hi Tony,
> >
> > I see some issues in your protocol.
> >
> > 1. How are mining fees handled?
> >
> > 2. Assume Alice sends Bob some Coins together with their history and
> > Bob checks that the history is correct. How does the hash of the txout
> > find its way into the blockchain?
> >
> > Regarding the blinding factor, I think you could just use HMAC.
> >
> > All the best
> > Henning
> >
> >
> > On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> > wrote:
> > > This is a proposal about hiding the entire content of bitcoin
> > > transactions.  It goes farther than CoinJoin and ring signatures, which
> > > only obfuscate the transaction graph, and Confidential Transactions,
> > which
> > > only hide the amounts.
> > >
> > > The central idea of the proposed design is to hide the entire inputs and
> > > outputs, and publish only the hash of inputs and outputs in the
> > > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > > inputs and outputs is sent directly to the payee via a private message,
> > and
> > > never goes into the blockchain.  The payee then calculates the hash and
> > > looks it up in the blockchain to verify that the hash was indeed
> > published
> > > by the payer.
> > >
> > > Since the plaintext of the transaction is not published to the public
> > > blockchain, all validation work has to be done only by the user who
> > > receives the payment.
> > >
> > > To protect against double-spends, the payer also has to publish another
> > > hash, which is the hash of the output being spent.  We?ll call this hash
> > *spend
> > > proof*.  Since the spend proof depends solely on the output being spent,
> > > any attempt to spend the same output again will produce exactly the same
> > > spend proof, and the payee will be able to see that, and will reject the
> > > payment.  If there are several outputs consumed by the same transaction,
> > > the payer has to publish several spend proofs.
> > >
> > > To prove that the outputs being spent are valid, the payer also has to
> > send
> > > the plaintexts of the earlier transaction(s) that produced them, then the
> > > plaintexts of even earlier transactions that produced the outputs spent
> > in
> > > those transactions, and so on, up until the issue (similar to coinbase)
> > > transactions that created the initial private coins.  Each new owner of
> > the
> > > coin will have to store its entire history, and when he spends the coin,
> > he
> > > forwards the entire history to the next owner and extends it with his own
> > > transaction.
> > >
> > > If we apply the existing bitcoin design that allows multiple inputs and
> > > multiple outputs per transaction, the history of ownership transfers
> > would
> > > grow exponentially.  Indeed, if we take any regular bitcoin output and
> > try
> > > to track its history back to coinbase, our history will branch every time
> > > we see a transaction that has more than one input (which is not
> > uncommon).
> > > After such a transaction (remember, we are traveling back in time), we?ll
> > > have to track two or more histories, for each respective input.  Those
> > > histories will branch again, and the total number of history entries
> > grows
> > > exponentially.  For example, if every transaction had exactly two inputs,
> > > the size of history would grow as 2^N where N is the number of steps back
> > > in history.
> > >
> > > To avoid such rapid growth of ownership history (which is not only
> > > inconvenient to move, but also exposes too much private information about
> > > previous owners of all the contributing coins), we will require each
> > > private transaction to have exactly one input (i.e. to consume exactly
> > one
> > > previous output).  This means that when we track a coin?s history back in
> > > time, it will no longer branch.  It will grow linearly with the number of
> > > transfers of ownership.  If a user wants to combine several inputs, he
> > will
> > > have to send them as separate private transactions (technically, several
> > > OP_RETURNs, which can be included in a single regular bitcoin
> > transaction).
> > >
> > > Thus, we are now forbidding any coin merges but still allowing coin
> > > splits.  To avoid ultimate splitting into the dust, we will also require
> > > that all private coins be issued in one of a small number of
> > > denominations.  Only integer number of ?banknotes? can be transferred,
> > the
> > > input and output amounts must therefore be divisible by the denomination.
> > > For example, an input of amount 700, denomination 100, can be split into
> > > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
> > > payer has to pick the unspent outputs of the highest denomination first,
> > > then the second highest, and so on, like we already do when we pay in
> > cash.
> > >
> > > With fixed denominations and one input per transaction, coin histories
> > > still grow, but only linearly, which should not be a concern in regard to
> > > scalability given that all relevant computing resources still grow
> > > exponentially.  The histories need to be stored only by the current owner
> > > of the coin, not every bitcoin node.  This is a fairer allocation of
> > > costs.  Regarding privacy, coin histories do expose private transactions
> > > (or rather parts thereof, since a typical payment will likely consist of
> > > several transactions due to one-input-per-transaction rule) of past coin
> > > owners to the future ones, and that exposure grows linearly with time,
> > but
> > > it is still much much better than having every transaction immediately on
> > > the public blockchain.  Also, the value of this information for potential
> > > adversaries arguably decreases with time.
> > >
> > > There is one technical nuance that I omitted above to avoid distraction.
> > >  Unlike regular bitcoin transactions, every output in a private payment
> > > must also include a blinding factor, which is just a random string.  When
> > > the output is spent, the corresponding spend proof will therefore depend
> > on
> > > this blinding factor (remember that spend proof is just a hash of the
> > > output).  Without a blinding factor, it would be feasible to pre-image
> > the
> > > spend proof and reveal the output being spent as the search space of all
> > > possible outputs is rather small.
> > >
> > > To issue the new private coin, one can burn regular BTC by sending it to
> > > one of several unspendable bitcoin addresses, one address per
> > denomination.
> > >  Burning BTC would entitle one to an equal amount of the new private
> > coin,
> > > let?s call it *black bitcoin*, or *BBC*.
> > >
> > > Then BBC would be transferred from user to user by:
> > > 1. creating a private transaction, which consists of one input and
> > several
> > > outputs;
> > > 2. storing the hash of the transaction and the spend proof of the
> > consumed
> > > output into the blockchain in an OP_RETURN (the sender pays the
> > > corresponding fees in regular BTC)
> > > 3. sending the transaction, together with the history leading to its
> > input,
> > > directly to the payee over a private communication channel.  The first
> > > entry of the history must be a bitcoin transaction that burned BTC to
> > issue
> > > an equal amount of BCC.
> > >
> > > To verify the payment, the payee:
> > > 1. makes sure that the amount of the input matches the sum of outputs,
> > and
> > > all are divisible by the denomination
> > > 2. calculates the hash of the private transaction
> > > 3. looks up an OP_RETURN that includes this hash and is signed by the
> > > payee.  If there is more than one, the one that comes in the earlier
> > block
> > > prevails.
> > > 4. calculates the spend proof and makes sure that it is included in the
> > > same OP_RETURN
> > > 5. makes sure the same spend proof is not included anywhere in the same
> > or
> > > earlier blocks (that is, the coin was not spent before).  Only
> > transactions
> > > by the same author are searched.
> > > 6. repeats the same steps for every entry in the history, except the
> > first
> > > entry, which should be a valid burning transaction.
> > >
> > > To facilitate exchange of private transaction data, the bitcoin network
> > > protocol can be extended with a new message type.  Unfortunately, it
> > lacks
> > > encryption, hence private payments are really private only when bitcoin
> > is
> > > used over tor.
> > >
> > > There are a few limitations that ought to be mentioned:
> > > 1. After user A sends a private payment to user B, user A will know what
> > > the spend proof is going to be when B decides to spend the coin.
> > >  Therefore, A will know when the coin was spent by B, but nothing more.
> > >  Neither the new owner of the coin, nor its future movements will be
> > known
> > > to A.
> > > 2. Over time, larger outputs will likely be split into many smaller
> > > outputs, whose amounts are not much greater than their denominations.
> > > You?ll have to combine more inputs to send the same amount.  When you
> > want
> > > to send a very large amount that is much greater than the highest
> > available
> > > denomination, you?ll have to send a lot of private transactions, your
> > > bitcoin transaction with so many OP_RETURNs will stand out, and their
> > > number will roughly indicate the total amount.  This kind of privacy
> > > leakage, however it applies to a small number of users, is easy to avoid
> > by
> > > using multiple addresses and storing a relatively small amount on each
> > > address.
> > > 3. Exchanges and large merchants will likely accumulate large coin
> > > histories.  Although fragmented, far from complete, and likely outdated,
> > it
> > > is still something to bear in mind.
> > >
> > > No hard or soft fork is required, BBC is just a separate privacy
> > preserving
> > > currency on top of bitcoin blockchain, and the same private keys and
> > > addresses are used for both BBC and the base currency BTC.  Every BCC
> > > transaction must be enclosed into by a small BTC transaction that stores
> > > the OP_RETURNs and pays for the fees.
> > >
> > > Are there any flaws in this design?
> > >
> > > Originally posted to BCT https://bitcointalk.org/index.
> > php?topic=1574508.0,
> > > but got no feedback so far, apparently everybody was consumed with
> > bitfinex
> > > drama and now mimblewimble.
> > >
> > > Tony
> >
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> > --
> > Henning Kopp
> > Institute of Distributed Systems
> > Ulm University, Germany
> >
> > Office: O27 - 3402
> > Phone: +49 731 50-24138
> > Web: http://www.uni-ulm.de/in/vs/~kopp
> >

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

From dev at jonasschnelli.ch  Tue Aug  9 10:02:06 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Tue, 9 Aug 2016 12:02:06 +0200
Subject: [bitcoin-dev] Authentication BIP
In-Reply-To: <57A8C76D.1080405@AndySchroder.com>
References: <57A89EA3.4020101@jonasschnelli.ch>
	<57A8BCD9.7050402@AndySchroder.com>
	<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
	<57A8C76D.1080405@AndySchroder.com>
Message-ID: <57A9AA1E.9050302@jonasschnelli.ch>

Hi Andy

>>
>>> Does openssh have this same problem?
>> No. OpenSSH doesn't make an effort to protect the privacy of its users.
>>
>>> I'm assuming this could be parallelized very easily, so it is not a huge
>>> problem?
>> It's not a issue because we're not aware of any usecase where a node
>> would have a large list of authenticated peers.
>>
>>> Each peer can configure one identity-key (ECC, 32 bytes) per listening
>> network interface (IPv4, IPv6, tor).
>>
>> I'm not aware of any reason for this limitation to exist. A node
>> should be able to have as many listening identities as it wants, with
>> a similar cost to having a large authorized keys list.
>>
> 
> So you are saying that you agree with me that the original text needs to
> be revised slightly or I am just misinterpreting the original text?

Yes. I think this limitation could be removed.
A responding node can have ? in theory ? multiple identity-keys per
network interface (network interfaces is also confusing, because you
could run multiple bitcoind instances on the same interface with
different ports).

The BIP should just make clear, that it is probably wise, to use
different identity-keys for each network interface (ipv4, v6, tor).

I'll try to overhaul that part.

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/2de7eeaa/attachment.sig>

From danielhoffman699 at gmail.com  Tue Aug  9 23:06:20 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Tue, 9 Aug 2016 18:06:20 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
Message-ID: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>

I have updated the GitHub a lot (changed tones to be less chirpy, fixed
some smalls) and made a couple of samples (see attachment for MP3 and FLAC
of both tone tables, first 16 then 4). Is this good enough to warrant an
official BIP number? I haven't built a decoder yet, but it seems like the
encoder is working properly (looked at Audacity, seems like it is working),
and some people on reddit want to "allow for decoding experiments"
<https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>

What suggestions do you all have for it?

On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699 at gmail.com>
wrote:

> It wouldn't be feasible in the vast majority of cases, but I can't think
> of a reason why it can't be built into the standard.
>
> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>> were to encode any extra information (such as amount), it would be useful
>> to include a checksum for the entire message. This checksum could possibly
>> be used instead of the checksum in the address.
>>
>> Trevin
>>
>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Daniel,
>>>    Thanks for proposing this.  I think this could have some useful use
>>> cases as you state.  I was wondering what you would think to adding some
>>> additional tones to optionally denote an amount (in satoshis?).
>>>
>>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>>
>>> Justin
>>>
>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>> (depending on type, 2 bit only for low quality audio like american
>>>> telephone lines), and generates a tone based upon that value. This started
>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>> having a Shazam-esque app (or a media player with this capability) that
>>>> gives me an address automatically would be wonderful for both the consumer
>>>> and producer. Comes with error correction built into the protocol
>>>>
>>>> You can see the full specification of the BIP on my GitHub page (
>>>> https://github.com/Dako300/BIP-0153).
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Justin W. Newton
>>> Founder/CEO
>>> Netki, Inc.
>>>
>>> justin at netki.com
>>> +1.818.261.4248
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/e580ef48/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/e580ef48/attachment-0001.tiff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BIP_latest_custom_address.flac
Type: audio/flac
Size: 2484566 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/e580ef48/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BIP_latest_custom_address.mp3
Type: audio/mpeg
Size: 585142 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/e580ef48/attachment-0001.mp3>

From jannes.faber at gmail.com  Wed Aug 10 00:17:35 2016
From: jannes.faber at gmail.com (Jannes Faber)
Date: Wed, 10 Aug 2016 02:17:35 +0200
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
Message-ID: <CABeL=0hrGpSZx+Y5vAKSOoZMrpZ3OgWSbdq_Sj-PWSt0j_H23Q@mail.gmail.com>

Wow. No value judgement, but 1980 called, they want their radio broadcast
for analogue modems back. Both very cool and very cringe worthy.

It sounds quite horrible tbh. Imagine this being as pervasive as bar and qr
codes. And it's as meaningful and unpleasant to the human ear as a qr code
is to the eye.

Please think of something like using a Mozart symphony as the carrier wave
onto which you modulate your signal. Let the notes last a little longer to
represent a 1 bit. Or change the tempo. Or add an echo. Make it so the
listener can interpret it as a generic not too annoying tune and not even
realise it's different every time without being an audiophile.

Maybe have a 100 different base tunes from mozart to hiphop so the user can
pick one suitable to their audience and context. Maybe have some that don't
interfere with human speech frequencies so narrator can keep talking right
over it.

I guess it may be tricky because you want your signal to survive
re-encoding as increased playback speeds.

Another consideration: you want a preamble that is very easy to detect, so
it doesn't cost a lot of CPU (battery) to have your podcast player
continuously scanning for these things.

Not sure all these wishes are possible at the same time, but surely there's
research around on some?.

On 10 Aug 2016 1:28 a.m., "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699 at gmail.com
> > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Daniel,
>>>>    Thanks for proposing this.  I think this could have some useful use
>>>> cases as you state.  I was wondering what you would think to adding some
>>>> additional tones to optionally denote an amount (in satoshis?).
>>>>
>>>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>>>
>>>> Justin
>>>>
>>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>>> (depending on type, 2 bit only for low quality audio like american
>>>>> telephone lines), and generates a tone based upon that value. This started
>>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>>> having a Shazam-esque app (or a media player with this capability) that
>>>>> gives me an address automatically would be wonderful for both the consumer
>>>>> and producer. Comes with error correction built into the protocol
>>>>>
>>>>> You can see the full specification of the BIP on my GitHub page (
>>>>> https://github.com/Dako300/BIP-0153).
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Justin W. Newton
>>>> Founder/CEO
>>>> Netki, Inc.
>>>>
>>>> justin at netki.com
>>>> +1.818.261.4248
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/a08aa8b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/a08aa8b1/attachment-0001.tiff>

From luke at dashjr.org  Wed Aug 10 00:36:04 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 10 Aug 2016 00:36:04 +0000
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
Message-ID: <201608100036.05930.luke@dashjr.org>

On Tuesday, August 09, 2016 11:06:20 PM Daniel Hoffman via bitcoin-dev wrote:
> Is this good enough to warrant an official BIP number?

Yeah, let's call it BIP 170.

Next step is to:
- Fix the BIP number in the file
- Format it in the usual BIP mediawiki format instead of markdown
- Add it to a fork of the bitcoin/bips git repository
- Open a pull request against bitcoin/bips

P.S. Why are telephones considered 4-tone? DTMF is 16-tone IIRC?

From luke at dashjr.org  Wed Aug 10 00:36:04 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 10 Aug 2016 00:36:04 +0000
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
Message-ID: <201608100036.05930.luke@dashjr.org>

On Tuesday, August 09, 2016 11:06:20 PM Daniel Hoffman via bitcoin-dev wrote:
> Is this good enough to warrant an official BIP number?

Yeah, let's call it BIP 170.

Next step is to:
- Fix the BIP number in the file
- Format it in the usual BIP mediawiki format instead of markdown
- Add it to a fork of the bitcoin/bips git repository
- Open a pull request against bitcoin/bips

P.S. Why are telephones considered 4-tone? DTMF is 16-tone IIRC?

From criley at gmail.com  Wed Aug 10 00:27:57 2016
From: criley at gmail.com (Chris Riley)
Date: Tue, 9 Aug 2016 20:27:57 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
Message-ID: <CAL5BAw2to-mx5YWCuks6n58Jy0+Q9qkJmUn92ddJ6g1GL1q=TA@mail.gmail.com>

Have you checked AudioModem out:
https://github.com/applidium/AudioModem

Or Chirp:
http://www.chirp.io/faq/

Or this Network World article (particularly the last portion on bitcoin):
http://www.networkworld.com/article/2956450/smartphones/sending-data-over-sound-revisited.html
and
http://www.networkworld.com/article/2689597/opensource-subnet/how-a-tv-network-is-being-used-to-move-financial-transactions.html

Instead of re-inventing the wheel, perhaps take a look at them.  Or at
least to see their design choices and rationale.

Cheers!


On Tue, Aug 9, 2016 at 7:06 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman <danielhoffman699 at gmail.com
> > wrote:
>
>> It wouldn't be feasible in the vast majority of cases, but I can't think
>> of a reason why it can't be built into the standard.
>>
>> On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Would it be feasible to transmit an entire BIP21 URI as audio? If you
>>> were to encode any extra information (such as amount), it would be useful
>>> to include a checksum for the entire message. This checksum could possibly
>>> be used instead of the checksum in the address.
>>>
>>> Trevin
>>>
>>> On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Daniel,
>>>>    Thanks for proposing this.  I think this could have some useful use
>>>> cases as you state.  I was wondering what you would think to adding some
>>>> additional tones to optionally denote an amount (in satoshis?).
>>>>
>>>> (FYI, actual link is here:  https://github.com/Dako300/BIP )
>>>>
>>>> Justin
>>>>
>>>> On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> This is my BIP idea: a fast, robust, and standardized for representing
>>>>> Bitcoin addresses over audio. It takes the binary representation of the
>>>>> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
>>>>> (depending on type, 2 bit only for low quality audio like american
>>>>> telephone lines), and generates a tone based upon that value. This started
>>>>> because I wanted an easy way to donate to podcasts that I listen to, and
>>>>> having a Shazam-esque app (or a media player with this capability) that
>>>>> gives me an address automatically would be wonderful for both the consumer
>>>>> and producer. Comes with error correction built into the protocol
>>>>>
>>>>> You can see the full specification of the BIP on my GitHub page (
>>>>> https://github.com/Dako300/BIP-0153).
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Justin W. Newton
>>>> Founder/CEO
>>>> Netki, Inc.
>>>>
>>>> justin at netki.com
>>>> +1.818.261.4248
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/231ed5cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/231ed5cb/attachment-0001.tiff>

From bztdlinux at gmail.com  Wed Aug 10 01:09:50 2016
From: bztdlinux at gmail.com (Thomas Daede)
Date: Tue, 9 Aug 2016 18:09:50 -0700
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
Message-ID: <aa41549b-b392-a225-26e1-2dcf4edfeb21@gmail.com>

If this is just encoding BIP-21 addresses, it is basically an "audio QR
code". In this case, does publishing it as a BIP still make sense? (Not
to imply that it doesn't, but it's something you should consider.)

Please look at existing implementations of audio modems when creating
your design. A lot of this work has been done many times before, so
there is a lot to learn from.

Your selected frequencies are harmonics of each other, meaning nonlinear
distortion will make detection more difficult. The Bell 202 and similar
modem standards chose AFSK frequencies to minimize interference.

Repeating a message multiple times is a very inefficient method of error
recovery. It works, but there may be better techniques, such as trellis
modulation or other convolutional codes.

Defining channel models to simulate your various use cases will help a
lot to determine if you have met your requirements.

- Thomas

P.S. I also briefly considered audio to exchange transactions with a
hardware wallet. Using GNU Radio made the implementation much easier.

On 08/09/2016 04:06 PM, Daniel Hoffman via bitcoin-dev wrote:
> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and
> FLAC of both tone tables, first 16 then 4). Is this good enough to
> warrant an official BIP number? I haven't built a decoder yet, but it
> seems like the encoder is working properly (looked at Audacity, seems
> like it is working), and some people on reddit want to "allow for
> decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
> 
> What suggestions do you all have for it?
> 
> On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman
> <danielhoffman699 at gmail.com <mailto:danielhoffman699 at gmail.com>> wrote:
> 
>     It wouldn't be feasible in the vast majority of cases, but I can't
>     think of a reason why it can't be built into the standard.
> 
>     On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev
>     <bitcoin-dev at lists.linuxfoundation.org
>     <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
>         Would it be feasible to transmit an entire BIP21 URI as audio?
>         If you were to encode any extra information (such as amount), it
>         would be useful to include a checksum for the entire message.
>         This checksum could possibly be used instead of the checksum in
>         the address.
> 
>         Trevin
> 
> 
>         On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev"
>         <bitcoin-dev at lists.linuxfoundation.org
>         <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
>             Daniel,
>                Thanks for proposing this.  I think this could have some
>             useful use cases as you state.  I was wondering what you
>             would think to adding some additional tones to optionally
>             denote an amount (in satoshis?).
> 
>             (FYI, actual link is here:  https://github.com/Dako300/BIP
>             <https://github.com/Dako300/BIP> )
> 
>             Justin
> 
>             On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via
>             bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>             <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> 
>                 This is my BIP idea: a fast, robust, and standardized
>                 for representing Bitcoin addresses over audio. It takes
>                 the binary representation of the Bitcoin address (little
>                 endian), chops that up into 4 or 2 bit chunks (depending
>                 on type, 2 bit only for low quality audio like american
>                 telephone lines), and generates a tone based upon that
>                 value. This started because I wanted an easy way to
>                 donate to podcasts that I listen to, and having a
>                 Shazam-esque app (or a media player with this
>                 capability) that gives me an address automatically would
>                 be wonderful for both the consumer and producer. Comes
>                 with error correction built into the protocol
> 
>                 You can see the full specification of the BIP on my
>                 GitHub page (https://github.com/Dako300/BIP-0153
>                 <https://github.com/Dako300/BIP-0153>).
> 
>                 _______________________________________________
>                 bitcoin-dev mailing list
>                 bitcoin-dev at lists.linuxfoundation.org
>                 <mailto:bitcoin-dev at lists.linuxfoundation.org>
>                 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>                 <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 
> 
>             -- 
> 
>             Justin W. Newton
>             Founder/CEO
>             Netki, Inc.
> 
>             justin at netki.com <mailto:justin at netki.com>
>             +1.818.261.4248 <tel:+1.818.261.4248>
> 
> 
> 
>             _______________________________________________
>             bitcoin-dev mailing list
>             bitcoin-dev at lists.linuxfoundation.org
>             <mailto:bitcoin-dev at lists.linuxfoundation.org>
>             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>             <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
>         _______________________________________________
>         bitcoin-dev mailing list
>         bitcoin-dev at lists.linuxfoundation.org
>         <mailto:bitcoin-dev at lists.linuxfoundation.org>
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

From danielhoffman699 at gmail.com  Wed Aug 10 01:53:06 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Tue, 9 Aug 2016 20:53:06 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <aa41549b-b392-a225-26e1-2dcf4edfeb21@gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<aa41549b-b392-a225-26e1-2dcf4edfeb21@gmail.com>
Message-ID: <CAL9WuQX=nPkmt6S5KJn=8UdmAnxU206hG3cL_qqXdmzvQ83CuQ@mail.gmail.com>

Thomas
In all honesty, I shouldn't have added the multiple feature. It should
always stay to one and have the Bitcoin address's built in checksum do all
of the heavy lifting (or implement another checksum into the protocol).
Having said that, it would make the most sense to not include BIP21
requests. The frequencies that are going to be used are prone to being
changed (probably moving them into the ultrasound range, at least for the
16 tones)

Luke Dashjr
I thought it was only 12, will change it accordingly.

Chris
I looked at Audio Modem and will probably look at the others soon as well.

The general idea of this BIP is to see if you all even approve of the idea
of sending Bitcoin addresses over sound waves. I will push it into the
ultrasound, and I might implement phase modulation.

On Tue, Aug 9, 2016 at 8:09 PM, Thomas Daede via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If this is just encoding BIP-21 addresses, it is basically an "audio QR
> code". In this case, does publishing it as a BIP still make sense? (Not
> to imply that it doesn't, but it's something you should consider.)
>
> Please look at existing implementations of audio modems when creating
> your design. A lot of this work has been done many times before, so
> there is a lot to learn from.
>
> Your selected frequencies are harmonics of each other, meaning nonlinear
> distortion will make detection more difficult. The Bell 202 and similar
> modem standards chose AFSK frequencies to minimize interference.
>
> Repeating a message multiple times is a very inefficient method of error
> recovery. It works, but there may be better techniques, such as trellis
> modulation or other convolutional codes.
>
> Defining channel models to simulate your various use cases will help a
> lot to determine if you have met your requirements.
>
> - Thomas
>
> P.S. I also briefly considered audio to exchange transactions with a
> hardware wallet. Using GNU Radio made the implementation much easier.
>
> On 08/09/2016 04:06 PM, Daniel Hoffman via bitcoin-dev wrote:
> > I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> > some smalls) and made a couple of samples (see attachment for MP3 and
> > FLAC of both tone tables, first 16 then 4). Is this good enough to
> > warrant an official BIP number? I haven't built a decoder yet, but it
> > seems like the encoder is working properly (looked at Audacity, seems
> > like it is working), and some people on reddit want to "allow for
> > decoding experiments"
> > <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_
> addresses_over_audio_thoughts/d69m3st>
> >
> > What suggestions do you all have for it?
> >
> > On Mon, Aug 8, 2016 at 8:50 PM, Daniel Hoffman
> > <danielhoffman699 at gmail.com <mailto:danielhoffman699 at gmail.com>> wrote:
> >
> >     It wouldn't be feasible in the vast majority of cases, but I can't
> >     think of a reason why it can't be built into the standard.
> >
> >     On Mon, Aug 8, 2016 at 5:59 PM, Trevin Hofmann via bitcoin-dev
> >     <bitcoin-dev at lists.linuxfoundation.org
> >     <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> >         Would it be feasible to transmit an entire BIP21 URI as audio?
> >         If you were to encode any extra information (such as amount), it
> >         would be useful to include a checksum for the entire message.
> >         This checksum could possibly be used instead of the checksum in
> >         the address.
> >
> >         Trevin
> >
> >
> >         On Aug 8, 2016 3:06 PM, "Justin Newton via bitcoin-dev"
> >         <bitcoin-dev at lists.linuxfoundation.org
> >         <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> >             Daniel,
> >                Thanks for proposing this.  I think this could have some
> >             useful use cases as you state.  I was wondering what you
> >             would think to adding some additional tones to optionally
> >             denote an amount (in satoshis?).
> >
> >             (FYI, actual link is here:  https://github.com/Dako300/BIP
> >             <https://github.com/Dako300/BIP> )
> >
> >             Justin
> >
> >             On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via
> >             bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> >             <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> >                 This is my BIP idea: a fast, robust, and standardized
> >                 for representing Bitcoin addresses over audio. It takes
> >                 the binary representation of the Bitcoin address (little
> >                 endian), chops that up into 4 or 2 bit chunks (depending
> >                 on type, 2 bit only for low quality audio like american
> >                 telephone lines), and generates a tone based upon that
> >                 value. This started because I wanted an easy way to
> >                 donate to podcasts that I listen to, and having a
> >                 Shazam-esque app (or a media player with this
> >                 capability) that gives me an address automatically would
> >                 be wonderful for both the consumer and producer. Comes
> >                 with error correction built into the protocol
> >
> >                 You can see the full specification of the BIP on my
> >                 GitHub page (https://github.com/Dako300/BIP-0153
> >                 <https://github.com/Dako300/BIP-0153>).
> >
> >                 _______________________________________________
> >                 bitcoin-dev mailing list
> >                 bitcoin-dev at lists.linuxfoundation.org
> >                 <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >                 https://lists.linuxfoundation.
> org/mailman/listinfo/bitcoin-dev
> >                 <https://lists.linuxfoundation.org/mailman/
> listinfo/bitcoin-dev>
> >
> >
> >
> >
> >             --
> >
> >             Justin W. Newton
> >             Founder/CEO
> >             Netki, Inc.
> >
> >             justin at netki.com <mailto:justin at netki.com>
> >             +1.818.261.4248 <tel:+1.818.261.4248>
> >
> >
> >
> >             _______________________________________________
> >             bitcoin-dev mailing list
> >             bitcoin-dev at lists.linuxfoundation.org
> >             <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >             https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-
> dev
> >             <https://lists.linuxfoundation.org/mailman/
> listinfo/bitcoin-dev>
> >
> >
> >         _______________________________________________
> >         bitcoin-dev mailing list
> >         bitcoin-dev at lists.linuxfoundation.org
> >         <mailto:bitcoin-dev at lists.linuxfoundation.org>
> >         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160809/5b88055b/attachment-0001.html>

From greg at xiph.org  Wed Aug 10 02:14:42 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 10 Aug 2016 02:14:42 +0000
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
Message-ID: <CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>

On Tue, Aug 9, 2016 at 11:06 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I have updated the GitHub a lot (changed tones to be less chirpy, fixed
> some smalls) and made a couple of samples (see attachment for MP3 and FLAC
> of both tone tables, first 16 then 4). Is this good enough to warrant an
> official BIP number? I haven't built a decoder yet, but it seems like the
> encoder is working properly (looked at Audacity, seems like it is working),
> and some people on reddit want to "allow for decoding experiments"
> <https://www.reddit.com/r/btc/comments/4wsn7v/bip_proposal_addresses_over_audio_thoughts/d69m3st>
>
> What suggestions do you all have for it?
>


With DSP hat on, your decoder for noisy/distorted channels will be 99.9% of
the complexity and will completely control the design of the encoder.

It's not a proposal yet without a decoder, it's just an idea.  FSK modems
microphone-channel (terrible multipath) is quite challenging and several
other parties have tried to do bitcoin info over audio in the past without
success.

It's very interesting, but I think you do need to go through and get the
whole thing working to really gauge viability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/af156283/attachment.html>

From macwhyte at gmail.com  Wed Aug 10 04:31:11 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Wed, 10 Aug 2016 04:31:11 +0000
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
	<CAH+Axy7BAC14eGugDVsqkRv+XU+5dL4AAv_kb7PSi61825E70w@mail.gmail.com>
	<CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
Message-ID: <CAH+Axy4J5vsi61eX_w1V=e2DdkttTBsbUcwXdqrgchJ6GXdaow@mail.gmail.com>

Signed by the key pair that was referenced in the output of the on-chain
transaction? (Bob in my example, actually) Doesn't that mean it's easy to
follow who is paying whom, you just can't see how much is going to reach
recipient?

On Tue, Aug 9, 2016, 04:40 Tony Churyumoff <tony991 at gmail.com> wrote:

> This troll is harmless.  A duplicate spend proof should also be signed
> by the same user (Alice, in your example) to be considered a double
> spend.
>
> 2016-08-09 3:18 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
> > One more thought about why verification by miners may be needed.
> >
> > Let's say Alice sends Bob a transaction, generating output C.
> >
> > A troll, named Timothy, broadcasts a transaction with a random hash,
> > referencing C's output as its spend proof. The miners can't tell if it's
> > valid or not, and so they include the transaction in a block. Now Bob's
> > money is useless, because everyone can see the spend proof referenced and
> > thinks it has already been spent, even though the transaction that
> claims it
> > isn't valid.
> >
> > Did I miss something that protects against this?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/718af0de/attachment.html>

From tier.nolan at gmail.com  Wed Aug 10 10:41:35 2016
From: tier.nolan at gmail.com (Tier Nolan)
Date: Wed, 10 Aug 2016 11:41:35 +0100
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
Message-ID: <CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>

Have you considered CDMA?  This has the nice property that it just sounds
like noise.  The codes would take longer to send, but you could send
multiple bits at once and have the codes orthogonal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/717d8ede/attachment.html>

From erik at q32.com  Wed Aug 10 11:42:57 2016
From: erik at q32.com (Erik Aronesty)
Date: Wed, 10 Aug 2016 07:42:57 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
Message-ID: <CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>

NOTE:

Addresses aren't really meant to be broadcast - you should probably be
encoding BIP32 public seeds, not addresses.

OR simply:

- Send btc to rick at q32.com
- TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
- DNS-SEC validation is *required*
- TXT record contains addr:[<bip32-pub-seed>]

Then you can just say, in the podcast, "Send your bitcoin donations to
rick at q32.com".   And you can link it to your email address, if your
provider lets you set up a TXT record.   (By structuring the TXT record
that way, many existing email providers will support the standard without
having to change anything.)

This works with audio, video, web and other publishing formats... and very
little infrastructure change is needed.


On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Have you considered CDMA?  This has the nice property that it just sounds
> like noise.  The codes would take longer to send, but you could send
> multiple bits at once and have the codes orthogonal.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/4af8834e/attachment.html>

From tony991 at gmail.com  Wed Aug 10 07:50:25 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Wed, 10 Aug 2016 10:50:25 +0300
Subject: [bitcoin-dev] Fwd: Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zpvv7ph9CJQF6E1VVdwCKKFLNe2EVh=JE=R0Gpt4y=1Tw@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<20160808215354.GA1373@fedora-21-dvm>
	<CAL3p6zpvv7ph9CJQF6E1VVdwCKKFLNe2EVh=JE=R0Gpt4y=1Tw@mail.gmail.com>
Message-ID: <CAL3p6zoMK=3Rv5VmR5auOt3CpnLaFQ-N2Gz4NBCBLqgmQr+mOA@mail.gmail.com>

> The OP's proposal sounds quite similar to my earlier one along similar lines:
>
>    https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

Similar indeed, thank you for the link.


2016-08-09 0:53 GMT+03:00 Peter Todd <pete at petertodd.org>:
>
> On Mon, Aug 08, 2016 at 09:41:27PM +0000, James MacWhyte via bitcoin-dev wrote:
> > Wouldn't you lose the ability to assume transactions in the blockchain are
> > verified as valid, since miners can't see the details of what is being
> > spent and how? I feel like this ability is bitcoin's greatest asset, and by
> > removing it you're creating an altcoin different enough to not be connected
> > to/supported by the main bitcoin project.
>
> The fact that miners verify transactions is just an optimisation:
>
>     https://petertodd.org/2013/disentangling-crypto-coin-mining
>
> Preventing double-spending however is a fundemental requirement of Bitcoin, and
> this proposal does prevent double-spending perfectly well (although there may
> be better ways to do it).
>
> The OP's proposal sounds quite similar to my earlier one along similar lines:
>
>     https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

From tony991 at gmail.com  Wed Aug 10 07:51:34 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Wed, 10 Aug 2016 10:51:34 +0300
Subject: [bitcoin-dev] Fwd: Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zr76k1F07dtvxQ8hiOiK_ZvVFBmW=ESYem60udUQmM+Cw@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
	<CAH+Axy6JiK-giXRTxENRCZbX7g0NuU=hq02O3j2Ac8HZ0ZhfFg@mail.gmail.com>
	<CAL3p6zr76k1F07dtvxQ8hiOiK_ZvVFBmW=ESYem60udUQmM+Cw@mail.gmail.com>
Message-ID: <CAL3p6zoU+YZ0VWHPHFinNG8aibBhXMe9nxM4ut4xh-p6WO6_bw@mail.gmail.com>

> That is a good point. As you said, it puts a lot more burden on the coin
> holders. One big downside would be data management. Instead of simply
> backing up a single HD private key, the user would have to back up entire
> histories of every output that has been sent to them if they want to secure
> their funds.

You are correct.  It is somewhat similar to bearer assets: if you lose
the histories, you lose money.

> It also requires them to be online to receive payments, and I think finding
> a method of sending the private message containing the coin's history is
> going to be a bit of a challenge. If you connect directly to the recipient
> to convey the information through traditional channels, anonymity is lost.
> Sending messages through the bitcoin network is one option to protect
> anonymity, but without active pathfinding there's no guarantee the payee
> will even get the message. I'm assuming you'd have to essentially replace tx
> messages with encrypted BBC histories, and mempools are quite full as it is.
>
> Tony, do you have any more thoughts on exactly how users would convey the
> private messages to payees?

You are right conveying the private messages is not trivial.  While we
can adapt the existing bitcoin network protocol for a limited set of
use cases, such as both parties being online at the same time and
connected directly, BBC would work best if we design a whole new
communication layer specifically for conveying private messages.  We
could route the end-to-end encrypted messages through hubs who are
constantly online and would store and forward the messages, thus the
peers don't have to be online at the same time and don't have to
connect directly.  The hubs could simultaneously serve as lightening
network hubs.


2016-08-09 3:03 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
> That is a good point. As you said, it puts a lot more burden on the coin
> holders. One big downside would be data management. Instead of simply
> backing up a single HD private key, the user would have to back up entire
> histories of every output that has been sent to them if they want to secure
> their funds.
>
> It also requires them to be online to receive payments, and I think finding
> a method of sending the private message containing the coin's history is
> going to be a bit of a challenge. If you connect directly to the recipient
> to convey the information through traditional channels, anonymity is lost.
> Sending messages through the bitcoin network is one option to protect
> anonymity, but without active pathfinding there's no guarantee the payee
> will even get the message. I'm assuming you'd have to essentially replace tx
> messages with encrypted BBC histories, and mempools are quite full as it is.
>
> Tony, do you have any more thoughts on exactly how users would convey the
> private messages to payees?
>
> On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991 at gmail.com> wrote:
>>
>> The whole point is in preventing every third party, including miners, from
>> seeing the details of what is being spent and how.  The burden of
>> verification is shifted to the owners of the coin (which is fair).
>>
>> In fact we could have miners recognize spend proofs and check that the
>> same spend proof is not entered into the blockchain more than once (which
>> would be a sign of double spend), but it is not required.  The coin owners
>> can already do that themselves.
>>
>> 2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
>>>
>>> Wouldn't you lose the ability to assume transactions in the blockchain
>>> are verified as valid, since miners can't see the details of what is being
>>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>>> removing it you're creating an altcoin different enough to not be connected
>>> to/supported by the main bitcoin project.
>>>
>>>
>>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> Hi Henning,
>>>>
>>>> 1. The fees are paid by the enclosing BTC transaction.
>>>> 2. The hash is encoded into an OP_RETURN.
>>>>
>>>> > Regarding the blinding factor, I think you could just use HMAC.
>>>> How exactly?
>>>>
>>>> Tony
>>>>
>>>>
>>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>>>>>
>>>>> Hi Tony,
>>>>>
>>>>> I see some issues in your protocol.
>>>>>
>>>>> 1. How are mining fees handled?
>>>>>
>>>>> 2. Assume Alice sends Bob some Coins together with their history and
>>>>> Bob checks that the history is correct. How does the hash of the txout
>>>>> find its way into the blockchain?
>>>>>
>>>>> Regarding the blinding factor, I think you could just use HMAC.
>>>>>
>>>>> All the best
>>>>> Henning
>>>>>
>>>>>
>>>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>>>> bitcoin-dev wrote:
>>>>> > This is a proposal about hiding the entire content of bitcoin
>>>>> > transactions.  It goes farther than CoinJoin and ring signatures,
>>>>> > which
>>>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>>>> > which
>>>>> > only hide the amounts.
>>>>> >
>>>>> > The central idea of the proposed design is to hide the entire inputs
>>>>> > and
>>>>> > outputs, and publish only the hash of inputs and outputs in the
>>>>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext
>>>>> > of
>>>>> > inputs and outputs is sent directly to the payee via a private
>>>>> > message, and
>>>>> > never goes into the blockchain.  The payee then calculates the hash
>>>>> > and
>>>>> > looks it up in the blockchain to verify that the hash was indeed
>>>>> > published
>>>>> > by the payer.
>>>>> >
>>>>> > Since the plaintext of the transaction is not published to the public
>>>>> > blockchain, all validation work has to be done only by the user who
>>>>> > receives the payment.
>>>>> >
>>>>> > To protect against double-spends, the payer also has to publish
>>>>> > another
>>>>> > hash, which is the hash of the output being spent.  We?ll call this
>>>>> > hash *spend
>>>>> > proof*.  Since the spend proof depends solely on the output being
>>>>> > spent,
>>>>> > any attempt to spend the same output again will produce exactly the
>>>>> > same
>>>>> > spend proof, and the payee will be able to see that, and will reject
>>>>> > the
>>>>> > payment.  If there are several outputs consumed by the same
>>>>> > transaction,
>>>>> > the payer has to publish several spend proofs.
>>>>> >
>>>>> > To prove that the outputs being spent are valid, the payer also has
>>>>> > to send
>>>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>>>> > the
>>>>> > plaintexts of even earlier transactions that produced the outputs
>>>>> > spent in
>>>>> > those transactions, and so on, up until the issue (similar to
>>>>> > coinbase)
>>>>> > transactions that created the initial private coins.  Each new owner
>>>>> > of the
>>>>> > coin will have to store its entire history, and when he spends the
>>>>> > coin, he
>>>>> > forwards the entire history to the next owner and extends it with his
>>>>> > own
>>>>> > transaction.
>>>>> >
>>>>> > If we apply the existing bitcoin design that allows multiple inputs
>>>>> > and
>>>>> > multiple outputs per transaction, the history of ownership transfers
>>>>> > would
>>>>> > grow exponentially.  Indeed, if we take any regular bitcoin output
>>>>> > and try
>>>>> > to track its history back to coinbase, our history will branch every
>>>>> > time
>>>>> > we see a transaction that has more than one input (which is not
>>>>> > uncommon).
>>>>> > After such a transaction (remember, we are traveling back in time),
>>>>> > we?ll
>>>>> > have to track two or more histories, for each respective input.
>>>>> > Those
>>>>> > histories will branch again, and the total number of history entries
>>>>> > grows
>>>>> > exponentially.  For example, if every transaction had exactly two
>>>>> > inputs,
>>>>> > the size of history would grow as 2^N where N is the number of steps
>>>>> > back
>>>>> > in history.
>>>>> >
>>>>> > To avoid such rapid growth of ownership history (which is not only
>>>>> > inconvenient to move, but also exposes too much private information
>>>>> > about
>>>>> > previous owners of all the contributing coins), we will require each
>>>>> > private transaction to have exactly one input (i.e. to consume
>>>>> > exactly one
>>>>> > previous output).  This means that when we track a coin?s history
>>>>> > back in
>>>>> > time, it will no longer branch.  It will grow linearly with the
>>>>> > number of
>>>>> > transfers of ownership.  If a user wants to combine several inputs,
>>>>> > he will
>>>>> > have to send them as separate private transactions (technically,
>>>>> > several
>>>>> > OP_RETURNs, which can be included in a single regular bitcoin
>>>>> > transaction).
>>>>> >
>>>>> > Thus, we are now forbidding any coin merges but still allowing coin
>>>>> > splits.  To avoid ultimate splitting into the dust, we will also
>>>>> > require
>>>>> > that all private coins be issued in one of a small number of
>>>>> > denominations.  Only integer number of ?banknotes? can be
>>>>> > transferred, the
>>>>> > input and output amounts must therefore be divisible by the
>>>>> > denomination.
>>>>> > For example, an input of amount 700, denomination 100, can be split
>>>>> > into
>>>>> > outputs 400 and 300, but not into 450 and 250.  To send a payment,
>>>>> > the
>>>>> > payer has to pick the unspent outputs of the highest denomination
>>>>> > first,
>>>>> > then the second highest, and so on, like we already do when we pay in
>>>>> > cash.
>>>>> >
>>>>> > With fixed denominations and one input per transaction, coin
>>>>> > histories
>>>>> > still grow, but only linearly, which should not be a concern in
>>>>> > regard to
>>>>> > scalability given that all relevant computing resources still grow
>>>>> > exponentially.  The histories need to be stored only by the current
>>>>> > owner
>>>>> > of the coin, not every bitcoin node.  This is a fairer allocation of
>>>>> > costs.  Regarding privacy, coin histories do expose private
>>>>> > transactions
>>>>> > (or rather parts thereof, since a typical payment will likely consist
>>>>> > of
>>>>> > several transactions due to one-input-per-transaction rule) of past
>>>>> > coin
>>>>> > owners to the future ones, and that exposure grows linearly with
>>>>> > time, but
>>>>> > it is still much much better than having every transaction
>>>>> > immediately on
>>>>> > the public blockchain.  Also, the value of this information for
>>>>> > potential
>>>>> > adversaries arguably decreases with time.
>>>>> >
>>>>> > There is one technical nuance that I omitted above to avoid
>>>>> > distraction.
>>>>> >  Unlike regular bitcoin transactions, every output in a private
>>>>> > payment
>>>>> > must also include a blinding factor, which is just a random string.
>>>>> > When
>>>>> > the output is spent, the corresponding spend proof will therefore
>>>>> > depend on
>>>>> > this blinding factor (remember that spend proof is just a hash of the
>>>>> > output).  Without a blinding factor, it would be feasible to
>>>>> > pre-image the
>>>>> > spend proof and reveal the output being spent as the search space of
>>>>> > all
>>>>> > possible outputs is rather small.
>>>>> >
>>>>> > To issue the new private coin, one can burn regular BTC by sending it
>>>>> > to
>>>>> > one of several unspendable bitcoin addresses, one address per
>>>>> > denomination.
>>>>> >  Burning BTC would entitle one to an equal amount of the new private
>>>>> > coin,
>>>>> > let?s call it *black bitcoin*, or *BBC*.
>>>>> >
>>>>> > Then BBC would be transferred from user to user by:
>>>>> > 1. creating a private transaction, which consists of one input and
>>>>> > several
>>>>> > outputs;
>>>>> > 2. storing the hash of the transaction and the spend proof of the
>>>>> > consumed
>>>>> > output into the blockchain in an OP_RETURN (the sender pays the
>>>>> > corresponding fees in regular BTC)
>>>>> > 3. sending the transaction, together with the history leading to its
>>>>> > input,
>>>>> > directly to the payee over a private communication channel.  The
>>>>> > first
>>>>> > entry of the history must be a bitcoin transaction that burned BTC to
>>>>> > issue
>>>>> > an equal amount of BCC.
>>>>> >
>>>>> > To verify the payment, the payee:
>>>>> > 1. makes sure that the amount of the input matches the sum of
>>>>> > outputs, and
>>>>> > all are divisible by the denomination
>>>>> > 2. calculates the hash of the private transaction
>>>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the
>>>>> > payee.  If there is more than one, the one that comes in the earlier
>>>>> > block
>>>>> > prevails.
>>>>> > 4. calculates the spend proof and makes sure that it is included in
>>>>> > the
>>>>> > same OP_RETURN
>>>>> > 5. makes sure the same spend proof is not included anywhere in the
>>>>> > same or
>>>>> > earlier blocks (that is, the coin was not spent before).  Only
>>>>> > transactions
>>>>> > by the same author are searched.
>>>>> > 6. repeats the same steps for every entry in the history, except the
>>>>> > first
>>>>> > entry, which should be a valid burning transaction.
>>>>> >
>>>>> > To facilitate exchange of private transaction data, the bitcoin
>>>>> > network
>>>>> > protocol can be extended with a new message type.  Unfortunately, it
>>>>> > lacks
>>>>> > encryption, hence private payments are really private only when
>>>>> > bitcoin is
>>>>> > used over tor.
>>>>> >
>>>>> > There are a few limitations that ought to be mentioned:
>>>>> > 1. After user A sends a private payment to user B, user A will know
>>>>> > what
>>>>> > the spend proof is going to be when B decides to spend the coin.
>>>>> >  Therefore, A will know when the coin was spent by B, but nothing
>>>>> > more.
>>>>> >  Neither the new owner of the coin, nor its future movements will be
>>>>> > known
>>>>> > to A.
>>>>> > 2. Over time, larger outputs will likely be split into many smaller
>>>>> > outputs, whose amounts are not much greater than their denominations.
>>>>> > You?ll have to combine more inputs to send the same amount.  When you
>>>>> > want
>>>>> > to send a very large amount that is much greater than the highest
>>>>> > available
>>>>> > denomination, you?ll have to send a lot of private transactions, your
>>>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their
>>>>> > number will roughly indicate the total amount.  This kind of privacy
>>>>> > leakage, however it applies to a small number of users, is easy to
>>>>> > avoid by
>>>>> > using multiple addresses and storing a relatively small amount on
>>>>> > each
>>>>> > address.
>>>>> > 3. Exchanges and large merchants will likely accumulate large coin
>>>>> > histories.  Although fragmented, far from complete, and likely
>>>>> > outdated, it
>>>>> > is still something to bear in mind.
>>>>> >
>>>>> > No hard or soft fork is required, BBC is just a separate privacy
>>>>> > preserving
>>>>> > currency on top of bitcoin blockchain, and the same private keys and
>>>>> > addresses are used for both BBC and the base currency BTC.  Every BCC
>>>>> > transaction must be enclosed into by a small BTC transaction that
>>>>> > stores
>>>>> > the OP_RETURNs and pays for the fees.
>>>>> >
>>>>> > Are there any flaws in this design?
>>>>> >
>>>>> > Originally posted to BCT
>>>>> > https://bitcointalk.org/index.php?topic=1574508.0,
>>>>> > but got no feedback so far, apparently everybody was consumed with
>>>>> > bitfinex
>>>>> > drama and now mimblewimble.
>>>>> >
>>>>> > Tony
>>>>>
>>>>> > _______________________________________________
>>>>> > bitcoin-dev mailing list
>>>>> > bitcoin-dev at lists.linuxfoundation.org
>>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>> --
>>>>> Henning Kopp
>>>>> Institute of Distributed Systems
>>>>> Ulm University, Germany
>>>>>
>>>>> Office: O27 - 3402
>>>>> Phone: +49 731 50-24138
>>>>> Web: http://www.uni-ulm.de/in/vs/~kopp
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

From tony991 at gmail.com  Wed Aug 10 07:52:11 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Wed, 10 Aug 2016 10:52:11 +0300
Subject: [bitcoin-dev] Fwd: Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zqj7bc=qrayBBK=O6p2b2PBNO3n5EMFf_1dR1oMq581hg@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<20160809072635.GA2178@banane.informatik.uni-ulm.de>
	<CAL3p6zqj7bc=qrayBBK=O6p2b2PBNO3n5EMFf_1dR1oMq581hg@mail.gmail.com>
Message-ID: <CAL3p6zqZC-mqCJ+qryYiYBZ3yCS2KmYPUE37xyt2KWg3=Y4Ngw@mail.gmail.com>

> Instead of a hash function you may use a keyed hash function (HMAC) where
> the key is just the random string. They key needs to be stored in the
> history of the coin to allow for verification.

This is nearly equivalent.  The sole purpose of the blinding factor is
to increase the search space and make preimaging of the output
impossible.  While in many applications HMAC is superior to plain hash
of a concatenation of the input data and the key (key = blinding
factor in our case), its preimage resistance is the same as that of
the hash.


2016-08-09 10:26 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
>
> Hi Tony,
>
> > > Regarding the blinding factor, I think you could just use HMAC.
> > How exactly?
>
> I am not entirely sure if this works. You wrote:
>
> > There is one technical nuance that I omitted above to avoid distraction.
> >  Unlike regular bitcoin transactions, every output in a private payment
> > must also include a blinding factor, which is just a random string.  When
> > the output is spent, the corresponding spend proof will therefore depend on
> > this blinding factor (remember that spend proof is just a hash of the
> > output).  Without a blinding factor, it would be feasible to pre-image the
> > spend proof and reveal the output being spent as the search space of all
> > possible outputs is rather small.
>
> Instead of a hash function you may use a keyed hash function (HMAC) where
> the key is just the random string. They key needs to be stored in the
> history of the coin to allow for verification.
>
> Best
> Henning
>
> On Mon, Aug 08, 2016 at 07:03:28PM +0300, Tony Churyumoff wrote:
> > Hi Henning,
> >
> > 1. The fees are paid by the enclosing BTC transaction.
> > 2. The hash is encoded into an OP_RETURN.
> >
> > > Regarding the blinding factor, I think you could just use HMAC.
> > How exactly?
> >
> > Tony
> >
> >
> > 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp at uni-ulm.de>:
> >
> > > Hi Tony,
> > >
> > > I see some issues in your protocol.
> > >
> > > 1. How are mining fees handled?
> > >
> > > 2. Assume Alice sends Bob some Coins together with their history and
> > > Bob checks that the history is correct. How does the hash of the txout
> > > find its way into the blockchain?
> > >
> > > Regarding the blinding factor, I think you could just use HMAC.
> > >
> > > All the best
> > > Henning
> > >
> > >
> > > On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> > > wrote:
> > > > This is a proposal about hiding the entire content of bitcoin
> > > > transactions.  It goes farther than CoinJoin and ring signatures, which
> > > > only obfuscate the transaction graph, and Confidential Transactions,
> > > which
> > > > only hide the amounts.
> > > >
> > > > The central idea of the proposed design is to hide the entire inputs and
> > > > outputs, and publish only the hash of inputs and outputs in the
> > > > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > > > inputs and outputs is sent directly to the payee via a private message,
> > > and
> > > > never goes into the blockchain.  The payee then calculates the hash and
> > > > looks it up in the blockchain to verify that the hash was indeed
> > > published
> > > > by the payer.
> > > >
> > > > Since the plaintext of the transaction is not published to the public
> > > > blockchain, all validation work has to be done only by the user who
> > > > receives the payment.
> > > >
> > > > To protect against double-spends, the payer also has to publish another
> > > > hash, which is the hash of the output being spent.  We?ll call this hash
> > > *spend
> > > > proof*.  Since the spend proof depends solely on the output being spent,
> > > > any attempt to spend the same output again will produce exactly the same
> > > > spend proof, and the payee will be able to see that, and will reject the
> > > > payment.  If there are several outputs consumed by the same transaction,
> > > > the payer has to publish several spend proofs.
> > > >
> > > > To prove that the outputs being spent are valid, the payer also has to
> > > send
> > > > the plaintexts of the earlier transaction(s) that produced them, then the
> > > > plaintexts of even earlier transactions that produced the outputs spent
> > > in
> > > > those transactions, and so on, up until the issue (similar to coinbase)
> > > > transactions that created the initial private coins.  Each new owner of
> > > the
> > > > coin will have to store its entire history, and when he spends the coin,
> > > he
> > > > forwards the entire history to the next owner and extends it with his own
> > > > transaction.
> > > >
> > > > If we apply the existing bitcoin design that allows multiple inputs and
> > > > multiple outputs per transaction, the history of ownership transfers
> > > would
> > > > grow exponentially.  Indeed, if we take any regular bitcoin output and
> > > try
> > > > to track its history back to coinbase, our history will branch every time
> > > > we see a transaction that has more than one input (which is not
> > > uncommon).
> > > > After such a transaction (remember, we are traveling back in time), we?ll
> > > > have to track two or more histories, for each respective input.  Those
> > > > histories will branch again, and the total number of history entries
> > > grows
> > > > exponentially.  For example, if every transaction had exactly two inputs,
> > > > the size of history would grow as 2^N where N is the number of steps back
> > > > in history.
> > > >
> > > > To avoid such rapid growth of ownership history (which is not only
> > > > inconvenient to move, but also exposes too much private information about
> > > > previous owners of all the contributing coins), we will require each
> > > > private transaction to have exactly one input (i.e. to consume exactly
> > > one
> > > > previous output).  This means that when we track a coin?s history back in
> > > > time, it will no longer branch.  It will grow linearly with the number of
> > > > transfers of ownership.  If a user wants to combine several inputs, he
> > > will
> > > > have to send them as separate private transactions (technically, several
> > > > OP_RETURNs, which can be included in a single regular bitcoin
> > > transaction).
> > > >
> > > > Thus, we are now forbidding any coin merges but still allowing coin
> > > > splits.  To avoid ultimate splitting into the dust, we will also require
> > > > that all private coins be issued in one of a small number of
> > > > denominations.  Only integer number of ?banknotes? can be transferred,
> > > the
> > > > input and output amounts must therefore be divisible by the denomination.
> > > > For example, an input of amount 700, denomination 100, can be split into
> > > > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
> > > > payer has to pick the unspent outputs of the highest denomination first,
> > > > then the second highest, and so on, like we already do when we pay in
> > > cash.
> > > >
> > > > With fixed denominations and one input per transaction, coin histories
> > > > still grow, but only linearly, which should not be a concern in regard to
> > > > scalability given that all relevant computing resources still grow
> > > > exponentially.  The histories need to be stored only by the current owner
> > > > of the coin, not every bitcoin node.  This is a fairer allocation of
> > > > costs.  Regarding privacy, coin histories do expose private transactions
> > > > (or rather parts thereof, since a typical payment will likely consist of
> > > > several transactions due to one-input-per-transaction rule) of past coin
> > > > owners to the future ones, and that exposure grows linearly with time,
> > > but
> > > > it is still much much better than having every transaction immediately on
> > > > the public blockchain.  Also, the value of this information for potential
> > > > adversaries arguably decreases with time.
> > > >
> > > > There is one technical nuance that I omitted above to avoid distraction.
> > > >  Unlike regular bitcoin transactions, every output in a private payment
> > > > must also include a blinding factor, which is just a random string.  When
> > > > the output is spent, the corresponding spend proof will therefore depend
> > > on
> > > > this blinding factor (remember that spend proof is just a hash of the
> > > > output).  Without a blinding factor, it would be feasible to pre-image
> > > the
> > > > spend proof and reveal the output being spent as the search space of all
> > > > possible outputs is rather small.
> > > >
> > > > To issue the new private coin, one can burn regular BTC by sending it to
> > > > one of several unspendable bitcoin addresses, one address per
> > > denomination.
> > > >  Burning BTC would entitle one to an equal amount of the new private
> > > coin,
> > > > let?s call it *black bitcoin*, or *BBC*.
> > > >
> > > > Then BBC would be transferred from user to user by:
> > > > 1. creating a private transaction, which consists of one input and
> > > several
> > > > outputs;
> > > > 2. storing the hash of the transaction and the spend proof of the
> > > consumed
> > > > output into the blockchain in an OP_RETURN (the sender pays the
> > > > corresponding fees in regular BTC)
> > > > 3. sending the transaction, together with the history leading to its
> > > input,
> > > > directly to the payee over a private communication channel.  The first
> > > > entry of the history must be a bitcoin transaction that burned BTC to
> > > issue
> > > > an equal amount of BCC.
> > > >
> > > > To verify the payment, the payee:
> > > > 1. makes sure that the amount of the input matches the sum of outputs,
> > > and
> > > > all are divisible by the denomination
> > > > 2. calculates the hash of the private transaction
> > > > 3. looks up an OP_RETURN that includes this hash and is signed by the
> > > > payee.  If there is more than one, the one that comes in the earlier
> > > block
> > > > prevails.
> > > > 4. calculates the spend proof and makes sure that it is included in the
> > > > same OP_RETURN
> > > > 5. makes sure the same spend proof is not included anywhere in the same
> > > or
> > > > earlier blocks (that is, the coin was not spent before).  Only
> > > transactions
> > > > by the same author are searched.
> > > > 6. repeats the same steps for every entry in the history, except the
> > > first
> > > > entry, which should be a valid burning transaction.
> > > >
> > > > To facilitate exchange of private transaction data, the bitcoin network
> > > > protocol can be extended with a new message type.  Unfortunately, it
> > > lacks
> > > > encryption, hence private payments are really private only when bitcoin
> > > is
> > > > used over tor.
> > > >
> > > > There are a few limitations that ought to be mentioned:
> > > > 1. After user A sends a private payment to user B, user A will know what
> > > > the spend proof is going to be when B decides to spend the coin.
> > > >  Therefore, A will know when the coin was spent by B, but nothing more.
> > > >  Neither the new owner of the coin, nor its future movements will be
> > > known
> > > > to A.
> > > > 2. Over time, larger outputs will likely be split into many smaller
> > > > outputs, whose amounts are not much greater than their denominations.
> > > > You?ll have to combine more inputs to send the same amount.  When you
> > > want
> > > > to send a very large amount that is much greater than the highest
> > > available
> > > > denomination, you?ll have to send a lot of private transactions, your
> > > > bitcoin transaction with so many OP_RETURNs will stand out, and their
> > > > number will roughly indicate the total amount.  This kind of privacy
> > > > leakage, however it applies to a small number of users, is easy to avoid
> > > by
> > > > using multiple addresses and storing a relatively small amount on each
> > > > address.
> > > > 3. Exchanges and large merchants will likely accumulate large coin
> > > > histories.  Although fragmented, far from complete, and likely outdated,
> > > it
> > > > is still something to bear in mind.
> > > >
> > > > No hard or soft fork is required, BBC is just a separate privacy
> > > preserving
> > > > currency on top of bitcoin blockchain, and the same private keys and
> > > > addresses are used for both BBC and the base currency BTC.  Every BCC
> > > > transaction must be enclosed into by a small BTC transaction that stores
> > > > the OP_RETURNs and pays for the fees.
> > > >
> > > > Are there any flaws in this design?
> > > >
> > > > Originally posted to BCT https://bitcointalk.org/index.
> > > php?topic=1574508.0,
> > > > but got no feedback so far, apparently everybody was consumed with
> > > bitfinex
> > > > drama and now mimblewimble.
> > > >
> > > > Tony
> > >
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev at lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >
> > >
> > > --
> > > Henning Kopp
> > > Institute of Distributed Systems
> > > Ulm University, Germany
> > >
> > > Office: O27 - 3402
> > > Phone: +49 731 50-24138
> > > Web: http://www.uni-ulm.de/in/vs/~kopp
> > >
>
> --
> 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

From tony991 at gmail.com  Wed Aug 10 07:53:01 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Wed, 10 Aug 2016 10:53:01 +0300
Subject: [bitcoin-dev] Fwd: Hiding entire content of on-chain transactions
In-Reply-To: <CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
	<CAH+Axy7BAC14eGugDVsqkRv+XU+5dL4AAv_kb7PSi61825E70w@mail.gmail.com>
	<CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
Message-ID: <CAL3p6zrYwxFRC5JctwKsLwEzENWL0B2iUgO3crubaYkc=m5SdQ@mail.gmail.com>

This troll is harmless.  A duplicate spend proof should also be signed
by the same user (Alice, in your example) to be considered a double
spend.

2016-08-09 3:18 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
> One more thought about why verification by miners may be needed.
>
> Let's say Alice sends Bob a transaction, generating output C.
>
> A troll, named Timothy, broadcasts a transaction with a random hash,
> referencing C's output as its spend proof. The miners can't tell if it's
> valid or not, and so they include the transaction in a block. Now Bob's
> money is useless, because everyone can see the spend proof referenced and
> thinks it has already been spent, even though the transaction that claims it
> isn't valid.
>
> Did I miss something that protects against this?
>

From tony991 at gmail.com  Wed Aug 10 08:37:37 2016
From: tony991 at gmail.com (Tony Churyumoff)
Date: Wed, 10 Aug 2016 11:37:37 +0300
Subject: [bitcoin-dev] Hiding entire content of on-chain transactions
In-Reply-To: <CAH+Axy4J5vsi61eX_w1V=e2DdkttTBsbUcwXdqrgchJ6GXdaow@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
	<20160808154707.GB2196@banane.informatik.uni-ulm.de>
	<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
	<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
	<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
	<CAH+Axy7BAC14eGugDVsqkRv+XU+5dL4AAv_kb7PSi61825E70w@mail.gmail.com>
	<CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
	<CAH+Axy4J5vsi61eX_w1V=e2DdkttTBsbUcwXdqrgchJ6GXdaow@mail.gmail.com>
Message-ID: <CAL3p6zpG8dnVju_m0Vh60FcVRywM4r8ymw03Hr4r1sbXgJzEaQ@mail.gmail.com>

> Signed by the key pair that was referenced in the output of the on-chain
> transaction?

Signed by the key pair referenced in the private output.

>  (Bob in my example, actually)

I misread your example.  If it was Bob, then the troll couldn't
generate the correct spend proof because he didn't see the private
output C.  The troll could try to replay the spend proof in the
Alice's transaction as soon as he sees it in the mempool, but then the
spend proof would be signed by the wrong user.

> Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?

Only the recipients of the private outputs can see the previous owners
of the coins they receive (including amounts).  What everybody else
sees, is just meaningless hashes that hide both the recipient of the
coin and the amount.


2016-08-10 7:31 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
> Signed by the key pair that was referenced in the output of the on-chain
> transaction? (Bob in my example, actually) Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?
>
> On Tue, Aug 9, 2016, 04:40 Tony Churyumoff <tony991 at gmail.com> wrote:
>>
>> This troll is harmless.  A duplicate spend proof should also be signed
>> by the same user (Alice, in your example) to be considered a double
>> spend.
>>
>> 2016-08-09 3:18 GMT+03:00 James MacWhyte <macwhyte at gmail.com>:
>> > One more thought about why verification by miners may be needed.
>> >
>> > Let's say Alice sends Bob a transaction, generating output C.
>> >
>> > A troll, named Timothy, broadcasts a transaction with a random hash,
>> > referencing C's output as its spend proof. The miners can't tell if it's
>> > valid or not, and so they include the transaction in a block. Now Bob's
>> > money is useless, because everyone can see the spend proof referenced
>> > and
>> > thinks it has already been spent, even though the transaction that
>> > claims it
>> > isn't valid.
>> >
>> > Did I miss something that protects against this?
>> >

From bitdev at theochino.com  Wed Aug 10 11:49:16 2016
From: bitdev at theochino.com (Theo Chino)
Date: Wed, 10 Aug 2016 07:49:16 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
Message-ID: <CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>

Another use for the audio would be for watches that can listen but can't
use a camera (ie: Samsung S2), so sound would be great.

On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> NOTE:
>
> Addresses aren't really meant to be broadcast - you should probably be
> encoding BIP32 public seeds, not addresses.
>
> OR simply:
>
> - Send btc to rick at q32.com
> - TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
> - DNS-SEC validation is *required*
> - TXT record contains addr:[<bip32-pub-seed>]
>
> Then you can just say, in the podcast, "Send your bitcoin donations to
> rick at q32.com".   And you can link it to your email address, if your
> provider lets you set up a TXT record.   (By structuring the TXT record
> that way, many existing email providers will support the standard without
> having to change anything.)
>
> This works with audio, video, web and other publishing formats... and very
> little infrastructure change is needed.
>
>
> On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Have you considered CDMA?  This has the nice property that it just sounds
>> like noise.  The codes would take longer to send, but you could send
>> multiple bits at once and have the codes orthogonal.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/ac810b1a/attachment.html>

From danielhoffman699 at gmail.com  Wed Aug 10 16:01:15 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Wed, 10 Aug 2016 11:01:15 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
Message-ID: <CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>

Erik
What would be the advantages of transmitting a BIP32 public seed, instead
of a plain address?

Theo
I didn't really think of that, but that's genius.

On Wed, Aug 10, 2016 at 6:49 AM, Theo Chino via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Another use for the audio would be for watches that can listen but can't
> use a camera (ie: Samsung S2), so sound would be great.
>
> On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> NOTE:
>>
>> Addresses aren't really meant to be broadcast - you should probably be
>> encoding BIP32 public seeds, not addresses.
>>
>> OR simply:
>>
>> - Send btc to rick at q32.com
>> - TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
>> - DNS-SEC validation is *required*
>> - TXT record contains addr:[<bip32-pub-seed>]
>>
>> Then you can just say, in the podcast, "Send your bitcoin donations to
>> rick at q32.com".   And you can link it to your email address, if your
>> provider lets you set up a TXT record.   (By structuring the TXT record
>> that way, many existing email providers will support the standard without
>> having to change anything.)
>>
>> This works with audio, video, web and other publishing formats... and
>> very little infrastructure change is needed.
>>
>>
>> On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Have you considered CDMA?  This has the nice property that it just
>>> sounds like noise.  The codes would take longer to send, but you could send
>>> multiple bits at once and have the codes orthogonal.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/8f1d1434/attachment-0001.html>

From earonesty at gmail.com  Wed Aug 10 17:28:16 2016
From: earonesty at gmail.com (Erik Aronesty)
Date: Wed, 10 Aug 2016 13:28:16 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
Message-ID: <CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>

By sending a public seed,  there's no way for someone to use the
transmitted address and trace the total amount of payments to it.

On Aug 10, 2016 12:02 PM, "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Erik
> What would be the advantages of transmitting a BIP32 public seed, instead
> of a plain address?
>
> Theo
> I didn't really think of that, but that's genius.
>
> On Wed, Aug 10, 2016 at 6:49 AM, Theo Chino via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Another use for the audio would be for watches that can listen but can't
>> use a camera (ie: Samsung S2), so sound would be great.
>>
>> On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> NOTE:
>>>
>>> Addresses aren't really meant to be broadcast - you should probably be
>>> encoding BIP32 public seeds, not addresses.
>>>
>>> OR simply:
>>>
>>> - Send btc to rick at q32.com
>>> - TXT record _btc.rick.q32.com is queried (_<coin-code>.<name>.<domain>)
>>> - DNS-SEC validation is *required*
>>> - TXT record contains addr:[<bip32-pub-seed>]
>>>
>>> Then you can just say, in the podcast, "Send your bitcoin donations to
>>> rick at q32.com".   And you can link it to your email address, if your
>>> provider lets you set up a TXT record.   (By structuring the TXT record
>>> that way, many existing email providers will support the standard without
>>> having to change anything.)
>>>
>>> This works with audio, video, web and other publishing formats... and
>>> very little infrastructure change is needed.
>>>
>>>
>>> On Wed, Aug 10, 2016 at 6:41 AM, Tier Nolan via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Have you considered CDMA?  This has the nice property that it just
>>>> sounds like noise.  The codes would take longer to send, but you could send
>>>> multiple bits at once and have the codes orthogonal.
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/4f50a2ea/attachment.html>

From pieter.wuille at gmail.com  Wed Aug 10 17:38:26 2016
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Wed, 10 Aug 2016 19:38:26 +0200
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
Message-ID: <CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>

On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> By sending a public seed,  there's no way for someone to use the transmitted
> address and trace the total amount of payments to it.

Worse. By revealing a public seed, anyone who has seen it (= anyone
who ever pays you through it) can identity all payments to _any_
address derived from that seed.

-- 
Pieter

From danielhoffman699 at gmail.com  Wed Aug 10 17:55:04 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Wed, 10 Aug 2016 12:55:04 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
Message-ID: <CAL9WuQVGu-7V3+Ty86zOMm1HdqCw5+999Vw7VCn6HXBwdoKBpA@mail.gmail.com>

thats how i thought it worked originally, but im not well versed on that,
so i took his word for it

On Aug 10, 2016 12:38 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > By sending a public seed,  there's no way for someone to use the
> transmitted
> > address and trace the total amount of payments to it.
>
> Worse. By revealing a public seed, anyone who has seen it (= anyone
> who ever pays you through it) can identity all payments to _any_
> address derived from that seed.
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/9722b54a/attachment.html>

From macwhyte at gmail.com  Wed Aug 10 22:31:16 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Wed, 10 Aug 2016 22:31:16 +0000
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAL9WuQVGu-7V3+Ty86zOMm1HdqCw5+999Vw7VCn6HXBwdoKBpA@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAL9WuQVGu-7V3+Ty86zOMm1HdqCw5+999Vw7VCn6HXBwdoKBpA@mail.gmail.com>
Message-ID: <CAH+Axy7ZCn4BLyk1GxhTNx945x-7sqW8Ehks32eLod3N0=HJYA@mail.gmail.com>

I agree, audio-based transference isn't really great for a podcast or radio
ad. It could be used to transmit payment details between phones that don't
have cameras, though. I think it would be better to define a standard for
transmitting information over audio, but not define what information is to
be conveyed so people could use the method for sending pub keys, payment
protocol requests, or anything else developers might want to make use of.

I'm guessing some sort of data-over-audio standard already exists? In which
case the bip could just say "we use [standard] to convey any
bitcoin-related data".

On Wed, Aug 10, 2016, 10:55 Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> thats how i thought it worked originally, but im not well versed on that,
> so i took his word for it
>
> On Aug 10, 2016 12:38 PM, "Pieter Wuille via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > By sending a public seed,  there's no way for someone to use the
>> transmitted
>> > address and trace the total amount of payments to it.
>>
>> Worse. By revealing a public seed, anyone who has seen it (= anyone
>> who ever pays you through it) can identity all payments to _any_
>> address derived from that seed.
>>
>> --
>> Pieter
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160810/115775e9/attachment-0001.html>

From erik at q32.com  Thu Aug 11 13:55:51 2016
From: erik at q32.com (Erik Aronesty)
Date: Thu, 11 Aug 2016 09:55:51 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
Message-ID: <CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>

Sorr, I thought there was some BIP for a public seed such that someone can
generate new random addresses, but cannot trivially verify whether an
address was derived from the seed.

On Wed, Aug 10, 2016 at 1:38 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:

> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > By sending a public seed,  there's no way for someone to use the
> transmitted
> > address and trace the total amount of payments to it.
>
> Worse. By revealing a public seed, anyone who has seen it (= anyone
> who ever pays you through it) can identity all payments to _any_
> address derived from that seed.
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160811/b2cd5a11/attachment.html>

From tier.nolan at gmail.com  Thu Aug 11 15:13:19 2016
From: tier.nolan at gmail.com (Tier Nolan)
Date: Thu, 11 Aug 2016 16:13:19 +0100
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
Message-ID: <CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>

On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Sorr, I thought there was some BIP for a public seed such that someone can
> generate new random addresses, but cannot trivially verify whether an
> address was derived from the seed.
>

If you take a public key and multiply it by k, then the recipient can work
out the private key by multiplying their master private key by k.

If k is random, then the recipient wouldn't be able to work it out, but if
it is non-random, then everyone else can work it out.  You need some way to
get k to the recipient without others figuring it out.

This means either the system is interactive or you use a shared secret.

The info about the shared secret is included in the scriptPubKey (or the
more socially conscientious option, an OP_RETURN).

The address would indicate the master public key.

master_public = master_private * G

The transaction contains k*G.

Both sides can compute the shared secret.

secret = k*master_private*G = master_private*k*G

<encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub key))>
EQUALVERIFY CHECKSIG

This adds 34 bytes to the scriptPubKey.

This is pretty heavy for scanning for transactions sent to you.  You have
to check every transaction output to see if it is the given template.  Then
you have to do an ECC multiply to compute the shared secret.  Once you have
the shared secret, you need to do an ECC addition and a hash to figure out
if it matches the public key hash in the output.

This is approx one ECC multiply per output and is similar CPU load to what
you would need to do to actually verify a block.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160811/7ac1043e/attachment.html>

From erik at q32.com  Thu Aug 11 20:37:04 2016
From: erik at q32.com (Erik Aronesty)
Date: Thu, 11 Aug 2016 16:37:04 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
	<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
Message-ID: <CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>

Can't have shared secrets or interactivity for a public address to have the
love it needs.

Still not sure how you can take a BIP32 public seed and figure out if an
address was derived from it though.   I mean, wouldn't I have to compute
all 2^31 possible public child addresses?





On Thu, Aug 11, 2016 at 11:13 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thu, Aug 11, 2016 at 2:55 PM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Sorr, I thought there was some BIP for a public seed such that someone
>> can generate new random addresses, but cannot trivially verify whether an
>> address was derived from the seed.
>>
>
> If you take a public key and multiply it by k, then the recipient can work
> out the private key by multiplying their master private key by k.
>
> If k is random, then the recipient wouldn't be able to work it out, but if
> it is non-random, then everyone else can work it out.  You need some way to
> get k to the recipient without others figuring it out.
>
> This means either the system is interactive or you use a shared secret.
>
> The info about the shared secret is included in the scriptPubKey (or the
> more socially conscientious option, an OP_RETURN).
>
> The address would indicate the master public key.
>
> master_public = master_private * G
>
> The transaction contains k*G.
>
> Both sides can compute the shared secret.
>
> secret = k*master_private*G = master_private*k*G
>
> <encode(k*G)> DROP DUP HASH160 <hash160(encode(secret + pub key))>
> EQUALVERIFY CHECKSIG
>
> This adds 34 bytes to the scriptPubKey.
>
> This is pretty heavy for scanning for transactions sent to you.  You have
> to check every transaction output to see if it is the given template.  Then
> you have to do an ECC multiply to compute the shared secret.  Once you have
> the shared secret, you need to do an ECC addition and a hash to figure out
> if it matches the public key hash in the output.
>
> This is approx one ECC multiply per output and is similar CPU load to what
> you would need to do to actually verify a block.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160811/70953954/attachment.html>

From greg at xiph.org  Fri Aug 12 00:36:07 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Fri, 12 Aug 2016 00:36:07 +0000
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
	<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
	<CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
Message-ID: <CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>

On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Still not sure how you can take a BIP32 public seed and figure out if an
> address was derived from it though.   I mean, wouldn't I have to compute all
> 2^31 possible public child addresses?

Which would take a quad core laptop about 8 hours with competent software

And presumably you're not using the whole 2^31 space else the receiver
also has to do that computation...

From erik at q32.com  Fri Aug 12 12:36:31 2016
From: erik at q32.com (Erik Aronesty)
Date: Fri, 12 Aug 2016 08:36:31 -0400
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
	<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
	<CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
	<CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>
Message-ID: <CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>

I'm imagining a "publishable seed" such that:

 - someone can derive a random bitcoin address from it -  and send funds to
it.
 - the possible derived address space is large enough that generating all
possible addresses would be a barrier
 - the receiver, however, knowing the private key, can easily scan the
blockchain fairly efficiently and determine which addresses he has the keys
to
 - another interested party cannot easily do so

Perhaps homomorphic encryption may need to be involved?


On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg at xiph.org> wrote:

> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Still not sure how you can take a BIP32 public seed and figure out if an
> > address was derived from it though.   I mean, wouldn't I have to compute
> all
> > 2^31 possible public child addresses?
>
> Which would take a quad core laptop about 8 hours with competent software
>
> And presumably you're not using the whole 2^31 space else the receiver
> also has to do that computation...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160812/eadb6765/attachment.html>

From dev at jonasschnelli.ch  Fri Aug 12 12:47:31 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Fri, 12 Aug 2016 14:47:31 +0200
Subject: [bitcoin-dev] Authentication BIP
In-Reply-To: <57A9AA1E.9050302@jonasschnelli.ch>
References: <57A89EA3.4020101@jonasschnelli.ch>
	<57A8BCD9.7050402@AndySchroder.com>
	<CAAS2fgQ1LZO=A-bqkJUod2og006iqWJn7RnyWc5cYnnnUq5MHg@mail.gmail.com>
	<57A8C76D.1080405@AndySchroder.com> <57A9AA1E.9050302@jonasschnelli.ch>
Message-ID: <57ADC563.5090107@jonasschnelli.ch>

> Yes. I think this limitation could be removed.
> A responding node can have ? in theory ? multiple identity-keys per
> network interface (network interfaces is also confusing, because you
> could run multiple bitcoind instances on the same interface with
> different ports).
> 
> The BIP should just make clear, that it is probably wise, to use
> different identity-keys for each network interface (ipv4, v6, tor).
> 

I have updated that part of the BIP

-----------
Each peer can configure multiple identity-keys (ECC, 32 bytes). Peers
should make sure, each network interface (IPv4, IPv6, tor) has its own
identity-key (otherwise it would be possible to link a tor address to a
IPvX address).
The identity-public-key(s) can be shared over a different channel with
other node-operators (or non-validating clients) to grant authorized access.
-----------

https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/auth_bip?expand=1

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160812/c8a0c3c3/attachment.sig>

From jtimon at jtimon.cc  Fri Aug 12 15:49:23 2016
From: jtimon at jtimon.cc (=?UTF-8?B?Sm9yZ2UgVGltw7Nu?=)
Date: Fri, 12 Aug 2016 17:49:23 +0200
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
	<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
	<CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
	<CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>
	<CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>
Message-ID: <CABm2gDrBcq5Eipq1Rhq2sap=yKd_gWFtvQAB1Smc13DkNM9EUw@mail.gmail.com>

No, anyone with the bip32 public seed can do the same as the receiver as
"watch only". The only difference is rhat the receiver can actually spend
the coins. As gmaxwell explained, if it's expensive for everyone, it will
be also expensive for the receiver (assuming no interaction after the bip32
public seed is transfered).

Something different would be to give a different bip32 public seed to each
payer.  That way they can simply start with zero an increment with each new
payment. With those assumptions, the receiver could start listening to new
addresses only after they receive something in the previous address.

Probably not useful for this case, just thinking out loud about using bip32
public seeds instead of one use addresses when there's going to be several
payments from the same payer to the payee.

On Aug 12, 2016 2:37 PM, "Erik Aronesty via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm imagining a "publishable seed" such that:
>
>  - someone can derive a random bitcoin address from it -  and send funds
to it.
>  - the possible derived address space is large enough that generating all
possible addresses would be a barrier
>  - the receiver, however, knowing the private key, can easily scan the
blockchain fairly efficiently and determine which addresses he has the keys
to
>  - another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?
>
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg at xiph.org> wrote:
>>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Still not sure how you can take a BIP32 public seed and figure out if
an
>> > address was derived from it though.   I mean, wouldn't I have to
compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent software
>>
>> And presumably you're not using the whole 2^31 space else the receiver
>> also has to do that computation...
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160812/c7c37c71/attachment.html>

From macwhyte at gmail.com  Fri Aug 12 18:39:07 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Fri, 12 Aug 2016 18:39:07 +0000
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
	<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
	<CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
	<CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>
	<CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>
Message-ID: <CAH+Axy6WAk+ru8zJ3zU5L9-Rv3mY-YBg2V+U=yE7f5BnaNGqRw@mail.gmail.com>

For reasons others have pointed out, it's not really plausible.

Either way, this has nothing to do with transmitting data over audio.
Please start a new thread if you want to discuss your idea instead of
hijacking this one. Thanks ;)

On Fri, Aug 12, 2016, 05:36 Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I'm imagining a "publishable seed" such that:
>
>  - someone can derive a random bitcoin address from it -  and send funds
> to it.
>  - the possible derived address space is large enough that generating all
> possible addresses would be a barrier
>  - the receiver, however, knowing the private key, can easily scan the
> blockchain fairly efficiently and determine which addresses he has the keys
> to
>  - another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?
>
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell <greg at xiph.org> wrote:
>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Still not sure how you can take a BIP32 public seed and figure out if an
>> > address was derived from it though.   I mean, wouldn't I have to
>> compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent software
>>
>> And presumably you're not using the whole 2^31 space else the receiver
>> also has to do that computation...
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160812/e916cf2b/attachment-0001.html>

From nicolas.dorier at gmail.com  Sat Aug 13 02:25:04 2016
From: nicolas.dorier at gmail.com (Nicolas Dorier)
Date: Sat, 13 Aug 2016 11:25:04 +0900
Subject: [bitcoin-dev] BIP Number Request: Open Asset
In-Reply-To: <CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>
References: <CA+1nnrmZAdzBn-FMBVMGtp4n7bbG8W0VEGvi1WopS-M49zBXpw@mail.gmail.com>
	<201605260353.06939.luke@dashjr.org>
	<20160705174636.GA24068@fedora-21-dvm>
	<201607060122.20593.luke@dashjr.org>
	<CAH+Axy5A-_oDoPjabyzzAF8kVq9DsFwonEYPp9EU+Hf_BP1-DA@mail.gmail.com>
	<CA+1nnrmsU5kLxuW=GJSmy8C7s6F3EM8sgFYoXDg1iM-eD2qzsg@mail.gmail.com>
	<CAJowKgJys93VTFuGA3ydcuqxcx_O6r0D7715Kgfyc+SP4P8J9A@mail.gmail.com>
	<CAE28kUSaTsQ4qyGK5t5D1KiEF3yf4LEjkFvy+SiGxDK5VeAo9Q@mail.gmail.com>
	<CABbpET83UAt-TZfQsi0ZyhPAEznucc2yKYA4Md9y78=XH-vpmw@mail.gmail.com>
Message-ID: <CA+1nnrkXnFjRQ_+wpoOud0-ELqot+UhuG8UswC0EZ9-zWcjwBw@mail.gmail.com>

I think that regardless of merits protocol or limitations of protocols,
once they become used and stable they merit their place as a BIP.
I'd like to submit OA as is on flavien's repository, and update or reword
things once it is there. (so he can ACK easily and we can keep track of
changes instead of using mails back and forth)
It would be useful to have other colored coin protocols as well. (EPOBC and
Colu)

On Thu, Aug 4, 2016 at 9:37 PM, Flavien Charlon <
flavien.charlon at coinprism.com> wrote:

> Hi,
>
> > I would love to see an RFC-style standard "multiple-colored-coin-protocol"
> written by reps from all of the major protocols and that meta-merges the
> features of these implementations
>
> Alex summarizes the situation well. Efforts to come up with a
> "multiple-colored-coin-protocol" have failed since the different
> protocols take different assumptions and different tradeoffs and are built
> for different use cases. In the end, we ended up exactly in the same
> situation as the well known XKCD comic strip about standards (
> https://xkcd.com/927/).
>
> > You can, however, provide a new OA2.0 protocol that improves upon these
> issues, and assure that upgraded wallets maintain support for both versions.
>
> I don't think there is a point in doing that. This would just result in
> having yet another "standard", which nobody uses. Open Assets 1.0 took 3
> years to get where it is today, and is used by many companies across the
> industry. It has well over 20 different implementations, some open source,
> some proprietary.
>
> The goal of this process is to have OA 1.0 becoming the BIP since this is
> the one people are using.
>
> > I was waiting for clarification on the Author thing, but Nicholas hasn't
> responded yet. I am unaware of any reason NOT to assign it, and there
> appear to be no objections, so let's call it BIP 160.
>
> Nicolas is proposing the BIP on my behalf. I'll ACK as needed but he can
> drive the discussions.
>
> Best,
> Flavien
>
> On Tue, Aug 2, 2016 at 6:25 PM, Alex Mizrahi via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would love to see an RFC-style standard "multiple-colored-coin-protocol"
>>> written by reps from all of the major protocols and that meta-merges the
>>> features of these implementations
>>>
>>
>> We actually tried to do that in 2014-2015, but that effort have failed...
>> Nobody was really interested in collaboration, each company only cared
>> about it's own product.
>> Especially Colu, they asked everyone for requirements, and then developed
>> a new protocol completely on their own without taking anyone's input.
>>
>> I'm not sure that merging the protocols makes sense, as some protocols
>> value simplicity, and a combined protocol cannot have this feature.
>>
>> I don't think there is much interest in a merged colored coin protocol
>> now.
>> Colu is moving away from colored coins, as far as I can tell.
>> CoinSpark is now doing MultiChain closed-source private blockchain.
>> CoinPrism also seems to be largely disinterested in colored coins.
>>
>> We (ChromaWay) won't mind replacing EPOBC with something better, our
>> software could always support multiple different kernels so adding a new
>> protocol isn't a big deal for us.
>>
>> So if somebody is interested in a new protocol please ping me.
>>
>> One of ideas I have is to decouple input-output mapping/multiplexing from
>> coloring.
>> So one layer will describe a mapping, e.g. "Inputs 0 and 1 should go into
>> outputs 0, 1 and 2".
>> In this case it will be possible to create more advanced protocols (e.g.
>> with support for 'smart contracts' and whatnot) while also keeping them
>> compatible with old ones to some extent, e.g. a wallet can safely engage in
>> p2ptrade or CoinJoin transactions without understanding all protocols used
>> in a transaction.
>>
>>
>>> - in collaboration with feedback from core developers that understand
>>> the direction the protocol will be taking and the issues to avoid.
>>>
>>
>> Core developers generally dislike things like colored coins, so I doubt
>> they are going to help.
>>
>> Blockstream is developing a sidechain with user-defined assets, so I
>> guess they see it as the preferred way of doing things:
>> https://elementsproject.org/elements/asset-issuance/
>>
>>
>>> As it stands, investors have to install multiple wallets to deal with
>>> these varying implementations.
>>>
>>
>> Actually this can be solved without making a new "merged protocol": one
>> can just implement a wallet which supports multiple protocols.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160813/41706ad9/attachment.html>

From danielhoffman699 at gmail.com  Sat Aug 13 04:41:32 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Fri, 12 Aug 2016 23:41:32 -0500
Subject: [bitcoin-dev] BIP Number Request: Addresses over Audio
In-Reply-To: <CAH+Axy6WAk+ru8zJ3zU5L9-Rv3mY-YBg2V+U=yE7f5BnaNGqRw@mail.gmail.com>
References: <CAL9WuQUUeR3cuUXHxUfBTNJ-+r0iJ-7Z8KRNub0G3NBujnkqcw@mail.gmail.com>
	<CABqynxJ3uph-4A+Ynq70CLa2kCCspTRsFWpKo_eP1FmVxZqSwQ@mail.gmail.com>
	<CALd2G5dERuX2n33MGZJ+mtM8WnvtzZcWDFFUfNFZEGJFkkHLDg@mail.gmail.com>
	<CAL9WuQUt+CMG2bEX+yv3LrFV7qn-=OSdn02ZxxPQci-3_ykPNQ@mail.gmail.com>
	<CAL9WuQXsbBJ0UwdS+o=UqJCcsebcPa9Ug5A=uNtc6Z+9CNEFPg@mail.gmail.com>
	<CAAS2fgR-weACn_Ezg8-uZuSH0QT5dfLEFE5WO2VDi0nx8H1e9g@mail.gmail.com>
	<CAE-z3OXeJHvjyF_phVh2u9S45_xss=C9ykL=BN=n=BxTx+AbrQ@mail.gmail.com>
	<CAJowKg+yh+PgTE14=+pPUXFdB_AGrsgk3cNSFnTGDYecsxDP5g@mail.gmail.com>
	<CAFh0iXOLN6B27Fkc=GXo-j3VwA0hkNggCiQOhR35R52yQGwSwg@mail.gmail.com>
	<CAL9WuQXH8TAKRabPSrZzMzpFBwmujdv-uSXJLeTt9u3H9WAFGw@mail.gmail.com>
	<CAJowKgK0N9VJZsm4fbZ5VvteUjoQkh9-xhg1yfcD3NRTuFV78Q@mail.gmail.com>
	<CAPg+sBi6mPviRRKysbuuOFKoYoyTufpUO_rJxJdB-8=7KGurYw@mail.gmail.com>
	<CAJowKg+0Oz7+Gdfm=NSO9MqOqSYV8Uo=nOMtkx3CBrsemK+BtQ@mail.gmail.com>
	<CAE-z3OU7XgqivsGLXMyd2_cVRE3Kw2FNLGBU261q39=hq9TnEw@mail.gmail.com>
	<CAJowKgL39qFpGAVTkNoUUR7-M2VJxqkQ=X6yK3aTsGLRAo59Jw@mail.gmail.com>
	<CAAS2fgTrUKvG9Eff6jNhtKfiV9v8oMDsEA9rJaViYsw50Ub5sA@mail.gmail.com>
	<CAJowKgJBHq4YL47A5Ms=NhFL_uETBB7Q+XjETpAS=9o8EoSJMQ@mail.gmail.com>
	<CAH+Axy6WAk+ru8zJ3zU5L9-Rv3mY-YBg2V+U=yE7f5BnaNGqRw@mail.gmail.com>
Message-ID: <CAL9WuQXaX2CDwuTL51OdmYZmu=gcwQnViGAciOcCE1mLjjmGtA@mail.gmail.com>

I started work on the decoder. It works by comparing each cycle of the sine
wave recorded with a certain frequency (freq_t). The function that does
this currently returns the last sample that falls in that range over all
samples. The longest chain to match up with a certain frequency the best is
interpreted as that frequency (assuming it passes an entrance floor to
separate it from static).  I will probably extrapolate the sine wave to
more samples (320 kbps+), but this works OK just for testing. I am also
prepping the docs per the official BIP spec.

GitHub is https://github.com/Dako300/BIP-0170

Is it okay to host the BIP on my own GitHub, or do I need to host it on a
more official repository?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160812/68e9539c/attachment.html>

From laanwj at gmail.com  Sat Aug 13 06:58:40 2016
From: laanwj at gmail.com (Wladimir J. van der Laan)
Date: Sat, 13 Aug 2016 08:58:40 +0200
Subject: [bitcoin-dev] Bitcoin Core 0.13.0 release candidate 3 available
Message-ID: <20160813065840.GA29417@amethyst.visucore.com>

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

Binaries for bitcoin Core version 0.13.0rc3 are available from:

    https://bitcoin.org/bin/bitcoin-core-0.13.0/test.rc3/

Source code can be found on github under the signed tag

    https://github.com/bitcoin/bitcoin/tree/v0.13.0rc3

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found at

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

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.13.0.

Please report bugs using the issue tracker at github:

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

Notable changes since rc2:

### Block and transaction handling

- - #8364 `3f65ba2` Treat high-sigop transactions as larger rather than rejecting them (sipa)

### Tests and QA

- - #8444 `cd0910b` Fix p2p-feefilter.py for changed tx relay behavior (sdaftuar)

### Mining

- - #8489 `8b0eee6` Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (luke-jr)

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

iQEcBAEBCgAGBQJXrsS5AAoJEHSBCwEjRsmmH1oH/3PKk2rJIgMhsf4a8fuGJD7H
+j+ugsdRpjRGK8XKgnCisLQ8UJc2Z7dRbRYfdUb1ibkkCccMQJdmS6JAahWTe+Hb
N8GbODwZ5m4LrP2PA1gqNE/pwix/pqBY4GfR+TxXEbegNUNYDkvUzeUidcYGMAZd
LEAFrVnvsTAOQiwK3/pwa+sdWVNc0Jx/hHSZhouUtFmaqjXdg5M8ShmnRjyhVovI
GeuJ2s/3+uMtIX0g+kIOv16e0qYHJtIJMexMV5x4x1oWpXMYi2YeVDFSAkcKxA/z
5JOqlhDBK2lVMOKw8kYcNXKpvhXg9UBKImJDS0S4Bye8nMLQC6VEnkscOd7bupU=
=ae21
-----END PGP SIGNATURE-----

From cannon at cannon-ciota.info  Sun Aug 14 03:41:25 2016
From: cannon at cannon-ciota.info (Cannon)
Date: Sun, 14 Aug 2016 03:41:25 +0000
Subject: [bitcoin-dev] General bitcoin users mailing list?
Message-ID: <bdcfa3a2-50f0-08ea-dc69-2432cd3547e0@cannon-ciota.info>

I understand this mailing list is for topics relating to development. Is
there a general users mailing list for bitcoin related things such as
questions that are not necessarily related to dev?

-- 

Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon at cannon-ciota.info
Bitmessage Address: BM-2cVaTbC8fJ5UDDaBBs4jPQoFNp1PfNhxqU
Ricochet-IM: ricochet:hfddt2csxnsb2mdq

From danielhoffman699 at gmail.com  Sun Aug 14 04:14:34 2016
From: danielhoffman699 at gmail.com (Daniel Hoffman)
Date: Sat, 13 Aug 2016 23:14:34 -0500
Subject: [bitcoin-dev] General bitcoin users mailing list?
In-Reply-To: <bdcfa3a2-50f0-08ea-dc69-2432cd3547e0@cannon-ciota.info>
References: <bdcfa3a2-50f0-08ea-dc69-2432cd3547e0@cannon-ciota.info>
Message-ID: <CAL9WuQXuh7GFR=8Bv4t6rfxZ7-ODokBL75Z8k+A7-raCi_s_VQ@mail.gmail.com>

Have you tried out reddit's /r/btc and /r/Bitcoin?

On Sat, Aug 13, 2016 at 10:41 PM, Cannon via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I understand this mailing list is for topics relating to development. Is
> there a general users mailing list for bitcoin related things such as
> questions that are not necessarily related to dev?
>
> --
>
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon at cannon-ciota.info
> Bitmessage Address: BM-2cVaTbC8fJ5UDDaBBs4jPQoFNp1PfNhxqU
> Ricochet-IM: ricochet:hfddt2csxnsb2mdq
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160813/bff1a497/attachment.html>

From luke at dashjr.org  Sun Aug 14 04:22:40 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Sun, 14 Aug 2016 04:22:40 +0000
Subject: [bitcoin-dev] General bitcoin users mailing list?
In-Reply-To: <bdcfa3a2-50f0-08ea-dc69-2432cd3547e0@cannon-ciota.info>
References: <bdcfa3a2-50f0-08ea-dc69-2432cd3547e0@cannon-ciota.info>
Message-ID: <201608140422.42707.luke@dashjr.org>

On Sunday, August 14, 2016 3:41:25 AM Cannon via bitcoin-dev wrote:
> I understand this mailing list is for topics relating to development. Is
> there a general users mailing list for bitcoin related things such as
> questions that are not necessarily related to dev?

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

From luke at dashjr.org  Mon Aug 15 04:13:01 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Mon, 15 Aug 2016 04:13:01 +0000
Subject: [bitcoin-dev] Bitcoin Knots 0.13.0.knots20160814 released
Message-ID: <201608150413.06752.luke@dashjr.org>

Bitcoin Knots version 0.13.0.knots20160814 is now available from:

  <https://bitcoinknots.org/files/0.13.x/0.13.0.knots20160814/>

This is a new major version release, including new features, various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at github:

  <https://github.com/bitcoinknots/bitcoin/issues>

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

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

Non-mining nodes may influence miner policy
-------------------------------------------

As a side-effect of Compact Blocks support (see below), ordinary non-mining
nodes will download and upload blocks faster if those blocks were produced by
miners using similar transaction filtering policies. This means that a miner
who produces a block with many transactions discouraged by your node will be
relayed slower than one with only transactions already in your memory pool.

The overall effect of such relay differences on the network may result in
blocks which include widely-discouraged transactions losing a stale block
race, and therefore miners may wish to configure their node to take common
relay policies into consideration.

Because of this influence, ordinary nodes should review their mempool policy
configuration, and explicitly make informed decisions about what they wish
their policy to be. Miners should think about whether their current policy is
widely accepted by the community, and consider possibly making adjustments.

Many policy options are available in the GUI settings. For reference, the
equivalent bitcoin.conf settings are: `permitbaremultisig`, `acceptnonstdtxn`,
`bytespersigop`, `bytespersigopstrict`, `datacarrier`, `datacarriersize`,
`mempoolreplacement`, `spamfilter`, `maxorphantx`, `maxmempool`,
`mempoolexpiry`, `limitancestorcount`, `limitancestorsize`,
`limitdescendantcount`, and `limitdescendantsize`. Further details on the
config file options can be seen with the `-help` command line option.

(Note that nodes still respect a strict first-seen order for competing tip
blocks, and this change only affects relay speed to peer nodes.)

Database cache memory increased
--------------------------------

As a result of growth of the UTXO set, performance with the prior default
database cache of 100 MiB has suffered.
For this reason the default was changed to 300 MiB in this release.

For nodes on low-memory systems, the database cache can be changed back to
100 MiB (or to another value) by either:

- Adding `dbcache=100` in bitcoin.conf
- Changing it in the GUI under `Options ? Size of database cache`

Note that the database cache setting has the most performance impact
during initial sync of a node, and when catching up after downtime.

bitcoin-cli: arguments privacy
------------------------------

The RPC command line client gained a new argument, `-stdin`
to read extra arguments from standard input, one per line until EOF/Ctrl-D.
For example:

    $ src/bitcoin-cli -stdin walletpassphrase
    mysecretcode
    120
    ..... press Ctrl-D here to end input
    $

It is recommended to use this for sensitive information such as wallet
passphrases, as command-line arguments can usually be read from the process
table by any user on the system.

C++11 and Python 3
------------------

Various code modernizations have been done. The Bitcoin Knots code base has
started using C++11. This means that a C++11-capable compiler is now needed 
for building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or 
higher.

For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now
required.

Linux ARM builds
----------------

Due to popular request, Linux ARM builds have been added to the uploaded
executables.

The following extra files can be found in the download directory or torrent:

- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most
  common 32-bit ARM architecture.
- `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most
  common 64-bit ARM architecture.

ARM builds are still experimental. If you have problems on a certain device or
Linux distribution combination please report them on the bug tracker, it may 
be possible to resolve them.

Note that Android is not considered ARM Linux in this context. The executables
are not expected to work out of the box on Android.

Fee filtering of invs (BIP 133)
-------------------------------

The optional new p2p message "feefilter" is implemented and the protocol
version is bumped to 70013. Upon receiving a feefilter message from a peer,
a node will not send invs for any transactions which do not meet the filter
feerate. [BIP 133]
(https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki)

Compact Block support (BIP 152)
-------------------------------

Support for block relay using the Compact Blocks protocol has been implemented
in PR 8068.

The primary goal is reducing the bandwidth spikes at relay time, though in 
many cases it also reduces propagation delay. It is automatically enabled 
between compatible peers.
[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)

Hierarchical Deterministic Key Generation
-----------------------------------------
Newly created wallets will use hierarchical deterministic key generation
according to BIP32 (keypath m/0'/0'/k').
Existing wallets will still use traditional key generation.

Backups of HD wallets, regardless of when they have been created, can
therefore be used to re-generate all possible private keys, even the
ones which haven't already been generated during the time of the backup.
**Attention:** Encrypting the wallet will create a new seed which requires
a new backup!

HD key generation for new wallets can be disabled by `-usehd=0`. Keep in
mind that this flag only has affect on newly created wallets.
You can't disable HD key generation once you have created a HD wallet.

There is no distinction between internal (change) and external keys.

HD wallets are incompatible with older versions of Bitcoin Knots.

[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32]
(https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)

Segregated Witness
------------------

The code preparations for Segregated Witness ("segwit"), as described in [BIP
141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), [BIP
143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), [BIP
144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), and [BIP
145](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) are
finished and included in this release.  However, BIP 141 does not yet specify
activation parameters on mainnet, and so this release does not support segwit
use on mainnet.  Testnet use is supported, and after BIP 141 is updated with
proposed parameters, a future release of Bitcoin Knots is expected that
implements those parameters for mainnet.

Furthermore, because segwit activation is not yet specified for mainnet,
version 0.13.0 will behave similarly as other pre-segwit releases even after a
future activation of BIP 141 on the network.  Upgrading from 0.13.0 will be
required in order to utilize segwit-related features on mainnet (such as 
signal BIP 141 activation, mine segwit blocks, fully validate segwit blocks, 
relay segwit blocks to other segwit nodes, and use segwit transactions in the
wallet, etc).

Mining transaction selection ("Child Pays For Parent")
------------------------------------------------------

The mining transaction selection algorithm has been replaced with an algorithm
that selects transactions based on their feerate inclusive of unconfirmed
ancestor transactions.  This means that a low-fee transaction can become more
likely to be selected if a high-fee transaction that spends its outputs is
relayed.

With this change, the `-blockminsize` command line option has been removed.

The command line option `-blockmaxsize` remains an option to specify the
maximum number of serialized bytes in a generated block.  In addition, the new
command line option `-blockmaxweight` has been added, which specifies the
maximum "block weight" of a generated block, as defined by [BIP 141 
(Segregated Witness)] 
(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).

In preparation for Segregated Witness, the mining algorithm has been modified
to choose transactions to mine based on their block weight, rather than number
of serialized bytes.  In this release, transaction selection is unaffected by
this distinction (as BIP 141 activation is not supported on mainnet in this
release, see above), but in future releases and after BIP 141 activation,
these calculations would be expected to differ.

Reindexing changes
------------------

In earlier versions, reindexing did validation while reading through the block
files on disk. These two have now been split up, so that all blocks are known
before validation starts. This was necessary to make certain optimizations 
that are available during normal synchronizations also available during 
reindexing.

The two phases are distinct in the Bitcoin-Qt GUI. During the first one,
"Reindexing blocks on disk" is shown. During the second (slower) one,
"Processing blocks on disk" is shown.

It is possible to only redo validation now, without rebuilding the block 
index, using the command line option `-reindex-chainstate` (in addition to
`-reindex` which does both). This new option is useful when the blocks on disk
are assumed to be fine, but the chainstate is still corrupted. It is also
useful for benchmarks.

Removal of internal miner
--------------------------

As CPU mining has been useless for a long time, the internal miner has been
removed in this release, and replaced with a simpler implementation for the
test framework.

The overall result of this is that `setgenerate` RPC call has been removed, as
well as the `-gen` and `-genproclimit` command-line options.

For testing, the `generate` call can still be used to mine a block, and a new
RPC call `generatetoaddress` has been added to mine to a specific address. 
This works with wallet disabled.

New bytespersigop implementation
--------------------------------

The former implementation of the bytespersigop filter accidentally broke bare
multisig (which is meant to be controlled by the `permitbaremultisig` option),
since the consensus protocol always counts these older transaction forms as 20
sigops for backwards compatibility. Simply fixing this bug by counting more
accurately would have reintroduced a vulnerability. It has therefore been
replaced with a new implementation that rather than filter such transactions,
instead treats them (for fee purposes only) as if they were in fact the size
of a transaction actually using all 20 sigops.

The original filtering behaviour is also available under the new
`bytespersigopstrict` option, but with fixed/accurate sigop counting.

Low-level P2P changes
----------------------

- The P2P alert system has been removed in PR #7692 and the `alert` P2P
  message is no longer supported.

- The transaction relay mechanism used to relay one quarter of all
  transactions instantly, while queueing up the rest and sending them out in
  batch. As this resulted in chains of dependent transactions being reordered,
  it systematically hurt transaction relay. The relay code was redesigned in
  PRs #7840 and #8082, and now always batches transactions announcements while
  also sorting them according to dependency order. This significantly reduces
  orphan transactions. To compensate for the removal of instant relay, the
  frequency of batch sending was doubled for outgoing peers.

- Since PR #7840 the BIP35 `mempool` command is also subject to batch
  processing. Also the `mempool` message is no longer handled for
  non-whitelisted peers when `NODE_BLOOM` is disabled through
  `-peerbloomfilters=0`.

- The maximum size of orphan transactions that are kept in memory until their
  ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They
  are now also removed from memory when they are included in a block, conflict
  with a block, and time out after 20 minutes.

- We respond at most once to a getaddr request during the lifetime of a
  connection since PR #7856.

- Connections to peers who have recently been the first one to give us a valid
  new block or transaction are protected from disconnections since PR #8084.

Low-level RPC changes
----------------------

- `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a
  divergence between 32-bit and 64-bit platforms, and the txids were missing
  in the hashed data. This has been fixed, but this means that the output will
  be different than from previous versions.

- Full UTF-8 support in the RPC API. Non-ASCII characters in, for example,
  wallet labels have always been malformed because they weren't taken into
  account properly in JSON RPC processing. This is no longer the case. This
  also affects the GUI debug console. (This may require upgrading system
  UniValue library.)

- Asm script outputs replacements for OP_NOP2 and OP_NOP3

  - OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP 
65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)

  - OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP 
112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)

  - The following outputs are affected by this change:

    - RPC `getrawtransaction` (in verbose mode)
    - RPC `decoderawtransaction`
    - RPC `decodescript`
    - REST `/rest/tx/` (JSON format)
    - REST `/rest/block/` (JSON format when including extended tx details)
    - `bitcoin-tx -json`

- The sorting of the output of the `getrawmempool` output has changed.

- New RPC commands: `generatetoaddress`, `importprunedfunds`, 
`removeprunedfunds`, `signmessagewithprivkey`,
  `createwitnessaddress`, `addwitnessaddress`.

- Removed RPC commands: `setgenerate`, `getgenerate`.

- New `feeRate` option was added to `fundrawtransaction`

Low-level ZMQ changes
----------------------

- Each ZMQ notification now contains an up-counting sequence number that
  allows listeners to detect lost notifications.
  The sequence number is always the last element in a multi-part ZMQ
  notification and therefore backward compatible. Each message type has its
  own counter. PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762).

0.13.0.knots20160814 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. Changes specific to Bitcoin Knots (beyond
Core) are flagged with an asterisk ('*') before the description.

### RPC and other APIs

- #7156 `9ee02cf` Remove cs_main lock from `createrawtransaction` (laanwj)
- #7326 `2cd004b` Fix typo, wrong information in gettxout help text 
(paveljanik)
- #7222 `82429d0` Indicate which transactions are signaling opt-in RBF 
(sdaftuar)
- #7480 `b49a623` Changed getnetworkhps value to double to avoid overflow 
(instagibbs)
- #7550 `8b958ab` Input-from-stdin mode for bitcoin-cli (laanwj)
- #7670 `c9a1265` Use cached block hash in blockToJSON() (rat4)
- #7726 `9af69fa` Correct importaddress help reference to importpubkey 
(CypherGrue)
- #7766 `16555b6` Register calls where they are defined (laanwj)
- #7797 `e662a76` Fix generatetoaddress failing to parse address (mruddy)
- #7774 `916b15a` Add versionHex in getblock and getblockheader JSON results 
(mruddy)
- #7863 `72c54e3` Getblockchaininfo: make bip9_softforks an object, not an 
array (rustyrussell)
- #7842 `d97101e` Do not print minping time in getpeerinfo when no ping 
received yet (paveljanik)
- #7518 `be14ca5` Add multiple options to fundrawtransaction (promag)
- #7756 `9e47fce` Add cursor to iterate over utxo set, use this in 
`gettxoutsetinfo` (laanwj)
- #7848 `88616d2` Divergence between 32- and 64-bit when hashing >4GB affects 
`gettxoutsetinfo` (laanwj)
- #7827 `4205ad7` Speed up `getchaintips` (mrbandrews)
- #7762 `a1eb344` Append a message sequence number to every ZMQ notification 
(jonasschnelli)
- #7688 `46880ed` List solvability in listunspent output and improve help 
(sipa)
- #7926 `5725807` Push back `getaddednodeinfo` dead value (instagibbs)
- #7953 `0630353` Create `signmessagewithprivkey` rpc (achow101)
- #8049 `c028c7b` Expose information on whether transaction relay is enabled 
in `getnetworkinfo` (laanwj)
- #7967 `8c1e49b` Add feerate option to `fundrawtransaction` (jonasschnelli)
- #8118 `9b6a48c` Reduce unnecessary hashing in `signrawtransaction` 
(jonasnick)
- #7957 `79004d4` Add support for transaction sequence number (jonasschnelli)
- #8153 `75ec320` `fundrawtransaction` feeRate: Use BTC/kB (MarcoFalke)
- #7292 `7ce9ac5` Expose ancestor/descendant information over RPC (sdaftuar)
- #8171 `62fcf27` Fix createrawtx sequence number unsigned int parsing 
(jonasschnelli)
- #7892 `9c3d0fa` Add full UTF-8 support to RPC (laanwj)
- #8317 `304eff3` Don't use floating point in rpcwallet (MarcoFalke)
- #8258 `5a06ebb` Hide softfork in `getblockchaininfo` if timeout is 0 
(jl2012)
- #8244 `1922e5a` Remove unnecessary LOCK(cs_main) in getrawmempool (dcousens)

### Block and transaction handling

- #7056 `6a07208` Save last db read (morcos)
- #6842 `0192806` Limitfreerelay edge case bugfix (ptschip)
- #7084 `11d74f6` Replace maxFeeRate of 10000*minRelayTxFee with maxTxFee in 
mempool (MarcoFalke)
- #7539 `9f33dba` Add tags to mempool's mapTx indices (sdaftuar)
- #7592 `26a2a72` Re-remove ERROR logging for mempool rejects (laanwj)
- #7187 `14d6324` Keep reorgs fast for SequenceLocks checks (morcos)
- #7594 `01f4267` Mempool: Add tracking of ancestor packages (sdaftuar)
- #7904 `fc9e334` Txdb: Fix assert crash in new UTXO set cursor (laanwj)
- #7927 `f9c2ac7` Minor changes to dbwrapper to simplify support for other 
databases (laanwj)
- #7933 `e26b620` Fix OOM when deserializing UTXO entries with invalid length 
(sipa)
- #8020 `5e374f7` Use SipHash-2-4 for various non-cryptographic hashes (sipa)
- #8076 `d720980` VerifyDB: don't check blocks that have been pruned 
(sdaftuar)
- #8080 `862fd24` Do not use mempool for GETDATA for tx accepted after the 
last mempool req (gmaxwell)
- #7997 `a82f033` Replace mapNextTx with slimmer setSpends (kazcw)
- #8220 `1f86d64` Stop trimming when mapTx is empty (sipa)
- #8273 `396f9d6` Bump `-dbcache` default to 300MiB (laanwj)
- #7225 `eb33179` Eliminate unnecessary call to CheckBlock (sdaftuar)
- #7907 `006cdf6` Optimize and Cleanup CScript::FindAndDelete (pstratem)
- #7917 `239d419` Optimize reindex (sipa)
- #7763 `3081fb9` Put hex-encoded version in UpdateTip (sipa)
- #8149 `d612837` Testnet-only segregated witness (sipa)
- #8305 `3730393` Improve handling of unconnecting headers (sdaftuar)
- #8363 `fca1a41` Rename "block cost" to "block weight" (sdaftuar)
- #8381 `f84ee3d` Make witness v0 outputs non-standard (jl2012)
- #8364 `3f65ba2` Treat high-sigop transactions as larger rather than 
rejecting them (sipa)
- n/a   `15edeeb` *Add a new checkpoint at block 421,888 (luke-jr)
- n/a   `6ae2e2d` *Restore original bytespersigop as bytespersigopstrict 
(luke-jr)

### P2P protocol and network code

- #6589 `dc0305d` Log bytes recv/sent per command (jonasschnelli)
- #7164 `3b43cad` Do not download transactions during initial blockchain sync 
(ptschip)
- #7458 `898fedf` peers.dat, banlist.dat recreated when missing (kirkalx)
- #7637 `3da5d1b` Fix memleak in TorController (laanwj, jonasschnelli)
- #7553 `9f14e5a` Remove vfReachable and modify IsReachable to only use 
vfLimited (pstratem)
- #7708 `9426632` De-neuter NODE_BLOOM (pstratem)
- #7692 `29b2be6` Remove P2P alert system (btcdrak)
- #7542 `c946a15` Implement "feefilter" P2P message (morcos)
- #7573 `352fd57` Add `-maxtimeadjustment` command line option (mruddy)
- #7570 `232592a` Add IPv6 Link-Local Address Support (mruddy)
- #7874 `e6a4d48` Improve AlreadyHave (morcos)
- #7856 `64e71b3` Only send one GetAddr response per connection (gmaxwell)
- #7868 `7daa3ad` Split DNS resolving functionality out of net structures 
(theuni)
- #7919 `7617682` Fix headers announcements edge case (sdaftuar)
- #7514 `d9594bf` Fix IsInitialBlockDownload for testnet (jmacwhyte)
- #7959 `03cf6e8` fix race that could fail to persist a ban (kazcw)
- #7840 `3b9a0bf` Several performance and privacy improvements to inv/mempool 
handling (sipa)
- #8011 `65aecda` Don't run ThreadMessageHandler at lowered priority (kazcw)
- #7696 `5c3f8dd` Fix de-serialization bug where AddrMan is left corrupted 
(EthanHeilman)
- #7932 `ed749bd` CAddrMan::Deserialize handle corrupt serializations better 
(pstratem)
- #7906 `83121cc` Prerequisites for p2p encapsulation changes (theuni)
- #8033 `18436d8` Fix Socks5() connect failures to be less noisy and less 
unnecessarily scary (wtogami)
- #8082 `01d8359` Defer inserting into maprelay until just before relaying 
(gmaxwell)
- #7960 `6a22373` Only use AddInventoryKnown for transactions (sdaftuar)
- #8078 `2156fa2` Disable the mempool P2P command when bloom filters disabled 
(petertodd)
- #8065 `67c91f8` Addrman offline attempts (gmaxwell)
- #7703 `761cddb` Tor: Change auth order to only use password auth if -
torpassword (laanwj)
- #8083 `cd0c513` Add support for dnsseeds with option to filter by 
servicebits (jonasschnelli)
- #8173 `4286f43` Use SipHash for node eviction (sipa)
- #8154 `1445835` Drop vAddrToSend after sending big addr message (kazcw)
- #7749 `be9711e` Enforce expected outbound services (sipa)
- #8208 `0a64777` Do not set extra flags for unfiltered DNS seed results 
(sipa)
- #8084 `e4bb4a8` Add recently accepted blocks and txn to 
AttemptToEvictConnection (gmaxwell)
- #8113 `3f89a53` Rework addnode behaviour (sipa)
- #8179 `94ab58b` Evict orphans which are included or precluded by accepted 
blocks (gmaxwell)
- #8068 `e9d76a1` Compact Blocks (TheBlueMatt)
- #8204 `0833894` Update petertodd's testnet seed (petertodd)
- #8247 `5cd35d3` Mark my dnsseed as supporting filtering (sipa)
- #8275 `042c323` Remove bad chain alert partition check (btcdrak)
- #8271 `1bc9c80` Do not send witnesses in cmpctblock (sipa)
- #8312 `ca40ef6` Fix mempool DoS vulnerability from malleated transactions 
(sdaftuar)
- #7180 `16ccb74` Account for `sendheaders` `verack` messages (laanwj)
- #8102 `425278d` Bugfix: use global ::fRelayTxes instead of CNode in version 
send (sipa)
- #8408 `b7e2011` Prevent fingerprinting, disk-DoS with compact blocks 
(sdaftuar)

### Build system

- #7302 `41f1a3e` C++11 build/runtime fixes (theuni)
- #7322 `fd9356b` c++11: add scoped enum fallbacks to CPPFLAGS rather than 
defining them locally (theuni)
- #7441 `a6771fc` Use Debian 8.3 in gitian build guide (fanquake)
- #7349 `152a821` Build against system UniValue when available (luke-jr)
- #7520 `621940e` LibreSSL doesn't define OPENSSL_VERSION, use 
LIBRESSL_VERSION_TEXT instead (paveljanik)
- #7528 `9b9bfce` autogen.sh: warn about needing autoconf if autoreconf is not 
found (knocte)
- #7504 `19324cf` Crystal clean make clean (paveljanik)
- #7619 `18b3f1b` Add missing sudo entry in gitian VM setup (btcdrak)
- #7616 `639ec58`  [depends] Delete unused patches  (MarcoFalke)
- #7658 `c15eb28` Add curl to Gitian setup instructions (btcdrak)
- #7710 `909b72b` [Depends] Bump miniupnpc and config.guess+sub (fanquake)
- #7723 `5131005` build: python 3 compatibility (laanwj)
- #7477 `28ad4d9` Fix quoting of copyright holders in configure.ac (domob1812)
- #7711 `a67bc5e` [build-aux] Update Boost & check macros to latest serials 
(fanquake)
- #7788 `4dc1b3a` Use relative paths instead of absolute paths in protoc calls 
(paveljanik)
- #7809 `bbd210d` depends: some base fixes/changes (theuni)
- #7603 `73fc922` Build System: Use PACKAGE_TARNAME in NSIS script 
(JeremyRand)
- #7905 `187186b` test: move accounting_tests and rpc_wallet_tests to 
wallet/test (laanwj)
- #7911 `351abf9` leveldb: integrate leveldb into our buildsystem (theuni)
- #7944 `a407807` Re-instate TARGET_OS=linux in configure.ac. Removed by 
351abf9e035 (randy-waterhouse)
- #7920 `c3e3cfb` Switch Travis to Trusty (theuni)
- #7954 `08b37c5` build: quiet annoying warnings without adding new ones 
(theuni)
- #7165 `06162f1` build: Enable C++11 in build, require C++11 compiler 
(laanwj)
- #7982 `559fbae` build: No need to check for leveldb atomics (theuni)
- #8002 `f9b4582` [depends] Add -stdlib=libc++ to darwin CXX flags (fanquake)
- #7993 `6a034ed` [depends] Bump Freetype, ccache, ZeroMQ, miniupnpc, expat 
(fanquake)
- #8167 `19ea173` Ship debug tarballs/zips with debug symbols (theuni)
- #8175 `f0299d8` Add --disable-bench to config flags for windows (laanwj)
- #7283 `fd9881a` [gitian] Default reference_datetime to commit author date 
(MarcoFalke)
- #8181 `9201ce8` Get rid of `CLIENT_DATE` (laanwj)
- #8133 `fde0ac4` Finish up out-of-tree changes (theuni)
- #8188 `65a9d7d` Add armhf/aarch64 gitian builds (theuni)
- #8194 `cca1c8c` [gitian] set correct PATH for wrappers (MarcoFalke)
- #8198 `5201614` Sync ax_pthread with upstream draft4 (fanquake)
- #8210 `12a541e` [Qt] Bump to Qt5.6.1 (jonasschnelli)
- #8285 `da50997` windows: Add testnet link to installer (laanwj)
- #8304 `0cca2fe` [travis] Update SDK_URL (MarcoFalke)
- #8310 `6ae20df` Require boost for bench (theuni)
- #8315 `2e51590` Don't require sudo for Linux (theuni)
- #8314 `67caef6` Fix pkg-config issues for 0.13 (theuni)
- #8373 `1fe7f40` Fix OSX non-deterministic dmg (theuni)
- #8358 `cfd1280` Gbuild: Set memory explicitly (default is too low) 
(MarcoFalke)
- #8492 `216d796` *configure: Allow building bench_bitcoin by itself (luke-jr)
- n/a   `2271350` *Qt/Options: Fix warning about comparing signed/unsigned 
(luke-jr)

### GUI

- #7154 `00b4b8d` Add InMempool() info to transaction details (jonasschnelli)
- #7068 `5f3c670` [RPC-Tests] add simple way to run rpc test over QT clients 
(jonasschnelli)
- #7218 `a1c185b` Fix misleading translation (MarcoFalke)
- #7214 `be9a9a3` qt5: Use the fixed font the system recommends (MarcoFalke)
- #7256 `08ab906` Add note to coin control dialog QT5 workaround (fanquake)
- #7255 `e289807` Replace some instances of formatWithUnit with 
formatHtmlWithUnit (fanquake)
- #7317 `3b57e9c` Fix RPCTimerInterface ordering issue (jonasschnelli)
- #7327 `c079d79` Transaction View: LastMonth calculation fixed (crowning-)
- #7334 `e1060c5` coincontrol workaround is still needed in qt5.4 (fixed in 
qt5.5) (MarcoFalke)
- #7383 `ae2db67` Rename "amount" to "requested amount" in receive coins table 
(jonasschnelli)
- #7396 `cdcbc59` Add option to increase/decrease font size in the console 
window (jonasschnelli)
- #7437 `9645218` Disable tab navigation for peers tables (Kefkius)
- #7604 `354b03d` build: Remove spurious dollar sign. Fixes #7189 (dooglus)
- #7605 `7f001bd` Remove openssl info from init/log and from Qt debug window 
(jonasschnelli)
- #7628 `87d6562` Add 'copy full transaction details' option (ericshawlinux)
- #7613 `3798e5d` Add autocomplete to bitcoin-qt's console window (GamerSg)
- #7668 `b24266c` Fix history deletion bug after font size change (achow101)
- #7680 `41d2dfa` Remove reflection from `about` icon (laanwj)
- #7686 `f034bce` Remove 0-fee from send dialog (MarcoFalke)
- #7506 `b88e0b0` Use CCoinControl selection in CWallet::FundTransaction 
(promag)
- #7732 `0b98dd7` Debug window: replace "Build date" with "Datadir" 
(jonasschnelli)
- #7761 `60db51d` remove trailing output-index from transaction-id 
(jonasschnelli)
- #7772 `6383268` Clear the input line after activating autocomplete 
(paveljanik)
- #7925 `f604bf6` Fix out-of-tree GUI builds (laanwj)
- #7939 `574ddc6` Make it possible to show details for multiple transactions 
(laanwj)
- #8012 `b33824b` Delay user confirmation of send (Tyler-Hardin)
- #8006 `7c8558d` Add option to disable the system tray icon (Tyler-Hardin)
- #8046 `169d379` Fix Cmd-Q / Menu Quit shutdown on OSX (jonasschnelli)
- #8042 `6929711` Don't allow to open the debug window during splashscreen & 
verification state (jonasschnelli)
- #8014 `77b49ac` Sort transactions by date (Tyler-Hardin)
- #8073 `eb2f6f7` askpassphrasedialog: Clear pass fields on accept (rat4)
- #8129 `ee1533e` Fix RPC console auto completer (UdjinM6)
- #7636 `fb0ac48` Add bitcoin address label to request payment QR code 
(makevoid)
- #8231 `760a6c7` Fix a bug where the SplashScreen will not be hidden during 
startup (jonasschnelli)
- #8256 `af2421c` BUG: bitcoin-qt crash (fsb4000)
- #8257 `ff03c50` Do not ask a UI question from bitcoind (sipa)
- #8288 `91abb77` Network-specific example address (laanwj)
- #7707 `a914968` UI support for abandoned transactions (jonasschnelli)
- #8207 `f7a403b` Add a link to the Bitcoin-Core repository and website to the 
About Dialog (MarcoFalke)
- #8281 `6a87eb0` Remove client name from debug window (laanwj)
- #8407 `45eba4b` Add dbcache migration path (jonasschnelli)
- n/a   `1e345d2` *Qt/Options: Replace blockminsize with blockmaxweight (luke-
jr)
- n/a   `2185e93` *Qt/Options: Update for bytespersigopstrict (luke-jr)
- n/a   `2da1d28` *Recognise NODE_XTHIN service bit (luke-jr)

### Wallet

- #7262 `fc08994` Reduce inefficiency of GetAccountAddress() (dooglus)
- #7537 `78e81b0` Warn on unexpected EOF while salvaging wallet (laanwj)
- #7521 `3368895` Don't resend wallet txs that aren't in our own mempool 
(morcos)
- #7576 `86a1ec5` Move wallet help string creation to CWallet (jonasschnelli)
- #7577 `5b3b5a7` Move "load wallet phase" to CWallet (jonasschnelli)
- #7608 `0735c0c` Move hardcoded file name out of log messages (MarcoFalke)
- #7649 `4900641` Prevent multiple calls to CWallet::AvailableCoins (promag)
- #7646 `e5c3511` Fix lockunspent help message (promag)
- #7558 `b35a591` Add import/removeprunedfunds rpc call (instagibbs)
- #7691 `30c2dd8` Refactor wallet/init interaction (jonasschnelli)
- #6215 `48c5adf` add bip32 pub key serialization (jonasschnelli)
- #7913 `bafd075` Fix for incorrect locking in GetPubKey() (keystore.cpp) 
(yurizhykin)
- #7816 `0c95ebc` Slighly refactor GetOldestKeyPoolTime() (jonasschnelli)
- #8036 `41138f9` init: Move berkeleydb version reporting to wallet (laanwj)
- #8028 `373b50d` Fix insanity of CWalletDB::WriteTx and 
CWalletTx::WriteToDisk (pstratem)
- #8061 `f6b7df3` Improve Wallet encapsulation (pstratem)
- #7891 `950be19` Always require OS randomness when generating secret keys 
(sipa)
- #7689 `b89ef13` Replace OpenSSL AES with ctaes-based version (sipa)
- #7825 `f972b04` Prevent multiple calls to ExtractDestination (pedrobranco)
- #8137 `243ac0c` Improve CWallet API with new AccountMove function (pstratem)
- #8142 `52c3f34` Improve CWallet API  with new GetAccountPubkey function 
(pstratem)
- #8035 `b67a472` Add simplest BIP32/deterministic key generation 
implementation (jonasschnelli)
- #7687 `a6ddb19` Stop treating importaddress'ed scripts as change (sipa)
- #8298 `aef3811` wallet: Revert input selection post-pruning (laanwj)
- #8324 `bc94b87` Keep HD seed during salvagewallet (jonasschnelli)
- #8323 `238300b` Add HD keypath to CKeyMetadata, report metadata in 
validateaddress (jonasschnelli)
- #8367 `3b38a6a` Ensure <0.13 clients can't open HD wallets (jonasschnelli)
- #8378 `ebea651` Move SetMinVersion for FEATURE_HD to SetHDMasterKey 
(pstratem)
- #8390 `73adfe3` Correct hdmasterkeyid/masterkeyid name confusion 
(jonasschnelli)
- #8206 `18b8ee1` Add HD xpriv to dumpwallet (jonasschnelli)
- #8389 `c3c82c4` Create a new HD seed after encrypting the wallet 
(jonasschnelli)
- n/a   `9480ef4` *wallet: Prevent key origin support for HD wallets, since 
they are incompatible (luke-jr)

### Tests and QA

- #7320 `d3dfc6d` Test walletpassphrase timeout (MarcoFalke)
- #7208 `47c5ed1` Make max tip age an option instead of chainparam (laanwj)
- #7372 `21376af` Trivial: [qa] wallet: Print maintenance (MarcoFalke)
- #7280 `668906f` [travis] Fail when documentation is outdated (MarcoFalke)
- #7177 `93b0576` [qa] Change default block priority size to 0 (MarcoFalke)
- #7236 `02676c5` Use createrawtx locktime parm in txn_clone (dgenr8)
- #7212 `326ffed` Adds unittests for CAddrMan and CAddrinfo, removes source of 
non-determinism (EthanHeilman)
- #7490 `d007511` tests: Remove May15 test (laanwj)
- #7531 `18cb2d5` Add bip68-sequence.py to extended rpc tests (btcdrak)
- #7536 `ce5fc02` test: test leading spaces for ParseHex (laanwj)
- #7620 `1b68de3` [travis] Only run check-doc.py once (MarcoFalke)
- #7455 `7f96671` [travis] Exit early when check-doc.py fails (MarcoFalke)
- #7667 `56d2c4e` Move GetTempPath() to testutil (musalbas)
- #7517 `f1ca891` test: script_error checking in script_invalid tests (laanwj)
- #7684 `3d0dfdb` Extend tests (MarcoFalke)
- #7697 `622fe6c` Tests: make prioritise_transaction.py more robust (sdaftuar)
- #7709 `efde86b` Tests: fix missing import in mempool_packages (sdaftuar)
- #7702 `29e1131` Add tests verifychain, lockunspent, getbalance, 
listsinceblock (MarcoFalke)
- #7720 `3b4324b` rpc-test: Normalize assert() (MarcoFalke)
- #7757 `26794d4` wallet: Wait for reindex to catch up (MarcoFalke)
- #7764 `a65b36c` Don't run pruning.py twice (MarcoFalke)
- #7773 `7c80e72` Fix comments in tests (btcdrak)
- #7489 `e9723cb` tests: Make proxy_test work on travis servers without IPv6 
(laanwj)
- #7778 `ff5874b` Bug fixes and refactor (MarcoFalke)
- #7801 `70ac71b` Remove misleading "errorString syntax" (MarcoFalke)
- #7803 `401c65c` maxblocksinflight: Actually enable test (MarcoFalke)
- #7802 `3bc71e1` httpbasics: Actually test second connection (MarcoFalke)
- #7818 `3911a0a` Refactor script tests (sipa)
- #7849 `ab8586e` tests: add varints_bitpatterns test (laanwj)
- #7846 `491171f` Clean up lockorder data of destroyed mutexes (sipa)
- #7853 `6ef5e00` py2: Unfiddle strings into bytes explicitly (MarcoFalke)
- #7878 `53adc83` [test] bctest.py: Revert faa41ee (MarcoFalke)
- #7798 `cabba24` [travis] Print the commit which was evaluated (MarcoFalke)
- #7833 `b1bf511` tests: Check Content-Type header returned from RPC server 
(laanwj)
- #7851 `fa9d86f` pull-tester: Don't mute zmq ImportError (MarcoFalke)
- #7822 `0e6fd5e` Add listunspent() test for spendable/unspendable UTXO 
(jpdffonseca)
- #7912 `59ad568` Tests: Fix deserialization of reject messages (sdaftuar)
- #7941 `0ea3941` Fixing comment in script_test.json test case (Christewart)
- #7807 `0ad1041` Fixed miner test values, gave constants for less error-prone 
values (instagibbs)
- #7980 `88b77c7` Smartfees: Properly use ordered dict (MarcoFalke)
- #7814 `77b637f` Switch to py3 (MarcoFalke)
- #8030 `409a8a1` Revert fatal-ness of missing python-zmq (laanwj)
- #8018 `3e90fe6` Autofind rpc tests --srcdir (jonasschnelli)
- #7971 `4e14afe` Refactor test_framework and pull tester (MarcoFalke)
- #8016 `5767e80` Fix multithread CScheduler and reenable test (paveljanik)
- #7972 `423ca30` pull-tester: Run rpc test in parallel  (MarcoFalke)
- #8039 `69b3a6d` Bench: Add crypto hash benchmarks (laanwj)
- #8041 `5b736dd` Fix bip9-softforks blockstore issue (MarcoFalke)
- #7994 `1f01443` Add op csv tests to script_tests.json (Christewart)
- #8038 `e2bf830` Various minor fixes (MarcoFalke)
- #8072 `1b87e5b` Travis: 'make check' in parallel and verbose (MarcoFalke)
- #8056 `8844ef1` Remove hardcoded "4 nodes" from test_framework (MarcoFalke)
- #8047 `37f9a1f` Test_framework: Set wait-timeout for bitcoind procs 
(MarcoFalke)
- #8095 `6700cc9` Test framework: only cleanup on successful test runs 
(sdaftuar)
- #8098 `06bd4f6` Test_framework: Append portseed to tmpdir (MarcoFalke)
- #8104 `6ff2c8d` Add timeout to sync_blocks() and sync_mempools() (sdaftuar)
- #8111 `61b8684` Benchmark SipHash (sipa)
- #8107 `52b803e` Bench: Added base58 encoding/decoding benchmarks 
(yurizhykin)
- #8115 `0026e0e` Avoid integer division in the benchmark inner-most loop 
(gmaxwell)
- #8090 `a2df115` Adding P2SH(p2pkh) script test case (Christewart)
- #7992 `ec45cc5` Extend #7956 with one more test (TheBlueMatt)
- #8139 `ae5575b` Fix interrupted HTTP RPC connection workaround for Python 
3.5+ (sipa)
- #8164 `0f24eaf` [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue 
(jonasschnelli)
- #8166 `0b5279f` Src/test: Do not shadow local variables (paveljanik)
- #8141 `44c1b1c` Continuing port of java comparison tool (mrbandrews)
- #8201 `36b7400` fundrawtransaction: Fix race, assert amounts (MarcoFalke)
- #8214 `ed2cd59` Mininode: fail on send_message instead of silent return 
(MarcoFalke)
- #8215 `a072d1a` Don't use floating point in wallet tests (MarcoFalke)
- #8066 `65c2058` Test_framework: Use different rpc_auth_pair for each node 
(MarcoFalke)
- #8216 `0d41d70` Assert 'changePosition out of bounds'  (MarcoFalke)
- #8222 `961893f` Enable mempool consistency checks in unit tests (sipa)
- #7751 `84370d5` test_framework: python3.4 authproxy compat (laanwj)
- #7744 `d8e862a` test_framework: detect failure of bitcoind startup (laanwj)
- #8280 `115735d` Increase sync_blocks() timeouts in pruning.py (MarcoFalke)
- #8340 `af9b7a9` Solve trivial merge conflict in p2p-segwit.py (MarcoFalke)
- #8067 `3e4cf8f` Travis: use slim generic image, and some fixups (theuni)
- #7951 `5c7df70` Test_framework: Properly print exception (MarcoFalke)
- #8070 `7771aa5` Remove non-determinism which is breaking net_tests #8069 
(EthanHeilman)
- #8309 `bb2646a` Add wallet-hd test (MarcoFalke)
- #8444 `cd0910b` Fix p2p-feefilter.py for changed tx relay behavior 
(sdaftuar)
- #6996 `5e6af82` *qa: Adapt preciousblock test to current test framework (and 
Py3) (luke-jr)

### Mining

- #7507 `11c7699` Remove internal miner (Leviathn)
- #7663 `c87f51e` Make the generate RPC call function for non-regtest (sipa)
- #7671 `e2ebd25` Add generatetoaddress RPC to mine to an address (achow101)
- #7935 `66ed450` Versionbits: GBT support (luke-jr)
- #7598 `e1486eb` Refactor CreateNewBlock to be a method of the BlockAssembler 
class (morcos)
- #7600 `66db2d6` Select transactions using feerate-with-ancestors (sdaftuar)
- #8295 `f5660d3` Mining-related fixups for 0.13.0 (sdaftuar)
- #7796 `536b75e` Add support for negative fee rates, fixes 
`prioritizetransaction` (MarcoFalke)
- #8362 `86edc20` Scale legacy sigop count in CreateNewBlock (sdaftuar)
- #8489 `8b0eee6` Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) 
(luke-jr)
- n/a   `5a716a3` *Trivially map blockmaxsize to blockmaxweight while segwit 
is unactivated (luke-jr)

### Documentation and miscellaneous

- #7423 `69e2a40` Add example for building with constrained resources (jarret)
- #8254 `c2c69ed` Add OSX ZMQ requirement to QA readme (fanquake)
- #8203 `377d131` Clarify documentation for running a tor node (nathaniel-
mahieu)
- #7428 `4b12266` Add example for listing ./configure flags (nathaniel-mahieu)
- #7847 `3eae681` Add arch linux build example (mruddy)
- #7968 `ff69aaf` Fedora build requirements (wtogami)
- #8013 `fbedc09` Fedora build requirements, add gcc-c++ and fix typo 
(wtogami)
- #8009 `fbd8478` Fixed invalid example paths in gitian-building.md 
(JeremyRand)
- #8240 `63fbdbc` Mention Windows XP end of support in release notes (laanwj)
- #8303 `5077d2c` Update bips.md for CSV softfork (fanquake)
- #7789 `e0b3e19` Add note about using the Qt official binary installer 
(paveljanik)
- #7791 `e30a5b0` Change Precise to Trusty in gitian-building.md (JeremyRand)
- #7838 `8bb5d3d` Update gitian build guide to debian 8.4.0 (fanquake)
- #7855 `b778e59` Replace precise with trusty (MarcoFalke)
- #7975 `fc23fee` Update bitcoin-core GitHub links (MarcoFalke)
- #8034 `e3a8207` Add basic git squash workflow (fanquake)
- #7813 `214ec0b` Update port in tor.md (MarcoFalke)
- #8193 `37c9830` Use Debian 8.5 in the gitian-build guide (fanquake)
- #8261 `3685e0c` Clarify help for `getblockchaininfo` (paveljanik)
- #7185 `ea0f5a2` Note that reviewers should mention the id of the commits 
they reviewed (pstratem)
- #7290 `c851d8d` [init] Add missing help for args (MarcoFalke)
- #7281 `f9fd4c2` Improve CheckInputs() comment about sig verification 
(petertodd)
- #7417 `1e06bab` Minor improvements to the release process (PRabahy)
- #7444 `4cdbd42` Improve block validity/ConnectBlock() comments (petertodd)
- #7527 `db2e1c0` Fix and cleanup listreceivedbyX documentation (instagibbs)
- #7541 `b6e00af` Clarify description of blockindex (pinheadmz)
- #7590 `f06af57` Improving wording related to Boost library requirements 
[updated] (jonathancross)
- #7635 `0fa88ef` Add dependency info to test docs (elliotolds)
- #7609 `3ba07bd` RPM spec file project (AliceWonderMiscreations)
- #7850 `229a17c` Removed call to `TryCreateDirectory` from 
`GetDefaultDataDir` in `src/util.cpp` (alexreg)
- #7888 `ec870e1` Prevector: fix 2 bugs in currently unreached code paths 
(kazcw)
- #7922 `90653bc` CBase58Data::SetString: cleanse the full vector (kazcw)
- #7881 `c4e8390` Update release process (laanwj)
- #7952 `a9c8b74` Log invalid block hash to make debugging easier (paveljanik)
- #7974 `8206835` More comments on the design of AttemptToEvictConnection 
(gmaxwell)
- #7795 `47a7cfb` UpdateTip: log only one line at most per block (laanwj)
- #8110 `e7e25ea` Add benchmarking notes (fanquake)
- #8121 `58f0c92` Update implemented BIPs list (fanquake)
- #8029 `58725ba` Simplify OS X build notes (fanquake)
- #8143 `d46b8b5` comment nit: miners don't vote (instagibbs)
- #8136 `22e0b35` Log/report in 10% steps during VerifyDB (jonasschnelli)
- #8168 `d366185` util: Add ParseUInt32 and ParseUInt64 (laanwj)
- #8178 `f7b1bfc` Add git and github tips and tricks to developer notes (sipa)
- #8177 `67db011` developer notes: updates for C++11 (kazcw)
- #8229 `8ccdac1` [Doc] Update OS X build notes for 10.11 SDK (fanquake)
- #8233 `9f1807a` Mention Linux ARM executables in release process and notes 
(laanwj)
- #7540 `ff46dd4` Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY (btcdrak)
- #8289 `26316ff` bash-completion: Adapt for 0.12 and 0.13 (roques)
- #7453 `3dc3149` Missing patches from 0.12 (MarcoFalke)
- #7113 `54a550b` Switch to a more efficient rolling Bloom filter (sipa)
- #7257 `de9e5ea` Combine common error strings for different options so 
translations can be shared and reused (luke-jr)
- #7304 `b8f485c` [contrib] Add clang-format-diff.py (MarcoFalke)
- #7378 `e6f97ef` devtools: replace github-merge with python version (laanwj)
- #7395 `0893705` devtools: show pull and commit information in github-merge 
(laanwj)
- #7402 `6a5932b` devtools: github-merge get toplevel dir without extra 
whitespace (achow101)
- #7425 `20a408c` devtools: Fix utf-8 support in messages for github-merge 
(laanwj)
- #7632 `409f843` Delete outdated test-patches reference (Lewuathe)
- #7662 `386f438` remove unused NOBLKS_VERSION_{START,END} constants (rat4)
- #7737 `aa0d2b2` devtools: make github-merge.py use py3 (laanwj)
- #7781 `55db5f0` devtools: Auto-set branch to merge to in github-merge 
(laanwj)
- #7934 `f17032f` Improve rolling bloom filter performance and benchmark 
(sipa)
- #8004 `2efe38b` signal handling: fReopenDebugLog and fRequestShutdown should 
be type sig_atomic_t (catilac)
- #7713 `f6598df` Fixes for verify-commits script (petertodd)
- #8412 `8360d5b` libconsensus: Expose a flag for BIP112 (jtimon)
- n/a   `d5d0ce6` *corepolicy: Add bytespersigopstrict=0 (luke-jr)
- #7483 `f8bf558` *Update SVG icon rendering for 0.13 (bitcoin_test.ico, RPM 
spec, VPATH builds) (luke-jr)

Credits
=======

Thanks to everyone who directly contributed to this release:

- 21E14
- accraze
- Adam Brown
- Alexander Regueiro
- Alex Morcos
- Alfie John
- Alice Wonder
- AlSzacrel
- Andrew Chow
- Andr?s G. Aragoneses
- Bob McElrath
- BtcDrak
- calebogden
- C?dric F?lizard
- Chirag Dav?
- Chris Moore
- Chris Stewart
- Christian von Roques
- Chris Wheeler
- Cory Fields
- crowning-
- Daniel Cousens
- Daniel Kraft
- Denis Lukianov
- Elias Rohrer
- Elliot Olds
- Eric Shaw
- error10
- Ethan Heilman
- face
- fanquake
- Francesco 'makevoid' Canessa
- fsb4000
- Gavin Andresen
- gladoscc
- Gregory Maxwell
- Gregory Sanders
- instagibbs
- James O'Beirne
- Jannes Faber
- Jarret Dyrbye
- Jeremy Rand
- jloughry
- jmacwhyte
- Joao Fonseca
- Johnson Lau
- Jonas Nick
- Jonas Schnelli
- Jonathan Cross
- Jo?o Barbosa
- Jorge Tim?n
- Kaz Wesley
- Kefkius
- kirkalx
- Krzysztof Jurewicz
- Leviathn
- lewuathe
- Luke Dashjr
- Luv Khemani
- Marcel Kr?ger
- Marco Falke
- Mark Friedenbach
- Matt
- Matt Bogosian
- Matt Corallo
- Matthew English
- Matthew Zipkin
- mb300sd
- Mitchell Cash
- mrbandrews
- mruddy
- Murch
- Mustafa
- Nathaniel Mahieu
- Nicolas Dorier
- Patrick Strateman
- Paul Rabahy
- paveljanik
- Pavel Jan?k
- Pavel Vasin
- Pedro Branco
- Peter Todd
- Philip Kaufmann
- Pieter Wuille
- Prayag Verma
- ptschip
- Puru
- randy-waterhouse
- R E Broadley
- Rusty Russell
- Suhas Daftuar
- Suriyaa Kudo
- TheLazieR Yip
- Thomas Kerin
- Tom Harding
- Tyler Hardin
- UdjinM6
- Warren Togami
- Will Binns
- Wladimir J. van der Laan
- Yuri Zhykin

As well as everyone that helped translating on [Transifex]
(https://www.transifex.com/projects/p/bitcoin/).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1513 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160815/98ccc262/attachment-0001.sig>

From jl2012 at xbt.hk  Tue Aug 16 10:10:01 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Tue, 16 Aug 2016 06:10:01 -0400 (EDT)
Subject: [bitcoin-dev] New BIP: Low S values signatures
Message-ID: <835406850.86951.1471342201363@privateemail.com>

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

As discussed in the 11 Aug 2016 IRC meeting (https://bitcoincore.org/en/meetings/2016/08/11/#softfork-to-make-low-s-required), a new BIP with implementation is prepared to make low S value signature as a consensus rule:

https://github.com/jl2012/bips/blob/biplows/bip-lows.mediawiki

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

The softfork is proposed to be deployed with segwit (BIP141), likely in v0.13.1

The text is copied below

  BIP: ?
  Title: Low S values signatures
  Author: Pieter Wuille <pieter.wuille at gmail.com>
          Johnson Lau <jl2012 at xbt.hk>
  Status: Draft
  Type: Standards Track
  Created: 2016-08-16

Abstract

This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to using low S values.

Motivation

ECDSA signatures are inherently malleable as taking the negative of the number S inside (modulo the curve order) does not invalidate it. This is a nuisance malleability vector as any relay node on the network may transform the signature, with no access to the relevant private keys required. For non-segregated witness transactions, this malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness (BIP141) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce the efficiency of compact block relay (BIP152).

To fix this malleability, we require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range). The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S.

Specification

Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied, MUST use a S value between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive) with strict DER encoding (see BIP66).

These operators all perform ECDSA verifications on pubkey/signature pairs, iterating from the top of the stack backwards. For each such verification, if the signature does not pass the IsLowDERSignature check, the entire script evaluates to false immediately. If the signature is valid DER with low S value, but does not pass ECDSA verification, opcode execution continues as it used to, causing opcode execution to stop and push false on the stack (but not immediately fail the script) in some cases, which potentially skips further signatures (and thus does not subject them to IsLowDERSignature).

Deployment

This BIP will be deployed by "version bits" BIP9 using the same parameters for BIP141 and BIP143, with the name "segwit" and using bit 1.

For Bitcoin mainnet, the BIP9 starttime will be midnight TBD UTC (Epoch timestamp TBD) and BIP9 timeout will be midnight TBD UTC (Epoch timestamp TBD).

For Bitcoin testnet, the BIP9 starttime will be midnight 1 May 2016 UTC (Epoch timestamp 1462060800) and BIP9 timeout will be midnight 1 May 2017 UTC (Epoch timestamp 1493596800).

Compatibility

The reference client has produced compatible signatures since v0.9.0, and the requirement to have low S value signatures has been enforced as a relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability.

Implementation

An implementation for the reference client is available at https://github.com/bitcoin/bitcoin/pull/8514

Acknowledgements

This document is extracted from the previous BIP62 proposal which had input from various people.

Copyright

This document is placed in the public domain.

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQGcBAEBCgAGBQJXsuZLAAoJEO6eVSA0viTSBkIL/RxdKYhfQUcXhWf3wPzJ2rSo
bhxoGOoswf5Npx1ybKvvTRf51IirgO9JkEl8hYfzLr9KSbfTxCKlr2Z/S+snFGDi
Q0bvVPcg8uoK1iBMrFmIqCi/0pW3/lnnpgqt+O5Jup+DfK4S1QbSVNff8uP7ZK9x
NcgXekAbad57JfZ7gki9aERRj4THliTFBlaKkWo4CP+AwCgtKP6BwWvJxnfGpCc5
Esb/7aFvB0OwTWC7bPdS/XSCChxEdK9n5U3LaUH5o1oMQQhaGVHqeR76Wuf2oDvY
YsXX0b1gttpSJhz00ifOhMf7PhFzQuNyI6gM6ee7kMXwHMlrmyvROQh009cUzKeZ
5m7QKiondMsCoyz0zYXncF/MlwoyI7y1M5pQEqF/CHI5yZGu2K3EeDQebEHDzIrd
RyI6j5BbjLQ4w+geswaxzRSJfkoaKTHdh8g49HL7Q7FUj551jExKA8ZM50SbfeRi
T4fAN8BTXWVpfHkeDYdM2fesaqmFuN9wg18/xwTWJA==
=GgxI
-----END PGP SIGNATURE-----

From luke at dashjr.org  Tue Aug 16 10:20:27 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Tue, 16 Aug 2016 10:20:27 +0000
Subject: [bitcoin-dev] New BIP: Low S values signatures
In-Reply-To: <835406850.86951.1471342201363@privateemail.com>
References: <835406850.86951.1471342201363@privateemail.com>
Message-ID: <201608161020.28467.luke@dashjr.org>

On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote:
> Specification
> 
> Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG,
> or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied,

Not 20-byte witness v0 programs?

> These operators all perform ECDSA verifications on pubkey/signature pairs,
> iterating from the top of the stack backwards. For each such verification,
> if the signature does not pass the IsLowDERSignature check,

"the IsLowDERSignature check" is not well-defined. Probably intend to 
reference the previous paragraph?

Luke

From dev at jonasschnelli.ch  Tue Aug 16 14:10:04 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Tue, 16 Aug 2016 16:10:04 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
Message-ID: <57B31EBC.1030806@jonasschnelli.ch>

Hi

Unfortunately, there is no standard in how desktop- or mobile-wallets
can interact with a hardware device resulting in wallet vendors adding
plugins with proprietary code for non-standardized interfaces.

I started a BIP (extreme draft, feel free to improve language, grammar
and content) to address this missing part of the ecosystem.

I think it would be extremely helpful if @ledger, @trezor,
@voisin/@breadwallet, @electrum, @bitpay (and more?!) would help working
on a such standard.

The BIP describes two approaches how to communicate (pipe and
URI-scheme) with the signing-devices app, although, in my opinion, all
major platform do support the URI approach (maybe we could drop the pipe
approach then).
The URI approach means that there is no need to configure the
application location in order to start a inter-process(-app) communication.

Mediawiki:
https://github.com/jonasschnelli/bips/blob/8abb51f0b21b6664388f6e88f6fd642c90d25dca/bip-undef-0.mediawiki

</jonas>


---- BIP (rough early stage draft)

<pre>
  BIP: ???
  Title: Detached Signing
  Author: Jonas Schnelli <dev at jonasschnelli.ch>
  Status: Draft (early stage!)
  Type: Standards Track
  Created: 2016-08-02
</pre>

== Abstract ==

This BIP describes a way how wallet applications can decouple sensitive
privatekeys from the internal keychain and interact with a
signing-devices (hardware wallet, "cold" storage) over a generic
interface in order to get signatures.

== Motivation ==

It seems like that the current approach for allowing signing-devices to
interact with third party wallets is to build a plugin [1][2][3]. Adding
plugins for each hardware wallet type will increase possible security
issues and result in multiple proprietary-third-party code within the
wallet application with very similar structures.

A generic interface how wallets can interact with signing-devices would
result in better user experience, less critical code and simpler
adaption for various signing-devices.

== Specification ==

In order to support desktop- and smartphone-wallet-applications, this
BIP describes two slightly different approaches (process pipe and URI
call) in how to interact with the signing-devices. If possible, the
modern URI approach should be chosen.

=== Signing-Device-Controller-Application ===

To allow a generic interface while still allowing different ways how to
internally communicate with the signing device itself (USB, TCP/IP,
air-gapped Qr-Code scanning, etc.) a controller-application is required.

=== General signing process ===

The wallets signing process must be according the following principal:
* Wallet prepares signing-request-object including bitcoin-transaction
or message together with metadata (scriptPubKey, hd-keypath of the inputs)
* Wallet passes signing-request-object to the
signing-device-controller-application
* Signing-device-controller-application processes
signing-request-object, eventually shows UI, user can sign or cancel
* Signing-device-controller-application sends back
signing-response-object with signatures or an error
* Wallet processes signing-response-object and completes data-object
creating process (example: add signatures to transaction and broadcast)

=== Desktop Process Intercommunication ===

Desktop wallets can interact with a signing device over process
intercommunication (pipe) together with a
signing-device-controller-application.
As specified below, the signing-request-object is a URI string passed
through the pipe. The desktop wallet needs to wait (with a recommended
timeout between 1 and 5 minutes) until the signing-response-object will
be sent back by the signing-device-controller-application.

=== Smartphone/URI App Intercommunication ===

Smartphones and modern operating systems are trying to sandbox
applications and interprocess communication (on pipe level) is mostly
disallowed.
On smartphones, we must use URI-schemes.
The wallet can pass information to the
signing-device-controller-application by using a predefined URI scheme.

<code>detatchedsigning://<command>?<querystring>&returnurischeme=<returnurischeme://></code>

The <code>querystring</code> must be URI encoded.
RFC 2616 does not specify a maximum length of URIs (get request). Most
modern smartphone operating system allow URIs up to serval megabytes.
Signing complex data-structure is therefore possible.

The <code>returnurischeme</code> must contain a URI schema where the
result of the signing process should be returned to.
The returnurischeme must be populated and "opened" once the signing
process has been completed (or cancled).

=== Signing Request ===

The signing request is a flexible URI-Query-String that will be used by
the Signing-device-controller-application for user confirmation as well
as for creating the signature.

The URI-query-string must conform to the following format:

<code>detatchedsigning://sign?type=<bitcoin-p2pkh|bitcoin-p2sh|bitcoin-msg>&data=<raw-transaction|message>&inputscripts=<scriptPubKey-input0>,<scriptPubKey-input1>,...&inputhdkeypath=<hdkeypath0>,<hdkeypath1>,...&returnscheme=<returnurischeme></code>

type = type of the data to sign
data = raw unsigned bitcoin transaction or text-message
(optional)inputscripts = scriptPubKey(s) of the inputs in exact order
(optional)inputhdkeypath = hd-keypath of the inputs in exact order
(optional)returnscheme = a URI scheme where the response must be sent to
(smartphone approach)

* inputhdkeypath or inputscripts must be provided.

=== Signing Response ===

The signing response is a flexible URI-Query-String that will be sent
back to the wallet application and must contain the signatures or an
error code.
The URI-query-string can be opened (smartphone approach) or will be sent
back though the interprocess pipe.

<code><returnurischeme>://signresponse?errorcode=<errorcode>&signatures=<signature-input0>,<signature-input0>,...</code>

In case of ECDSA, the returned signatures must be normalized compact
signatures with the size of 64bytes (128 hex chars).

==== Possible error code ====

0 = no error
1 = user canceled
2 = timeout
10 = missing key identifier (missing HD keypath or input scriptpubkey)
11 = unsupported signing type
12 = could not resolve script
50 = unknown internal error


==== Examples ====

===== Simple p2pkh transaction =====
Unsigned raw transaction:
<code>0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388ac00000000</code>
(input ced97f90d7d10a767dfd2bed769ac42cc48be1d3e648f1bfb5dbb70f9dd13cfd
vout:1, output: P2PKH mtgQ54Uf3iRTc9kq18rw9SJznngvF5ryZn 1 BTC)

signing-request URI must be:
<code>detatchedsigning://sign?type=bitcoin-p2pkh&data=0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388ac00000000&inputscripts=76a914531148ad17fdbffd4bac72d43deea6c7cf0387d088ac&inputhdkeypath=m/0'/0'/1&returnscheme=myapp</code>
The <code>inputhdkeypath</code> is optional in this case

signing-response URI must be:
<code>detatchedsigning://signresponse?error=0&signatures=<128hex-chars></code>

===== Simple a bitcoin message =====
Message: <code>Lorem ipsum dolor sit amet</code>

signing-request URI must be:
<code>detatchedsigning://sign?type=bitcoinmsg&data=Lorem+ipsum+dolor+sit+amet&inputhdkeypath=m/0'/0'/2</code>

signing-response URI must be:
<code>detatchedsigning://signresponse?error=0&signatures=<128hex-chars></code>

=== Support for multiple signing-devices ===
Must operating systems allow only one registered application per
URI-scheme. To support multiple signing-devices, wallets and
signing-devices can optional add support for brand based URI-schemes.

In addition to the standard URI scheme,
signing-devices-controller-applications can register an additional URI
scheme (with the identical request/response syntax and logic) including
a brand-identifier.

Registering a brand-identifier based URI scheme without registering the
default URI scheme is not allowed.

Wallets can detect if a certain brand based URI scheme is supported and
therefore gives user a selection if multiple signing-devices where
detected [4][5].

<code>detatchedsigning<brandid>://</code>

Supported brand-identifiers are:
* trezor
* ledger
* keepkey
* digitalbitbix

== References ==
[1] https://github.com/spesmilo/electrum/pull/1662
[2] https://github.com/spesmilo/electrum/pull/1391
[3] https://github.com/bitpay/copay/pull/3143
[4]
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/
[5]
https://developer.android.com/reference/android/content/pm/PackageManager.html
== Acknowledgements ==

== Copyright ==
This work is placed in the public domain.





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/fe4471a9/attachment.sig>

From stick at satoshilabs.com  Tue Aug 16 14:48:53 2016
From: stick at satoshilabs.com (Pavol Rusnak)
Date: Tue, 16 Aug 2016 16:48:53 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
Message-ID: <342485b4-586d-c753-94b6-999d5fc14e46@satoshilabs.com>

I think it does not make sense to try to get this standardized for
current Bitcoin transactions. They are just too complex.

What might be interesting is to have something similar for Segwit and
Lightning transactions.

* TREZOR performs extended validation of the inputs, when all of
prev-txs are streamed into the device and validated. Your standard does
not tackle this at all and I don't think it's worthy to make this
standard unnecessarily complicated.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/802e48ca/attachment.sig>

From dev at jonasschnelli.ch  Tue Aug 16 15:13:33 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Tue, 16 Aug 2016 17:13:33 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <342485b4-586d-c753-94b6-999d5fc14e46@satoshilabs.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<342485b4-586d-c753-94b6-999d5fc14e46@satoshilabs.com>
Message-ID: <57B32D9D.8080908@jonasschnelli.ch>

> I think it does not make sense to try to get this standardized for
> current Bitcoin transactions. They are just too complex.
> 
> What might be interesting is to have something similar for Segwit and
> Lightning transactions.
> 
> * TREZOR performs extended validation of the inputs, when all of
> prev-txs are streamed into the device and validated. Your standard does
> not tackle this at all and I don't think it's worthy to make this
> standard unnecessarily complicated.

I'm aware of this approach but I don't think this makes sense long term.
We need a better way on the protocol level to validate inputs amounts
(where segwit is a first step towards this).

IMO, not having a standard for hardware wallet interfaces/communication
will long term result in reducing the end user experience.

I think we should collaborate together and work out a standard.

My goal is to add hardware wallet support in Bitcoin-Core where adding
proprietary code (plugin-ish) is something we don't want to do for the
sake of security and compatibility.

As said, the "BIP" is very draft and I'm happy to include the input
streaming as part of it (or you could add it if you want because you
have more experience with it).

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/75ee098a/attachment.sig>

From stick at satoshilabs.com  Tue Aug 16 15:21:57 2016
From: stick at satoshilabs.com (Pavol Rusnak)
Date: Tue, 16 Aug 2016 17:21:57 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B32D9D.8080908@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<342485b4-586d-c753-94b6-999d5fc14e46@satoshilabs.com>
	<57B32D9D.8080908@jonasschnelli.ch>
Message-ID: <0e9cd5e4-eba0-4dd3-7e8f-258c899cd66f@satoshilabs.com>

On 16/08/16 17:13, Jonas Schnelli wrote:
> I'm aware of this approach but I don't think this makes sense long term.
> We need a better way on the protocol level to validate inputs amounts
> (where segwit is a first step towards this).

So you basically rephrased what I am saying but in another words.

> I think we should collaborate together and work out a standard.

I am for it. I am just saying we should create a standard for new forms
of transactions (Segwit and maybe Lightning), not the current "ugly" ones.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/07dddfef/attachment.sig>

From jl2012 at xbt.hk  Tue Aug 16 17:46:11 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Tue, 16 Aug 2016 13:46:11 -0400 (EDT)
Subject: [bitcoin-dev] New BIP: Low S values signatures
In-Reply-To: <201608161020.28467.luke@dashjr.org>
References: <835406850.86951.1471342201363@privateemail.com>
	<201608161020.28467.luke@dashjr.org>
Message-ID: <1210216648.90169.1471369571065@privateemail.com>



> On August 16, 2016 at 6:20 AM Luke Dashjr <luke at dashjr.org> wrote:
>
>
> On Tuesday, August 16, 2016 10:10:01 AM Johnson Lau via bitcoin-dev wrote:
> > Specification
> >
> > Every signature passed to OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG,
> > or OP_CHECKMULTISIGVERIFY, to which ECDSA verification is applied,
>
> Not 20-byte witness v0 programs?

That's an implicit CHECKSIG. Will clarify.

>
> > These operators all perform ECDSA verifications on pubkey/signature pairs,
> > iterating from the top of the stack backwards. For each such verification,
> > if the signature does not pass the IsLowDERSignature check,
>
> "the IsLowDERSignature check" is not well-defined. Probably intend to
> reference the previous paragraph?

IsLowDERSignature is the function in Bitcoin Core. That's a bit complicated as the real checking function is not directly called. I'll clarify.


>
> Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/b039cd88/attachment-0001.html>

From hoenicke at gmail.com  Tue Aug 16 17:48:27 2016
From: hoenicke at gmail.com (Jochen Hoenicke)
Date: Tue, 16 Aug 2016 19:48:27 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
Message-ID: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>

Hello Jonas,

thanks for your efforts of writing the draft for the standard.

First, this only describes detached signing.  A wallet also needs to
connect with a hardware wallet at some time to learn the xpubs
controlled by the hardware.  Do you plan to have this in a separate
standard or should this also be included here?  Basically one needs one
operation: get xpub for an HD path.

From a first read over the specification I found the following points
missing, that a fully checking hardware wallet needs to know:

- the amount spent by each input (necessary for segwit).
- the full serialized input transactions (without witness informations)
to prove that the amount really matches (this is not necessary for segwit)
- the position of the change output and its HD Path (to verify that it
really is a change output).
- For multisig change addresses, there are more extensive checks
necessary:  All inputs must be multisig addresses signed with public
keys derived from the same set of xpubs as the change address and use
the same "m of n" scheme.  So for multisig inputs and multisig change
address the standard should allow to give the parent xpubs of the other
public keys and their derivation paths.

It is also a bit ambiguous what the "inputscript" is especially for p2sh
transactions.  Is this always the scriptPubKey of the transaction output
that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
there are three scripts

    witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
    scriptSig:    <0 <32-byte-hash>>
                  (0x220020{32-byte-hash})
    scriptPubKey: HASH160 <20-byte-hash> EQUAL
                  (0xA914{20-byte-hash}87)
 (quoted from BIP-141).

In principle one could put witness and scriptSig (with "OP_FALSE" in
places of the signatures) in the raw transaction and make inputscript
always the scriptPubKey of the corresponding output.  Then one also
doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
nested in bip16 p2sh" transactions.

Regards,
  Jochen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/37adb191/attachment.sig>

From jl2012 at xbt.hk  Tue Aug 16 17:53:08 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Tue, 16 Aug 2016 13:53:08 -0400 (EDT)
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability
	in P2WSH
Message-ID: <1736097121.90204.1471369988809@privateemail.com>

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

A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in P2WSH:
https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
https://github.com/bitcoin/bitcoin/pull/8526

   BIP: x
   Title: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
   Author: Johnson Lau <jl2012 at xbt.hk>
   Status: Draft
   Type: Standards Track
   Created: 2016-08-17

Abstract

This document specifies proposed changes to the Bitcoin script validity rules in order to make transaction malleability related to OP_IF and OP_NOTIF impossible in pay-to-witness-script-hash (P2WSH) scripts.

Motivation

OP_IF and OP_NOTIF are flow control codes in the Bitcoin script system. The programme flow is decided by whether the top stake value is True or False. However, this behaviour opens a source of malleability as a third party may replace a True (False) stack item with any other True (False) value without invalidating the transaction.

The proposed rules apply only to pay-to-witness-script-hash (P2WSH) scripts described in BIP141, which has not been activated on the Bitcoin mainnet as of writing. To ensure OP_IF and OP_NOTIF transactions created before the introduction of this BIP will still be accepted by the network, the new rules are not applied to non-segregated witness scripts.

Specification

In P2WSH, the argument for OP_IF and OP_NOTIF MUST be exactly an empty vector or 0x01, or the script evaluation fails immediately.

This is deployed using BIP9 after segregated witness (BIP141) is activated. Details TBD.

Compatibility

This is a softfork on top of BIP141. The rules are enforced as a relay policy by the reference client since the first release of BIP141 (v0.13.1). To avoid risks of fund loss, users MUST NOT create P2WSH scripts that are incompatible with this BIP. An OP_0NOTEQUAL may be used before OP_IF or OP_NOTIF to imitate the original behaviour (which may also re-enable the malleability vector depending on the exact script).

Implementation

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

Copyright

This work is placed in the public domain.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQGcBAEBCgAGBQJXs1LgAAoJEO6eVSA0viTSrJQL/A/womJKgi4FuyBTL9oykCss
aBMNN9+SLtmuH7SBgEUGZ8TFxa2st+6RP6Imu+Vvn4O5sXQl3DIXV+X38X93sUYk
wrjdpvdpqFFYJezPDESz6pR/6bZ1ES0aO2QqX578/8sqr8GO6L388s66vJeIGj4n
0LWW8sdEypMuV3HUG/9FFdUNHgiVX1U0sS1rT3P4aN30JYtb7PQpd7r8KTMta7Rt
L1VOZB+W3m2m2YZ9gB7IRmMfzzNm2QXRTPIZXt2x3mYDBuMkp+zEd5+ogA4sBpgP
wp2+l/aos686v0w8QYiNUX2+9Qpe7+238qUpw75d2XJYmLzdotWFvmp4g1hP+awX
HEfwe4BUM+El17LjrHkNeMWNJXMlhTtXb2i0XMj8tU5lZVHep4WpQ+LEahrNlsUl
FdFsi3q8HeWh8JsGaNCL41Bgbg/rKb5hUXyF6hTRHa//E6llOrpXRnsloKgBLv8c
QezgKTAPwwgdjcS6Ek0AqgLp7bCFRijCduYH9i9uaQ==
=lLIZ
-----END PGP SIGNATURE-----

From luke at dashjr.org  Tue Aug 16 19:22:29 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Tue, 16 Aug 2016 19:22:29 +0000
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
Message-ID: <201608161922.30588.luke@dashjr.org>

On Tuesday, August 16, 2016 2:10:04 PM Jonas Schnelli via bitcoin-dev wrote:
> The BIP describes two approaches how to communicate (pipe and
> URI-scheme) with the signing-devices app, although, in my opinion, all
> major platform do support the URI approach (maybe we could drop the pipe
> approach then).

IMO it's kindof ugly to abuse URIs for communication. Stdio pipes are pretty 
universally supported, why not just use those?

On the other hand, no matter how the plugin is implemented, it's still a 
security risk, and requires installation (which the user might not have access 
for). It would be best if the hardware protocol were standardised, so the user 
doesn't need a plugin of *any* sort... I notice some hardware wallets have 
begun to implement (or reuse) Trezor's interface, so that would seem a good 
place to start?

Luke

From luke at dashjr.org  Tue Aug 16 19:37:19 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Tue, 16 Aug 2016 19:37:19 +0000
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
	malleability in P2WSH
In-Reply-To: <1736097121.90204.1471369988809@privateemail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
Message-ID: <201608161937.20748.luke@dashjr.org>

On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> P2WSH:
> https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> https://github.com/bitcoin/bitcoin/pull/8526

I am not sure this makes sense. SegWit transactions are already non-malleable 
due to skipping the witness data in calculating the transaction id. What is 
the benefit to this?

Luke

From pete at petertodd.org  Tue Aug 16 19:43:32 2016
From: pete at petertodd.org (Peter Todd)
Date: Tue, 16 Aug 2016 12:43:32 -0700
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <201608161937.20748.luke@dashjr.org>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
Message-ID: <20160816194332.GA5888@fedora-21-dvm>

On Tue, Aug 16, 2016 at 07:37:19PM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> > P2WSH:
> > https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> > https://github.com/bitcoin/bitcoin/pull/8526
> 
> I am not sure this makes sense. SegWit transactions are already non-malleable 
> due to skipping the witness data in calculating the transaction id. What is 
> the benefit to this?

SegWit txids aren't malleable, but segwit transactions as a whole still are.
For instance, I could mess with a segwit transaction by replacing part of the
witness that is used as an argument to an OP_IF with a much larger push,
potentially making the transaction larger, thus making it not get mined due to
the higher fee. There are also potential legal issues if someone replaces a
push with data where posession in your jurisdiction is illegal.

Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode
that fails unless the top item on the stack is a minimally encoded true or
false value, to allow script writers to opt into this behavior; it's not always
ideal.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/98322ba5/attachment.sig>

From joseph at lightning.network  Tue Aug 16 21:58:58 2016
From: joseph at lightning.network (Joseph Poon)
Date: Tue, 16 Aug 2016 14:58:58 -0700
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <20160816194332.GA5888@fedora-21-dvm>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
Message-ID: <20160816215858.GB2532@lightning.network>

I agree this is an interesting area of transaction malleability to still
consider in the future, and minimization of these areas of malleability
with regards to its impact on the p2p network should be easy to resolve
and (hopefully) well-understood by script writers in the future.

On Tue, Aug 16, 2016 at 12:43:32PM -0700, Peter Todd via bitcoin-dev wrote:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode
> that fails unless the top item on the stack is a minimally encoded true or
> false value, to allow script writers to opt into this behavior; it's not always
> ideal.

I think the biggest value of the proposed BIP behavior is that the cost
is lower for "doing it right" to create script enforcement of OP_TRUE or
OP_FALSE. It is already possible to enforce with 2 bytes pushing OP_TRUE
and then OP_EQUAL. Creating an "OP_CHECKBOOLVERIFY" definitely achieves
the same result, but at a 1-byte (insetad of 2-byte) cost to "do it
right", so there is the same incentive to save on the byte and push
potential DoS costs onto the network -- whereas enforcing OP_TRUE byte
in OP_IF would create costs for those who want to evaluate pushdata, so
that has to be explicitly opt-in from an optimization/convenience
standpoint.

-- 
Joseph Poon

From roconnor at blockstream.io  Tue Aug 16 22:23:00 2016
From: roconnor at blockstream.io (Russell O'Connor)
Date: Tue, 16 Aug 2016 18:23:00 -0400
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <20160816194332.GA5888@fedora-21-dvm>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
Message-ID: <CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>

On Tue, Aug 16, 2016 at 3:43 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Tue, Aug 16, 2016 at 07:37:19PM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > On Tuesday, August 16, 2016 5:53:08 PM Johnson Lau via bitcoin-dev wrote:
> > > A new BIP is prepared to deal with OP_IF and OP_NOTIF malleability in
> > > P2WSH:
> > > https://github.com/jl2012/bips/blob/minimalif/bip-minimalif.mediawiki
> > > https://github.com/bitcoin/bitcoin/pull/8526
> >
> > I am not sure this makes sense. SegWit transactions are already
> non-malleable
> > due to skipping the witness data in calculating the transaction id. What
> is
> > the benefit to this?
>
> SegWit txids aren't malleable, but segwit transactions as a whole still
> are.
> For instance, I could mess with a segwit transaction by replacing part of
> the
> witness that is used as an argument to an OP_IF with a much larger push,
> potentially making the transaction larger, thus making it not get mined
> due to
> the higher fee. There are also potential legal issues if someone replaces a
> push with data where posession in your jurisdiction is illegal.
>

If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness.  Given two transactions with the same txid and
different witness data, miners and good nodes ought to mine/relay the
version with the lower cost (smaller?) witness data.

Worries about "illegal data" appearing in the blockchain is not an issue
worth writing a soft-fork over.

There may be good reasons for this BIP, but I don't think the reasons give
above are good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/06d324f7/attachment.html>

From pieter.wuille at gmail.com  Tue Aug 16 22:30:52 2016
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Wed, 17 Aug 2016 00:30:52 +0200
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
Message-ID: <CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>

On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness.  Given two transactions with the same txid and
different witness data, miners and good nodes ought to mine/relay the
version with the lower cost (smaller?) witness data.

That implies that everyone will see both versions and be able to make that
choice. Unfortunately, those two versions will be definition be in conflict
with each other, and thus only one will end up paying a fee. We're can't
relay two transactions for the price of one, or we'd expose the p2p network
to a very cheap DDoS attack: just send increasingly small versions of the
same transaction.

Segwit's third party mallebility protection makes it not an issue for
dependent contracts if transactions are mauled (=apparently the verb
related to malleability), but there are still good reasons for senders not
to gratuitously make their transactions extensible in size or other
resources.

--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/2c5284a7/attachment.html>

From roconnor at blockstream.io  Tue Aug 16 22:36:24 2016
From: roconnor at blockstream.io (Russell O'Connor)
Date: Tue, 16 Aug 2016 18:36:24 -0400
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
Message-ID: <CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>

On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:

> On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > If one's goal is to mess with an transaction to prevent it from being
> mined, it is more effective to just not relay the transaction rather than
> to mess with the witness.  Given two transactions with the same txid and
> different witness data, miners and good nodes ought to mine/relay the
> version with the lower cost (smaller?) witness data.
>
> That implies that everyone will see both versions and be able to make that
> choice. Unfortunately, those two versions will be definition be in conflict
> with each other, and thus only one will end up paying a fee. We're can't
> relay two transactions for the price of one, or we'd expose the p2p network
> to a very cheap DDoS attack: just send increasingly small versions of the
> same transaction.
>
Can I already do something similar with replace by fee, or are there limits
on that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/a0057d43/attachment.html>

From pieter.wuille at gmail.com  Tue Aug 16 22:39:08 2016
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Wed, 17 Aug 2016 00:39:08 +0200
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
Message-ID: <CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>

On Aug 17, 2016 00:36, "Russell O'Connor" <roconnor at blockstream.io> wrote:

> Can I already do something similar with replace by fee, or are there
limits on that?

BIP125 and mempool eviction both require the replacing transaction to have
higher fee, to compensate for the cost of relaying the replaced
transaction(s).

-- 
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/3710f5b7/attachment.html>

From roconnor at blockstream.io  Tue Aug 16 22:52:38 2016
From: roconnor at blockstream.io (Russell O'Connor)
Date: Tue, 16 Aug 2016 18:52:38 -0400
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
	<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
Message-ID: <CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>

I see.

But is it really necessary to soft fork over this issue?  Why not just make
it a relay rule?  Miners are already incentivized to modify transactions to
drop excess witness data and/or prioritize (versions of) transactions based
on their cost.  If a miner wants to mine a block with excess witness data,
it is mostly their own loss.

On Tue, Aug 16, 2016 at 6:39 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:

> On Aug 17, 2016 00:36, "Russell O'Connor" <roconnor at blockstream.io> wrote:
>
> > Can I already do something similar with replace by fee, or are there
> limits on that?
>
> BIP125 and mempool eviction both require the replacing transaction to have
> higher fee, to compensate for the cost of relaying the replaced
> transaction(s).
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/e72fef81/attachment-0001.html>

From liaiqin.lanzhou at gmail.com  Tue Aug 16 23:36:02 2016
From: liaiqin.lanzhou at gmail.com (Aiqin Li)
Date: Wed, 17 Aug 2016 09:36:02 +1000
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
Message-ID: <0501f5c2-611c-53c1-5fd1-d4da5ba5137b@gmail.com>

Out of curiosity, what is the technical reason a normal ECC-enabled 
smart-card cannot be used for the hardware signing component of a wallet 
app? (Since if it can, its standardization must have been discussed.)

Debian wiki gives a list of such cards with related opensource software 
to access them.

Regards


From pete at petertodd.org  Wed Aug 17 00:14:07 2016
From: pete at petertodd.org (Peter Todd)
Date: Tue, 16 Aug 2016 17:14:07 -0700
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <0501f5c2-611c-53c1-5fd1-d4da5ba5137b@gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<0501f5c2-611c-53c1-5fd1-d4da5ba5137b@gmail.com>
Message-ID: <20160817001407.GA6571@fedora-21-dvm>

On Wed, Aug 17, 2016 at 09:36:02AM +1000, Aiqin Li via bitcoin-dev wrote:
> Out of curiosity, what is the technical reason a normal ECC-enabled
> smart-card cannot be used for the hardware signing component of a wallet
> app? (Since if it can, its standardization must have been discussed.)
> 
> Debian wiki gives a list of such cards with related opensource software to
> access them.

I'm not aware of any ECC-enabled smart-cards that can sign the specific curve
that Bitcoin uses, not to mention the fact that those smartcards generally only
speak higher level protocols than raw signature generation, precluding the
signing of bitcoin transactions.

The other serious problem - and this is a problem with smartcards in general
anyway - is that without Bitcoin-specific logic you're just signing blindly; we
recently saw the problems with that with the Bitfinex/BitGo hack. And even
then, without a screen most of the hardware wallets in are still just signing
blindly, with at best hard-to-use limits on maximum funds moved
per-transaction. Also note how even hardware wallets with a screen, like
Trezor, aren't yet able to authenticate who you are paying.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/29699c7e/attachment.sig>

From greg at xiph.org  Wed Aug 17 00:18:09 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 17 Aug 2016 00:18:09 +0000
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
	<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
	<CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
Message-ID: <CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>

On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I see.
>
> But is it really necessary to soft fork over this issue?  Why not just make
> it a relay rule?  Miners are already incentivized to modify transactions to
> drop excess witness data and/or prioritize (versions of) transactions based
> on their cost.  If a miner wants to mine a block with excess witness data,
> it is mostly their own loss.

Relay rules are quite fragile-- people build programs or protocols not
expecting them to be violated, without proper error handling in those
cases... and then eventually some miner rips them out because they
simply don't care about them: not enforcing them won't make their
blocks invalid.

It's my general view that we should avoid blocking things with relay
rules unless we think that someday they could be made invalid... not
necessarily that they will, but that it's plausible. Then the
elimination at the relay level is just the first exploratory step in
that direction.

One should also consider adversarial behavior by miners.  For example,
I can mine blocks with mutated witnesses with a keyed mac that chooses
the mutation. The key is shared by conspirators or customers, and now
collectively we have a propagation advantage (since we know the
mutated version before it shows up).  Not the _biggest_ concern, since
parties doing this could just create their own new transactions to
selectively propagate; but doing that would require leaving behind fee
paying public transactions, while using malleability wouldn't.

From bztdlinux at gmail.com  Wed Aug 17 00:03:00 2016
From: bztdlinux at gmail.com (Thomas Daede)
Date: Tue, 16 Aug 2016 17:03:00 -0700
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <201608161922.30588.luke@dashjr.org>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<201608161922.30588.luke@dashjr.org>
Message-ID: <3a183d3a-757c-ec32-0bd1-c3f8a1982edd@gmail.com>

On 08/16/2016 12:22 PM, Luke Dashjr via bitcoin-dev wrote:
> It would be best if the hardware protocol were standardised, so the user 
> doesn't need a plugin of *any* sort... I notice some hardware wallets have 
> begun to implement (or reuse) Trezor's interface, so that would seem a good 
> place to start?

I also agree with this - the user experience would be a lot better
without the need to install custom adapter software, especially for the
desktop case.

There could be two layers to the specification - the raw messages that
need to be passed, and the transport mechanism to pass them (USB HID, QR
code, audio...). For the most common case (USB), both layers could be
defined, and other transports could be added later. This split already
exists in the draft specification, though it's not very clear (URIs
include return URIs that don't make sense for a pipe, for example).

The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets. This means that the "driver" would have to include a GUI to
select this. Also, passing return URIs seems rather fragile - are there
any other examples of protocols that use URIs for bidirectional IPC?

Thomas

From me at thomaskerin.io  Wed Aug 17 00:25:29 2016
From: me at thomaskerin.io (Thomas Kerin)
Date: Wed, 17 Aug 2016 01:25:29 +0100
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
Message-ID: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>

Hi all,

Thanks again Jonas for starting this!

I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascript code / using Core's debug
console / coinb.in

Happily the procedure is largely the same, though I would echo Jochen's
point that there needs to be a way to request an xpub/public key.

The redeemScript and witnessScript are also required fields for full
validation & signing a transaction input if it's P2SH, or just the
witnessScript if it's bare V0_P2WSH

Since the output amounts are required, so maybe instead provide
serialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].

The protocol ought to be as stateless as possible - it can't be assumed
whether the redeemScript and other details will ever be saved on the
device - so perhaps provide the redeemScript + witnessScript as the
final fields on the Utxo structure above.

I do think it enables two important choices for bitcoin users:

* it might be preferable to provide your own xpub vs generating a brand
new HD key to potentially lose.

* you could leverage the services provided by [random example]
GreenAddress without necessarily having to rely on signing code provided
by them, and so end up only having to trust only one ECDSA
implementation when interacting with a wide number of services

All the best

Thomas

On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing.  A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware.  Do you plan to have this in a separate
> standard or should this also be included here?  Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary:  All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme.  So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions.  Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
>     witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
>     scriptSig:    <0 <32-byte-hash>>
>                   (0x220020{32-byte-hash})
>     scriptPubKey: HASH160 <20-byte-hash> EQUAL
>                   (0xA914{20-byte-hash}87)
>  (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output.  Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
>   Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing.  A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware.  Do you plan to have this in a separate
> standard or should this also be included here?  Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary:  All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme.  So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions.  Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
>     witness:      0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
>     scriptSig:    <0 <32-byte-hash>>
>                   (0x220020{32-byte-hash})
>     scriptPubKey: HASH160 <20-byte-hash> EQUAL
>                   (0xA914{20-byte-hash}87)
>  (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output.  Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
>   Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.sig>

From roconnor at blockstream.io  Wed Aug 17 00:27:54 2016
From: roconnor at blockstream.io (Russell O'Connor)
Date: Tue, 16 Aug 2016 20:27:54 -0400
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
	<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
	<CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
	<CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
Message-ID: <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>

Okay.

I'm not really opposed to this BIP, but I am worried that fighting script
malleability is a battle that can never be won; even leaving one avenue of
malleability open is probably just as bad as having many avenues of
malleability, so it just doesn't seem worthwhile to me.

On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell <greg at xiph.org> wrote:

> On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I see.
> >
> > But is it really necessary to soft fork over this issue?  Why not just
> make
> > it a relay rule?  Miners are already incentivized to modify transactions
> to
> > drop excess witness data and/or prioritize (versions of) transactions
> based
> > on their cost.  If a miner wants to mine a block with excess witness
> data,
> > it is mostly their own loss.
>
> Relay rules are quite fragile-- people build programs or protocols not
> expecting them to be violated, without proper error handling in those
> cases... and then eventually some miner rips them out because they
> simply don't care about them: not enforcing them won't make their
> blocks invalid.
>
> It's my general view that we should avoid blocking things with relay
> rules unless we think that someday they could be made invalid... not
> necessarily that they will, but that it's plausible. Then the
> elimination at the relay level is just the first exploratory step in
> that direction.
>
> One should also consider adversarial behavior by miners.  For example,
> I can mine blocks with mutated witnesses with a keyed mac that chooses
> the mutation. The key is shared by conspirators or customers, and now
> collectively we have a propagation advantage (since we know the
> mutated version before it shows up).  Not the _biggest_ concern, since
> parties doing this could just create their own new transactions to
> selectively propagate; but doing that would require leaving behind fee
> paying public transactions, while using malleability wouldn't.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/891f91a7/attachment.html>

From pete at petertodd.org  Wed Aug 17 02:30:07 2016
From: pete at petertodd.org (Peter Todd)
Date: Tue, 16 Aug 2016 19:30:07 -0700
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
	<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
	<CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
	<CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
Message-ID: <20160817023007.GA7296@fedora-21-dvm>

On Tue, Aug 16, 2016 at 08:27:54PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Okay.
> 
> I'm not really opposed to this BIP, but I am worried that fighting script
> malleability is a battle that can never be won; even leaving one avenue of
> malleability open is probably just as bad as having many avenues of
> malleability, so it just doesn't seem worthwhile to me.

At least some types of malleability are less harmful than others: changing a
few bits with some weird ECC transformation isn't as likely to cause problems
as being able to append arbitrary data to a transaction's input script. And of
course, we do prevent the latter with the cleanstack rule - consensus enforced
in segwit.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/3a991698/attachment.sig>

From jl2012 at xbt.hk  Wed Aug 17 03:02:53 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Tue, 16 Aug 2016 23:02:53 -0400 (EDT)
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
	<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
	<CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
	<CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
Message-ID: <976728541.94211.1471402973613@privateemail.com>


> On August 16, 2016 at 8:27 PM Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 
> Okay.
> 
> I'm not really opposed to this BIP, but I am worried that fighting script malleability is a battle that can never be won; even leaving one avenue of malleability open is probably just as bad as having many avenues of malleability, so it just doesn't seem worthwhile to me.

Not really. I think the goal is to protect as many common scripts as possible.

For example:
1) BIP146 (Low S values signatures) will eliminate all malleability for P2WPKH
2) BIP146 + null dummy value for CHECKMULTISIG ("NULLDUMMY") will eliminate all malleability for simple multi-sig in P2WSH. This is particularly interesting since without NULLDUMMY, attackers are able to replace the dummy value with anything.
3) BIP146 + NULLDUMMY + minimal IF argument ("MINIMALIF") will eliminate malleability for any Lightening Network scripts that I'm aware of.

With 3), 99.99% of segwit transactions in foreseeable future should be fully protected.

The plan is to implement MINIMALIF as a relay policy first, and enforce the softfork after further risks assessment. This BIP serves as a warning to users for not using incompatible script.

Peter Todd:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode that fails unless the top item on the stack is a minimally encoded true or false value, to allow script writers to opt into this behavior; it's not always ideal.

I believe all Lightening Network scripts (the only real users of IF/NOTIF in foreseeable future) are already compatible with MINIMALIF. It may not be a good idea for them to spend 1 more byte to get protected.

If people want to have the original OP_IF behaviour, a simple way would be using "0NOTEQUAL IF". However, this works only if the argument is a valid number (also beware of MINIMALDATA rule in BIP62).

To completely replicate the original behaviour, one may use:
"DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script} ELSE DROP {else script} ENDIF"

This is because we don't have a simple OP_CASTTOBOOL, and IFDUP is 1 of the 4 codes that perform CastToBool on top stack item (the others are VERIFY, IF, and NOTIF; and VERIFY can't be used here since it terminates the script with a False).

From luke at dashjr.org  Wed Aug 17 04:40:34 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 17 Aug 2016 04:40:34 +0000
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
	malleability in P2WSH
In-Reply-To: <976728541.94211.1471402973613@privateemail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
	<976728541.94211.1471402973613@privateemail.com>
Message-ID: <201608170440.35767.luke@dashjr.org>

On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> To completely replicate the original behaviour, one may use:
> "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}
> ELSE DROP {else script} ENDIF"

This is much uglier than expected. IMO if that's the best workaround for the 
current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if they 
need to avoid malleability issues.

I suspect most cases OP_IF would be used, you really want to accept any non-
zero value. For example, the HTLC script I posted on the list about not long 
ago (OP_IF operates on the result from OP_SIZE). Counter-examples would be BIP 
124, the examples in BIP 65 and BIP 112, but I note all of these could be just 
as easily done without the explicit boolean being fed to the OP_IF (you'd need 
an OP_DUP to keep the value, so it wouldn't reduce the byte-size).

Of course, as long as we're talking about a softfork activating together with 
segwit, and only having effect in segwit scripts... there's no reason we can't 
add whatever opcodes we need so long as it gets done before 0.13.1. I suggest 
OP_CASTTOBOOL and OP_DUPASBOOL would be two good candidates if we make OP_IF 
stricter. There's also the possibility of adding an OP_RETAINIF which behaves 
as the current OP_IF, except not popping the conditional value off the stack. 
But perhaps this is getting too complicated for testing in time for segwit...

Luke

From dev at jonasschnelli.ch  Wed Aug 17 07:24:46 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Wed, 17 Aug 2016 09:24:46 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
Message-ID: <57B4113E.4010502@jonasschnelli.ch>

Hi all

Thanks for the response.


Jochen's points:
===============
Indeed. There are some missing points and I'd like to work this into the
BIP. Thanks for bringing this up.

Along with a support for wallet-creation with a xpub from the signing
device, we might also want to support loading multiple pubkeys into a
keypool from the device (in case someone likes to use hardened
derivation at all levels). I guess this would not be over-complex to
achieve.

Luke's points:
=============

USB / Plugin/Driver problematic
-------------------------------
I don't think it would be wise to set Trezors USB communication
(hardware interface) as "the standard". A) A USB stack/interaction in
wallets should be avoided IMO. B) This approach won't work for some
platforms (like iOS) due to technical and legal restrictions.

In my opinion, each hardware wallet has to provide custom software in
any case. We don't want to standardize how a hardware wallet has to do
backups, recovers, firmware upgrade, etc. and if we agree on that, then
hardware wallets must provide an application (mostly Chrome extensions
today) to implement theses processes.

Also diversity at the hardware interface will reduce centralized risks
for weak security/vulnerabilities.

The proposed URI scheme approach does not require any sorts of
libraries/dependencies. USB HID can be a problem for cross platform
desktop wallets as well as it won't work of one of the major mobile
platform (iOS). USB HID interaction can be restricted or disabled in non
superuser setups where I'm not aware of any restriction on URI-Scheme level.

URI scheme instead of stdio/pipe
--------------------------------
The URI scheme is not ugly. Its a modern way ? implemented in almost all
platforms ? how applications can interact with each other while not
directly knowing each other. Registering a URI scheme like "bitcoin://"
has some concrete advantages over just piping through stdio.

Also, the stdio/piping approach does not work for mobile platforms
(where the URI scheme works).

The URI scheme does not require any sorts of wallet app level
configuration (where the stdio/pipe approach would require to configure
some details about the used hardware wallet).


Thomase D.'s points:
===================
Standardizing to many layers of the interaction stack (including the
hardware interaction) will very likely result in vendors not sticking to
the standard.

I agree, the URI scheme has some fragility, but at a level where we can
handle it and with the advantage of abstracting the used brand/device
for privacy and security reasons.

> The existing URI scheme, while allowing disambiguate by manufacturer,
provides no way to to enumerate available manufacturers or enabled
wallets.

Most operating systems allow to check if a certain URL-Scheme is
supported (registered), this would allow at least to check for known
major vendors (like trezor, etc.) which should solve most
multi-hardware-wallet use-cases.

The URI return scheme does work fine and with the correct set timeouts
it should result in a neat user experience.
It's the proposed way of application intercommunication in Apple iOS [1]
and Google Android [2].

Conclusion:
===========
* Non of the points convinced me that there is a better alternative to
the proposed URI scheme interaction (please tell me if I'm stubborn).
* Also, we should move the end users UX in the center of the
problems-to-solve (and not overweight the ideal
code-/API-/hardware-interaction-design while ignoring the end user
experience).
* We should try to not over-standardize the interaction with the device
itself to allow flexibility on the hardware wallet vendor side.

[1]
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
[2] https://developer.android.com/training/basics/intents/sending.html

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/63e4d8a4/attachment-0001.sig>

From nicolas at ledger.fr  Wed Aug 17 07:27:03 2016
From: nicolas at ledger.fr (Nicolas Bacca)
Date: Wed, 17 Aug 2016 09:27:03 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <20160817001407.GA6571@fedora-21-dvm>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<0501f5c2-611c-53c1-5fd1-d4da5ba5137b@gmail.com>
	<20160817001407.GA6571@fedora-21-dvm>
Message-ID: <CALGb227zi6FUtjkGAScqttk9xfz_p+D6Tx7q30aCJP5rNgPvkg@mail.gmail.com>

On Wed, Aug 17, 2016 at 2:14 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> I'm not aware of any ECC-enabled smart-cards that can sign the specific
> curve
> that Bitcoin uses, not to mention the fact that those smartcards generally
> only
> speak higher level protocols than raw signature generation, precluding the
> signing of bitcoin transactions.
>

any Java Card supporting ECC can sign on user supplied Weierstrass curve
parameters - you can find a good shopping list at
http://www.fi.muni.cz/~xsvenda/jcsupport.html (look for ALG_ECDSA_SHA256 on
javacard.crypto.signature). The NXP JCOP platform (found in Yubico Neo) is
a popular choice, and then you can add your own custom logic for validation.

-- 
Nicolas Bacca | CTO, Ledger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/2502add3/attachment.html>

From nicolas at ledger.fr  Wed Aug 17 07:40:58 2016
From: nicolas at ledger.fr (Nicolas Bacca)
Date: Wed, 17 Aug 2016 09:40:58 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B4113E.4010502@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
Message-ID: <CALGb224uUWo7J1iFp+79Lk3HN4V1uQWeGo3R+PMUjtJgtvd30g@mail.gmail.com>

On Wed, Aug 17, 2016 at 9:24 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> Conclusion:
> ===========
> * Non of the points convinced me that there is a better alternative to
> the proposed URI scheme interaction (please tell me if I'm stubborn).
>

I'd also agree with this - and it's convenient to test against simulators /
mocks.

-- 
Nicolas Bacca | CTO, Ledger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/62fc71e9/attachment.html>

From jl2012 at xbt.hk  Wed Aug 17 10:00:37 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Wed, 17 Aug 2016 06:00:37 -0400 (EDT)
Subject: [bitcoin-dev] BIP draft: HTLC transactions
In-Reply-To: <201607200617.40917.luke@dashjr.org>
References: <CAKazn3mKUMMz0wyqTsgbkd4mBLgvG2PXziXhgRTi4hX_ApbPhg@mail.gmail.com>
	<20160720054654.GA1420@fedora-21-dvm>
	<201607200617.40917.luke@dashjr.org>
Message-ID: <253352817.96000.1471428037734@privateemail.com>


> On July 20, 2016 at 2:17 AM Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 
> On Wednesday, July 20, 2016 5:46:54 AM Peter Todd via bitcoin-dev wrote:
> 
> > On Tue, Jul 19, 2016 at 10:35:39PM -0600, Sean Bowe via bitcoin-dev wrote:
> > 
> > > I'm requesting feedback for Hash Time-Locked Contract (HTLC) transactions
> > > in Bitcoin.
> > > 
> > > HTLC transactions allow you to pay for the preimage of a hash. CSV/CLTV
> > > can be used to recover your funds if the other party is not cooperative.
> > > These
> > > 
> > > scripts take the following general form:
> > >  [HASHOP]  OP_EQUAL
> > >  OP_IF
> > > 
> > > 
> > > 
> > > OP_ELSE
> > > 
> > >  [TIMEOUTOP] OP_DROP 
> > > 
> > > OP_ENDIF
> > >  OP_CHECKSIG
> > 
> > Note that because you're hashing the top item on the stack regardless
> > scriptSig's that satisfy HTLC's are malleable: that top stack item can be
> > changed anything in the digest-not-provided case and the script still
> > passes.
> 
> OP_SIZE
> OP_IF
>  [HASHOP] <digest> OP_EQUALVERIFY
>  <seller pubkey>
> OP_ELSE
>  <num> [TIMEOUTOP]
>  <buyer pubkey>
> OP_ENDIF
> OP_CHECKSIG
> 

This is incompatible with my proposal for fixing the OP_IF/NOTIF malleability in segwit ("MINIMALIF"). In this case only the timeout branch may be executed.

To make it compatible, you may use one of the following 2 scripts:

OP_SIZE OP_0NOTEQUAL
OP_IF
 [HASHOP] <digest> OP_EQUALVERIFY
 <seller pubkey>
OP_ELSE
 <num> [TIMEOUTOP] OP_DROP
 <buyer pubkey>
OP_ENDIF
OP_CHECKSIG

or

OP_IF
 [HASHOP] <digest> OP_EQUALVERIFY
 <seller pubkey>
OP_ELSE
 <num> [TIMEOUTOP] OP_DROP
 <buyer pubkey>
OP_ENDIF
OP_CHECKSIG

The overall witness size are the same for these scripts. They are 1 byte larger than Luke's script, in case MINIMALIF is not enforced.

(btw, the OP_DROP after TIMEOUTOP is missing in Luke's script)

From jl2012 at xbt.hk  Wed Aug 17 10:15:48 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Wed, 17 Aug 2016 06:15:48 -0400 (EDT)
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <201608170440.35767.luke@dashjr.org>
References: <1736097121.90204.1471369988809@privateemail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
	<976728541.94211.1471402973613@privateemail.com>
	<201608170440.35767.luke@dashjr.org>
Message-ID: <703193091.96057.1471428948569@privateemail.com>


> On August 17, 2016 at 12:40 AM Luke Dashjr <luke at dashjr.org> wrote:
>
>
> On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev wrote:
> > To completely replicate the original behaviour, one may use:
> > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if script}
> > ELSE DROP {else script} ENDIF"
>
> This is much uglier than expected. IMO if that's the best workaround for the
> current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if they
> need to avoid malleability issues.

It is ugly only if you want to faithfully replicate the behaviour. I'd argue that in no real use case you need to do this. For example, "OP_SIZE OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must return a valid MINIMALDATA number.

And your workaround does not fix malleability, since any non-0x01 values are valid FALSE

However, in some case, enforcing MINIMALIF does require 1 more witness byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013036.html

I think the best strategy is to make it a relay policy first, and decide whether we want a softfork later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/c3a1cef3/attachment.html>

From dana.coe at bitlox.com  Wed Aug 17 10:13:29 2016
From: dana.coe at bitlox.com (Dana L. Coe)
Date: Wed, 17 Aug 2016 18:13:29 +0800
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B4113E.4010502@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
Message-ID: <D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>


> On Aug 17, 2016, at 15:24, Jonas Schnelli via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> 
> URI scheme instead of stdio/pipe
> --------------------------------
> The URI scheme is not ugly. Its a modern way ? implemented in almost all
> platforms ? how applications can interact with each other while not
> directly knowing each other. Registering a URI scheme like "bitcoin://"
> has some concrete advantages over just piping through stdio.
> 
> Also, the stdio/piping approach does not work for mobile platforms
> (where the URI scheme works).
> 
> The URI scheme does not require any sorts of wallet app level
> configuration (where the stdio/pipe approach would require to configure
> some details about the used hardware wallet).

Hi everybody, just thought I?d throw my opinion in here.

The URI scheme is a nice idea, but this ignores the fact that hardware wallet vendors do most of the work on talking between the computer/mobile and the wallet on a lower level of communication. In the case of BitLox, the base protocol is Google?s ProtoBuf. The commands and transaction data is in a ?schema? which is then encoded in different methods accessible via ProtoBuf (depending on the data being sent). The advantages of this protocol is that it can be implemented on a wide variety of platforms. (but that?s a whole 'nother discussion)

The URI would be handled waaaaay up in the specific application (such as the mytrezor wallet software or the various standalone wallets) - nowhere near the actual hardware communications layer.

Best regards,
Dana
BitLox
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/bddd5d9e/attachment.sig>

From dev at jonasschnelli.ch  Wed Aug 17 11:34:35 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Wed, 17 Aug 2016 13:34:35 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
Message-ID: <57B44BCB.3010400@jonasschnelli.ch>

Hi Dana

>> The URI scheme does not require any sorts of wallet app level
>> configuration (where the stdio/pipe approach would require to configure
>> some details about the used hardware wallet).
> 
> Hi everybody, just thought I?d throw my opinion in here.
> 
> The URI scheme is a nice idea, but this ignores the fact that hardware wallet vendors do most of the work on talking between the computer/mobile and the wallet on a lower level of communication. In the case of BitLox, the base protocol is Google?s ProtoBuf. The commands and transaction data is in a ?schema? which is then encoded in different methods accessible via ProtoBuf (depending on the data being sent). The advantages of this protocol is that it can be implemented on a wide variety of platforms. (but that?s a whole 'nother discussion)
> 
> The URI would be handled waaaaay up in the specific application (such as the mytrezor wallet software or the various standalone wallets) - nowhere near the actual hardware communications layer.

This is maybe a question of the scope.
The BIP I'm proposing would make a clear interface cut between
wallet-with-unsigned-transaction and a signing-device (and maybe between
wallet-requires-pubkey, signing-device generate some pubkeys [or
non-hardened xpub]).

The detached-signing proposal does not duplicate work. It just moves the
current plugin design into a separate application. Plugins in security
and privacy critical wallet software is something that should probably
be avoided.

It's intentional at a high level to allow maximum flexibility at the
hardware interaction layer.

Your protobuf example is a good use-case. You could implement your
custom processes behind the URI scheme (which is probably way more
efficient then writing a couple of wallet plugins where you ? at the end
? mostly don't control the deployment and the source-code).

Defining a standard on the hardware interaction layer is possible, but a
fairly different approach.

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/3eea9613/attachment-0001.sig>

From jl2012 at xbt.hk  Wed Aug 17 12:43:47 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Wed, 17 Aug 2016 08:43:47 -0400 (EDT)
Subject: [bitcoin-dev] New BIP: Low S values signatures
In-Reply-To: <835406850.86951.1471342201363@privateemail.com>
References: <835406850.86951.1471342201363@privateemail.com>
Message-ID: <212784600.96759.1471437827809@privateemail.com>

The BIP146 has been updated to include NULLDUMMY* as part of the softfork:

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

NULLDUMMY is a trivial softfork to fix malleability related to the extra stack element consumed by CHECKMULTISIG(VERIFY). It is probably more important than LOW_S since without that an attacker may replace the stack element with any value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/9188d171/attachment.html>

From marek at palatinus.cz  Wed Aug 17 17:06:08 2016
From: marek at palatinus.cz (Marek Palatinus)
Date: Wed, 17 Aug 2016 19:06:08 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B44BCB.3010400@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
Message-ID: <CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>

Hi,

I fundamentally disagree with the concept of driving signing workflow by
the wallet software. Wallet software does not know in advance all data
necessary for the signer to do the job. As Jochen mentioned above, Segwit
vs Non-segwit use cases are a good example, but there may be many.

Currently the TREZOR protocol works like device is a server and wallet is a
client calling methods on it. It's like: "Sign this for me, please", "Ok,
give me this information", "Here it is", "Now I need this another
piece".... "There is the signature". Wallet does not know in advance what
will go next, and it is for sake of simplicity. I'm quite happy with the
protocol so far.

Considering the difference in between current hardware, I really don't
think it is possible to find any minimal URI-based API good enough for
communicating with all vendors. What I see more likely is some 3rd party
libraries (JS, C++, Python, ...) defining high-level API and implementing
hardware-specific protocols and transports as plugins. That way vendors are
not limited by strict standard and application developers and services can
integrate wide range of hardware wallets easily. However, this can be done
already and we do not need any standardization process (yet).

slush

On Wed, Aug 17, 2016 at 1:34 PM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Dana
>
> >> The URI scheme does not require any sorts of wallet app level
> >> configuration (where the stdio/pipe approach would require to configure
> >> some details about the used hardware wallet).
> >
> > Hi everybody, just thought I?d throw my opinion in here.
> >
> > The URI scheme is a nice idea, but this ignores the fact that hardware
> wallet vendors do most of the work on talking between the computer/mobile
> and the wallet on a lower level of communication. In the case of BitLox,
> the base protocol is Google?s ProtoBuf. The commands and transaction data
> is in a ?schema? which is then encoded in different methods accessible via
> ProtoBuf (depending on the data being sent). The advantages of this
> protocol is that it can be implemented on a wide variety of platforms. (but
> that?s a whole 'nother discussion)
> >
> > The URI would be handled waaaaay up in the specific application (such as
> the mytrezor wallet software or the various standalone wallets) - nowhere
> near the actual hardware communications layer.
>
> This is maybe a question of the scope.
> The BIP I'm proposing would make a clear interface cut between
> wallet-with-unsigned-transaction and a signing-device (and maybe between
> wallet-requires-pubkey, signing-device generate some pubkeys [or
> non-hardened xpub]).
>
> The detached-signing proposal does not duplicate work. It just moves the
> current plugin design into a separate application. Plugins in security
> and privacy critical wallet software is something that should probably
> be avoided.
>
> It's intentional at a high level to allow maximum flexibility at the
> hardware interaction layer.
>
> Your protobuf example is a good use-case. You could implement your
> custom processes behind the URI scheme (which is probably way more
> efficient then writing a couple of wallet plugins where you ? at the end
> ? mostly don't control the deployment and the source-code).
>
> Defining a standard on the hardware interaction layer is possible, but a
> fairly different approach.
>
> </jonas>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/136eadac/attachment.html>

From kanzure at gmail.com  Wed Aug 17 18:36:38 2016
From: kanzure at gmail.com (Bryan Bishop)
Date: Wed, 17 Aug 2016 13:36:38 -0500
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <20160817001407.GA6571@fedora-21-dvm>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<0501f5c2-611c-53c1-5fd1-d4da5ba5137b@gmail.com>
	<20160817001407.GA6571@fedora-21-dvm>
Message-ID: <CABaSBawL29aRF5aJ9jbshBU+FSzOPGYj0EaETawi7ttXewTAsg@mail.gmail.com>

On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>

"Welcome to my threat model."

In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.

I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.

Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.

As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.

Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.

((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))

- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/5492f37f/attachment.html>

From sergio.d.lerner at gmail.com  Thu Aug 18 00:11:16 2016
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Wed, 17 Aug 2016 21:11:16 -0300
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <703193091.96057.1471428948569@privateemail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
	<976728541.94211.1471402973613@privateemail.com>
	<201608170440.35767.luke@dashjr.org>
	<703193091.96057.1471428948569@privateemail.com>
Message-ID: <CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com>

I think that we're not attacking the real source of the problem: that the
witness data size is not signed. It may be the case that a new source of
malleability is detected in witness programs later, or related to new
opcodes we'll soft-fork in the future.

The problem is real, as some systems (such as hardware wallets or other
low-memory IoT embedded systems) may have hard limits in the size of the
witness program they can accept. So we need a solution for all current and
future segwit extension problems.

We could soft-fork to add an opcode OP_PROGSIZE using segwit script
versioning that pushes in the stack the size of the segwit program being
evaluated, and then the script can take any action it wishes based on that.

Example:
<0x50> OP_PROGSIZE OP_GREATERTHAN OP_VERIFY ..... OP_CHECKSIG

Then an attacker cannot create a clone of the transaction having a witness
ECDSA signature longer than 0x50 bytes. (many details omitted in this
example)



On Wed, Aug 17, 2016 at 7:15 AM, Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> > On August 17, 2016 at 12:40 AM Luke Dashjr <luke at dashjr.org> wrote:
> >
> >
> > On Wednesday, August 17, 2016 3:02:53 AM Johnson Lau via bitcoin-dev
> wrote:
> > > To completely replicate the original behaviour, one may use:
> > > "DEPTH TOALTSTACK IFDUP DEPTH FROMALTSTACK NUMNOTEQUAL IF 2DROP {if
> script}
> > > ELSE DROP {else script} ENDIF"
> >
> > This is much uglier than expected. IMO if that's the best workaround for
> the
> > current behaviour, people should just use "OP_1 OP_EQUAL OP_IF" when/if
> they
> > need to avoid malleability issues.
>
> It is ugly only if you want to faithfully replicate the behaviour. I'd
> argue that in no real use case you need to do this. For example, "OP_SIZE
> OP_IF" could just become "OP_SIZE OP_0NOTEQUAL OP_IF", since OP_SIZE must
> return a valid MINIMALDATA number.
>
> And your workaround does not fix malleability, since any non-0x01 values
> are valid FALSE
>
> However, in some case, enforcing MINIMALIF does require 1 more witness
> byte: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/
> 013036.html
>
> I think the best strategy is to make it a relay policy first, and decide
> whether we want a softfork later.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/7e9c664e/attachment-0001.html>

From sergio.d.lerner at gmail.com  Thu Aug 18 00:33:24 2016
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Wed, 17 Aug 2016 21:33:24 -0300
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
	<976728541.94211.1471402973613@privateemail.com>
	<201608170440.35767.luke@dashjr.org>
	<703193091.96057.1471428948569@privateemail.com>
	<CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com>
	<CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
Message-ID: <CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.com>

On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I think that we're not attacking the real source of the problem: that the
> > witness data size is not signed.
>
> It's not possible to do that for the general case, since you may not
> even know the witness size in advance (even for checksig's ECDSA, the
> encoding is variable sized).
>
> That's why scripts can check a maximum witness size, and not necessarily
an exact value.


I think that is overly focusing on "someone might change the feerate",
> yes that is an example of an undesirable witness tampering, but it's
> not the only one.
>
> I don't think fees are the problem. There is another problem. Let me
re-explain.
If I send a transaction to an IoT device (say to an OpenDime or to the old
Firmcoin), and the OpenDime must verify that the transaction has been mined
(SPV verification), then it may expect the witness program to be of certain
maximum size (an implementation-imposed  limit). If a Miner modifies the
witness size and makes it too large, then the device may not be able to
accept the transaction and the bitcoins may be lost. Lost because the
private key is in the device, and because the device cannot accept that
cloned transaction, never ever.

The same is true (although less strict) for side-chains and drive-chains:
they may have certain restrictions on the size of transactions they accept
to lock bitcoins.

That's why I'm proposing that a transaction becomes INVALID if the witness
size is higher than the expected size (by the sender).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/8a7bc92b/attachment.html>

From pete at petertodd.org  Thu Aug 18 03:00:38 2016
From: pete at petertodd.org (Peter Todd)
Date: Wed, 17 Aug 2016 20:00:38 -0700
Subject: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
In-Reply-To: <CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<CAMZUoKm2VX=kL7c3QsenQmQeKnR86APwvdNduDOUtOrtzL2B6A@mail.gmail.com>
	<976728541.94211.1471402973613@privateemail.com>
	<201608170440.35767.luke@dashjr.org>
	<703193091.96057.1471428948569@privateemail.com>
	<CAKzdR-qmL0Em058ama8CyAONrY2TbCSU7_SbfKoDEy0ZwnsFBA@mail.gmail.com>
	<CAAS2fgQ=Z+xmg0DcANV4vhp+XhpL1Vz0HNkJwNGdHTxtK1q1kg@mail.gmail.com>
	<CAKzdR-peLkVqdrnQS61J=H4e4N5dAnXa_+UzXR4cGPsjn=cWHw@mail.gmail.com>
Message-ID: <20160818030038.GA12001@fedora-21-dvm>

On Wed, Aug 17, 2016 at 09:33:24PM -0300, Sergio Demian Lerner via bitcoin-dev wrote:
> If I send a transaction to an IoT device (say to an OpenDime or to the old
> Firmcoin), and the OpenDime must verify that the transaction has been mined
> (SPV verification), then it may expect the witness program to be of certain
> maximum size (an implementation-imposed  limit). If a Miner modifies the
> witness size and makes it too large, then the device may not be able to
> accept the transaction and the bitcoins may be lost. Lost because the
> private key is in the device, and because the device cannot accept that
> cloned transaction, never ever.
> 
> The same is true (although less strict) for side-chains and drive-chains:
> they may have certain restrictions on the size of transactions they accept
> to lock bitcoins.
> 
> That's why I'm proposing that a transaction becomes INVALID if the witness
> size is higher than the expected size (by the sender).

An important part of the design of segwit is that resource constained devices
doing lite-client verification don't need to get witness data at all to verify
lite-client merkle-path proofs.

Remember that lite-clients can't verify anything useful in witnesses anyway, so
for them to have witness data is useless (unless they're doing some kind of
embedded consensus protocol with data published in witnesses, but few people
here care about that use-case).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/77ec1d9f/attachment.sig>

From dev at jonasschnelli.ch  Thu Aug 18 06:54:04 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Thu, 18 Aug 2016 08:54:04 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
Message-ID: <57B55B8C.1070001@jonasschnelli.ch>

Hi

> I fundamentally disagree with the concept of driving signing workflow by
> the wallet software. Wallet software does not know in advance all data
> necessary for the signer to do the job. As Jochen mentioned above,
> Segwit vs Non-segwit use cases are a good example, but there may be many.

I think this is easily solvable. The required data to verify and sign a
(standard) bitcoin transaction (including P2WSH multi-sig) is manageable.

IMO what a signing devices requires in order to sign a (standard)
transaction:
-> serialized tx
-> serialized tx of the inputs
-> scriptPubKey of the inputs
-> inputs redeem-Scripts
-> input amounts
-> position of the change output any maybe its keypath
-> cosigners pubkeys for inputs and changeaddress

This seems to be manageable for a 1 round communication?
Or do I miss something?


> Currently the TREZOR protocol works like device is a server and wallet
> is a client calling methods on it. It's like: "Sign this for me,
> please", "Ok, give me this information", "Here it is", "Now I need this
> another piece".... "There is the signature". Wallet does not know in
> advance what will go next, and it is for sake of simplicity. I'm quite
> happy with the protocol so far.

I think multiple rounds would still be possible with a clever design.
Although I could imaging that >95% of the users transaction would
require only a single "shot".

Whats the benefits of the multiple rounds communication? Would a single
round result in to many data transported?

Passing a 300kb chunk (assuming a large transaction) over a URI scheme
requires a couple of milliseconds on standard Smartphones or PCs.

> Considering the difference in between current hardware, I really don't
> think it is possible to find any minimal URI-based API good enough for
> communicating with all vendors. What I see more likely is some 3rd party
> libraries (JS, C++, Python, ...) defining high-level API and
> implementing hardware-specific protocols and transports as plugins. That
> way vendors are not limited by strict standard and application
> developers and services can integrate wide range of hardware wallets
> easily. However, this can be done already and we do not need any
> standardization process (yet).

The URI-based API allows transmitting data of multiple megabytes while
there is no need for...
* dependencies of any form (library, etc.)
* library support for a particular language
* platform that supports the dependencies of the library (like USBHID,
not supported by iOS)

Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?

How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?

Thanks
--
</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/5ae29972/attachment.sig>

From marek at palatinus.cz  Thu Aug 18 09:15:23 2016
From: marek at palatinus.cz (Marek Palatinus)
Date: Thu, 18 Aug 2016 11:15:23 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B55B8C.1070001@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
Message-ID: <CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>

> Can you elaborate what benefits you would get from the library approach
and how the library API would be different form the proposed URI-scheme?

The main benefit is that you don't need "standard" to solve problem, but
use natural tools in given environment and programming stack. Build a
"standard" on top of URI protocol is a huge limitation, which does not give
any advantage.

We already see issues with dead simple "bitcoin uri" standard, it barely
works in most of bitcoin apps. Think of vague definitions of parameters or
ability to send payment requests over it. HW API would be complicated by an
order of magnitude and I have serious concerns that it will be helpful for
anything. So why complicate things.

> How would the library approach work on mobile platforms? Would USB be
the only supported hardware communication layer?

Interprocess communication/libraries/dependencies on Android are not bound
to specific transport anyhow. Such library could be used by any android
app, and the library would implement proper transports for various
supported vendors. USB for Trezor, NFC for something different etc. If the
point is "make life of app developers easier", let's do this and do not
define artifical "standards".

slush


On Thu, Aug 18, 2016 at 8:54 AM, Jonas Schnelli <dev at jonasschnelli.ch>
wrote:

> Hi
>
> > I fundamentally disagree with the concept of driving signing workflow by
> > the wallet software. Wallet software does not know in advance all data
> > necessary for the signer to do the job. As Jochen mentioned above,
> > Segwit vs Non-segwit use cases are a good example, but there may be many.
>
> I think this is easily solvable. The required data to verify and sign a
> (standard) bitcoin transaction (including P2WSH multi-sig) is manageable.
>
> IMO what a signing devices requires in order to sign a (standard)
> transaction:
> -> serialized tx
> -> serialized tx of the inputs
> -> scriptPubKey of the inputs
> -> inputs redeem-Scripts
> -> input amounts
> -> position of the change output any maybe its keypath
> -> cosigners pubkeys for inputs and changeaddress
>
> This seems to be manageable for a 1 round communication?
> Or do I miss something?
>
>
> > Currently the TREZOR protocol works like device is a server and wallet
> > is a client calling methods on it. It's like: "Sign this for me,
> > please", "Ok, give me this information", "Here it is", "Now I need this
> > another piece".... "There is the signature". Wallet does not know in
> > advance what will go next, and it is for sake of simplicity. I'm quite
> > happy with the protocol so far.
>
> I think multiple rounds would still be possible with a clever design.
> Although I could imaging that >95% of the users transaction would
> require only a single "shot".
>
> Whats the benefits of the multiple rounds communication? Would a single
> round result in to many data transported?
>
> Passing a 300kb chunk (assuming a large transaction) over a URI scheme
> requires a couple of milliseconds on standard Smartphones or PCs.
>
> > Considering the difference in between current hardware, I really don't
> > think it is possible to find any minimal URI-based API good enough for
> > communicating with all vendors. What I see more likely is some 3rd party
> > libraries (JS, C++, Python, ...) defining high-level API and
> > implementing hardware-specific protocols and transports as plugins. That
> > way vendors are not limited by strict standard and application
> > developers and services can integrate wide range of hardware wallets
> > easily. However, this can be done already and we do not need any
> > standardization process (yet).
>
> The URI-based API allows transmitting data of multiple megabytes while
> there is no need for...
> * dependencies of any form (library, etc.)
> * library support for a particular language
> * platform that supports the dependencies of the library (like USBHID,
> not supported by iOS)
>
> Can you elaborate what benefits you would get from the library approach
> and how the library API would be different form the proposed URI-scheme?
>
> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
>
> Thanks
> --
> </jonas>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/59c71c94/attachment-0001.html>

From dev at jonasschnelli.ch  Thu Aug 18 09:35:05 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Thu, 18 Aug 2016 11:35:05 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
	<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
Message-ID: <57B58149.8000200@jonasschnelli.ch>

Hi

> The main benefit is that you don't need "standard" to solve problem, but
> use natural tools in given environment and programming stack. Build a
> "standard" on top of URI protocol is a huge limitation, which does not
> give any advantage.

Standards can help an ecosystem to grow, can help to sustain a good user
experience.

The hardware wallet vendors have used "natural tools" and look where we
are. We have *native* plugins in Electrum, Copay, etc. for different
hardware wallets. Mostly the plugins are in the code base of the wallet,
which makes it ? in theory ? impossible to change from the perspective
of the hardware wallet vendor (there is no control of the deployment if
there are bugs in the plugins code).
The plugins functions overlap significant.

I think this is a bad design for security critical applications.

What I want as hardware wallet user:
* I'd like to have a trusted application (layer) where I'm sure I'm
using software provided through my hardware wallet vendor.

What I want as hardware wallet vendor:
* I'd like to be able to provide and update a software layer (app) to my
customer with the ability to provide code signatures and security
updates anytime. I do want to control the user experience.


> We already see issues with dead simple "bitcoin uri" standard, it barely
> works in most of bitcoin apps. Think of vague definitions of parameters
> or ability to send payment requests over it. HW API would be complicated
> by an order of magnitude and I have serious concerns that it will be
> helpful for anything. So why complicate things.

As far as I know most bitcoin wallets do support the bitcoin:// URI
scheme quite well.
I agree that BIP70 is a mess (including the bitcoin:// additions).

The proposed URI scheme would be completely different. The only
similarity is using the URI scheme as transport layer (which is the
proposed long term inter-app communication layer by Apple and Google).

>> How would the library approach work on mobile platforms? Would USB be
> the only supported hardware communication layer?
> 
> Interprocess communication/libraries/dependencies on Android are not
> bound to specific transport anyhow. Such library could be used by any
> android app, and the library would implement proper transports for
> various supported vendors. USB for Trezor, NFC for something different
> etc. If the point is "make life of app developers easier", let's do this
> and do not define artifical "standards".

So you propose having one library that would support multiple vendors?
What if new vendors add a new transport layer (lets assume NFC or
Bluetooth), wouldn't that result in every possible consumer of that
library (all wallets) need to update before the new vendors transport
layer could be used, resulting in a huge deployment process probably
require many month until it can be used?

What if there is a critical security issue in the library? How would the
deployment plan looks like?

I really think we should remove the "hardware communication layer" from
wallets and move it towards the hardware vendor app.

What about iOS? Should we just leave that platform unsupported with
hardware wallets?

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/ca1a24d9/attachment.sig>

From marek at palatinus.cz  Thu Aug 18 09:43:33 2016
From: marek at palatinus.cz (Marek Palatinus)
Date: Thu, 18 Aug 2016 11:43:33 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B58149.8000200@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
	<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
	<57B58149.8000200@jonasschnelli.ch>
Message-ID: <CAJna-Hj8HQy9Dhx3Gx8CpmpgoiQZ2waaj9o5b6hHwda4Dm_fGw@mail.gmail.com>

On Thu, Aug 18, 2016 at 11:35 AM, Jonas Schnelli <dev at jonasschnelli.ch>
wrote:

> I agree that BIP70 is a mess (including the bitcoin:// additions). The
> proposed URI scheme would be completely different.


This reminds me https://xkcd.com/927/

I have some experience with hardware wallet development and its integration
and I know it's a mess. But it is too early to define such rigid standards
yet. Also, TREZOR concept (device as a server and the primary source of
workflow management) goes directly against your proposal of wallet software
as an workflow manager. So it is clear NACK for me.

slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/2fd8ecbe/attachment.html>

From dev at jonasschnelli.ch  Thu Aug 18 09:49:51 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Thu, 18 Aug 2016 11:49:51 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <CAJna-Hj8HQy9Dhx3Gx8CpmpgoiQZ2waaj9o5b6hHwda4Dm_fGw@mail.gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
	<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
	<57B58149.8000200@jonasschnelli.ch>
	<CAJna-Hj8HQy9Dhx3Gx8CpmpgoiQZ2waaj9o5b6hHwda4Dm_fGw@mail.gmail.com>
Message-ID: <57B584BF.7000004@jonasschnelli.ch>

Hi

> I have some experience with hardware wallet development and its
> integration and I know it's a mess. But it is too early to define such
> rigid standards yet. Also, TREZOR concept (device as a server and the
> primary source of workflow management) goes directly against your
> proposal of wallet software as an workflow manager. So it is clear NACK
> for me.

The current question ? as already mentioned ? is we ACK to work together
on a signing protocol or if we NACK this before we even have started.

I'm not saying that the draft proposal I made is the way to go, I'm
happy to NACK it myself in favor of a better proposal.

I strongly recommend to work together on a standard that will have one
central winner: the end user.

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/343d9d28/attachment.sig>

From nicolas at ledger.fr  Thu Aug 18 10:23:21 2016
From: nicolas at ledger.fr (Nicolas Bacca)
Date: Thu, 18 Aug 2016 12:23:21 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B584BF.7000004@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
	<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
	<57B58149.8000200@jonasschnelli.ch>
	<CAJna-Hj8HQy9Dhx3Gx8CpmpgoiQZ2waaj9o5b6hHwda4Dm_fGw@mail.gmail.com>
	<57B584BF.7000004@jonasschnelli.ch>
Message-ID: <CALGb225DLv22ktt_7HJTcuPphJ=TMEU_b3LApBJy17KgAZwSzQ@mail.gmail.com>

On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi
>
> > I have some experience with hardware wallet development and its
> > integration and I know it's a mess. But it is too early to define such
> > rigid standards yet. Also, TREZOR concept (device as a server and the
> > primary source of workflow management) goes directly against your
> > proposal of wallet software as an workflow manager. So it is clear NACK
> > for me.
>
> The current question ? as already mentioned ? is we ACK to work together
> on a signing protocol or if we NACK this before we even have started.
>

ACK for Ledger. What's necessary to sign a transaction is well known, I
don't see how driving any hardware wallet from the wallet itself or from a
third party daemon implementing that URL scheme would make any difference,
other than providing better devices interoperability, as well as easier
maintenance and update paths for the wallets.

-- 
Nicolas Bacca | CTO, Ledger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160818/cac3d457/attachment.html>

From luke at dashjr.org  Thu Aug 18 21:09:00 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Thu, 18 Aug 2016 21:09:00 +0000
Subject: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113
Message-ID: <201608182109.01522.luke@dashjr.org>

On Friday, July 15, 2016 4:46:57 PM Wladimir J. van der Laan wrote:
> On Fri, Jul 15, 2016 at 03:52:37PM +0000, Luke Dashjr wrote:
> > On Friday, July 15, 2016 3:46:28 PM Wladimir J. van der Laan wrote:
> > > I'm not sure why it is labeled as only "Informational" in the first
> > > place, as BIP9 is part of the consensus logic.
> > 
> > Only by proxy/inclusion from another BIP, such as 68, 112, and 113. In
> > other words, BIP 9 is informational in that it advises how other BIPs
> > might deploy themselves.
> 
> It's a bit of grey area, as indeed, only the BIPs that are actual softforks
> are consensus changes - which employ this mechanism for deployment. But I
> think such an important deployment mechanism, which is supposed to be used
> by all softforks from now onwards, shouldn't just be an informational BIP.

As things stand right now, none of the Authors have commented on changing the 
type. It has been a month, and I am prepared to change the status to Final or 
Active; but I am unclear if your comments were an objection to changing the 
status or not.

Last call: Does anyone mind if I update BIP 9 to Final status?

Luke

From btcdrak at gmail.com  Thu Aug 18 23:05:59 2016
From: btcdrak at gmail.com (Btc Drak)
Date: Fri, 19 Aug 2016 00:05:59 +0100
Subject: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113
In-Reply-To: <201607151531.00058.luke@dashjr.org>
References: <201607151531.00058.luke@dashjr.org>
Message-ID: <CADJgMzucAsUkfs=K8aL8qeCoSNzMJxPsx7dd6dmAcsMy-Hj=5Q@mail.gmail.com>

Fine by me to update BIP68 and BIP112 to Final status. The forks have
activated.

On Fri, Jul 15, 2016 at 4:30 PM, Luke Dashjr <luke at dashjr.org> wrote:

> Daniel Cousens opened the issue a few weeks ago, that BIP 9 should
> progress to
> Accepted stage. However, as an informational BIP, it is not entirely clear
> on
> whether it falls in the Draft/Accepted/Final classification of proposals
> requiring implementation, or the Draft/Active classification like process
> BIPs. Background of this discussion is at:
>     https://github.com/bitcoin/bips/pull/413
> (Discussion on the GitHub BIPs repo is *NOT* recommended, hence bringing
> this
> topic to the mailing list)
>
> Reviewing the criteria for status changes, my opinion is that:
> - BIPs 68, 112, 113, and 141 are themselves implementations of BIP 9
> -- therefore, BIP 9 falls under the Draft/Accepted/Final class
> - BIPs 68, 112, and 113 have been deployed to the network successfully
> -- therefore, BIP 9 has satisfied the conditions of not only Accepted
> status,
>    but also Final status
> -- therefore, BIPs 68, 112, and 113 also ought to be Final status
>
> If there are no objections, I plan to update the status to Final for BIPs
> 9,
> 68, 112, and 113 in one month. Since all four BIPs are currently Draft, I
> also
> need at least one author from each BIP to sign-off on promoting them to
> (and
> beyond) Accepted.
>
> BIP   9: Pieter Wuille <pieter.wuille at gmail.com>
>          Peter Todd <pete at petertodd.org>
>          Greg Maxwell <greg at xiph.org>
>          Rusty Russell <rusty at rustcorp.com.au>
>
> BIP  68: Mark Friedenbach <mark at friedenbach.org>
>          BtcDrak <btcdrak at gmail.com>
>          Nicolas Dorier <nicolas.dorier at gmail.com>
>          kinoshitajona <kinoshitajona at gmail.com>
>
> BIP 112: BtcDrak <btcdrak at gmail.com>
>          Mark Friedenbach <mark at friedenbach.org>
>          Eric Lombrozo <elombrozo at gmail.com>
>
> BIP 113: Thomas Kerin <me at thomaskerin.io>
>          Mark Friedenbach <mark at friedenbach.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160819/70d02f16/attachment.html>

From ethan.scruples at gmail.com  Mon Aug 22 16:50:13 2016
From: ethan.scruples at gmail.com (Moral Agent)
Date: Mon, 22 Aug 2016 12:50:13 -0400
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <57B31EBC.1030806@jonasschnelli.ch>
References: <57B31EBC.1030806@jonasschnelli.ch>
Message-ID: <CACiOHGycQKr3zETzhOfxzOFb2FgqOou_3bod66NuPWbf=4hhEQ@mail.gmail.com>

It would be nice if the detached signer and the normal wallet could both
verify the correctness of generated addresses before you cause coins to be
sent there.

e.g. the hardware wallet could give its master public key to Bitcoin Core
and you can thereafter generate your receiving addresses on Core, with the
option to have the HW wallet validate them.

One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?

With the above scheme, you are pretty well protected from losing money if
your HW wallet is defective. You could still lose it if the HW wallet was
evil of course, but that strikes me as much more likely to be discovered
quickly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160822/2f6378e9/attachment.html>

From laanwj at gmail.com  Tue Aug 23 15:23:38 2016
From: laanwj at gmail.com (Wladimir J. van der Laan)
Date: Tue, 23 Aug 2016 17:23:38 +0200
Subject: [bitcoin-dev] Bitcoin Core 0.13.0 released
Message-ID: <20160823152338.GA3176@amethyst.visucore.com>

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

Bitcoin Core version 0.13.0 is now available from:

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

Or through bittorrent:

  magnet:?xt=urn:btih:35367ed2db6c41f7af9c1ed2dd54ae29d99bc632&dn=bitcoin-core-0.13.0&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 major version release, including new features, 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 verion 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.

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

Database cache memory increased
- --------------------------------

As a result of growth of the UTXO set, performance with the prior default
database cache of 100 MiB has suffered.
For this reason the default was changed to 300 MiB in this release.

For nodes on low-memory systems, the database cache can be changed back to
100 MiB (or to another value) by either:

- - Adding `dbcache=100` in bitcoin.conf
- - Changing it in the GUI under `Options ? Size of database cache`

Note that the database cache setting has the most performance impact
during initial sync of a node, and when catching up after downtime.


bitcoin-cli: arguments privacy
- ------------------------------

The RPC command line client gained a new argument, `-stdin`
to read extra arguments from standard input, one per line until EOF/Ctrl-D.
For example:

    $ src/bitcoin-cli -stdin walletpassphrase
    mysecretcode
    120
    ..... press Ctrl-D here to end input
    $

It is recommended to use this for sensitive information such as wallet
passphrases, as command-line arguments can usually be read from the process
table by any user on the system.


C++11 and Python 3
- ------------------

Various code modernizations have been done. The Bitcoin Core code base has
started using C++11. This means that a C++11-capable compiler is now needed for
building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.

When cross-compiling for a target that doesn't have C++11 libraries, configure with
`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`.

For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now
required.


Linux ARM builds
- ----------------

Due to popular request, Linux ARM builds have been added to the uploaded
executables.

The following extra files can be found in the download directory or torrent:

- - `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most
  common 32-bit ARM architecture.
- - `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most
  common 64-bit ARM architecture.

ARM builds are still experimental. If you have problems on a certain device or
Linux distribution combination please report them on the bug tracker, it may be
possible to resolve them.

Note that Android is not considered ARM Linux in this context. The executables
are not expected to work out of the box on Android.


Compact Block support (BIP 152)
- -------------------------------

Support for block relay using the Compact Blocks protocol has been implemented
in PR 8068.

The primary goal is reducing the bandwidth spikes at relay time, though in many
cases it also reduces propagation delay. It is automatically enabled between
compatible peers.
[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)

As a side-effect, ordinary non-mining nodes will download and upload blocks
faster if those blocks were produced by miners using similar transaction
filtering policies. This means that a miner who produces a block with many
transactions discouraged by your node will be relayed slower than one with
only transactions already in your memory pool. The overall effect of such
relay differences on the network may result in blocks which include widely-
discouraged transactions losing a stale block race, and therefore miners may
wish to configure their node to take common relay policies into consideration.


Hierarchical Deterministic Key Generation
- -----------------------------------------
Newly created wallets will use hierarchical deterministic key generation
according to BIP32 (keypath m/0'/0'/k').
Existing wallets will still use traditional key generation.

Backups of HD wallets, regardless of when they have been created, can
therefore be used to re-generate all possible private keys, even the
ones which haven't already been generated during the time of the backup.
**Attention:** Encrypting the wallet will create a new seed which requires
a new backup!

Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic
seed. This is expected to allow future versions to import the seed and all
associated funds, but this is not yet implemented.

HD key generation for new wallets can be disabled by `-usehd=0`. Keep in
mind that this flag only has affect on newly created wallets.
You can't disable HD key generation once you have created a HD wallet.

There is no distinction between internal (change) and external keys.

HD wallets are incompatible with older versions of Bitcoin Core.

[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)


Segregated Witness
- ------------------

The code preparations for Segregated Witness ("segwit"), as described in [BIP
141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), [BIP
143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), [BIP
144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), and [BIP
145](https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) are
finished and included in this release.  However, BIP 141 does not yet specify
activation parameters on mainnet, and so this release does not support segwit
use on mainnet.  Testnet use is supported, and after BIP 141 is updated with
proposed parameters, a future release of Bitcoin Core is expected that
implements those parameters for mainnet.

Furthermore, because segwit activation is not yet specified for mainnet,
version 0.13.0 will behave similarly as other pre-segwit releases even after a
future activation of BIP 141 on the network.  Upgrading from 0.13.0 will be
required in order to utilize segwit-related features on mainnet (such as signal
BIP 141 activation, mine segwit blocks, fully validate segwit blocks, relay
segwit blocks to other segwit nodes, and use segwit transactions in the
wallet, etc).


Mining transaction selection ("Child Pays For Parent")
- ------------------------------------------------------

The mining transaction selection algorithm has been replaced with an algorithm
that selects transactions based on their feerate inclusive of unconfirmed
ancestor transactions.  This means that a low-fee transaction can become more
likely to be selected if a high-fee transaction that spends its outputs is
relayed.

With this change, the `-blockminsize` command line option has been removed.

The command line option `-blockmaxsize` remains an option to specify the
maximum number of serialized bytes in a generated block.  In addition, the new
command line option `-blockmaxweight` has been added, which specifies the
maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated
Witness)] (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).

In preparation for Segregated Witness, the mining algorithm has been modified
to optimize transaction selection for a given block weight, rather than a given
number of serialized bytes in a block.  In this release, transaction selection
is unaffected by this distinction (as BIP 141 activation is not supported on
mainnet in this release, see above), but in future releases and after BIP 141
activation, these calculations would be expected to differ.

For optimal runtime performance, miners using this release should specify
`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.
Additionally (or only) specifying `-blockmaxsize`, or relying on default
settings for both, may result in performance degradation, as the logic to
support `-blockmaxsize` performs additional computation to ensure that
constraint is met.  (Note that for mainnet, in this release, the equivalent
parameter for `-blockmaxweight` would be four times the desired
`-blockmaxsize`.  See [BIP 141]
(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional
details.)

In the future, the `-blockmaxsize` option may be removed, as block creation is
no longer optimized for this metric.  Feedback is requested on whether to
deprecate or keep this command line option in future releases.


Reindexing changes
- ------------------

In earlier versions, reindexing did validation while reading through the block
files on disk. These two have now been split up, so that all blocks are known
before validation starts. This was necessary to make certain optimizations that
are available during normal synchronizations also available during reindexing.

The two phases are distinct in the Bitcoin-Qt GUI. During the first one,
"Reindexing blocks on disk" is shown. During the second (slower) one,
"Processing blocks on disk" is shown.

It is possible to only redo validation now, without rebuilding the block index,
using the command line option `-reindex-chainstate` (in addition to
`-reindex` which does both). This new option is useful when the blocks on disk
are assumed to be fine, but the chainstate is still corrupted. It is also
useful for benchmarks.


Removal of internal miner
- --------------------------

As CPU mining has been useless for a long time, the internal miner has been
removed in this release, and replaced with a simpler implementation for the
test framework.

The overall result of this is that `setgenerate` RPC call has been removed, as
well as the `-gen` and `-genproclimit` command-line options.

For testing, the `generate` call can still be used to mine a block, and a new
RPC call `generatetoaddress` has been added to mine to a specific address. This
works with wallet disabled.


New bytespersigop implementation
- --------------------------------

The former implementation of the bytespersigop filter accidentally broke bare
multisig (which is meant to be controlled by the `permitbaremultisig` option),
since the consensus protocol always counts these older transaction forms as 20
sigops for backwards compatibility. Simply fixing this bug by counting more
accurately would have reintroduced a vulnerability. It has therefore been
replaced with a new implementation that rather than filter such transactions,
instead treats them (for fee purposes only) as if they were in fact the size
of a transaction actually using all 20 sigops.


Low-level P2P changes
- ----------------------

- - The optional new p2p message "feefilter" is implemented and the protocol
  version is bumped to 70013. Upon receiving a feefilter message from a peer,
  a node will not send invs for any transactions which do not meet the filter
  feerate. [BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki)

- - The P2P alert system has been removed in PR #7692 and the `alert` P2P message
  is no longer supported.

- - The transaction relay mechanism used to relay one quarter of all transactions
  instantly, while queueing up the rest and sending them out in batch. As
  this resulted in chains of dependent transactions being reordered, it
  systematically hurt transaction relay. The relay code was redesigned in PRs
  \#7840 and #8082, and now always batches transactions announcements while also
  sorting them according to dependency order. This significantly reduces orphan
  transactions. To compensate for the removal of instant relay, the frequency of
  batch sending was doubled for outgoing peers.

- - Since PR #7840 the BIP35 `mempool` command is also subject to batch processing.
  Also the `mempool` message is no longer handled for non-whitelisted peers when
  `NODE_BLOOM` is disabled through `-peerbloomfilters=0`.

- - The maximum size of orphan transactions that are kept in memory until their
  ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They
  are now also removed from memory when they are included in a block, conflict
  with a block, and time out after 20 minutes.

- - We respond at most once to a getaddr request during the lifetime of a
  connection since PR #7856.

- - Connections to peers who have recently been the first one to give us a valid
  new block or transaction are protected from disconnections since PR #8084.


Low-level RPC changes
- ----------------------

- - RPC calls have been added to output detailed statistics for individual mempool
  entries, as well as to calculate the in-mempool ancestors or descendants of a
  transaction: see `getmempoolentry`, `getmempoolancestors`, `getmempooldescendants`.

- - `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a divergence between
  32-bit and 64-bit platforms, and the txids were missing in the hashed data. This has been
  fixed, but this means that the output will be different than from previous versions.

- - Full UTF-8 support in the RPC API. Non-ASCII characters in, for example,
  wallet labels have always been malformed because they weren't taken into account
  properly in JSON RPC processing. This is no longer the case. This also affects
  the GUI debug console.

- - Asm script outputs replacements for OP_NOP2 and OP_NOP3

  - OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP 
65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)

  - OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP 
112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)

  - The following outputs are affected by this change:

    - RPC `getrawtransaction` (in verbose mode)
    - RPC `decoderawtransaction`
    - RPC `decodescript`
    - REST `/rest/tx/` (JSON format)
    - REST `/rest/block/` (JSON format when including extended tx details)
    - `bitcoin-tx -json`

- - The sorting of the output of the `getrawmempool` output has changed.

- - New RPC commands: `generatetoaddress`, `importprunedfunds`, `removeprunedfunds`, `signmessagewithprivkey`,
  `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`,
  `createwitnessaddress`, `addwitnessaddress`.

- - Removed RPC commands: `setgenerate`, `getgenerate`.

- - New options were added to `fundrawtransaction`: `includeWatching`, `changeAddress`, `changePosition` and `feeRate`.


Low-level ZMQ changes
- ----------------------

- - Each ZMQ notification now contains an up-counting sequence number that allows
  listeners to detect lost notifications.
  The sequence number is always the last element in a multi-part ZMQ notification and
  therefore backward compatible. Each message type has its own counter.
  PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762).


0.13.0 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

- - #7156 `9ee02cf` Remove cs_main lock from `createrawtransaction` (laanwj)
- - #7326 `2cd004b` Fix typo, wrong information in gettxout help text (paveljanik)
- - #7222 `82429d0` Indicate which transactions are signaling opt-in RBF (sdaftuar)
- - #7480 `b49a623` Changed getnetworkhps value to double to avoid overflow (instagibbs)
- - #7550 `8b958ab` Input-from-stdin mode for bitcoin-cli (laanwj)
- - #7670 `c9a1265` Use cached block hash in blockToJSON() (rat4)
- - #7726 `9af69fa` Correct importaddress help reference to importpubkey (CypherGrue)
- - #7766 `16555b6` Register calls where they are defined (laanwj)
- - #7797 `e662a76` Fix generatetoaddress failing to parse address (mruddy)
- - #7774 `916b15a` Add versionHex in getblock and getblockheader JSON results (mruddy)
- - #7863 `72c54e3` Getblockchaininfo: make bip9_softforks an object, not an array (rustyrussell)
- - #7842 `d97101e` Do not print minping time in getpeerinfo when no ping received yet (paveljanik)
- - #7518 `be14ca5` Add multiple options to fundrawtransaction (promag)
- - #7756 `9e47fce` Add cursor to iterate over utxo set, use this in `gettxoutsetinfo` (laanwj)
- - #7848 `88616d2` Divergence between 32- and 64-bit when hashing >4GB affects `gettxoutsetinfo` (laanwj)
- - #7827 `4205ad7` Speed up `getchaintips` (mrbandrews)
- - #7762 `a1eb344` Append a message sequence number to every ZMQ notification (jonasschnelli)
- - #7688 `46880ed` List solvability in listunspent output and improve help (sipa)
- - #7926 `5725807` Push back `getaddednodeinfo` dead value (instagibbs)
- - #7953 `0630353` Create `signmessagewithprivkey` rpc (achow101)
- - #8049 `c028c7b` Expose information on whether transaction relay is enabled in `getnetworkinfo` (laanwj)
- - #7967 `8c1e49b` Add feerate option to `fundrawtransaction` (jonasschnelli)
- - #8118 `9b6a48c` Reduce unnecessary hashing in `signrawtransaction` (jonasnick)
- - #7957 `79004d4` Add support for transaction sequence number (jonasschnelli)
- - #8153 `75ec320` `fundrawtransaction` feeRate: Use BTC/kB (MarcoFalke)
- - #7292 `7ce9ac5` Expose ancestor/descendant information over RPC (sdaftuar)
- - #8171 `62fcf27` Fix createrawtx sequence number unsigned int parsing (jonasschnelli)
- - #7892 `9c3d0fa` Add full UTF-8 support to RPC (laanwj)
- - #8317 `304eff3` Don't use floating point in rpcwallet (MarcoFalke)
- - #8258 `5a06ebb` Hide softfork in `getblockchaininfo` if timeout is 0 (jl2012)
- - #8244 `1922e5a` Remove unnecessary LOCK(cs_main) in getrawmempool (dcousens)

### Block and transaction handling

- - #7056 `6a07208` Save last db read (morcos)
- - #6842 `0192806` Limitfreerelay edge case bugfix (ptschip)
- - #7084 `11d74f6` Replace maxFeeRate of 10000*minRelayTxFee with maxTxFee in mempool (MarcoFalke)
- - #7539 `9f33dba` Add tags to mempool's mapTx indices (sdaftuar)
- - #7592 `26a2a72` Re-remove ERROR logging for mempool rejects (laanwj)
- - #7187 `14d6324` Keep reorgs fast for SequenceLocks checks (morcos)
- - #7594 `01f4267` Mempool: Add tracking of ancestor packages (sdaftuar)
- - #7904 `fc9e334` Txdb: Fix assert crash in new UTXO set cursor (laanwj)
- - #7927 `f9c2ac7` Minor changes to dbwrapper to simplify support for other databases (laanwj)
- - #7933 `e26b620` Fix OOM when deserializing UTXO entries with invalid length (sipa)
- - #8020 `5e374f7` Use SipHash-2-4 for various non-cryptographic hashes (sipa)
- - #8076 `d720980` VerifyDB: don't check blocks that have been pruned (sdaftuar)
- - #8080 `862fd24` Do not use mempool for GETDATA for tx accepted after the last mempool req (gmaxwell)
- - #7997 `a82f033` Replace mapNextTx with slimmer setSpends (kazcw)
- - #8220 `1f86d64` Stop trimming when mapTx is empty (sipa)
- - #8273 `396f9d6` Bump `-dbcache` default to 300MiB (laanwj)
- - #7225 `eb33179` Eliminate unnecessary call to CheckBlock (sdaftuar)
- - #7907 `006cdf6` Optimize and Cleanup CScript::FindAndDelete (pstratem)
- - #7917 `239d419` Optimize reindex (sipa)
- - #7763 `3081fb9` Put hex-encoded version in UpdateTip (sipa)
- - #8149 `d612837` Testnet-only segregated witness (sipa)
- - #8305 `3730393` Improve handling of unconnecting headers (sdaftuar)
- - #8363 `fca1a41` Rename "block cost" to "block weight" (sdaftuar)
- - #8381 `f84ee3d` Make witness v0 outputs non-standard (jl2012)
- - #8364 `3f65ba2` Treat high-sigop transactions as larger rather than rejecting them (sipa)

### P2P protocol and network code

- - #6589 `dc0305d` Log bytes recv/sent per command (jonasschnelli)
- - #7164 `3b43cad` Do not download transactions during initial blockchain sync (ptschip)
- - #7458 `898fedf` peers.dat, banlist.dat recreated when missing (kirkalx)
- - #7637 `3da5d1b` Fix memleak in TorController (laanwj, jonasschnelli)
- - #7553 `9f14e5a` Remove vfReachable and modify IsReachable to only use vfLimited (pstratem)
- - #7708 `9426632` De-neuter NODE_BLOOM (pstratem)
- - #7692 `29b2be6` Remove P2P alert system (btcdrak)
- - #7542 `c946a15` Implement "feefilter" P2P message (morcos)
- - #7573 `352fd57` Add `-maxtimeadjustment` command line option (mruddy)
- - #7570 `232592a` Add IPv6 Link-Local Address Support (mruddy)
- - #7874 `e6a4d48` Improve AlreadyHave (morcos)
- - #7856 `64e71b3` Only send one GetAddr response per connection (gmaxwell)
- - #7868 `7daa3ad` Split DNS resolving functionality out of net structures (theuni)
- - #7919 `7617682` Fix headers announcements edge case (sdaftuar)
- - #7514 `d9594bf` Fix IsInitialBlockDownload for testnet (jmacwhyte)
- - #7959 `03cf6e8` fix race that could fail to persist a ban (kazcw)
- - #7840 `3b9a0bf` Several performance and privacy improvements to inv/mempool handling (sipa)
- - #8011 `65aecda` Don't run ThreadMessageHandler at lowered priority (kazcw)
- - #7696 `5c3f8dd` Fix de-serialization bug where AddrMan is left corrupted (EthanHeilman)
- - #7932 `ed749bd` CAddrMan::Deserialize handle corrupt serializations better (pstratem)
- - #7906 `83121cc` Prerequisites for p2p encapsulation changes (theuni)
- - #8033 `18436d8` Fix Socks5() connect failures to be less noisy and less unnecessarily scary (wtogami)
- - #8082 `01d8359` Defer inserting into maprelay until just before relaying (gmaxwell)
- - #7960 `6a22373` Only use AddInventoryKnown for transactions (sdaftuar)
- - #8078 `2156fa2` Disable the mempool P2P command when bloom filters disabled (petertodd)
- - #8065 `67c91f8` Addrman offline attempts (gmaxwell)
- - #7703 `761cddb` Tor: Change auth order to only use password auth if -torpassword (laanwj)
- - #8083 `cd0c513` Add support for dnsseeds with option to filter by servicebits (jonasschnelli)
- - #8173 `4286f43` Use SipHash for node eviction (sipa)
- - #8154 `1445835` Drop vAddrToSend after sending big addr message (kazcw)
- - #7749 `be9711e` Enforce expected outbound services (sipa)
- - #8208 `0a64777` Do not set extra flags for unfiltered DNS seed results (sipa)
- - #8084 `e4bb4a8` Add recently accepted blocks and txn to AttemptToEvictConnection (gmaxwell)
- - #8113 `3f89a53` Rework addnode behaviour (sipa)
- - #8179 `94ab58b` Evict orphans which are included or precluded by accepted blocks (gmaxwell)
- - #8068 `e9d76a1` Compact Blocks (TheBlueMatt)
- - #8204 `0833894` Update petertodd's testnet seed (petertodd)
- - #8247 `5cd35d3` Mark my dnsseed as supporting filtering (sipa)
- - #8275 `042c323` Remove bad chain alert partition check (btcdrak)
- - #8271 `1bc9c80` Do not send witnesses in cmpctblock (sipa)
- - #8312 `ca40ef6` Fix mempool DoS vulnerability from malleated transactions (sdaftuar)
- - #7180 `16ccb74` Account for `sendheaders` `verack` messages (laanwj)
- - #8102 `425278d` Bugfix: use global ::fRelayTxes instead of CNode in version send (sipa)
- - #8408 `b7e2011` Prevent fingerprinting, disk-DoS with compact blocks (sdaftuar)

### Build system

- - #7302 `41f1a3e` C++11 build/runtime fixes (theuni)
- - #7322 `fd9356b` c++11: add scoped enum fallbacks to CPPFLAGS rather than defining them locally (theuni)
- - #7441 `a6771fc` Use Debian 8.3 in gitian build guide (fanquake)
- - #7349 `152a821` Build against system UniValue when available (luke-jr)
- - #7520 `621940e` LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead (paveljanik)
- - #7528 `9b9bfce` autogen.sh: warn about needing autoconf if autoreconf is not found (knocte)
- - #7504 `19324cf` Crystal clean make clean (paveljanik)
- - #7619 `18b3f1b` Add missing sudo entry in gitian VM setup (btcdrak)
- - #7616 `639ec58`  [depends] Delete unused patches  (MarcoFalke)
- - #7658 `c15eb28` Add curl to Gitian setup instructions (btcdrak)
- - #7710 `909b72b` [Depends] Bump miniupnpc and config.guess+sub (fanquake)
- - #7723 `5131005` build: python 3 compatibility (laanwj)
- - #7477 `28ad4d9` Fix quoting of copyright holders in configure.ac (domob1812)
- - #7711 `a67bc5e` [build-aux] Update Boost & check macros to latest serials (fanquake)
- - #7788 `4dc1b3a` Use relative paths instead of absolute paths in protoc calls (paveljanik)
- - #7809 `bbd210d` depends: some base fixes/changes (theuni)
- - #7603 `73fc922` Build System: Use PACKAGE_TARNAME in NSIS script (JeremyRand)
- - #7905 `187186b` test: move accounting_tests and rpc_wallet_tests to wallet/test (laanwj)
- - #7911 `351abf9` leveldb: integrate leveldb into our buildsystem (theuni)
- - #7944 `a407807` Re-instate TARGET_OS=linux in configure.ac. Removed by 351abf9e035 (randy-waterhouse)
- - #7920 `c3e3cfb` Switch Travis to Trusty (theuni)
- - #7954 `08b37c5` build: quiet annoying warnings without adding new ones (theuni)
- - #7165 `06162f1` build: Enable C++11 in build, require C++11 compiler (laanwj)
- - #7982 `559fbae` build: No need to check for leveldb atomics (theuni)
- - #8002 `f9b4582` [depends] Add -stdlib=libc++ to darwin CXX flags (fanquake)
- - #7993 `6a034ed` [depends] Bump Freetype, ccache, ZeroMQ, miniupnpc, expat (fanquake)
- - #8167 `19ea173` Ship debug tarballs/zips with debug symbols (theuni)
- - #8175 `f0299d8` Add --disable-bench to config flags for windows (laanwj)
- - #7283 `fd9881a` [gitian] Default reference_datetime to commit author date (MarcoFalke)
- - #8181 `9201ce8` Get rid of `CLIENT_DATE` (laanwj)
- - #8133 `fde0ac4` Finish up out-of-tree changes (theuni)
- - #8188 `65a9d7d` Add armhf/aarch64 gitian builds (theuni)
- - #8194 `cca1c8c` [gitian] set correct PATH for wrappers (MarcoFalke)
- - #8198 `5201614` Sync ax_pthread with upstream draft4 (fanquake)
- - #8210 `12a541e` [Qt] Bump to Qt5.6.1 (jonasschnelli)
- - #8285 `da50997` windows: Add testnet link to installer (laanwj)
- - #8304 `0cca2fe` [travis] Update SDK_URL (MarcoFalke)
- - #8310 `6ae20df` Require boost for bench (theuni)
- - #8315 `2e51590` Don't require sudo for Linux (theuni)
- - #8314 `67caef6` Fix pkg-config issues for 0.13 (theuni)
- - #8373 `1fe7f40` Fix OSX non-deterministic dmg (theuni)
- - #8358 `cfd1280` Gbuild: Set memory explicitly (default is too low) (MarcoFalke)

### GUI

- - #7154 `00b4b8d` Add InMempool() info to transaction details (jonasschnelli)
- - #7068 `5f3c670` [RPC-Tests] add simple way to run rpc test over QT clients (jonasschnelli)
- - #7218 `a1c185b` Fix misleading translation (MarcoFalke)
- - #7214 `be9a9a3` qt5: Use the fixed font the system recommends (MarcoFalke)
- - #7256 `08ab906` Add note to coin control dialog QT5 workaround (fanquake)
- - #7255 `e289807` Replace some instances of formatWithUnit with formatHtmlWithUnit (fanquake)
- - #7317 `3b57e9c` Fix RPCTimerInterface ordering issue (jonasschnelli)
- - #7327 `c079d79` Transaction View: LastMonth calculation fixed (crowning-)
- - #7334 `e1060c5` coincontrol workaround is still needed in qt5.4 (fixed in qt5.5) (MarcoFalke)
- - #7383 `ae2db67` Rename "amount" to "requested amount" in receive coins table (jonasschnelli)
- - #7396 `cdcbc59` Add option to increase/decrease font size in the console window (jonasschnelli)
- - #7437 `9645218` Disable tab navigation for peers tables (Kefkius)
- - #7604 `354b03d` build: Remove spurious dollar sign. Fixes #7189 (dooglus)
- - #7605 `7f001bd` Remove openssl info from init/log and from Qt debug window (jonasschnelli)
- - #7628 `87d6562` Add 'copy full transaction details' option (ericshawlinux)
- - #7613 `3798e5d` Add autocomplete to bitcoin-qt's console window (GamerSg)
- - #7668 `b24266c` Fix history deletion bug after font size change (achow101)
- - #7680 `41d2dfa` Remove reflection from `about` icon (laanwj)
- - #7686 `f034bce` Remove 0-fee from send dialog (MarcoFalke)
- - #7506 `b88e0b0` Use CCoinControl selection in CWallet::FundTransaction (promag)
- - #7732 `0b98dd7` Debug window: replace "Build date" with "Datadir" (jonasschnelli)
- - #7761 `60db51d` remove trailing output-index from transaction-id (jonasschnelli)
- - #7772 `6383268` Clear the input line after activating autocomplete (paveljanik)
- - #7925 `f604bf6` Fix out-of-tree GUI builds (laanwj)
- - #7939 `574ddc6` Make it possible to show details for multiple transactions (laanwj)
- - #8012 `b33824b` Delay user confirmation of send (Tyler-Hardin)
- - #8006 `7c8558d` Add option to disable the system tray icon (Tyler-Hardin)
- - #8046 `169d379` Fix Cmd-Q / Menu Quit shutdown on OSX (jonasschnelli)
- - #8042 `6929711` Don't allow to open the debug window during splashscreen & verification state (jonasschnelli)
- - #8014 `77b49ac` Sort transactions by date (Tyler-Hardin)
- - #8073 `eb2f6f7` askpassphrasedialog: Clear pass fields on accept (rat4)
- - #8129 `ee1533e` Fix RPC console auto completer (UdjinM6)
- - #7636 `fb0ac48` Add bitcoin address label to request payment QR code (makevoid)
- - #8231 `760a6c7` Fix a bug where the SplashScreen will not be hidden during startup (jonasschnelli)
- - #8256 `af2421c` BUG: bitcoin-qt crash (fsb4000)
- - #8257 `ff03c50` Do not ask a UI question from bitcoind (sipa)
- - #8288 `91abb77` Network-specific example address (laanwj)
- - #7707 `a914968` UI support for abandoned transactions (jonasschnelli)
- - #8207 `f7a403b` Add a link to the Bitcoin-Core repository and website to the About Dialog (MarcoFalke)
- - #8281 `6a87eb0` Remove client name from debug window (laanwj)
- - #8407 `45eba4b` Add dbcache migration path (jonasschnelli)

### Wallet

- - #7262 `fc08994` Reduce inefficiency of GetAccountAddress() (dooglus)
- - #7537 `78e81b0` Warn on unexpected EOF while salvaging wallet (laanwj)
- - #7521 `3368895` Don't resend wallet txs that aren't in our own mempool (morcos)
- - #7576 `86a1ec5` Move wallet help string creation to CWallet (jonasschnelli)
- - #7577 `5b3b5a7` Move "load wallet phase" to CWallet (jonasschnelli)
- - #7608 `0735c0c` Move hardcoded file name out of log messages (MarcoFalke)
- - #7649 `4900641` Prevent multiple calls to CWallet::AvailableCoins (promag)
- - #7646 `e5c3511` Fix lockunspent help message (promag)
- - #7558 `b35a591` Add import/removeprunedfunds rpc call (instagibbs)
- - #6215 `48c5adf` add bip32 pub key serialization (jonasschnelli)
- - #7913 `bafd075` Fix for incorrect locking in GetPubKey() (keystore.cpp) (yurizhykin)
- - #8036 `41138f9` init: Move berkeleydb version reporting to wallet (laanwj)
- - #8028 `373b50d` Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk (pstratem)
- - #8061 `f6b7df3` Improve Wallet encapsulation (pstratem)
- - #7891 `950be19` Always require OS randomness when generating secret keys (sipa)
- - #7689 `b89ef13` Replace OpenSSL AES with ctaes-based version (sipa)
- - #7825 `f972b04` Prevent multiple calls to ExtractDestination (pedrobranco)
- - #8137 `243ac0c` Improve CWallet API with new AccountMove function (pstratem)
- - #8142 `52c3f34` Improve CWallet API  with new GetAccountPubkey function (pstratem)
- - #8035 `b67a472` Add simplest BIP32/deterministic key generation implementation (jonasschnelli)
- - #7687 `a6ddb19` Stop treating importaddress'ed scripts as change (sipa)
- - #8298 `aef3811` wallet: Revert input selection post-pruning (laanwj)
- - #8324 `bc94b87` Keep HD seed during salvagewallet (jonasschnelli)
- - #8323 `238300b` Add HD keypath to CKeyMetadata, report metadata in validateaddress (jonasschnelli)
- - #8367 `3b38a6a` Ensure <0.13 clients can't open HD wallets (jonasschnelli)
- - #8378 `ebea651` Move SetMinVersion for FEATURE_HD to SetHDMasterKey (pstratem)
- - #8390 `73adfe3` Correct hdmasterkeyid/masterkeyid name confusion (jonasschnelli)
- - #8206 `18b8ee1` Add HD xpriv to dumpwallet (jonasschnelli)
- - #8389 `c3c82c4` Create a new HD seed after encrypting the wallet (jonasschnelli)

### Tests and QA

- - #7320 `d3dfc6d` Test walletpassphrase timeout (MarcoFalke)
- - #7208 `47c5ed1` Make max tip age an option instead of chainparam (laanwj)
- - #7372 `21376af` Trivial: [qa] wallet: Print maintenance (MarcoFalke)
- - #7280 `668906f` [travis] Fail when documentation is outdated (MarcoFalke)
- - #7177 `93b0576` [qa] Change default block priority size to 0 (MarcoFalke)
- - #7236 `02676c5` Use createrawtx locktime parm in txn_clone (dgenr8)
- - #7212 `326ffed` Adds unittests for CAddrMan and CAddrinfo, removes source of non-determinism (EthanHeilman)
- - #7490 `d007511` tests: Remove May15 test (laanwj)
- - #7531 `18cb2d5` Add bip68-sequence.py to extended rpc tests (btcdrak)
- - #7536 `ce5fc02` test: test leading spaces for ParseHex (laanwj)
- - #7620 `1b68de3` [travis] Only run check-doc.py once (MarcoFalke)
- - #7455 `7f96671` [travis] Exit early when check-doc.py fails (MarcoFalke)
- - #7667 `56d2c4e` Move GetTempPath() to testutil (musalbas)
- - #7517 `f1ca891` test: script_error checking in script_invalid tests (laanwj)
- - #7684 `3d0dfdb` Extend tests (MarcoFalke)
- - #7697 `622fe6c` Tests: make prioritise_transaction.py more robust (sdaftuar)
- - #7709 `efde86b` Tests: fix missing import in mempool_packages (sdaftuar)
- - #7702 `29e1131` Add tests verifychain, lockunspent, getbalance, listsinceblock (MarcoFalke)
- - #7720 `3b4324b` rpc-test: Normalize assert() (MarcoFalke)
- - #7757 `26794d4` wallet: Wait for reindex to catch up (MarcoFalke)
- - #7764 `a65b36c` Don't run pruning.py twice (MarcoFalke)
- - #7773 `7c80e72` Fix comments in tests (btcdrak)
- - #7489 `e9723cb` tests: Make proxy_test work on travis servers without IPv6 (laanwj)
- - #7801 `70ac71b` Remove misleading "errorString syntax" (MarcoFalke)
- - #7803 `401c65c` maxblocksinflight: Actually enable test (MarcoFalke)
- - #7802 `3bc71e1` httpbasics: Actually test second connection (MarcoFalke)
- - #7849 `ab8586e` tests: add varints_bitpatterns test (laanwj)
- - #7846 `491171f` Clean up lockorder data of destroyed mutexes (sipa)
- - #7853 `6ef5e00` py2: Unfiddle strings into bytes explicitly (MarcoFalke)
- - #7878 `53adc83` [test] bctest.py: Revert faa41ee (MarcoFalke)
- - #7798 `cabba24` [travis] Print the commit which was evaluated (MarcoFalke)
- - #7833 `b1bf511` tests: Check Content-Type header returned from RPC server (laanwj)
- - #7851 `fa9d86f` pull-tester: Don't mute zmq ImportError (MarcoFalke)
- - #7822 `0e6fd5e` Add listunspent() test for spendable/unspendable UTXO (jpdffonseca)
- - #7912 `59ad568` Tests: Fix deserialization of reject messages (sdaftuar)
- - #7941 `0ea3941` Fixing comment in script_test.json test case (Christewart)
- - #7807 `0ad1041` Fixed miner test values, gave constants for less error-prone values (instagibbs)
- - #7980 `88b77c7` Smartfees: Properly use ordered dict (MarcoFalke)
- - #7814 `77b637f` Switch to py3 (MarcoFalke)
- - #8030 `409a8a1` Revert fatal-ness of missing python-zmq (laanwj)
- - #8018 `3e90fe6` Autofind rpc tests --srcdir (jonasschnelli)
- - #8016 `5767e80` Fix multithread CScheduler and reenable test (paveljanik)
- - #7972 `423ca30` pull-tester: Run rpc test in parallel  (MarcoFalke)
- - #8039 `69b3a6d` Bench: Add crypto hash benchmarks (laanwj)
- - #8041 `5b736dd` Fix bip9-softforks blockstore issue (MarcoFalke)
- - #7994 `1f01443` Add op csv tests to script_tests.json (Christewart)
- - #8038 `e2bf830` Various minor fixes (MarcoFalke)
- - #8072 `1b87e5b` Travis: 'make check' in parallel and verbose (MarcoFalke)
- - #8056 `8844ef1` Remove hardcoded "4 nodes" from test_framework (MarcoFalke)
- - #8047 `37f9a1f` Test_framework: Set wait-timeout for bitcoind procs (MarcoFalke)
- - #8095 `6700cc9` Test framework: only cleanup on successful test runs (sdaftuar)
- - #8098 `06bd4f6` Test_framework: Append portseed to tmpdir (MarcoFalke)
- - #8104 `6ff2c8d` Add timeout to sync_blocks() and sync_mempools() (sdaftuar)
- - #8111 `61b8684` Benchmark SipHash (sipa)
- - #8107 `52b803e` Bench: Added base58 encoding/decoding benchmarks (yurizhykin)
- - #8115 `0026e0e` Avoid integer division in the benchmark inner-most loop (gmaxwell)
- - #8090 `a2df115` Adding P2SH(p2pkh) script test case (Christewart)
- - #7992 `ec45cc5` Extend #7956 with one more test (TheBlueMatt)
- - #8139 `ae5575b` Fix interrupted HTTP RPC connection workaround for Python 3.5+ (sipa)
- - #8164 `0f24eaf` [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue (jonasschnelli)
- - #8166 `0b5279f` Src/test: Do not shadow local variables (paveljanik)
- - #8141 `44c1b1c` Continuing port of java comparison tool (mrbandrews)
- - #8201 `36b7400` fundrawtransaction: Fix race, assert amounts (MarcoFalke)
- - #8214 `ed2cd59` Mininode: fail on send_message instead of silent return (MarcoFalke)
- - #8215 `a072d1a` Don't use floating point in wallet tests (MarcoFalke)
- - #8066 `65c2058` Test_framework: Use different rpc_auth_pair for each node (MarcoFalke)
- - #8216 `0d41d70` Assert 'changePosition out of bounds'  (MarcoFalke)
- - #8222 `961893f` Enable mempool consistency checks in unit tests (sipa)
- - #7751 `84370d5` test_framework: python3.4 authproxy compat (laanwj)
- - #7744 `d8e862a` test_framework: detect failure of bitcoind startup (laanwj)
- - #8280 `115735d` Increase sync_blocks() timeouts in pruning.py (MarcoFalke)
- - #8340 `af9b7a9` Solve trivial merge conflict in p2p-segwit.py (MarcoFalke)
- - #8067 `3e4cf8f` Travis: use slim generic image, and some fixups (theuni)
- - #7951 `5c7df70` Test_framework: Properly print exception (MarcoFalke)
- - #8070 `7771aa5` Remove non-determinism which is breaking net_tests #8069 (EthanHeilman)
- - #8309 `bb2646a` Add wallet-hd test (MarcoFalke)
- - #8444 `cd0910b` Fix p2p-feefilter.py for changed tx relay behavior (sdaftuar)

### Mining

- - #7507 `11c7699` Remove internal miner (Leviathn)
- - #7663 `c87f51e` Make the generate RPC call function for non-regtest (sipa)
- - #7671 `e2ebd25` Add generatetoaddress RPC to mine to an address (achow101)
- - #7935 `66ed450` Versionbits: GBT support (luke-jr)
- - #7600 `66db2d6` Select transactions using feerate-with-ancestors (sdaftuar)
- - #8295 `f5660d3` Mining-related fixups for 0.13.0 (sdaftuar)
- - #7796 `536b75e` Add support for negative fee rates, fixes `prioritizetransaction` (MarcoFalke)
- - #8362 `86edc20` Scale legacy sigop count in CreateNewBlock (sdaftuar)
- - #8489 `8b0eee6` Bugfix: Use pre-BIP141 sigops until segwit activates (GBT) (luke-jr)

### Documentation and miscellaneous

- - #7423 `69e2a40` Add example for building with constrained resources (jarret)
- - #8254 `c2c69ed` Add OSX ZMQ requirement to QA readme (fanquake)
- - #8203 `377d131` Clarify documentation for running a tor node (nathaniel-mahieu)
- - #7428 `4b12266` Add example for listing ./configure flags (nathaniel-mahieu)
- - #7847 `3eae681` Add arch linux build example (mruddy)
- - #7968 `ff69aaf` Fedora build requirements (wtogami)
- - #8013 `fbedc09` Fedora build requirements, add gcc-c++ and fix typo (wtogami)
- - #8009 `fbd8478` Fixed invalid example paths in gitian-building.md (JeremyRand)
- - #8240 `63fbdbc` Mention Windows XP end of support in release notes (laanwj)
- - #8303 `5077d2c` Update bips.md for CSV softfork (fanquake)
- - #7789 `e0b3e19` Add note about using the Qt official binary installer (paveljanik)
- - #7791 `e30a5b0` Change Precise to Trusty in gitian-building.md (JeremyRand)
- - #7838 `8bb5d3d` Update gitian build guide to debian 8.4.0 (fanquake)
- - #7855 `b778e59` Replace precise with trusty (MarcoFalke)
- - #7975 `fc23fee` Update bitcoin-core GitHub links (MarcoFalke)
- - #8034 `e3a8207` Add basic git squash workflow (fanquake)
- - #7813 `214ec0b` Update port in tor.md (MarcoFalke)
- - #8193 `37c9830` Use Debian 8.5 in the gitian-build guide (fanquake)
- - #8261 `3685e0c` Clarify help for `getblockchaininfo` (paveljanik)
- - #7185 `ea0f5a2` Note that reviewers should mention the id of the commits they reviewed (pstratem)
- - #7290 `c851d8d` [init] Add missing help for args (MarcoFalke)
- - #7281 `f9fd4c2` Improve CheckInputs() comment about sig verification (petertodd)
- - #7417 `1e06bab` Minor improvements to the release process (PRabahy)
- - #7444 `4cdbd42` Improve block validity/ConnectBlock() comments (petertodd)
- - #7527 `db2e1c0` Fix and cleanup listreceivedbyX documentation (instagibbs)
- - #7541 `b6e00af` Clarify description of blockindex (pinheadmz)
- - #7590 `f06af57` Improving wording related to Boost library requirements [updated] (jonathancross)
- - #7635 `0fa88ef` Add dependency info to test docs (elliotolds)
- - #7609 `3ba07bd` RPM spec file project (AliceWonderMiscreations)
- - #7850 `229a17c` Removed call to `TryCreateDirectory` from `GetDefaultDataDir` in `src/util.cpp` (alexreg)
- - #7888 `ec870e1` Prevector: fix 2 bugs in currently unreached code paths (kazcw)
- - #7922 `90653bc` CBase58Data::SetString: cleanse the full vector (kazcw)
- - #7881 `c4e8390` Update release process (laanwj)
- - #7952 `a9c8b74` Log invalid block hash to make debugging easier (paveljanik)
- - #7974 `8206835` More comments on the design of AttemptToEvictConnection (gmaxwell)
- - #7795 `47a7cfb` UpdateTip: log only one line at most per block (laanwj)
- - #8110 `e7e25ea` Add benchmarking notes (fanquake)
- - #8121 `58f0c92` Update implemented BIPs list (fanquake)
- - #8029 `58725ba` Simplify OS X build notes (fanquake)
- - #8143 `d46b8b5` comment nit: miners don't vote (instagibbs)
- - #8136 `22e0b35` Log/report in 10% steps during VerifyDB (jonasschnelli)
- - #8168 `d366185` util: Add ParseUInt32 and ParseUInt64 (laanwj)
- - #8178 `f7b1bfc` Add git and github tips and tricks to developer notes (sipa)
- - #8177 `67db011` developer notes: updates for C++11 (kazcw)
- - #8229 `8ccdac1` [Doc] Update OS X build notes for 10.11 SDK (fanquake)
- - #8233 `9f1807a` Mention Linux ARM executables in release process and notes (laanwj)
- - #7540 `ff46dd4` Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY (btcdrak)
- - #8289 `26316ff` bash-completion: Adapt for 0.12 and 0.13 (roques)
- - #7453 `3dc3149` Missing patches from 0.12 (MarcoFalke)
- - #7113 `54a550b` Switch to a more efficient rolling Bloom filter (sipa)
- - #7257 `de9e5ea` Combine common error strings for different options so translations can be shared and reused (luke-jr)
- - #7304 `b8f485c` [contrib] Add clang-format-diff.py (MarcoFalke)
- - #7378 `e6f97ef` devtools: replace github-merge with python version (laanwj)
- - #7395 `0893705` devtools: show pull and commit information in github-merge (laanwj)
- - #7402 `6a5932b` devtools: github-merge get toplevel dir without extra whitespace (achow101)
- - #7425 `20a408c` devtools: Fix utf-8 support in messages for github-merge (laanwj)
- - #7632 `409f843` Delete outdated test-patches reference (Lewuathe)
- - #7662 `386f438` remove unused NOBLKS_VERSION_{START,END} constants (rat4)
- - #7737 `aa0d2b2` devtools: make github-merge.py use py3 (laanwj)
- - #7781 `55db5f0` devtools: Auto-set branch to merge to in github-merge (laanwj)
- - #7934 `f17032f` Improve rolling bloom filter performance and benchmark (sipa)
- - #8004 `2efe38b` signal handling: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t (catilac)
- - #7713 `f6598df` Fixes for verify-commits script (petertodd)
- - #8412 `8360d5b` libconsensus: Expose a flag for BIP112 (jtimon)

Credits
=======

Thanks to everyone who directly contributed to this release:

- - 21E14
- - accraze
- - Adam Brown
- - Alexander Regueiro
- - Alex Morcos
- - Alfie John
- - Alice Wonder
- - AlSzacrel
- - Andrew Chow
- - Andr?s G. Aragoneses
- - Bob McElrath
- - BtcDrak
- - calebogden
- - C?dric F?lizard
- - Chirag Dav?
- - Chris Moore
- - Chris Stewart
- - Christian von Roques
- - Chris Wheeler
- - Cory Fields
- - crowning-
- - Daniel Cousens
- - Daniel Kraft
- - Denis Lukianov
- - Elias Rohrer
- - Elliot Olds
- - Eric Shaw
- - error10
- - Ethan Heilman
- - face
- - fanquake
- - Francesco 'makevoid' Canessa
- - fsb4000
- - Gavin Andresen
- - gladoscc
- - Gregory Maxwell
- - Gregory Sanders
- - instagibbs
- - James O'Beirne
- - Jannes Faber
- - Jarret Dyrbye
- - Jeremy Rand
- - jloughry
- - jmacwhyte
- - Joao Fonseca
- - Johnson Lau
- - Jonas Nick
- - Jonas Schnelli
- - Jonathan Cross
- - Jo?o Barbosa
- - Jorge Tim?n
- - Kaz Wesley
- - Kefkius
- - kirkalx
- - Krzysztof Jurewicz
- - Leviathn
- - lewuathe
- - Luke Dashjr
- - Luv Khemani
- - Marcel Kr?ger
- - Marco Falke
- - Mark Friedenbach
- - Matt
- - Matt Bogosian
- - Matt Corallo
- - Matthew English
- - Matthew Zipkin
- - mb300sd
- - Mitchell Cash
- - mrbandrews
- - mruddy
- - Murch
- - Mustafa
- - Nathaniel Mahieu
- - Nicolas Dorier
- - Patrick Strateman
- - Paul Rabahy
- - paveljanik
- - Pavel Jan?k
- - Pavel Vasin
- - Pedro Branco
- - Peter Todd
- - Philip Kaufmann
- - Pieter Wuille
- - Prayag Verma
- - ptschip
- - Puru
- - randy-waterhouse
- - R E Broadley
- - Rusty Russell
- - Suhas Daftuar
- - Suriyaa Kudo
- - TheLazieR Yip
- - Thomas Kerin
- - Tom Harding
- - Tyler Hardin
- - UdjinM6
- - Warren Togami
- - Will Binns
- - Wladimir J. van der Laan
- - Yuri Zhykin

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

Hashes for verification
========================

These are the SHA-256 hashes of the released files:

    f94123e37530f9de25988ff93e5568a93aa5146f689e63fb0ec1f962cf0bbfcd  bitcoin-0.13.0-aarch64-linux-gnu.tar.gz
    7c657ec6f6a5dbb93b9394da510d5dff8dd461df8b80a9410f994bc53c876303  bitcoin-0.13.0-arm-linux-gnueabihf.tar.gz
    d6da2801dd9d92183beea16d0f57edcea85fc749cdc2abec543096c8635ad244  bitcoin-0.13.0-i686-pc-linux-gnu.tar.gz
    2f67ac67b935368e06f2f3b83f0173be641eef799e45d0a267efc0b9802ca8d2  bitcoin-0.13.0-osx64.tar.gz
    e7fed095f1fb833d167697c19527d735e43ab2688564887b80b76c3c349f85b0  bitcoin-0.13.0-osx.dmg
    0c7d7049689bb17f4256f1e5ec20777f42acef61814d434b38e6c17091161cda  bitcoin-0.13.0.tar.gz
    213e6626ad1f7a0c7a0ae2216edd9c8f7b9617c84287c17c15290feca0b8f13b  bitcoin-0.13.0-win32-setup.exe
    5c5bd6d31e4f764e33f2f3034e97e34789c3066a62319ae8d6a6011251187f7c  bitcoin-0.13.0-win32.zip
    c94f351fd5266e07d2132d45dd831d87d0e7fdb673d5a0ba48638e2f9f8339fc  bitcoin-0.13.0-win64-setup.exe
    54606c9a4fd32b826ceab4da9335d7a34a380859fa9495bf35a9e9c0dd9b6298  bitcoin-0.13.0-win64.zip
    bcc1e42d61f88621301bbb00512376287f9df4568255f8b98bc10547dced96c8  bitcoin-0.13.0-x86_64-linux-gnu.tar.gz

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

iQEcBAEBCgAGBQJXvGoPAAoJEHSBCwEjRsmm8a4H/j06PHEWZ/NDL+38d//aHLIn
7QTE3ih2aSPsEVtwSnC8cFQVyTAG6ZyJ0T4DvXZ7wizzCqTjtDzDs03GQCBaAHH6
QzqGgdezffFFxYG2/aTcEhf0bW44FMqc9t5ypgn61o1cbrgP9/1edWz4FSj6BGoX
kx4D9pPudST3J1mYEdC77foi7uFCLU2J6m2N02qwCqr/uXxao+2dR+l3nfpeJA8N
1D+D1MdAq55/UEwxankVFeoLdMHSb5AXZZQyvkeimfwxnEDX1k1maoyYyYFx9MJK
MevaNTpRwiAhNtY3m9ucI/LrLETKC3vRvonxoSHBHioz9rZwvBEwNkP0+M/9zGQ=
=wCgV
-----END PGP SIGNATURE-----

From luke at dashjr.org  Tue Aug 23 20:12:11 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Tue, 23 Aug 2016 20:12:11 +0000
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final Status)
	- BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
Message-ID: <201608232012.12588.luke@dashjr.org>

A number of BIPs seem ready for updating to Final Status. If there are no 
objections, I will update these in 2 weeks:

BIP 39: Mnemonic code for generating deterministic keys
- Used by many wallets and hundreds of thousands of users.

BIP 44: Multi-Account Hierarchy for Deterministic Wallets
- Appears to be implemented by multiple wallets.

BIP 67: Deterministic Pay-to-script-hash multi-signature addresses through
        public key sorting
- Implementations in multiple wallet software exist.

BIP 125: Opt-in Full Replace-by-Fee Signaling
- Implemented in Bitcoin Core and derivatives; appears to be in regular use on 
the network.

BIP 130: sendheaders message
- Implemented in Bitcoin Core and derivatives.

Also, BIP 43 (Purpose Field for Deterministic Wallets) is an informational BIP 
which appears to be guiding to some extent the creation of new BIPs; therefore 
I propose its Status be upgraded to Active. I will make this update in 2 weeks 
also, if no objections.

Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in Bitcoin 
Core and derivatives; it is unclear if used by clients yet. Can developers of 
such clients please comment and let me know: 1) if their software supports 
this BIP already; 2) if not, do they intend to support it in the future?
If and only if there are any clients using this service bit already, I will 
update BIP 111 to Final Status in 2 weeks also.

Thanks,

Luke

From ken at keepkey.com  Tue Aug 23 20:54:50 2016
From: ken at keepkey.com (Kenneth Heutmaker)
Date: Tue, 23 Aug 2016 13:54:50 -0700
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
	Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <201608232012.12588.luke@dashjr.org>
References: <201608232012.12588.luke@dashjr.org>
Message-ID: <7FF3E128-4D92-46CC-8FBA-9B9E9A9FC7AD@keepkey.com>

> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in Bitcoin
> Core and derivatives; it is unclear if used by clients yet. Can developers of
> such clients please comment and let me know: 1) if their software supports
> this BIP already; 2) if not, do they intend to support it in the future?
> If and only if there are any clients using this service bit already, I will
> update BIP 111 to Final Status in 2 weeks also.

Multibit is adding detection of the NODE_BLOOM bit in the next 2-3 weeks.

SPV is kinda broken if the wallet doesn?t do this detection. If your wallet connects only to nodes that don?t support bloom filtering, the wallet never gets updates. We have had a spike in users reporting that their wallet isn't getting updated. To compound the problem, they rescan the blockchain and lose all of their transaction history. It has caused much panic among less technical users.

We believe that failing to detect the NODE_BLOOM bit is the culprit, although it is non-deterministic, so we aren't certain.

I imagine that other SPV wallets are having similar issues. BIP 111 really isn?t optional at this point, so it should be marked final.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160823/2e38b60b/attachment.sig>

From pete at petertodd.org  Wed Aug 24 01:46:34 2016
From: pete at petertodd.org (Peter Todd)
Date: Wed, 24 Aug 2016 01:46:34 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
Message-ID: <20160824014634.GA19905@fedora-21-dvm>

Bitcoin-based honeypots incentivise intruders into revealing the fact they have
broken into a server by allowing them to claim a reward based on secret
information obtained during the intrusion. Spending a bitcoin can only be done
by publishing data to a public place - the Bitcoin blockchain - allowing
detection of the intrusion.

The simplest way to achieve this is with one private key per server, with each
server associated with one transaction output spendable by that key. However
this isn't capital efficient if you have multiple servers to protect: if we
have N servers and P bitcoins that we can afford to lose in the compromise, one
key per server gives the intruder only N/P incentive.

Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
single txout protected by a 1-N tree of keys, with each server assigned a
specific key. Unfortunately though, tree signatures aren't yet implemented in
the Bitcoin protocol.

However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can implement
this functionality with the existing Bitcoin protocol using the following
script:

    2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG

The honeypot secret key is shared among all N servers, and left on them. The
distriminator secret key meanwhile is kept secret, however for each server a
unique signature is created with SIGHASH_SINGLE, paying a token amount to a
notification address. For each individual server a pre-signed signature created
with the distriminator secret key is then left on the associated server along
with the honeypot secret key.

Recall the SIGHASH_SINGLE flag means that the signature only signs a single
transaction input and transaction output; the transaction is allowed to have
additional inputs and outputs added. This allows the thief to use the honeypot
key to construct a claim transaction with an additional output added that pays
an address that they own with the rest of the funds.

Equally, we could also use SIGHASH_NONE, with the per-server discriminator
being the K value used in the pre-signed transaction.

Note that Jeff Coleman deserves credit as co-inventor of all the above.


Censorship Resistance
=====================

A potential disadvantage of using non-standard SIGHASH flags is that the
transactions involved are somewhat unusual, and may be flagged by
risk analysis at exchanges and the like, a threat to the fungibility of the
reward.

We can improve on the above concept from Todd/Coleman by using a pre-signed
standard transaction instead. The pre-signed transaction spends the honeypot
txout to two addresses, a per-server canary address, and a change address. The
private key associated with the change addres is also left on the server, and
the intruder can then spend that change output to finally collect their reward.

To any external observer the result looks like two normal transactions created
in the process of someone with a standard wallet sending a small amount of
funds to an address, followed by sending a larger amount.


Doublespending
==============

A subtlety in the the two transactions concept is that the intruder doesn't
have the necessary private keys to modify the first transaction, which means
that the honeypot owner can respond to the compromise by doublespending that
transaction, potentially recovering the honeypot while still learning about the
compromise. While this is possible with all honeypots, if the first transaction
is signed with the opt-in RBF flags, and CPFP-aware transaction replacement is
not implemented by miners, the mechanics are particularly disadvantageous to
the intruder, as the honeypot owner only needs to increase the first
transaction's fee slightly to have a high chance of recovering their funds.
With CPFP-aware transaction replacement the intruder could in-turn respond with
a high-fee CPFP second transaction, but currently no such implementation is
known.


Scorched Earth
==============

We can use the "scorched earth" concept to improve the credibility of the
honeypot reward by making it costly for the honeypot owner to doublespend. Here
a second version of the honeypot pre-signed transaction would also be provided
which sepnds the entirety of the honeypot output to fees, and additionally
spends a second output to fees. An economically rational intruder will publish
the first version, which maximizes the funds they get out of the honeypot. If
the owner tries to dishonestly doublespend, they can respond by publishing the
"scorched earth" transaction, encouraging the honeypot owner's honesty and
making CPFP-aware transaction replacement irrelevant.

Of course, miner centralization adds complexity to the above: in many instances
honeypot owners and/or intruders will be able to recover funds from altruistic
miners. Equally, the additional complexity may discourage intruders from making
use of the honeypot entirely.

Note that as an implementation consideration CHECKSEQUENCEVERIFY can be used to
ensure the honeypot output can only be spent with transaction replacement
enabled, as CSV requires nSequence to be set in specific ways in any transation
spending the output.


References
==========

1) https://blockstream.com/2015/08/24/treesignatures/

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/b348f953/attachment.sig>

From dev at jonasschnelli.ch  Wed Aug 24 06:59:56 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Wed, 24 Aug 2016 08:59:56 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <7FF3E128-4D92-46CC-8FBA-9B9E9A9FC7AD@keepkey.com>
References: <201608232012.12588.luke@dashjr.org>
	<7FF3E128-4D92-46CC-8FBA-9B9E9A9FC7AD@keepkey.com>
Message-ID: <57BD45EC.1090000@jonasschnelli.ch>

>> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in Bitcoin
>> Core and derivatives; it is unclear if used by clients yet. Can developers of
>> such clients please comment and let me know: 1) if their software supports
>> this BIP already; 2) if not, do they intend to support it in the future?
>> If and only if there are any clients using this service bit already, I will
>> update BIP 111 to Final Status in 2 weeks also.
> 
> Multibit is adding detection of the NODE_BLOOM bit in the next 2-3 weeks.
> 
> SPV is kinda broken if the wallet doesn?t do this detection. If your wallet connects only to nodes that don?t support bloom filtering, the wallet never gets updates. We have had a spike in users reporting that their wallet isn't getting updated. To compound the problem, they rescan the blockchain and lose all of their transaction history. It has caused much panic among less technical users.
> 
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although it is non-deterministic, so we aren't certain.
> 
> I imagine that other SPV wallets are having similar issues. BIP 111 really isn?t optional at this point, so it should be marked final.

SPV Wallets should definitively update to respect NODE_BLOOM. Bloom
filtering is CPU and disk intense and some node operators have disabled
it (or will disabled it) because there is no direct p2p network-health
benefit.

SPV wallets should probably also make use of the new DNS seeder filter
option.
It is running at least on seed.bitcoin.sipa.be and
seed.bitcoin.jonasschnelli.ch.

The filter option allows SPV Wallets to only get nodes that signal
support for NODE_BLOOM.

The syntax is

   x<networkservice_flags_filter_as_int>.seed.bitcoin....

Example for NODE_NETWORK together with NODE_BLOOM
dig x5.seed.bitcoin.jonasschnelli.ch
(NETWORK = (1 << 0), NODE_BLOOM = (1 << 2)) = (bin00000101 = (int)5)


</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/c7311f2b/attachment.sig>

From greg at xiph.org  Wed Aug 24 08:34:20 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 24 Aug 2016 08:34:20 +0000
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <7FF3E128-4D92-46CC-8FBA-9B9E9A9FC7AD@keepkey.com>
References: <201608232012.12588.luke@dashjr.org>
	<7FF3E128-4D92-46CC-8FBA-9B9E9A9FC7AD@keepkey.com>
Message-ID: <CAAS2fgSm_5hnP854ygp50FKQnH_5K239b+1E3Zw=ANTU6pe5Sw@mail.gmail.com>

On Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> SPV is kinda broken if the wallet doesn?t do this detection. If your wallet connects only to nodes that don?t support bloom filtering, the wallet never gets updates. We have had a spike in users reporting that their wallet isn't getting updated. To compound the problem, they rescan the blockchain and lose all of their transaction history. It has caused much panic among less technical users.
>
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although it is non-deterministic, so we aren't certain.

There are almost no NODE_BLOOM supporting bloom-off nodes on the
network currently. So, while supporting this is important, I am
doubtful that its the current problem you've suffered.

There are a great many fake nodes which appear to exist purely to
monitor transactions. Many do not implement enough of the protocol to
support scanning or transaction relay. (and, in fact, relaying
transactions would make monitoring less effective).

You can't count on peers on a peer to peer network to be honest and
cooperative. Implementations need to work hard to be robust to abusive
peers. Unfortunately, the design of the bloom filtering is such that
it isn't always easy (or even possible) to be robust.

From thomasv at electrum.org  Wed Aug 24 12:51:32 2016
From: thomasv at electrum.org (Thomas Voegtlin)
Date: Wed, 24 Aug 2016 14:51:32 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <201608232012.12588.luke@dashjr.org>
References: <201608232012.12588.luke@dashjr.org>
Message-ID: <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>

Le 23/08/2016 ? 22:12, Luke Dashjr via bitcoin-dev a ?crit :
> BIP 39: Mnemonic code for generating deterministic keys
> - Used by many wallets and hundreds of thousands of users.
> 
> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
> - Appears to be implemented by multiple wallets.
> 

I personally believe that BIP39/BIP44 is a bad design. There is limited
support for these BIPs in Electrum, in order to provide compatibility
with hardware wallets. However, I do not plan to use BIP39/BIP44 for
default Electrum wallets, for the following reasons.

(Note that it does not make sense to consider BIP39 and BIP44
independently. Any wallet that decides to implement one without the
other would be considered as broken.)

Here is why I rejected this design:

1 - BIP44 uses multiple accounts. This means that in order to be
compatible with the standard, a wallet *must* implement multiple
accounts. A wallet that decides to keep things simple and use only one
account, will not allow users to recover all their funds when they
restore from a BIP39 seed, and will be considered as broken.

2 - An appealing feature of deterministic wallets is that you can use
the same instance of your wallet on different devices. Two instances of
your wallet can automatically synchronize their Bitcoin addresses, and
display the same balance. The problem is that hardened derivations break
this property. Indeed, with hardened derivations, software wallets need
to ask the user's password in order to derive new accounts. Therefore,
in order to implement automated detection of newly created accounts, a
BIP44-compatible software wallets would need to ask the user's password
whenever a new account is detected. This means that the wallet would ask
the password without the user initiating any action. This seems to be an
avenue for malware.

Of course, hardware wallets do not have that issue, because they can
derive new accounts without requesting a password from the user. BIP44
is a standard that has been designed for hardware wallets, but that
makes things really difficult for software wallets.

3 - Unneeded complexity. From an end user perspective, the multiple
accounts in BIP44 achieve the same result as using different derivation
passphrases with the same BIP39 seed phrase. The only real difference is
that BIP44 accounts can be enumerated deterministically, while
passphrases in general cannot. However, this property is of limited
interest, because automatic synchronization of multiple accounts cannot
be guaranteed for bip44 software wallets, as explained in 2.

4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
phrase' in order to derive the BIP32 seed. This hash-based derivation
was added on my suggestion, in order to make the BIP independent from
the particular wordlist used to generate the seed phrases. However,
BIP39 also requires the implementation of a checksum, in order to verify
that a seed phrase is valid. Suprisingly, the specification of the
checksum involves wordlist indices. This means the checksum (and thus
the BIP) requires a fixed wordlist. This defeats the purpose of using a
hash for the derivation of the seed.

The authors of the BIP should either have used hash functions for both
the seed AND the checksum (that is what Electrum does), or for none of
them (in that case case, you can have a bidirectional function between
seed phrases and entropy, which is nice if you want to perform Shamir
secret sharing of seed phrases, at the expenses of a fixed wordlist). In
its current state, BIP39 takes the worst of both worlds.

5 - The fact that the wordlist must be part of BIP39, and cannot be
changed in the future, seems a terrible idea to me. I believe that a
specification should always try to be minimal. In that case, the
specification includes a 2000+ words dictionary, when it could have
avoided that.

Even if you decide that BIP39 is final, there will always be users
requiring the addition of wordlists for new languages. So, in practice,
this BIP will never be final.

6 - Finally, and most importantly, BIP39 seed phrases do not have a
version number. Without a version number, how are you going to derive
addresses from a BIP39 seed phrase, when wallets start to use to new
derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
that a BIP39 compatible wallet will have to check addresses from all the
derivation methods that ever existed in the past, in order to ensure
that all coins are correctly retrieved? Or will there be users that
cannot access their coins because their BIP39 seed phrase is too old for
newer software?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/926591b8/attachment.sig>

From andreas at schildbach.de  Wed Aug 24 13:47:08 2016
From: andreas at schildbach.de (Andreas Schildbach)
Date: Wed, 24 Aug 2016 15:47:08 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
Message-ID: <npk8gr$shs$1@blaine.gmane.org>

FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.

That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on separating BIP43 from BIP44 is that someone else can come up
with a better "BIP44+" standard and not get into the way of existing
standards. I think BIP43 should be made final as well, if it isn't already.


On 08/24/2016 02:51 PM, Thomas Voegtlin via bitcoin-dev wrote:
> Le 23/08/2016 ? 22:12, Luke Dashjr via bitcoin-dev a ?crit :
>> BIP 39: Mnemonic code for generating deterministic keys
>> - Used by many wallets and hundreds of thousands of users.
>>
>> BIP 44: Multi-Account Hierarchy for Deterministic Wallets
>> - Appears to be implemented by multiple wallets.
>>
> 
> I personally believe that BIP39/BIP44 is a bad design. There is limited
> support for these BIPs in Electrum, in order to provide compatibility
> with hardware wallets. However, I do not plan to use BIP39/BIP44 for
> default Electrum wallets, for the following reasons.
> 
> (Note that it does not make sense to consider BIP39 and BIP44
> independently. Any wallet that decides to implement one without the
> other would be considered as broken.)
> 
> Here is why I rejected this design:
> 
> 1 - BIP44 uses multiple accounts. This means that in order to be
> compatible with the standard, a wallet *must* implement multiple
> accounts. A wallet that decides to keep things simple and use only one
> account, will not allow users to recover all their funds when they
> restore from a BIP39 seed, and will be considered as broken.
> 
> 2 - An appealing feature of deterministic wallets is that you can use
> the same instance of your wallet on different devices. Two instances of
> your wallet can automatically synchronize their Bitcoin addresses, and
> display the same balance. The problem is that hardened derivations break
> this property. Indeed, with hardened derivations, software wallets need
> to ask the user's password in order to derive new accounts. Therefore,
> in order to implement automated detection of newly created accounts, a
> BIP44-compatible software wallets would need to ask the user's password
> whenever a new account is detected. This means that the wallet would ask
> the password without the user initiating any action. This seems to be an
> avenue for malware.
> 
> Of course, hardware wallets do not have that issue, because they can
> derive new accounts without requesting a password from the user. BIP44
> is a standard that has been designed for hardware wallets, but that
> makes things really difficult for software wallets.
> 
> 3 - Unneeded complexity. From an end user perspective, the multiple
> accounts in BIP44 achieve the same result as using different derivation
> passphrases with the same BIP39 seed phrase. The only real difference is
> that BIP44 accounts can be enumerated deterministically, while
> passphrases in general cannot. However, this property is of limited
> interest, because automatic synchronization of multiple accounts cannot
> be guaranteed for bip44 software wallets, as explained in 2.
> 
> 4 - BIP39 is inconsistent. It uses a hash of the utf8 encoded 'seed
> phrase' in order to derive the BIP32 seed. This hash-based derivation
> was added on my suggestion, in order to make the BIP independent from
> the particular wordlist used to generate the seed phrases. However,
> BIP39 also requires the implementation of a checksum, in order to verify
> that a seed phrase is valid. Suprisingly, the specification of the
> checksum involves wordlist indices. This means the checksum (and thus
> the BIP) requires a fixed wordlist. This defeats the purpose of using a
> hash for the derivation of the seed.
> 
> The authors of the BIP should either have used hash functions for both
> the seed AND the checksum (that is what Electrum does), or for none of
> them (in that case case, you can have a bidirectional function between
> seed phrases and entropy, which is nice if you want to perform Shamir
> secret sharing of seed phrases, at the expenses of a fixed wordlist). In
> its current state, BIP39 takes the worst of both worlds.
> 
> 5 - The fact that the wordlist must be part of BIP39, and cannot be
> changed in the future, seems a terrible idea to me. I believe that a
> specification should always try to be minimal. In that case, the
> specification includes a 2000+ words dictionary, when it could have
> avoided that.
> 
> Even if you decide that BIP39 is final, there will always be users
> requiring the addition of wordlists for new languages. So, in practice,
> this BIP will never be final.
> 
> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that a BIP39 compatible wallet will have to check addresses from all the
> derivation methods that ever existed in the past, in order to ensure
> that all coins are correctly retrieved? Or will there be users that
> cannot access their coins because their BIP39 seed phrase is too old for
> newer software?
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



From dev at jonasschnelli.ch  Wed Aug 24 14:18:26 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Wed, 24 Aug 2016 16:18:26 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
Message-ID: <57BDACB2.9040307@jonasschnelli.ch>

Hi

> 6 - Finally, and most importantly, BIP39 seed phrases do not have a
> version number. Without a version number, how are you going to derive
> addresses from a BIP39 seed phrase, when wallets start to use to new
> derivation methods (such as SegWit, or Schnorr signatures)? Does it mean
> that a BIP39 compatible wallet will have to check addresses from all the
> derivation methods that ever existed in the past, in order to ensure
> that all coins are correctly retrieved? Or will there be users that
> cannot access their coins because their BIP39 seed phrase is too old for
> newer software?

I totally agree with Thomas.

Another thing that I think could be a BIP misdesign:

BIP44 Gap Limits
From the BIP:

----------
  "Address gap limit is currently set to 20. If the software hits 20
unused addresses in a row, it expects there are no used addresses beyond
this point and stops searching the address chain."
----------

* Does that mean, we do a transaction rescan back to the genesis block
for every 20 addresses?
* Or is it a prerequirement to do a wallet recovery after BIP44's to
have access to a full address-indexed blockchain?

Or maybe I'm missing something.

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/c679a7ea/attachment.sig>

From hoenicke at gmail.com  Wed Aug 24 14:42:25 2016
From: hoenicke at gmail.com (Jochen Hoenicke)
Date: Wed, 24 Aug 2016 16:42:25 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <57BDACB2.9040307@jonasschnelli.ch>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
Message-ID: <278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>

On 24.08.2016 16:18, Jonas Schnelli via bitcoin-dev wrote:
> 
> Another thing that I think could be a BIP misdesign:
> 
> BIP44 Gap Limits
> From the BIP:
> 
> ----------
>   "Address gap limit is currently set to 20. If the software hits 20
> unused addresses in a row, it expects there are no used addresses beyond
> this point and stops searching the address chain."
> ----------
> 
> * Does that mean, we do a transaction rescan back to the genesis block
> for every 20 addresses?

As I understand it, you can scan sequentially starting with the genesis
block (or with a block at around the time when BIP44 was written).  Then
if you find a new transaction, which requires to generate new addresses,
you generate them and scan further from that point on.  This way you can
scan in a single pass if the scanning process calls you back when it
finds a transaction and allows you to change the set of addresses on the
fly.

  Jochen


From me at thomaskerin.io  Wed Aug 24 10:31:20 2016
From: me at thomaskerin.io (Thomas Kerin)
Date: Wed, 24 Aug 2016 12:31:20 +0200
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <CALGb225DLv22ktt_7HJTcuPphJ=TMEU_b3LApBJy17KgAZwSzQ@mail.gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>
	<9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io>
	<57B4113E.4010502@jonasschnelli.ch>
	<D41B40FA-0C75-496D-937A-0DF733FB87E2@bitlox.com>
	<57B44BCB.3010400@jonasschnelli.ch>
	<CAJna-HhQred_E7PYRFmgzb_0gd2b+4qsFOWEGqBjfzX1PbhyxQ@mail.gmail.com>
	<57B55B8C.1070001@jonasschnelli.ch>
	<CAJna-Hi3a5mLBkXfS4Qa=kjFCj4=GVBr4WUDZ=Tg27iX=FiCJA@mail.gmail.com>
	<57B58149.8000200@jonasschnelli.ch>
	<CAJna-Hj8HQy9Dhx3Gx8CpmpgoiQZ2waaj9o5b6hHwda4Dm_fGw@mail.gmail.com>
	<57B584BF.7000004@jonasschnelli.ch>
	<CALGb225DLv22ktt_7HJTcuPphJ=TMEU_b3LApBJy17KgAZwSzQ@mail.gmail.com>
Message-ID: <86fb234e-54b1-d7ec-cd8f-97f8840658e6@thomaskerin.io>

I want to pitch a use-case that might have been ignored in this discussion:

I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also find this valuable.

I hope we can move forward with a protocol that suits both the hardware
people, and the people who find signing transactions in browsers
unsettling.

Maybe we the focus should move away from only servicing hardware, and
asking if the motivation is better captured by "allow users pick their
own ECDSA implementation, hardware or software", then working out what
we need to get us there.


On 08/18/2016 12:23 PM, Nicolas Bacca via bitcoin-dev wrote:
> On Thu, Aug 18, 2016 at 11:49 AM, Jonas Schnelli via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>     Hi
>
>     > I have some experience with hardware wallet development and its
>     > integration and I know it's a mess. But it is too early to
>     define such
>     > rigid standards yet. Also, TREZOR concept (device as a server
>     and the
>     > primary source of workflow management) goes directly against your
>     > proposal of wallet software as an workflow manager. So it is
>     clear NACK
>     > for me.
>
>     The current question ? as already mentioned ? is we ACK to work
>     together
>     on a signing protocol or if we NACK this before we even have started.
>
>
> ACK for Ledger. What's necessary to sign a transaction is well known,
> I don't see how driving any hardware wallet from the wallet itself or
> from a third party daemon implementing that URL scheme would make any
> difference, other than providing better devices interoperability, as
> well as easier maintenance and update paths for the wallets.
>
> -- 
> Nicolas Bacca | CTO, Ledger
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/ce0a856d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/ce0a856d/attachment-0001.sig>

From matthew at roberts.pm  Wed Aug 24 15:37:34 2016
From: matthew at roberts.pm (Matthew Roberts)
Date: Thu, 25 Aug 2016 01:37:34 +1000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <20160824014634.GA19905@fedora-21-dvm>
References: <20160824014634.GA19905@fedora-21-dvm>
Message-ID: <CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>

Really nice idea. So its like a smart contract that incentivizes
publication that a server has been hacked? I also really like how the
funding has been handled -- with all the coins stored in the same address
and then each server associated with a unique signature. That way, you
don't have to split up all the coins among every server and reduce the
incentive for an attacker yet you can still identify which server was
hacked.

It would be nice if after the attacker broke into the server that they were
also incentivized to act on the information as soon as possible (revealing
early on when the server was compromised.) I suppose you could split up the
coins into different outputs that could optimally be redeemed by the owner
at different points in the future -- so they're incentivzed to act lest
their reward decays even more (this is of course, assuming that the
monetary reward for this is greater than any possible legal consequences
for the attacker -- it might not be. Thinking about this some more: it
would also be somewhat hard to deny that this -wasn't- a honeypot with such
a complex and unique scheme required for transactions, and I for one
wouldn't like to reveal that I'd hacked a server if I knew it was all a
calculated ploy. Don't honeypots rely on subtly?)

What about also proving to an attacker that by breaking into a server they
would be guaranteed a reward? I know that the use-case for this is proof of
compromise so incentivizing a security audit would kind of fall more into
an active invitation to audit but couldn't you also make a cryptocurrency
that allowed coins to be moved based on a service banner existing at a
given IP address? Attackers could then break into the server, setup a
service that broadcasts their public key hash, and then spend coins locked
at this special contract address to that pub key hash which miners would
check on redemption (putting aside malicious use-cases for now.)


On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
>     2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =====================
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the result looks like two normal transactions
> created
> in the process of someone with a standard wallet sending a small amount of
> funds to an address, followed by sending a larger amount.
>
>
> Doublespending
> ==============
>
> A subtlety in the the two transactions concept is that the intruder doesn't
> have the necessary private keys to modify the first transaction, which
> means
> that the honeypot owner can respond to the compromise by doublespending
> that
> transaction, potentially recovering the honeypot while still learning
> about the
> compromise. While this is possible with all honeypots, if the first
> transaction
> is signed with the opt-in RBF flags, and CPFP-aware transaction
> replacement is
> not implemented by miners, the mechanics are particularly disadvantageous
> to
> the intruder, as the honeypot owner only needs to increase the first
> transaction's fee slightly to have a high chance of recovering their funds.
> With CPFP-aware transaction replacement the intruder could in-turn respond
> with
> a high-fee CPFP second transaction, but currently no such implementation is
> known.
>
>
> Scorched Earth
> ==============
>
> We can use the "scorched earth" concept to improve the credibility of the
> honeypot reward by making it costly for the honeypot owner to doublespend.
> Here
> a second version of the honeypot pre-signed transaction would also be
> provided
> which sepnds the entirety of the honeypot output to fees, and additionally
> spends a second output to fees. An economically rational intruder will
> publish
> the first version, which maximizes the funds they get out of the honeypot.
> If
> the owner tries to dishonestly doublespend, they can respond by publishing
> the
> "scorched earth" transaction, encouraging the honeypot owner's honesty and
> making CPFP-aware transaction replacement irrelevant.
>
> Of course, miner centralization adds complexity to the above: in many
> instances
> honeypot owners and/or intruders will be able to recover funds from
> altruistic
> miners. Equally, the additional complexity may discourage intruders from
> making
> use of the honeypot entirely.
>
> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
> used to
> ensure the honeypot output can only be spent with transaction replacement
> enabled, as CSV requires nSequence to be set in specific ways in any
> transation
> spending the output.
>
>
> References
> ==========
>
> 1) https://blockstream.com/2015/08/24/treesignatures/
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/9d41f9d8/attachment.html>

From jimmyjack at gmail.com  Wed Aug 24 16:29:19 2016
From: jimmyjack at gmail.com (Jimmy)
Date: Wed, 24 Aug 2016 16:29:19 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
Message-ID: <CAE0GdZW-vN-kpUMATjkRQYnKH4n41HGdwQGb-JKZjcjxr6mO9g@mail.gmail.com>

Is this unrelated to Bitcoin Vigil idea published in 2014?

http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/





On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Really nice idea. So its like a smart contract that incentivizes
> publication that a server has been hacked? I also really like how the
> funding has been handled -- with all the coins stored in the same address
> and then each server associated with a unique signature. That way, you
> don't have to split up all the coins among every server and reduce the
> incentive for an attacker yet you can still identify which server was
> hacked.
>
> It would be nice if after the attacker broke into the server that they
> were also incentivized to act on the information as soon as possible
> (revealing early on when the server was compromised.) I suppose you could
> split up the coins into different outputs that could optimally be redeemed
> by the owner at different points in the future -- so they're incentivzed to
> act lest their reward decays even more (this is of course, assuming that
> the monetary reward for this is greater than any possible legal
> consequences for the attacker -- it might not be. Thinking about this some
> more: it would also be somewhat hard to deny that this -wasn't- a honeypot
> with such a complex and unique scheme required for transactions, and I for
> one wouldn't like to reveal that I'd hacked a server if I knew it was all a
> calculated ploy. Don't honeypots rely on subtly?)
>
> What about also proving to an attacker that by breaking into a server they
> would be guaranteed a reward? I know that the use-case for this is proof of
> compromise so incentivizing a security audit would kind of fall more into
> an active invitation to audit but couldn't you also make a cryptocurrency
> that allowed coins to be moved based on a service banner existing at a
> given IP address? Attackers could then break into the server, setup a
> service that broadcasts their public key hash, and then spend coins locked
> at this special contract address to that pub key hash which miners would
> check on redemption (putting aside malicious use-cases for now.)
>
>
> On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Bitcoin-based honeypots incentivise intruders into revealing the fact
>> they have
>> broken into a server by allowing them to claim a reward based on secret
>> information obtained during the intrusion. Spending a bitcoin can only be
>> done
>> by publishing data to a public place - the Bitcoin blockchain - allowing
>> detection of the intrusion.
>>
>> The simplest way to achieve this is with one private key per server, with
>> each
>> server associated with one transaction output spendable by that key.
>> However
>> this isn't capital efficient if you have multiple servers to protect: if
>> we
>> have N servers and P bitcoins that we can afford to lose in the
>> compromise, one
>> key per server gives the intruder only N/P incentive.
>>
>> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
>> single txout protected by a 1-N tree of keys, with each server assigned a
>> specific key. Unfortunately though, tree signatures aren't yet
>> implemented in
>> the Bitcoin protocol.
>>
>> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
>> implement
>> this functionality with the existing Bitcoin protocol using the following
>> script:
>>
>>     2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>>
>> The honeypot secret key is shared among all N servers, and left on them.
>> The
>> distriminator secret key meanwhile is kept secret, however for each
>> server a
>> unique signature is created with SIGHASH_SINGLE, paying a token amount to
>> a
>> notification address. For each individual server a pre-signed signature
>> created
>> with the distriminator secret key is then left on the associated server
>> along
>> with the honeypot secret key.
>>
>> Recall the SIGHASH_SINGLE flag means that the signature only signs a
>> single
>> transaction input and transaction output; the transaction is allowed to
>> have
>> additional inputs and outputs added. This allows the thief to use the
>> honeypot
>> key to construct a claim transaction with an additional output added that
>> pays
>> an address that they own with the rest of the funds.
>>
>> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
>> being the K value used in the pre-signed transaction.
>>
>> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>>
>>
>> Censorship Resistance
>> =====================
>>
>> A potential disadvantage of using non-standard SIGHASH flags is that the
>> transactions involved are somewhat unusual, and may be flagged by
>> risk analysis at exchanges and the like, a threat to the fungibility of
>> the
>> reward.
>>
>> We can improve on the above concept from Todd/Coleman by using a
>> pre-signed
>> standard transaction instead. The pre-signed transaction spends the
>> honeypot
>> txout to two addresses, a per-server canary address, and a change
>> address. The
>> private key associated with the change addres is also left on the server,
>> and
>> the intruder can then spend that change output to finally collect their
>> reward.
>>
>> To any external observer the result looks like two normal transactions
>> created
>> in the process of someone with a standard wallet sending a small amount of
>> funds to an address, followed by sending a larger amount.
>>
>>
>> Doublespending
>> ==============
>>
>> A subtlety in the the two transactions concept is that the intruder
>> doesn't
>> have the necessary private keys to modify the first transaction, which
>> means
>> that the honeypot owner can respond to the compromise by doublespending
>> that
>> transaction, potentially recovering the honeypot while still learning
>> about the
>> compromise. While this is possible with all honeypots, if the first
>> transaction
>> is signed with the opt-in RBF flags, and CPFP-aware transaction
>> replacement is
>> not implemented by miners, the mechanics are particularly disadvantageous
>> to
>> the intruder, as the honeypot owner only needs to increase the first
>> transaction's fee slightly to have a high chance of recovering their
>> funds.
>> With CPFP-aware transaction replacement the intruder could in-turn
>> respond with
>> a high-fee CPFP second transaction, but currently no such implementation
>> is
>> known.
>>
>>
>> Scorched Earth
>> ==============
>>
>> We can use the "scorched earth" concept to improve the credibility of the
>> honeypot reward by making it costly for the honeypot owner to
>> doublespend. Here
>> a second version of the honeypot pre-signed transaction would also be
>> provided
>> which sepnds the entirety of the honeypot output to fees, and additionally
>> spends a second output to fees. An economically rational intruder will
>> publish
>> the first version, which maximizes the funds they get out of the
>> honeypot. If
>> the owner tries to dishonestly doublespend, they can respond by
>> publishing the
>> "scorched earth" transaction, encouraging the honeypot owner's honesty and
>> making CPFP-aware transaction replacement irrelevant.
>>
>> Of course, miner centralization adds complexity to the above: in many
>> instances
>> honeypot owners and/or intruders will be able to recover funds from
>> altruistic
>> miners. Equally, the additional complexity may discourage intruders from
>> making
>> use of the honeypot entirely.
>>
>> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
>> used to
>> ensure the honeypot output can only be spent with transaction replacement
>> enabled, as CSV requires nSequence to be set in specific ways in any
>> transation
>> spending the output.
>>
>>
>> References
>> ==========
>>
>> 1) https://blockstream.com/2015/08/24/treesignatures/
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/03bc35b5/attachment-0001.html>

From luke at dashjr.org  Wed Aug 24 18:22:39 2016
From: luke at dashjr.org (Luke Dashjr)
Date: Wed, 24 Aug 2016 18:22:39 +0000
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
	Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <npk8gr$shs$1@blaine.gmane.org>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<npk8gr$shs$1@blaine.gmane.org>
Message-ID: <201608241822.40882.luke@dashjr.org>

On Wednesday, August 24, 2016 1:47:08 PM Andreas Schildbach via bitcoin-dev 
wrote:
> FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
> wallets do not need to scan from the beginning of the blockchain.
> 
> That doesn't mean BIP44 could not be final. There are some wallets that
> interoperate on that standard and that's fine.

Right. The Status doesn't depend on whether it is a good idea or not, only 
whether or not people are de facto using it.

BIP 2's BIP Comments would have provided a place for Thomas and yourself to 
criticise the BIP, but unfortunately this was too controversial.

> I think BIP43 should be made final as well, if it isn't already.

BIP 43 merely advises other BIPs how they might do things, so it goes into the 
Draft->Active Status flow rather than Draft->Accepted->Final.

Luke

From pete at petertodd.org  Wed Aug 24 19:18:48 2016
From: pete at petertodd.org (Peter Todd)
Date: Wed, 24 Aug 2016 19:18:48 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAE0GdZW-vN-kpUMATjkRQYnKH4n41HGdwQGb-JKZjcjxr6mO9g@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
	<CAE0GdZW-vN-kpUMATjkRQYnKH4n41HGdwQGb-JKZjcjxr6mO9g@mail.gmail.com>
Message-ID: <20160824191848.GA24668@fedora-21-dvm>

On Wed, Aug 24, 2016 at 04:29:19PM +0000, Jimmy wrote:
> Is this unrelated to Bitcoin Vigil idea published in 2014?
> 
> http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/

I think it's very related; to be absolutely clear the idea of a Bitcoin
honeypot is 100% not my idea! Also, if anyone else had previously invented the
techniques I (and Jeff Coleman) invented, I'd love to hear about it so I can
give appropriate credit.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/8a9f76f9/attachment.sig>

From pete at petertodd.org  Wed Aug 24 19:22:11 2016
From: pete at petertodd.org (Peter Todd)
Date: Wed, 24 Aug 2016 19:22:11 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
Message-ID: <20160824192211.GB24668@fedora-21-dvm>

On Thu, Aug 25, 2016 at 01:37:34AM +1000, Matthew Roberts wrote:
> Really nice idea. So its like a smart contract that incentivizes
> publication that a server has been hacked? I also really like how the
> funding has been handled -- with all the coins stored in the same address
> and then each server associated with a unique signature. That way, you
> don't have to split up all the coins among every server and reduce the
> incentive for an attacker yet you can still identify which server was
> hacked.
> 
> It would be nice if after the attacker broke into the server that they were
> also incentivized to act on the information as soon as possible (revealing
> early on when the server was compromised.) I suppose you could split up the
> coins into different outputs that could optimally be redeemed by the owner
> at different points in the future -- so they're incentivzed to act lest

Remember that it's _always_ possible for the owner to redeem the coins at any
time, and there's no way to prevent that.

The incentive for the intruder to collect the honeypot in a timely manner is
simple: once they've broken in, the moment the honeypot owner learns about the
compromise they have every reason to attempt to recover the funds, so the
intruder needs to act as fast as possible to maximize their chances of being
rewarded.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/860da896/attachment.sig>

From sergio.d.lerner at gmail.com  Wed Aug 24 20:51:47 2016
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Wed, 24 Aug 2016 17:51:47 -0300
Subject: [bitcoin-dev] Attack by modifying non-segwit transactions after
	segwit is accepted ?
Message-ID: <CAKzdR-q4hagujzWxJxmwpxJUQFLe7SKukbDNs=_S_VKgJ9N_TA@mail.gmail.com>

In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.

What worries me is what happens with non-segwit transactions after segwit
is activated. I've followed the code from transaction arrival to
transaction relay and it seems that a malicious node could receive a
non-segwit tx, and re-format it into a segwit tx having as high as 400
Kbytes of segwit witness program data, and then relay it. Both transaction
would have the same hash.

The MAX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not
in old non-segwit execution, so witness program stack elements could be as
large as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).
Such large modified transaction will probably not be properly relayed by
the network due too low fee/byte, so the honest miner will probably win and
forward the original transaction through the network.
But if the attacker has better connectivity with the network and he
modifies the original transaction adding segwit witness program data only
up to the point where the transaction is relayed but miners are discouraged
to include it in blocks due to low fees/byte, then the attacker has
successfully prevented a transaction from being mined (or at least it will
take much more).

Also an attacker can encode arbitrary data (such as virus signatures or
illegal content) into passing non-segwit transactions.

One solution would be to increase the transaction version to 3 for segwit
transactions, so a non-segwit transaction cannot be converted into a segwit
transaction without changing the transaction hash. But this seems not to be
a good solution, because it does not solve all the problems. Transactions
having a mixture of segwit and non-segwit inputs could suffer the same
attack (even if they are version 3).

I proposed that a rule is added to IsStandardTX() that prevents witness
programs of having a stack elements of length greater than
MAX_SCRIPT_ELEMENT_SIZE. (currently this is not a rule)

That's a simple check that prevents most of the problems.

A long term solution would be to add the maximum size of the witness stack
in bytes (maxWitnessSize) as a field for each input, or as a field of the
whole transaction.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/1158ef31/attachment.html>

From cp368202 at ohiou.edu  Wed Aug 24 23:03:16 2016
From: cp368202 at ohiou.edu (Chris Priest)
Date: Wed, 24 Aug 2016 16:03:16 -0700
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <20160824192211.GB24668@fedora-21-dvm>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
	<20160824192211.GB24668@fedora-21-dvm>
Message-ID: <CAAcC9yvh_BSerOeGka=9T_wOkUDw6bMGj=MWoBP4N16EswcKcw@mail.gmail.com>

How does your system prevent against insider attacks? How do you know
the money is stolen by someone who compromised server #4, and not
stolen by the person who set up server #4? It is my understanding
these days most attacks are inside jobs.

On 8/24/16, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Aug 25, 2016 at 01:37:34AM +1000, Matthew Roberts wrote:
>> Really nice idea. So its like a smart contract that incentivizes
>> publication that a server has been hacked? I also really like how the
>> funding has been handled -- with all the coins stored in the same address
>> and then each server associated with a unique signature. That way, you
>> don't have to split up all the coins among every server and reduce the
>> incentive for an attacker yet you can still identify which server was
>> hacked.
>>
>> It would be nice if after the attacker broke into the server that they
>> were
>> also incentivized to act on the information as soon as possible
>> (revealing
>> early on when the server was compromised.) I suppose you could split up
>> the
>> coins into different outputs that could optimally be redeemed by the
>> owner
>> at different points in the future -- so they're incentivzed to act lest
>
> Remember that it's _always_ possible for the owner to redeem the coins at
> any
> time, and there's no way to prevent that.
>
> The incentive for the intruder to collect the honeypot in a timely manner
> is
> simple: once they've broken in, the moment the honeypot owner learns about
> the
> compromise they have every reason to attempt to recover the funds, so the
> intruder needs to act as fast as possible to maximize their chances of
> being
> rewarded.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

From greg at xiph.org  Wed Aug 24 23:38:30 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Wed, 24 Aug 2016 23:38:30 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAAcC9yvh_BSerOeGka=9T_wOkUDw6bMGj=MWoBP4N16EswcKcw@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAAEDBiEkGtj0HSBVgM1KGfsoLmpwK7QxGCTQE1z7FaCPtG2V6g@mail.gmail.com>
	<20160824192211.GB24668@fedora-21-dvm>
	<CAAcC9yvh_BSerOeGka=9T_wOkUDw6bMGj=MWoBP4N16EswcKcw@mail.gmail.com>
Message-ID: <CAAS2fgQCVeZUBkuRCn0p1gtZpC4UMQaUx5XtDQMTxEq5U3W9GQ@mail.gmail.com>

On Wed, Aug 24, 2016 at 11:03 PM, Chris Priest via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> How does your system prevent against insider attacks? How do you know
> the money is stolen by someone who compromised server #4, and not
> stolen by the person who set up server #4? It is my understanding
> these days most attacks are inside jobs.

Working as designed in that case:  You know #4 is compromised, it
doesn't tell you if it was an insider or an outsider, but in both
cases someone unauthorized or without integrity got access to the
key(s).

From jl2012 at xbt.hk  Thu Aug 25 01:49:34 2016
From: jl2012 at xbt.hk (Johnson Lau)
Date: Wed, 24 Aug 2016 21:49:34 -0400 (EDT)
Subject: [bitcoin-dev] Attack by modifying non-segwit transactions after
 segwit is accepted ?
In-Reply-To: <CAKzdR-q4hagujzWxJxmwpxJUQFLe7SKukbDNs=_S_VKgJ9N_TA@mail.gmail.com>
References: <CAKzdR-q4hagujzWxJxmwpxJUQFLe7SKukbDNs=_S_VKgJ9N_TA@mail.gmail.com>
Message-ID: <339348690.148734.1472089774841@privateemail.com>

Adding witness data to a non-segwit script is invalid by consensus:

https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/interpreter.cpp#L1467


This PR will detect such violation early and ban the peer:

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


Another approach is to run the scripts of all incoming transactions. That's not too bad as you have already fetched the utxos which is a major part of validation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/957edeac/attachment.html>

From macwhyte at gmail.com  Thu Aug 25 02:54:47 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Thu, 25 Aug 2016 02:54:47 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <20160824014634.GA19905@fedora-21-dvm>
References: <20160824014634.GA19905@fedora-21-dvm>
Message-ID: <CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>

I've always assumed honeypots were meant to look like regular, yet
poorly-secured, assets. If the intruder could identify this as a honeypot
by the strange setup (presigned, non-standard transactions lying around)
and was aware that the creator intended to doublespend as soon as the
transaction was discovered, wouldn't they instead prefer to not touch
anything and wait for a non-bait target to appear? Is the assumption here
that the intruder wouldn't know this is a honeypot, or that they would know
and it's just assumed that they would rather take their chances on this
instead of causing some other trouble?

On Tue, Aug 23, 2016 at 6:47 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
>     2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =====================
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the result looks like two normal transactions
> created
> in the process of someone with a standard wallet sending a small amount of
> funds to an address, followed by sending a larger amount.
>
>
> Doublespending
> ==============
>
> A subtlety in the the two transactions concept is that the intruder doesn't
> have the necessary private keys to modify the first transaction, which
> means
> that the honeypot owner can respond to the compromise by doublespending
> that
> transaction, potentially recovering the honeypot while still learning
> about the
> compromise. While this is possible with all honeypots, if the first
> transaction
> is signed with the opt-in RBF flags, and CPFP-aware transaction
> replacement is
> not implemented by miners, the mechanics are particularly disadvantageous
> to
> the intruder, as the honeypot owner only needs to increase the first
> transaction's fee slightly to have a high chance of recovering their funds.
> With CPFP-aware transaction replacement the intruder could in-turn respond
> with
> a high-fee CPFP second transaction, but currently no such implementation is
> known.
>
>
> Scorched Earth
> ==============
>
> We can use the "scorched earth" concept to improve the credibility of the
> honeypot reward by making it costly for the honeypot owner to doublespend.
> Here
> a second version of the honeypot pre-signed transaction would also be
> provided
> which sepnds the entirety of the honeypot output to fees, and additionally
> spends a second output to fees. An economically rational intruder will
> publish
> the first version, which maximizes the funds they get out of the honeypot.
> If
> the owner tries to dishonestly doublespend, they can respond by publishing
> the
> "scorched earth" transaction, encouraging the honeypot owner's honesty and
> making CPFP-aware transaction replacement irrelevant.
>
> Of course, miner centralization adds complexity to the above: in many
> instances
> honeypot owners and/or intruders will be able to recover funds from
> altruistic
> miners. Equally, the additional complexity may discourage intruders from
> making
> use of the honeypot entirely.
>
> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
> used to
> ensure the honeypot output can only be spent with transaction replacement
> enabled, as CSV requires nSequence to be set in specific ways in any
> transation
> spending the output.
>
>
> References
> ==========
>
> 1) https://blockstream.com/2015/08/24/treesignatures/
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/52443c18/attachment.html>

From dev at jonasschnelli.ch  Thu Aug 25 07:39:28 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Thu, 25 Aug 2016 09:39:28 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
	<278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
Message-ID: <57BEA0B0.3090308@jonasschnelli.ch>

Sorry for hijacking the thread again

> As I understand it, you can scan sequentially starting with the genesis
> block (or with a block at around the time when BIP44 was written).  Then
> if you find a new transaction, which requires to generate new addresses,
> you generate them and scan further from that point on.  This way you can
> scan in a single pass if the scanning process calls you back when it
> finds a transaction and allows you to change the set of addresses on the
> fly.

(I think this case if not completely unrealistic):

What would happen, if a user gave out 21 addresses, then address0 had
receive funds in +180 days after generation where address21 had receive
funds immediately (all other addresses never received a tx).

In a scan, address0 would be detected at <address-birthday>+180 days
which would trigger the resize+20 of the address-lookup-window, but, we
would require to go back 180day in order to detect received transaction
of address21 (new lookup-window) in that case.

Or do I misunderstand something?


</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/b7df9cb6/attachment.sig>

From thomasv at electrum.org  Thu Aug 25 07:56:17 2016
From: thomasv at electrum.org (Thomas Voegtlin)
Date: Thu, 25 Aug 2016 09:56:17 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <57BEA0B0.3090308@jonasschnelli.ch>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
	<278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
	<57BEA0B0.3090308@jonasschnelli.ch>
Message-ID: <756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org>



Le 25/08/2016 ? 09:39, Jonas Schnelli via bitcoin-dev a ?crit :
> (I think this case if not completely unrealistic):
> 
> What would happen, if a user gave out 21 addresses, then address0 had
> receive funds in +180 days after generation where address21 had receive
> funds immediately (all other addresses never received a tx).
> 
> In a scan, address0 would be detected at <address-birthday>+180 days
> which would trigger the resize+20 of the address-lookup-window, but, we
> would require to go back 180day in order to detect received transaction
> of address21 (new lookup-window) in that case.
> 
> Or do I misunderstand something?
> 
> 

That case is not unrealistic; a merchant might generate addresses that
are beyond their gap limit, and orders get filled at a later date.

In that case you will not get the same result when restoring your wallet
in a block-scanning wallet and in Electrum.

The lack of consideration for these cases is another issue with BIP44.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/5fed1fda/attachment-0001.sig>

From dev at jonasschnelli.ch  Thu Aug 25 08:08:21 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Thu, 25 Aug 2016 10:08:21 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
	<278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
	<57BEA0B0.3090308@jonasschnelli.ch>
	<756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org>
Message-ID: <57BEA775.4020701@jonasschnelli.ch>


> Le 25/08/2016 ? 09:39, Jonas Schnelli via bitcoin-dev a ?crit :
>> (I think this case if not completely unrealistic):
>>
>> What would happen, if a user gave out 21 addresses, then address0 had
>> receive funds in +180 days after generation where address21 had receive
>> funds immediately (all other addresses never received a tx).
>>
>> In a scan, address0 would be detected at <address-birthday>+180 days
>> which would trigger the resize+20 of the address-lookup-window, but, we
>> would require to go back 180day in order to detect received transaction
>> of address21 (new lookup-window) in that case.
>>
>> Or do I misunderstand something?
>>
>>
> 
> That case is not unrealistic; a merchant might generate addresses that
> are beyond their gap limit, and orders get filled at a later date.
> 
> In that case you will not get the same result when restoring your wallet
> in a block-scanning wallet and in Electrum.
> 
> The lack of consideration for these cases is another issue with BIP44.

The development paradigm of "maybe detect funds" is not something we
should *not* encourage for Bitcoin IMO.

Users might sweep their existing bip32/bip44 seed (which could miss
funds according to the problem above) to a new wallet and discard the
previous seed.

But I agree with Luke-Jr.
This Thread is not about specification, it's about what's used and what
should be marked as standard.

New BIPs could cover "overhauled" proposals for BIP39 and BIP44.
Otherwise ? very likely ? nothing will happen.

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/500f4db6/attachment.sig>

From dev at jonasschnelli.ch  Thu Aug 25 08:12:22 2016
From: dev at jonasschnelli.ch (Jonas Schnelli)
Date: Thu, 25 Aug 2016 10:12:22 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <57BEA775.4020701@jonasschnelli.ch>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
	<278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
	<57BEA0B0.3090308@jonasschnelli.ch>
	<756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org>
	<57BEA775.4020701@jonasschnelli.ch>
Message-ID: <57BEA866.5070801@jonasschnelli.ch>


> The development paradigm of "maybe detect funds" is not something we
> should *not* encourage for Bitcoin IMO.

Sorry. That was one "not" to many.

</jonas>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/3a663553/attachment.sig>

From marek at palatinus.cz  Thu Aug 25 08:50:43 2016
From: marek at palatinus.cz (Marek Palatinus)
Date: Thu, 25 Aug 2016 10:50:43 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <57BEA866.5070801@jonasschnelli.ch>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
	<278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
	<57BEA0B0.3090308@jonasschnelli.ch>
	<756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org>
	<57BEA775.4020701@jonasschnelli.ch> <57BEA866.5070801@jonasschnelli.ch>
Message-ID: <CAJna-Hjueu2-ShSGCTVF10x4yW5LUV1jv60SfY0rcGe149p5GA@mail.gmail.com>

As Luke pointed, BIP44 is already used by many wallets and to my knowledge
people don't have any real world issues with that, including loading funds
in another BIP44 wallet. I'm not saying that BIP44 is perfect from all
points of view, but IMO it just works for most use cases. Let's set it as
final, and propose competing standards which cover all your concerns.

slush

On Thu, Aug 25, 2016 at 10:12 AM, Jonas Schnelli via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> > The development paradigm of "maybe detect funds" is not something we
> > should *not* encourage for Bitcoin IMO.
>
> Sorry. That was one "not" to many.
>
> </jonas>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/ffbc4f83/attachment.html>

From pieter.wuille at gmail.com  Thu Aug 25 09:02:27 2016
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Thu, 25 Aug 2016 11:02:27 +0200
Subject: [bitcoin-dev] BIP Status updates (including to Active/Final
 Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130
In-Reply-To: <CAJna-Hjueu2-ShSGCTVF10x4yW5LUV1jv60SfY0rcGe149p5GA@mail.gmail.com>
References: <201608232012.12588.luke@dashjr.org>
	<90bf12f2-e109-28b4-e93e-54bbc8002cb4@electrum.org>
	<57BDACB2.9040307@jonasschnelli.ch>
	<278c940d-4b3b-2b8a-1aa5-f0991f1e6c8e@gmail.com>
	<57BEA0B0.3090308@jonasschnelli.ch>
	<756a4e04-c42d-cd61-794d-59f159c109b5@electrum.org>
	<57BEA775.4020701@jonasschnelli.ch> <57BEA866.5070801@jonasschnelli.ch>
	<CAJna-Hjueu2-ShSGCTVF10x4yW5LUV1jv60SfY0rcGe149p5GA@mail.gmail.com>
Message-ID: <CAPg+sBidFN7o4HSFqL_MXnSU9vhQFo2bDorPu_MiZWutcV4ecw@mail.gmail.com>

This is not the place to discuss the merits and/or issues of these BIPs,
only whether they should be treated as final.

On Aug 25, 2016 10:51, "Marek Palatinus via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> As Luke pointed, BIP44 is already used by many wallets and to my knowledge
> people don't have any real world issues with that, including loading funds
> in another BIP44 wallet. I'm not saying that BIP44 is perfect from all
> points of view, but IMO it just works for most use cases. Let's set it as
> final, and propose competing standards which cover all your concerns.
>
> slush
>
> On Thu, Aug 25, 2016 at 10:12 AM, Jonas Schnelli via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> > The development paradigm of "maybe detect funds" is not something we
>> > should *not* encourage for Bitcoin IMO.
>>
>> Sorry. That was one "not" to many.
>>
>> </jonas>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160825/f6711fae/attachment.html>

From decker.christian at gmail.com  Thu Aug 25 14:27:32 2016
From: decker.christian at gmail.com (Christian Decker)
Date: Thu, 25 Aug 2016 16:27:32 +0200
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
Message-ID: <20160825142732.GA11295@nex>

On Thu, Aug 25, 2016 at 02:54:47AM +0000, James MacWhyte via bitcoin-dev wrote:
> I've always assumed honeypots were meant to look like regular, yet
> poorly-secured, assets. If the intruder could identify this as a honeypot
> by the strange setup (presigned, non-standard transactions lying around)
> and was aware that the creator intended to doublespend as soon as the
> transaction was discovered, wouldn't they instead prefer to not touch
> anything and wait for a non-bait target to appear? Is the assumption here
> that the intruder wouldn't know this is a honeypot, or that they would know
> and it's just assumed that they would rather take their chances on this
> instead of causing some other trouble?

That strongly depends on the value of the compromised machine to the
attacker. If he has syphoned all the data from it and has no further
use for it then the he will probably trip the tripwire to get the
coins even though this will make the compromise apparent. If however
he is planning to use it as a foothold to further compromise your
company, send spam or similar, he will likely try to avoid these
tripwires. In which case a classic honeypot, that attempts to look
like a regular system is what you're looking for.

From greg at xiph.org  Thu Aug 25 18:26:21 2016
From: greg at xiph.org (Gregory Maxwell)
Date: Thu, 25 Aug 2016 18:26:21 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <20160825142732.GA11295@nex>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
	<20160825142732.GA11295@nex>
Message-ID: <CAAS2fgRTgymPn+YU61N0rR=PRkQbsUHxXt6RySqJbGTCjwuWMg@mail.gmail.com>

On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> If however
> he is planning to use it as a foothold to further compromise your
> company, send spam or similar, he will likely try to avoid these
> tripwires. [...]

Depends on the value of their activity compared to the value of the coins.
Spamming doesn't pay much.

Covert tripwires would obviously be better, but if shared tripwires
allow you to have 100x the funds available it could be a good
trade-off.

From sergio.d.lerner at gmail.com  Fri Aug 26 13:16:36 2016
From: sergio.d.lerner at gmail.com (Sergio Demian Lerner)
Date: Fri, 26 Aug 2016 10:16:36 -0300
Subject: [bitcoin-dev] Attack by modifying non-segwit transactions after
 segwit is accepted ?
In-Reply-To: <339348690.148734.1472089774841@privateemail.com>
References: <CAKzdR-q4hagujzWxJxmwpxJUQFLe7SKukbDNs=_S_VKgJ9N_TA@mail.gmail.com>
	<339348690.148734.1472089774841@privateemail.com>
Message-ID: <CAKzdR-oMEe6rcusn5kajZHvWXEkneywsNEJpooss76o9WuhDxg@mail.gmail.com>

Because there was a discussion on reddit about this topic, I want to
clarify that Johnson Lau explained how a check in the code prevents this
attack.
So there is no real attack.

Also note that the subject of this thread has a question mark, which means
that I'm asking the community for clarification, not asserting the
existence of a vulnerability.

The segwit code is complex, and some key parts of the consensus code are
spread over the source files (such as state.CorruptionPossible() relation
to DoS banning, IsNull() check in witness program serialization, etc.).

Thanks again Johnson for your clarifications.


On Wed, Aug 24, 2016 at 10:49 PM, Johnson Lau <jl2012 at xbt.hk> wrote:

> Adding witness data to a non-segwit script is invalid by consensus:
>
> https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5e
> b919a87907/src/script/interpreter.cpp#L1467
>
>
> This PR will detect such violation early and ban the peer:
>
> https://github.com/bitcoin/bitcoin/pull/8499
>
>
> Another approach is to run the scripts of all incoming transactions.
> That's not too bad as you have already fetched the utxos which is a major
> part of validation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160826/aa2ad6dd/attachment.html>

From macwhyte at gmail.com  Sun Aug 28 02:50:12 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Sun, 28 Aug 2016 02:50:12 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAAS2fgRTgymPn+YU61N0rR=PRkQbsUHxXt6RySqJbGTCjwuWMg@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
	<20160825142732.GA11295@nex>
	<CAAS2fgRTgymPn+YU61N0rR=PRkQbsUHxXt6RySqJbGTCjwuWMg@mail.gmail.com>
Message-ID: <CAH+Axy5wOLfAO5XKb5v=A34k5V8RYxnO7ubUd_H7bmH+iS4-0w@mail.gmail.com>

Why not just have a single 1-of-m multisig transaction, with one key on
each server? Based on which key is used you would know which server is
compromised, and (in my opinion) it wouldn't look nearly as suspicious.

On Thu, Aug 25, 2016 at 11:26 AM Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If however
> > he is planning to use it as a foothold to further compromise your
> > company, send spam or similar, he will likely try to avoid these
> > tripwires. [...]
>
> Depends on the value of their activity compared to the value of the coins.
> Spamming doesn't pay much.
>
> Covert tripwires would obviously be better, but if shared tripwires
> allow you to have 100x the funds available it could be a good
> trade-off.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160828/5d9952ea/attachment.html>

From pete at petertodd.org  Sun Aug 28 04:42:01 2016
From: pete at petertodd.org (Peter Todd)
Date: Sun, 28 Aug 2016 04:42:01 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
	Doublespending Protection
In-Reply-To: <CAAS2fgRTgymPn+YU61N0rR=PRkQbsUHxXt6RySqJbGTCjwuWMg@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
	<20160825142732.GA11295@nex>
	<CAAS2fgRTgymPn+YU61N0rR=PRkQbsUHxXt6RySqJbGTCjwuWMg@mail.gmail.com>
Message-ID: <92F89733-809F-40DC-B315-1323DE550BE2@petertodd.org>



On 25 August 2016 14:26:21 GMT-04:00, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
><bitcoin-dev at lists.linuxfoundation.org> wrote:
>> If however
>> he is planning to use it as a foothold to further compromise your
>> company, send spam or similar, he will likely try to avoid these
>> tripwires. [...]
>
>Depends on the value of their activity compared to the value of the
>coins.
>Spamming doesn't pay much.
>
>Covert tripwires would obviously be better, but if shared tripwires
>allow you to have 100x the funds available it could be a good
>trade-off.

Also, having a overt tripwire doesn't preclude having covert tripwires as well.


In any case, this all deserves a Standard? to make sure intruders know where to look to find the funds. Maybe /var/honeypot...

From pete at petertodd.org  Sun Aug 28 04:37:29 2016
From: pete at petertodd.org (Peter Todd)
Date: Sun, 28 Aug 2016 04:37:29 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
	Doublespending Protection
In-Reply-To: <CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
Message-ID: <82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>



On 24 August 2016 22:54:47 GMT-04:00, James MacWhyte <macwhyte at gmail.com> wrote:
>I've always assumed honeypots were meant to look like regular, yet
>poorly-secured, assets.

Not at all. Most servers have zero reason to have any Bitcoin's accessible via them, so the presence of BTC privkeys is a gigantic red flag that they are part of a honeypot.

> If the intruder could identify this as a
>honeypot
>by the strange setup (presigned, non-standard transactions lying
>around)
>and was aware that the creator intended to doublespend as soon as the
>transaction was discovered, wouldn't they instead prefer to not touch
>anything and wait for a non-bait target to appear?

Re-read my last section on the "scorched earth" disincentive to doublespend the intruder.


From corey3 at gmail.com  Sun Aug 28 23:14:03 2016
From: corey3 at gmail.com (Corey Haddad)
Date: Sun, 28 Aug 2016 16:14:03 -0700
Subject: [bitcoin-dev] Hardware Wallet Standard
In-Reply-To: <CACiOHGycQKr3zETzhOfxzOFb2FgqOou_3bod66NuPWbf=4hhEQ@mail.gmail.com>
References: <57B31EBC.1030806@jonasschnelli.ch>
	<CACiOHGycQKr3zETzhOfxzOFb2FgqOou_3bod66NuPWbf=4hhEQ@mail.gmail.com>
Message-ID: <CAK_HAC-AeJPDa6+SU3wPtnP_UJ_WciyhYZAu9F7_6S02ZGZvaA@mail.gmail.com>

*One of my biggest fears about using any wallet is the "whoops, cosmic ray
flipped a bit while producing receiving address; SFYL!" possibility. For
high value cold storage, I always generate my addresses on two independent
machines using two different pieces of software. Am I nuts for doing that?*
A randomly flipped bit would be extremely unlikely to yield a valid
address, however, I still think it you are wise to use independent routes
to confirm that your addresses match the keys.  I do the same when I
generating my cold storage key pairs.  I think malicious address
substitution is an under appreciated attack vector.

Regarding this thread in general, would it make sense for this proposal to
include standards for multi-sig wallet interoperability?  A whole spectrum
of attacks would be made less likely - and easy for typical users to guard
against - by using wallets on separate devices AND where the wallet
software was written and provided by different parties.

On Mon, Aug 22, 2016 at 9:50 AM, Moral Agent via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> It would be nice if the detached signer and the normal wallet could both
> verify the correctness of generated addresses before you cause coins to be
> sent there.
>
> e.g. the hardware wallet could give its master public key to Bitcoin Core
> and you can thereafter generate your receiving addresses on Core, with the
> option to have the HW wallet validate them.
>
> One of my biggest fears about using any wallet is the "whoops, cosmic ray
> flipped a bit while producing receiving address; SFYL!" possibility. For
> high value cold storage, I always generate my addresses on two independent
> machines using two different pieces of software. Am I nuts for doing that?
>
> With the above scheme, you are pretty well protected from losing money if
> your HW wallet is defective. You could still lose it if the HW wallet was
> evil of course, but that strikes me as much more likely to be discovered
> quickly.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160828/65c0f30a/attachment.html>

From pieter.wuille at gmail.com  Wed Aug 31 14:29:53 2016
From: pieter.wuille at gmail.com (Pieter Wuille)
Date: Wed, 31 Aug 2016 16:29:53 +0200
Subject: [bitcoin-dev] BIP 151
In-Reply-To: <0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org>
References: <87h9cecad5.fsf@rustcorp.com.au>
	<1E86A00F-0609-4DBC-9543-94AE04CC13C9@voskuil.org>
	<577234A4.3030808@jonasschnelli.ch>
	<CAAS2fgQFqHBdbym4GMAV-mdcEWR1SdGc3av0mDu65keKP9Ak6g@mail.gmail.com>
	<AB9C1C8F-7369-42CC-8551-7E03B16D5229@voskuil.org>
	<CAAS2fgT4V72vj17qTLu7pz5EQ60bqnggeDnTP5ASdwYxpuNpWw@mail.gmail.com>
	<CB6D8DF2-3EB7-4A12-8861-494D1DBC3D93@voskuil.org>
	<CAPg+sBigr0BZBiuW9DYpxJ3ytZ4g30k_9B+Eb8QhQv2dC9qQUA@mail.gmail.com>
	<0932A659-6BE0-441F-AD05-ED846BBE7C80@voskuil.org>
Message-ID: <CAPg+sBhZaSkRc9yDKHYPjq3oD_bXZ1GsBgzgqOV_Dcd-LZY3BA@mail.gmail.com>

Hello Eric,

I felt like I still owed you a response to the points below.

On Thu, Jun 30, 2016 at 5:10 PM, Eric Voskuil <eric at voskuil.org> wrote:
> Pieter, these are in my opinion very reasonable positions. I've made some observations inline.
>
>> On Jun 30, 2016, at 3:03 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>>
>> On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> The proliferation of node identity is my primary concern - this relates to privacy and the security of the network.
>>
>> I think this is a reasonable concern.
>>
>> However, node identity is already being used widely, and in a very
>> inadvisable way:
>> * Since forever there have been lists of 'good nodes' to pass in
>> addnode= configuration options.
>> * Various people run multiple nodes in different geographic locations,
>> peering with each other.
>> * Various pieces of infrastructure exist that relies on connecting to
>> well-behaving nodes (miner relay networks, large players peering
>> directly with each other, ...)
>
> Yes, libbitcoin also provides these options on an IP basis.
>
>> * Several lightweight clients support configuring a trusted host to connect to.
>
> I explicitly exclude client-server behavior as I believe the proper resolution is to isolate clients from the P2P protocol. Libbitcoin does this already.

I think that's a false dichotomy. There is no reason why the P2P
network consists of purely servers (full nodes) and clients
(lightweight nodes). Where does a client fit that is SPV at startup,
but upgrades in the background to a full node? It seems strange that
such a client would use a 'client protocol' for initial connections,
but the P2P protocol for syncing with history, when both come from the
same peers, and transmit the same kind of information.

What would make sense IMHO is a protocol split between the different
kinds of transmission:
1) Historical block download
2) Block synchronization at the tip
3) Transaction relay
...

(1) prefers high bandwidth, has no connectivity concerns, and does not
care about latency and has no privacy concerns. (2) needs
partition-resistance, low latency and has also no privacy concerns.
(3) needs moderate latency, reliability of propagation and privacy.

If there were to be separate protocols for these, I would argue that
(3) should use opportunistic encryption always to increase transaction
source privacy, and (2) and (3) need authentication when one of the
peers is not fully validating.

BIP 150/151 give the tools to construct these.

>> Perhaps you deplore that fact, but I believe it is inevitable that different pieces of the network will make different choices here. You can't prevent people from create connections along preexisting trust lines. That does not mean that the network as a whole relies on first establishing trust everywhere.
>
> Of course, the network operates just fine without universal trust. My concern is not that it is required, but that it may grow significantly and will have a tendency to gravitate towards more effective registration mechanisms for what is a "good" peer. Even an informal but pervasive web of trust may make it difficult for untrusted parties to connect.

Maybe, but I'm very unconvinced that that will happen more than how
today IP and DNS-based "authentication" is used already (in very
inadvisable ways).

>> And I do think there are advantages.
>>
>> BIP 151 on its own gives you opportunistic encryption. You're very right to point out that this does not give you protection from active attackers, and that active attacking is relatively easy through sybil attacks. I still prefer my attacker to actually do that over just listening in on my connection.

> I agree, and I doubt this proposal will have much impact on an advanced persistent threat, or even lesser threats. People should understand that there is both a risk and a limited benefit to this proposal.

I believe the risk is only in misunderstanding what it is good for,
and there significant benefits to a network that encrypts connections
by default, as it excludes purely passive attackers.

> I believe you have misinterpreted my comments on distributed anonymous credentials (and the like) as commentary on the construction of BIP151 (and a subsequent auth proposal). As such your observation that it is exaggerated would make sense, but it is not what I intended. Encryption and auth are straightforward. Preventing bad nodes from participating in an anonymous distributed system is not.

Preventing bad nodes from participating is a very hard problem, if not
impossible. That doesn't mean we can't improve the current situation:
people are relying on node identity already, and doing so in ways that
have unclear attack vectors (IP spoofing, DNS poisoning, BGP routing
attacks). Adding optional and non-discoverable cryptographic
identities can improve this.

-- 
Pieter

From macwhyte at gmail.com  Wed Aug 31 17:02:39 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Wed, 31 Aug 2016 17:02:39 +0000
Subject: [bitcoin-dev] BIP75 Update - August 31, 2016
Message-ID: <CAH+Axy7F1Up0nQwZdmUp+5Lo9PF065AHK0uJjwcFnic9vrSVyA@mail.gmail.com>

Hello all,

Today we are submitting some updates to BIP75:

-- Example use cases have been reworded to more accurately describe the
goal of this BIP and how the technology works.
-- ECDSA and PGP have been added to the supported public key infrastructure
(PKI) types to increase flexibility and use cases.
-- Versioning has been added to make future changes and backwards
compatibility easy to manage.
-- Other minor, technical details have been added or changed to improve
performance and reduce ambiguity during implementation.

You can see the PR here: https://github.com/bitcoin/bips/pull/439

Thank you,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160831/87e4cd0e/attachment.html>

From macwhyte at gmail.com  Wed Aug 31 19:48:50 2016
From: macwhyte at gmail.com (James MacWhyte)
Date: Wed, 31 Aug 2016 19:48:50 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
	<82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>
Message-ID: <CAH+Axy6eOtqoLt5A40qYQG4S6UgFfEQeaM3Dgo677ZaH3NhQ5Q@mail.gmail.com>

>
> >I've always assumed honeypots were meant to look like regular, yet
> >poorly-secured, assets.
>
> Not at all. Most servers have zero reason to have any Bitcoin's accessible
> via them, so the presence of BTC privkeys is a gigantic red flag that they
> are part of a honeypot.
>

I was talking about the traditional concept. From Wikipedia: "Generally, a
honeypot consists of data (for example, in a network site) that appears to
be a legitimate part of the site but is actually isolated and monitored,
and that seems to contain information or a resource of value to attackers,
which are then blocked."

I would argue there are ways to make it look like it is not a honeypot
(plenty of bitcoin services have had their hot wallets hacked before, and
if the intruder only gains access to one server they wouldn't know that all
the servers have the same honeypot on them). But I was just confirming that
the proposal is for an obvious honeypot.


> Re-read my last section on the "scorched earth" disincentive to
> doublespend the intruder.
>
> The first time I read it I didn't realize that the second transaction the
intruder has is designed to waste the honeypot AND additional funds
belonging to the honeypot creator. That's pretty good, from a game theory
perspective.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160831/fe3096c6/attachment.html>

From pete at petertodd.org  Wed Aug 31 20:01:14 2016
From: pete at petertodd.org (Peter Todd)
Date: Wed, 31 Aug 2016 20:01:14 +0000
Subject: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth"
 Doublespending Protection
In-Reply-To: <CAH+Axy6eOtqoLt5A40qYQG4S6UgFfEQeaM3Dgo677ZaH3NhQ5Q@mail.gmail.com>
References: <20160824014634.GA19905@fedora-21-dvm>
	<CAH+Axy4ahvQOG5=jGn68u0m5dTTmFCJ0isfOEt-Be=63ot55dg@mail.gmail.com>
	<82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org>
	<CAH+Axy6eOtqoLt5A40qYQG4S6UgFfEQeaM3Dgo677ZaH3NhQ5Q@mail.gmail.com>
Message-ID: <20160831200114.GA23079@fedora-21-dvm>

On Wed, Aug 31, 2016 at 07:48:50PM +0000, James MacWhyte wrote:
> >
> > >I've always assumed honeypots were meant to look like regular, yet
> > >poorly-secured, assets.
> >
> > Not at all. Most servers have zero reason to have any Bitcoin's accessible
> > via them, so the presence of BTC privkeys is a gigantic red flag that they
> > are part of a honeypot.
> >
> 
> I was talking about the traditional concept. From Wikipedia: "Generally, a
> honeypot consists of data (for example, in a network site) that appears to
> be a legitimate part of the site but is actually isolated and monitored,
> and that seems to contain information or a resource of value to attackers,
> which are then blocked."
> 
> I would argue there are ways to make it look like it is not a honeypot
> (plenty of bitcoin services have had their hot wallets hacked before, and
> if the intruder only gains access to one server they wouldn't know that all
> the servers have the same honeypot on them). But I was just confirming that
> the proposal is for an obvious honeypot.

Ah, yeah, I think you have a point re: naming - this isn't quite the
traditional honeypot, as we uniquely have the ability to give the attackers a
reward in a way where it's ok for the intruder to know that they've been
detected; with traditional non-monetary honeypots it's quite difficult to come
up with a scenario where it's ok for an intruder to gain something from the
intrusion, so you're forced to use deception instead.

Perhaps a better term for this technique would be a "compromise canary"? Or
"intruder bait"? After all, in wildlife animal research it's common to use bait
as a way of attracting targets to discover that they exist (e.g. w/ wildlife
cameras), even when you have no intention of doing any harm to the animal.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160831/1f5db108/attachment.sig>