📅 Original date posted:2019-04-03
📝 Original message:James,
You might be interested by my work which is currently used in production,
without any change to bitcoin core.
I properly explain how to verify the utxoset independently.
https://github.com/btcpayserver/btcpayserver-docker/blob/master/contrib/FastSync/README.md
People are using it, since I get around 10 download a day.
What can be done to help at Bitcoin Core level is actually very minimal.
First, instead of asking signers of by UTXOSet to sign the utxoset hash
from gettxoutsetinfo, I ask them to sign the hash of the tarball of my UTXO
Set.
The reason is that it is currently impossible to stop BitcoinD on a
specific block then asking the serialized hash of the UTXO Set.
So instead, a verifier download the tarball (300 blocks + utxoset at
specific height), sync to the latest block, then compare the
gettxoutsetinfo of the newly synched node with another trusted node. If it
match, the verifier sign the tarball.
I create a new utxoset snapshot every 6 months, so people have time to
verify it and add their signatures. (Approximately once every bitcoin core
release)
The easiest thing that could be done at Bitcoin Core level does not require
any code change, but a change in the release process.
The new process would be to ask to the gitian signers to not only build the
source themselves, but also verify a tarball following the procedure I
explain in the link above.
More complicated solution like signing the serialized utxoset itself, while
possible, would require bothersome code changes.
Nicolas,
On Wed, Apr 3, 2019 at 9:25 AM <
bitcoin-dev-request at lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at 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 at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at 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 at 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 at tutanota.com>
> To: <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?
> Message-ID: <LbTxyE4--3-1 at 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 at protonmail.com>
> To: "nathanw at tutanota.com" <nathanw at tutanota.com>, Bitcoin Protocol
> Discussion <bitcoin-dev at 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 at 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 at gmail.com>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: [bitcoin-dev] assumeutxo and UTXO snapshots
> Message-ID:
> <CAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=
> XwngA at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 47, Issue 6
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/7a1cb47c/attachment-0001.html>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-07 18:17:31
in reply to nevent1q…ux5j
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-07 18:17:31Event JSON
{
"id": "feaecac0388abccae26573a911289ec968fede73805f15657de45b2d9c5d04bc",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686161851,
"kind": 1,
"tags": [
[
"e",
"d51423b816a5e272cd7ecbf1b35efedda8fc13cec521b06aa380e4798704e650",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2019-04-03\n📝 Original message:James,\n\nYou might be interested by my work which is currently used in production,\nwithout any change to bitcoin core.\n\nI properly explain how to verify the utxoset independently.\n\nhttps://github.com/btcpayserver/btcpayserver-docker/blob/master/contrib/FastSync/README.md\n\n\nPeople are using it, since I get around 10 download a day.\nWhat can be done to help at Bitcoin Core level is actually very minimal.\n\nFirst, instead of asking signers of by UTXOSet to sign the utxoset hash\nfrom gettxoutsetinfo, I ask them to sign the hash of the tarball of my UTXO\nSet.\n\nThe reason is that it is currently impossible to stop BitcoinD on a\nspecific block then asking the serialized hash of the UTXO Set.\n\nSo instead, a verifier download the tarball (300 blocks + utxoset at\nspecific height), sync to the latest block, then compare the\ngettxoutsetinfo of the newly synched node with another trusted node. If it\nmatch, the verifier sign the tarball.\n\nI create a new utxoset snapshot every 6 months, so people have time to\nverify it and add their signatures. (Approximately once every bitcoin core\nrelease)\n\nThe easiest thing that could be done at Bitcoin Core level does not require\nany code change, but a change in the release process.\n\nThe new process would be to ask to the gitian signers to not only build the\nsource themselves, but also verify a tarball following the procedure I\nexplain in the link above.\n\nMore complicated solution like signing the serialized utxoset itself, while\npossible, would require bothersome code changes.\n\nNicolas,\n\nOn Wed, Apr 3, 2019 at 9:25 AM \u003c\nbitcoin-dev-request at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Send bitcoin-dev mailing list submissions to\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\n\u003e To subscribe or unsubscribe via the World Wide Web, visit\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e or, via email, send a message with subject or body 'help' to\n\u003e bitcoin-dev-request at lists.linuxfoundation.org\n\u003e\n\u003e You can reach the person managing the list at\n\u003e bitcoin-dev-owner at lists.linuxfoundation.org\n\u003e\n\u003e When replying, please edit your Subject line so it is more specific\n\u003e than \"Re: Contents of bitcoin-dev digest...\"\n\u003e\n\u003e\n\u003e Today's Topics:\n\u003e\n\u003e 1. BIP: Bitcoin Integrated Address Feature? (nathanw at tutanota.com)\n\u003e 2. Re: BIP: Bitcoin Integrated Address Feature? (htimSxelA)\n\u003e 3. assumeutxo and UTXO snapshots (James O'Beirne)\n\u003e\n\u003e\n\u003e ----------------------------------------------------------------------\n\u003e\n\u003e Message: 1\n\u003e Date: Tue, 2 Apr 2019 18:53:11 +0200 (CEST)\n\u003e From: \u003cnathanw at tutanota.com\u003e\n\u003e To: \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?\n\u003e Message-ID: \u003cLbTxyE4--3-1 at tutanota.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e To whom it may concern,\n\u003e\n\u003e I believe a missing feature in Bitcoin is the ability to have an\n\u003e \"integrated address\", where the address resolves into a Bitcoin address,\n\u003e and also a transaction message or some other kind of identifier.\n\u003e\n\u003e By having this feature we could enhance the security of exchange\n\u003e cold-wallet systems, by allowing them to easily receive all payments to a\n\u003e single address from an infinite number of customers. We would also greatly\n\u003e simplify the process of setting up and managing exchange cold-wallet\n\u003e systems, because we would eliminate the \"sweeping\" step required to move\n\u003e multiple customer deposits from a hot address into a single cold address.\n\u003e\n\u003e Although it would be nice to have all customers deposit directly into cold\n\u003e addresses, this quickly becomes impractical when large amounts of customers\n\u003e begin to use exchange wallets as their personal web-wallet, frequently\n\u003e depositing and withdrawing without trading action. You end up needing to\n\u003e have a staff member moving funds away from cold deposit addresses as a full\n\u003e time job - if you wish to handle customer funds in a completely secure\n\u003e manner.\n\u003e\n\u003e Thus we see that most exchanges now use the hot-deposit system, where\n\u003e customers deposit into a hot address that is then automatically swept into\n\u003e a singular cold address, by a service which holds customers private keys\n\u003e online. You can observe this service at work simply by making a deposit to\n\u003e most major exchanges (including the largest exchange Binance), as you will\n\u003e see the funds quickly being \"swept\" to their cold wallet address in a\n\u003e manner which heavily suggests automation by a program which possesses\n\u003e private keys to the address you are sending funds to. This means there is\n\u003e always the danger of a sophisticated hacker being able to capture private\n\u003e keys to customer deposit addresses (as they are clearly being held online).\n\u003e An integrated address would allow all exchanges using this automated\n\u003e hot-deposit service to easily switch to a far more secure alternative of\n\u003e having all customers depositing directly into their singular cold wallet\n\u003e address.\n\u003e\n\u003e There are several other more minor advantages such a feature would have,\n\u003e including:\n\u003e - Lower fees for exchanges (which could be passed onto customers), by\n\u003e reducing a transaction step out of the deposit-to-withdrawal flow.\n\u003e - Less need for large rescans after loading huge amounts of customer\n\u003e addresses into client software.\n\u003e - Exchanges can more easily provision deposit addresses to new customers\n\u003e in a secure manner, by simply generating a hex or other value, creating an\n\u003e integrated address from the cold wallet address, and then providing this to\n\u003e the customer.\n\u003e - By providing a singular cold address for exchanges publicly, customers\n\u003e can more easily verify that no man-in-the-middle has given them an\n\u003e incorrect address to deposit to.\n\u003e The integrated address could work by combining the Bitcoin address\n\u003e together with some kind of hex or other value, allowing users to choose the\n\u003e amount they wish to deposit themselves, but ensuring their deposits are\n\u003e uniquely trackable.\n\u003e\n\u003e I'm not sure if some kind of functionality already exists in BTC, as I\n\u003e haven't been able to find it. If not, can I submit a proposal to implement\n\u003e this? This feature would be a godsend to all exchange developers if it was\n\u003e widely accepted.\n\u003e\n\u003e Thanks for your time.\n\u003e Regards,\n\u003e\n\u003e Nathan Worsley\n\u003e CTO - LocalCoinSwap.Com\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003c\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/400c1e1b/attachment-0001.html\n\u003e \u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 2\n\u003e Date: Tue, 02 Apr 2019 20:01:34 +0000\n\u003e From: htimSxelA \u003chtimsxela at protonmail.com\u003e\n\u003e To: \"nathanw at tutanota.com\" \u003cnathanw at tutanota.com\u003e, Bitcoin Protocol\n\u003e Discussion \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] BIP: Bitcoin Integrated Address Feature?\n\u003e Message-ID:\n\u003e\n\u003e \u003cwtbAF1FAGePDAkY3xkqANuFJtAhEXvz0JeGWnc_OZcGEyFQb-1B590I3IbwtW2FBivur0yONbSQtxaWqiQTJeoDdadivtbGkWwJnLnnzQQE=@\n\u003e protonmail.com\u003e\n\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e Hello,\n\u003e\n\u003e I see two immediate issues with this:\n\u003e 1. Increased resource requirements per transaction\n\u003e 2. Embedding identifying information into the blockchain is generally bad\n\u003e for privacy\n\u003e\n\u003e It may help your case to provide some technical details of how you'd like\n\u003e to see this implemented, but without overcoming the issues mentioned above\n\u003e I think this proposal will be a very tough sell.\n\u003e\n\u003e \u003e ...this quickly becomes impractical when large amounts of customers\n\u003e begin to use exchange wallets as their personal web-wallet, frequently\n\u003e depositing and withdrawing without trading action. You end up needing to\n\u003e have a staff member moving funds away from cold deposit addresses as a full\n\u003e time job - if you wish to handle customer funds in a completely secure\n\u003e manner.\n\u003e\n\u003e I am not sure if I see how this issue is solved by your proposal.\n\u003e Assumedly, a human will still need to manually approve cold-wallet\n\u003e withdrawals in order to maintain security. So it seems to me that removing\n\u003e the 'hot-wallet' component of the backend would only amplify the need for\n\u003e human interaction.\n\u003e\n\u003e I assume you are familiar with hierarchical deterministic wallets? They\n\u003e can allow an exchange to assign/identify user deposits based on address\n\u003e derivation path. Keys for deposit addresses can be kept offline if wanted,\n\u003e and a proper implementation of an HD wallet system should also remove the\n\u003e need for rescans of user deposit addresses.\n\u003e\n\u003e There is also a functionality built into Bitcoin that allows a user to\n\u003e prove that they own the private keys to some address: signing an agreed\n\u003e upon message using the private key that controls that address.\n\u003e Unfortunately I don't think this is a workable solution for you, since the\n\u003e majority of modern wallet software does not include this feature-- but\n\u003e perhaps worth mentioning nonetheless.\n\u003e\n\u003e Best,\n\u003e Alex\n\u003e\n\u003e ??????? Original Message ???????\n\u003e On Tuesday, April 2, 2019 9:53 AM, Nathan Worsley via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \u003e To whom it may concern,\n\u003e \u003e\n\u003e \u003e I believe a missing feature in Bitcoin is the ability to have an\n\u003e \"integrated address\", where the address resolves into a Bitcoin address,\n\u003e and also a transaction message or some other kind of identifier.\n\u003e \u003e\n\u003e \u003e By having this feature we could enhance the security of exchange\n\u003e cold-wallet systems, by allowing them to easily receive all payments to a\n\u003e single address from an infinite number of customers. We would also greatly\n\u003e simplify the process of setting up and managing exchange cold-wallet\n\u003e systems, because we would eliminate the \"sweeping\" step required to move\n\u003e multiple customer deposits from a hot address into a single cold address.\n\u003e \u003e\n\u003e \u003e Although it would be nice to have all customers deposit directly into\n\u003e cold addresses, this quickly becomes impractical when large amounts of\n\u003e customers begin to use exchange wallets as their personal web-wallet,\n\u003e frequently depositing and withdrawing without trading action. You end up\n\u003e needing to have a staff member moving funds away from cold deposit\n\u003e addresses as a full time job - if you wish to handle customer funds in a\n\u003e completely secure manner.\n\u003e \u003e\n\u003e \u003e Thus we see that most exchanges now use the hot-deposit system, where\n\u003e customers deposit into a hot address that is then automatically swept into\n\u003e a singular cold address, by a service which holds customers private keys\n\u003e online. You can observe this service at work simply by making a deposit to\n\u003e most major exchanges (including the largest exchange Binance), as you will\n\u003e see the funds quickly being \"swept\" to their cold wallet address in a\n\u003e manner which heavily suggests automation by a program which possesses\n\u003e private keys to the address you are sending funds to. This means there is\n\u003e always the danger of a sophisticated hacker being able to capture private\n\u003e keys to customer deposit addresses (as they are clearly being held online).\n\u003e An integrated address would allow all exchanges using this automated\n\u003e hot-deposit service to easily switch to a far more secure alternative of\n\u003e having all customers depositing directly into their singular cold wallet\n\u003e address.\n\u003e \u003e\n\u003e \u003e There are several other more minor advantages such a feature would have,\n\u003e including:\n\u003e \u003e - Lower fees for exchanges (which could be passed onto customers), by\n\u003e reducing a transaction step out of the deposit-to-withdrawal flow.\n\u003e \u003e - Less need for large rescans after loading huge amounts of customer\n\u003e addresses into client software.\n\u003e \u003e - Exchanges can more easily provision deposit addresses to new customers\n\u003e in a secure manner, by simply generating a hex or other value, creating an\n\u003e integrated address from the cold wallet address, and then providing this to\n\u003e the customer.\n\u003e \u003e - By providing a singular cold address for exchanges publicly, customers\n\u003e can more easily verify that no man-in-the-middle has given them an\n\u003e incorrect address to deposit to.\n\u003e \u003e\n\u003e \u003e The integrated address could work by combining the Bitcoin address\n\u003e together with some kind of hex or other value, allowing users to choose the\n\u003e amount they wish to deposit themselves, but ensuring their deposits are\n\u003e uniquely trackable.\n\u003e \u003e\n\u003e \u003e I'm not sure if some kind of functionality already exists in BTC, as I\n\u003e haven't been able to find it. If not, can I submit a proposal to implement\n\u003e this? This feature would be a godsend to all exchange developers if it was\n\u003e widely accepted.\n\u003e \u003e\n\u003e \u003e Thanks for your time.\n\u003e \u003e\n\u003e \u003e Regards,\n\u003e \u003e\n\u003e \u003e Nathan Worsley\n\u003e \u003e CTO - LocalCoinSwap.Com\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003c\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/ade34235/attachment-0001.html\n\u003e \u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Message: 3\n\u003e Date: Tue, 2 Apr 2019 16:43:11 -0400\n\u003e From: \"James O'Beirne\" \u003cjames.obeirne at gmail.com\u003e\n\u003e To: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: [bitcoin-dev] assumeutxo and UTXO snapshots\n\u003e Message-ID:\n\u003e \u003cCAPfvXf+JS6ZhXUieWVxiaNa4uhhWwafCk3odMKy5F_yi=\n\u003e XwngA at mail.gmail.com\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e Hi,\n\u003e\n\u003e I'd like to discuss assumeutxo, which is an appealing and simple\n\u003e optimization in the spirit of assumevalid[0].\n\u003e\n\u003e # Motivation\n\u003e\n\u003e To start a fully validating bitcoin client from scratch, that client\n\u003e currently\n\u003e needs to perform an initial block download. To the surprise of no one, IBD\n\u003e takes a linear amount time based on the length of the chain's history. For\n\u003e clients running on modest hardware under limited bandwidth constraints,\n\u003e say a mobile device, completing IBD takes a considerable amount of time\n\u003e and thus poses serious usability challenges.\n\u003e\n\u003e As a result, having fully validating clients run on such hardware is rare\n\u003e and\n\u003e basically unrealistic. Clients with even moderate resource constraints\n\u003e are encouraged to rely on the SPV trust model. Though we have promising\n\u003e improvements to existing SPV modes pending deployment[1], it's worth\n\u003e thinking about a mechanism that would allow such clients to use trust\n\u003e models closer to full validation.\n\u003e\n\u003e The subject of this mail is a proposal for a complementary alternative to\n\u003e SPV\n\u003e modes, and which is in the spirit of an existing default, `assumevalid`. It\n\u003e may\n\u003e help modest clients transact under a security model that closely resembles\n\u003e full validation within minutes instead of hours or days.\n\u003e\n\u003e # assumeutxo\n\u003e\n\u003e The basic idea is to allow nodes to initialize using a serialized version\n\u003e of the\n\u003e UTXO set rendered by another node at some predetermined height. The\n\u003e initializing node syncs the headers chain from the network, then obtains\n\u003e and\n\u003e loads one of these UTXO snapshots (i.e. a serialized version of the UTXO\n\u003e set\n\u003e bundled with the block header indicating its \"base\" and some other\n\u003e metadata).\n\u003e\n\u003e Based upon the snapshot, the node is able to quickly reconstruct its\n\u003e chainstate,\n\u003e and compares a hash of the resulting UTXO set to a preordained hash\n\u003e hard-coded\n\u003e in the software a la assumevalid. This all takes ~23 minutes, not\n\u003e accounting for\n\u003e download of the 3.2GB snapshot[2].\n\u003e\n\u003e The node then syncs to the network tip and afterwards begins a simultaneous\n\u003e background validation (i.e., a conventional IBD) up to the base height of\n\u003e the\n\u003e snapshot in order to achieve full validation. Crucially, even while the\n\u003e background validation is happening the node can validate incoming blocks\n\u003e and\n\u003e transact with the benefit of the full (assumed-valid) UTXO set.\n\u003e\n\u003e Snapshots could be obtained from multiple separate peers in the same manner\n\u003e as\n\u003e block download, but I haven't put much thought into this. In concept it\n\u003e doesn't\n\u003e matter too much where the snapshots come from since their validity is\n\u003e determined via content hash.\n\u003e\n\u003e # Security\n\u003e\n\u003e Obviously there are some security implications due consideration. While\n\u003e this\n\u003e proposal is in the spirit of assumevalid, practical attacks may become\n\u003e easier.\n\u003e Under assumevalid, a user can be tricked into transacting under a false\n\u003e history\n\u003e if an attacker convinces them to start bitcoind with a malicious\n\u003e `-assumevalid`\n\u003e parameter, sybils their node, and then feeds them a bogus chain\n\u003e encompassing\n\u003e all of the hard-coded checkpoints[3].\n\u003e\n\u003e The same attack is made easier in assumeutxo because, unlike in\n\u003e assumevalid,\n\u003e the attacker need not construct a valid PoW chain to get the victim's node\n\u003e into\n\u003e a false state; they simply need to get the user to accept a bad\n\u003e `-assumeutxo`\n\u003e parameter and then supply them an easily made UTXO snapshot containing,\n\u003e say, a\n\u003e false coin assignment.\n\u003e\n\u003e For this reason, I recommend that if we were to implement assumeutxo, we\n\u003e not\n\u003e allow its specification via commandline argument[4].\n\u003e\n\u003e Beyond this risk, I can't think of material differences in security\n\u003e relative to\n\u003e assumevalid, though I appeal to the list for help with this.\n\u003e\n\u003e # More fully validating clients\n\u003e\n\u003e A particularly exciting use-case for assumeutxo is the possibility of\n\u003e mobile\n\u003e devices functioning as fully validating nodes with access to the complete\n\u003e UTXO\n\u003e set (as an alternative to SPV models). The total resource burden needed to\n\u003e start a node\n\u003e from scratch based on a snapshot is, at time of writing, a ~(3.2GB\n\u003e + blocks_to_tip * 4MB) download and a few minutes of processing time, which\n\u003e sounds\n\u003e manageable for many mobile devices currently in use.\n\u003e\n\u003e A mobile user could initialize an assumed-valid bitcoin node within an\n\u003e hour,\n\u003e transact immediately, and complete a pruned full validation of their\n\u003e assumed-valid chain over the next few days, perhaps only doing the\n\u003e background\n\u003e IBD when their device has access to suitable high-bandwidth connections.\n\u003e\n\u003e If we end up implementing an accumulator-based UTXO scaling design[5][6]\n\u003e down\n\u003e the road, it's easy to imagine an analogous process that would allow very\n\u003e fast\n\u003e startup using an accumulator of a few kilobytes in lieu of a multi-GB\n\u003e snapshot.\n\u003e\n\u003e ---\n\u003e\n\u003e I've created a related issue at our Github repository here:\n\u003e https://github.com/bitcoin/bitcoin/issues/15605\n\u003e\n\u003e and have submitted a draft implementation of snapshot usage via RPC here:\n\u003e https://github.com/bitcoin/bitcoin/pull/15606\n\u003e\n\u003e I'd like to discuss here whether this is a good fit for Bitcoin\n\u003e conceptually. Concrete\n\u003e plans for deployment steps should be discussed in the Github issue, and\n\u003e after all\n\u003e that my implementation may be reviewed as a sketch of the specific software\n\u003e changes necessary.\n\u003e\n\u003e Regards,\n\u003e James\n\u003e\n\u003e\n\u003e [0]:\n\u003e https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks\n\u003e [1]: https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki\n\u003e [2]: as tested at height 569895, on a 12 core Intel Xeon Silver 4116 CPU @\n\u003e 2.10GHz\n\u003e [3]:\n\u003e\n\u003e https://github.com/bitcoin/bitcoin/blob/84d0fdc/src/chainparams.cpp#L145-L161\n\u003e [4]: Marco Falke is due credit for this point\n\u003e [5]: utreexo: https://www.youtube.com/watch?v=edRun-6ubCc\n\u003e [6]: Boneh, Bunz, Fisch on accumulators: https://eprint.iacr.org/2018/1188\n\u003e -------------- next part --------------\n\u003e An HTML attachment was scrubbed...\n\u003e URL: \u003c\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190402/46b25dd8/attachment.html\n\u003e \u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e End of bitcoin-dev Digest, Vol 47, Issue 6\n\u003e ******************************************\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190403/7a1cb47c/attachment-0001.html\u003e",
"sig": "68623f0354a2e5604a4c2111d898c093ee1d9a9ce5c8a5297f6099f07088fad7da3c10c5c55427819a13cb40e8a5891ae5fcec4946eea2983cafa8c39c56d3d4"
}