📅 Original date posted:2012-05-16
📝 Original message:On Wed, May 16, 2012 at 12:46 PM, Mike Hearn <mike at plan99.net> wrote:
> Thanks for getting this started.
>
> With regards to the specific proposal, I don't believe it's the best option
> and still plan to eventually implement the original design outlined more
> than a year ago in this thread:
>
> https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
>
> Namely that you use a new protocol command to set a Bloom filter on a
> connection. Only transactions matching that filter will appear in relayed
> inventory. Blocks that are requested will arrive as a header plus
> transaction/merkle branch pairs. Clients are expected to maintain and track
> the block chain as per usual, but instead of downloading the whole chain and
> then dropping the irrelevant transactions, that filtering is done server
> side. By strengthening or weakening the Bloom filters you can choose your
> preferred point on the privacy/bandwidth-usage spectrum. It is a fairly
> simple change to the Satoshi and BitcoinJ codebases but still allows clients
> to gain confidence in their balance by examining the chain, and this is true
> even in the presence of a hijacked internet connection (you can't trust
> pending transactions that way, but you can still trust confirmed
> transactions).
Makes sense.
In an idealized model of a client as a set of private keys, they will
want to (a) notice new activity on these keys, (b) notice increased
confidence on existing transactions with those keys [confirmations],
and (c) be able to submit to the network new transactions. Your
proposal covers those bases, I believe.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 10:08:46
in reply to nevent1q…29fx
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 10:08:46Event JSON
{
"id": "d24b0e7991cb0aad8b174b6d74bac2d5cd062f66e95d9d0b81868123d861dd14",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686132526,
"kind": 1,
"tags": [
[
"e",
"c62092b3795e0d3f4501bc78e2345c6bf370499fb688709c13783f41a7bae2f2",
"",
"root"
],
[
"e",
"7136268e4425e2c3306dcca008ffdbbb101bc902553519bbbce35702fae942ae",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 Original date posted:2012-05-16\n📝 Original message:On Wed, May 16, 2012 at 12:46 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e Thanks for getting this started.\n\u003e\n\u003e With regards to the specific proposal, I don't believe it's the best option\n\u003e and still plan to eventually implement the original design outlined more\n\u003e than a year ago in this thread:\n\u003e\n\u003e https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285\n\u003e\n\u003e Namely that you use a new protocol command to set a Bloom filter on a\n\u003e connection. Only transactions matching that filter will appear in relayed\n\u003e inventory. Blocks that are requested will arrive as a header plus\n\u003e transaction/merkle branch pairs. Clients are expected to maintain and track\n\u003e the block chain as per usual, but instead of downloading the whole chain and\n\u003e then dropping the irrelevant transactions, that filtering is done server\n\u003e side. By strengthening or weakening the Bloom filters you can choose your\n\u003e preferred point on the privacy/bandwidth-usage spectrum. It is a fairly\n\u003e simple change to the Satoshi and BitcoinJ codebases but still allows clients\n\u003e to gain confidence in their balance by examining the chain, and this is true\n\u003e even in the presence of a hijacked internet connection (you can't trust\n\u003e pending transactions that way, but you can still trust confirmed\n\u003e transactions).\n\nMakes sense.\n\nIn an idealized model of a client as a set of private keys, they will\nwant to (a) notice new activity on these keys, (b) notice increased\nconfidence on existing transactions with those keys [confirmations],\nand (c) be able to submit to the network new transactions. Your\nproposal covers those bases, I believe.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "3f95152b456a1a0e7c75e5347e0314f6d321a39378b6b92b4d0d0cef41ec4f2566951ee9354ba7da9c386f2064a5e508acbc4f219eb8989ae603e9236220e234"
}