Send bitcoin-dev mailing list submissions to
        bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
        bitcoin-dev-request@lists.linuxfoundation.org

You can reach the person managing the list at
        bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   1. BIP: Bitcoin Integrated Address Feature? (nathanw@tutanota.com)
   2. Re: BIP: Bitcoin Integrated Address Feature? (htimSxelA)
   3. assumeutxo and UTXO snapshots (James O'Beirne)


----------------------------------------------------------------------

Message: 1
Date: Tue, 2 Apr 2019 18:53:11 +0200 (CEST)
From: <nathanw@tutanota.com>
To: <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?
Message-ID: <LbTxyE4--3-1@tutanota.com>
Content-Type: text/plain; charset="utf-8"

To whom it may concern,

I believe a missing feature in Bitcoin is the ability to have an "integrated address", where the address resolves into a Bitcoin address, and also a transaction message or some other kind of identifier.

By having this feature we could enhance the security of exchange cold-wallet systems, by allowing them to easily receive all payments to a single address from an infinite number of customers. We would also greatly simplify the process of setting up and managing exchange cold-wallet systems, because we would eliminate the "sweeping" step required to move multiple customer deposits from a hot address into a single cold address.

Although it would be nice to have all customers deposit directly into cold addresses, this quickly becomes impractical when large amounts of customers begin to use exchange wallets as their personal web-wallet, frequently depositing and withdrawing without trading action. You end up needing to have a staff member moving funds away from cold deposit addresses as a full time job - if you wish to handle customer funds in a completely secure manner.

Thus we see that most exchanges now use the hot-deposit system, where customers deposit into a hot address that is then automatically swept into a singular cold address, by a service which holds customers private keys online. You can observe this service at work simply by making a deposit to most major exchanges (including the largest exchange Binance), as you will see the funds quickly being "swept" to their cold wallet address in a manner which heavily suggests automation by a program which possesses private keys to the address you are sending funds to. This means there is always the danger of a sophisticated hacker being able to capture private keys to customer deposit addresses (as they are clearly being held online). An integrated address would allow all exchanges using this automated hot-deposit service to easily switch to a far more secure alternative of having all customers depositing directly into their singular cold wallet address.

There are several other more minor advantages such a feature would have, including:
- Lower fees for exchanges (which could be passed onto customers), by reducing a transaction step out of the deposit-to-withdrawal flow.
- Less need for large rescans after loading huge amounts of customer addresses into client software.
- Exchanges can more easily provision deposit addresses to new customers in a secure manner, by simply generating a hex or other value, creating an integrated address from the cold wallet address, and then providing this to the customer.
- By providing a singular cold address for exchanges publicly, customers can more easily verify that no man-in-the-middle has given them an incorrect address to deposit to.
The integrated address could work by combining the Bitcoin address together with some kind of hex or other value, allowing users to choose the amount they wish to deposit themselves, but ensuring their deposits are uniquely trackable.

I'm not sure if some kind of functionality already exists in BTC, as I haven't been able to find it. If not, can I submit a proposal to implement this? This feature would be a godsend to all exchange developers if it was widely accepted.

Thanks for your time.
Regards,

Nathan Worsley
CTO - LocalCoinSwap.Com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/400c1e1b/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 02 Apr 2019 20:01:34 +0000
From: htimSxelA <htimsxela@protonmail.com>
To: "nathanw@tutanota.com" <nathanw@tutanota.com>,      Bitcoin Protocol
        Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?
Message-ID:
        <wtbAF1FAGePDAkY3xkqANuFJtAhEXvz0JeGWnc_OZcGEyFQb-1B590I3IbwtW2FBivur0yONbSQtxaWqiQTJeoDdadivtbGkWwJnLnnzQQE=@protonmail.com>

Content-Type: text/plain; charset="utf-8"

Hello,

I see two immediate issues with this:
1. Increased resource requirements per transaction
2. Embedding identifying information into the blockchain is generally bad for privacy

It may help your case to provide some technical details of how you'd like to see this implemented, but without overcoming the issues mentioned above I think this proposal will be a very tough sell.

> ...this quickly becomes impractical when large amounts of customers begin to use exchange wallets as their personal web-wallet, frequently depositing and withdrawing without trading action. You end up needing to have a staff member moving funds away from cold deposit addresses as a full time job - if you wish to handle customer funds in a completely secure manner.

I am not sure if I see how this issue is solved by your proposal. Assumedly, a human will still need to manually approve cold-wallet withdrawals in order to maintain security. So it seems to me that removing the 'hot-wallet' component of the backend would only amplify the need for human interaction.

I assume you are familiar with hierarchical deterministic wallets? They can allow an exchange to assign/identify user deposits based on address derivation path. Keys for deposit addresses can be kept offline if wanted, and a proper implementation of an HD wallet system should also remove the need for rescans of user deposit addresses.

There is also a functionality built into Bitcoin that allows a user to prove that they own the private keys to some address: signing an agreed upon message using the private key that controls that address. Unfortunately I don't think this is a workable solution for you, since the majority of modern wallet software does not include this feature-- but perhaps worth mentioning nonetheless.

Best,
Alex

??????? Original Message ???????
On Tuesday, April 2, 2019 9:53 AM, Nathan Worsley via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> To whom it may concern,
>
> I believe a missing feature in Bitcoin is the ability to have an "integrated address", where the address resolves into a Bitcoin address, and also a transaction message or some other kind of identifier.
>
> By having this feature we could enhance the security of exchange cold-wallet systems, by allowing them to easily receive all payments to a single address from an infinite number of customers. We would also greatly simplify the process of setting up and managing exchange cold-wallet systems, because we would eliminate the "sweeping" step required to move multiple customer deposits from a hot address into a single cold address.
>
> Although it would be nice to have all customers deposit directly into cold addresses, this quickly becomes impractical when large amounts of customers begin to use exchange wallets as their personal web-wallet, frequently depositing and withdrawing without trading action. You end up needing to have a staff member moving funds away from cold deposit addresses as a full time job - if you wish to handle customer funds in a completely secure manner.
>
> Thus we see that most exchanges now use the hot-deposit system, where customers deposit into a hot address that is then automatically swept into a singular cold address, by a service which holds customers private keys online. You can observe this service at work simply by making a deposit to most major exchanges (including the largest exchange Binance), as you will see the funds quickly being "swept" to their cold wallet address in a manner which heavily suggests automation by a program which possesses private keys to the address you are sending funds to. This means there is always the danger of a sophisticated hacker being able to capture private keys to customer deposit addresses (as they are clearly being held online). An integrated address would allow all exchanges using this automated hot-deposit service to easily switch to a far more secure alternative of having all customers depositing directly into their singular cold wallet address.
>
> There are several other more minor advantages such a feature would have, including:
> - Lower fees for exchanges (which could be passed onto customers), by reducing a transaction step out of the deposit-to-withdrawal flow.
> - Less need for large rescans after loading huge amounts of customer addresses into client software.
> - Exchanges can more easily provision deposit addresses to new customers in a secure manner, by simply generating a hex or other value, creating an integrated address from the cold wallet address, and then providing this to the customer.
> - By providing a singular cold address for exchanges publicly, customers can more easily verify that no man-in-the-middle has given them an incorrect address to deposit to.
>
> The integrated address could work by combining the Bitcoin address together with some kind of hex or other value, allowing users to choose the amount they wish to deposit themselves, but ensuring their deposits are uniquely trackable.
>
> I'm not sure if some kind of functionality already exists in BTC, as I haven't been able to find it. If not, can I submit a proposal to implement this? This feature would be a godsend to all exchange developers if it was widely accepted.
>
> Thanks for your time.
>
> Regards,
>
> Nathan Worsley
> CTO - LocalCoinSwap.Com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/ade34235/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 2 Apr 2019 16:43:11 -0400
From: "James O'Beirne" <james.obeirne@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] assumeutxo and UTXO snapshots
Message-ID:
        <CAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=XwngA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I'd like to discuss assumeutxo, which is an appealing and simple
optimization in the spirit of assumevalid[0].

# Motivation

To start a fully validating bitcoin client from scratch, that client
currently
needs to perform an initial block download. To the surprise of no one, IBD
takes a linear amount time based on the length of the chain's history. For
clients running on modest hardware under limited bandwidth constraints,
say a mobile device, completing IBD takes a considerable amount of time
and thus poses serious usability challenges.

As a result, having fully validating clients run on such hardware is rare
and
basically unrealistic. Clients with even moderate resource constraints
are encouraged to rely on the SPV trust model. Though we have promising
improvements to existing SPV modes pending deployment[1], it's worth
thinking about a mechanism that would allow such clients to use trust
models closer to full validation.

The subject of this mail is a proposal for a complementary alternative to
SPV
modes, and which is in the spirit of an existing default, `assumevalid`. It
may
help modest clients transact under a security model that closely resembles
full validation within minutes instead of hours or days.

# assumeutxo

The basic idea is to allow nodes to initialize using a serialized version
of the
UTXO set rendered by another node at some predetermined height. The
initializing node syncs the headers chain from the network, then obtains and
loads one of these UTXO snapshots (i.e. a serialized version of the UTXO set
bundled with the block header indicating its "base" and some other
metadata).

Based upon the snapshot, the node is able to quickly reconstruct its
chainstate,
and compares a hash of the resulting UTXO set to a preordained hash
hard-coded
in the software a la assumevalid. This all takes ~23 minutes, not
accounting for
download of the 3.2GB snapshot[2].

The node then syncs to the network tip and afterwards begins a simultaneous
background validation (i.e., a conventional IBD) up to the base height of
the
snapshot in order to achieve full validation. Crucially, even while the
background validation is happening the node can validate incoming blocks and
transact with the benefit of the full (assumed-valid) UTXO set.

Snapshots could be obtained from multiple separate peers in the same manner
as
block download, but I haven't put much thought into this. In concept it
doesn't
matter too much where the snapshots come from since their validity is
determined via content hash.

# Security

Obviously there are some security implications due consideration. While this
proposal is in the spirit of assumevalid, practical attacks may become
easier.
Under assumevalid, a user can be tricked into transacting under a false
history
if an attacker convinces them to start bitcoind with a malicious
`-assumevalid`
parameter, sybils their node, and then feeds them a bogus chain encompassing
all of the hard-coded checkpoints[3].

The same attack is made easier in assumeutxo because, unlike in assumevalid,
the attacker need not construct a valid PoW chain to get the victim's node
into
a false state; they simply need to get the user to accept a bad
`-assumeutxo`
parameter and then supply them an easily made UTXO snapshot containing,
say, a
false coin assignment.

For this reason, I recommend that if we were to implement assumeutxo, we not
allow its specification via commandline argument[4].

Beyond this risk, I can't think of material differences in security
relative to
assumevalid, though I appeal to the list for help with this.

# More fully validating clients

A particularly exciting use-case for assumeutxo is the possibility of mobile
devices functioning as fully validating nodes with access to the complete
UTXO
set (as an alternative to SPV models). The total resource burden needed to
start a node
from scratch based on a snapshot is, at time of writing, a ~(3.2GB
+ blocks_to_tip * 4MB) download and a few minutes of processing time, which
sounds
manageable for many mobile devices currently in use.

A mobile user could initialize an assumed-valid bitcoin node within an hour,
transact immediately, and complete a pruned full validation of their
assumed-valid chain over the next few days, perhaps only doing the
background
IBD when their device has access to suitable high-bandwidth connections.

If we end up implementing an accumulator-based UTXO scaling design[5][6]
down
the road, it's easy to imagine an analogous process that would allow very
fast
startup using an accumulator of a few kilobytes in lieu of a multi-GB
snapshot.

---

I've created a related issue at our Github repository here:
  https://github.com/bitcoin/bitcoin/issues/15605

and have submitted a draft implementation of snapshot usage via RPC here:
  https://github.com/bitcoin/bitcoin/pull/15606

I'd like to discuss here whether this is a good fit for Bitcoin
conceptually. Concrete
plans for deployment steps should be discussed in the Github issue, and
after all
that my implementation may be reviewed as a sketch of the specific software
changes necessary.

Regards,
James


[0]:
https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks
[1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
[2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @
2.10GHz
[3]:
https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161
[4]: Marco Falke is due credit for this point
[5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc
[6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/46b25dd8/attachment.html>

------------------------------

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


End of bitcoin-dev Digest, Vol 47, Issue 6
******************************************