📅 Original date posted:2014-01-17
📝 Original message:Well, at least we don't have to worry about cache invalidation.
Ben
On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> > I must say, this shed is mighty fine looking. It'd be a great place to
> > store our bikes. But, what colour should we paint it?
>
> I think we should paint it this colour:
>
> They had uncovered what seemed to be the side of a large coloured
> globule embedded in the substance. The colour, which resembled some
> of the bands in the meteor's strange spectrum, was almost impossible
> to describe; and it was only by analogy that they called it colour
> at all. Its texture was glossy, and upon tapping it appeared to
> promise both brittle ness and hollowness. One of the professors gave
> it a smart blow with a hammer, and it burst with a nervous little
> pop. Nothing was emitted, and all trace of the thing vanished with
> the puncturing. It left behind a hollow spherical space about three
> inches across, and all thought it probable that others would be
> discovered as the enclosing substance wasted away.
>
> I think it really gets to the core of my feelings about this naming
> discussion.
>
> > How about we split the difference and go with "privacy address"? As Peter
> > notes, that's what people actually like and want. The problem with
> stealth
> > is it's got strong connotations with American military hardware and
> perhaps
> > thieves sneaking around in the night:
> >
> > https://www.google.com/search?tbm=isch&q=stealth
>
> WOW! AWESOME KICK-ASS PICS!
>
> Come to think of it, I could have called it "incognito addresses" - a
> term nice enough that Google and Firefox use it in their browsers - but
> what's done is done and any further discussion about this is just going
> to confuse the public. Remember that in the long run all this stuff will
> be hidden behind payment protocols anyway, and users *won't even know*
> that under the hood a stealth address is being used, making the name
> just a technical detail. For now though, lets use the good PR and get
> some early adopters on board.
>
> However, the term 'incognito' probably would be a good one to use within
> wallet software itself to describe what it's doing when the user clicks
> the "I want my transactions to be private" setting - there are after all
> fundemental bandwidth-privacy trade-offs in the threat model supposed by
> both prefix and bloom filters. In this instance the term isn't going to
> go away.
>
>
> Anyway, back to work: For the actual address format I strongly think we
> need to ensure that it can be upgrading in a backwards compatible way.
> This means we have to be able to add new fields - for instance if
> Gregory's ideas for different ways of doing the SPV-bait came to
> fruition. Given that "addresses" aren't something that should stay
> user-visible forever, thoughts on just making the actual data a protocol
> buffers object?
>
> Second question: Any performance figures yet on how efficient scanning
> the blockchain for matching transactions actually is? I'd like to get an
> idea soon for both desktop and smartphone wallets so we can figure out
> what kind of trade-offs users might be forced into in terms of prefix
> length.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/f1767ee8/attachment.html>;
Ben Davenport [ARCHIVE] /
npub1qa…wrrvp
2023-06-07 15:11:49
in reply to nevent1q…rqne
Author Public Key
npub1qa67gm2kyrqt7sldhzeppu5hq2ajx80y8f5rs9z6f34pjce03lms4wrrvpPublished at
2023-06-07 15:11:49Event JSON
{
"id": "b6080b557ebc933b58fd2c34dec684f9270ec3911694e8814fc0803abe97245c",
"pubkey": "0775e46d5620c0bf43edb8b210f29702bb231de43a6838145a4c6a19632f8ff7",
"created_at": 1686150709,
"kind": 1,
"tags": [
[
"e",
"6b79d8c7bec3dc6952db91cc68d0510d9897c37dcf58a24d8e2f4288fe42525c",
"",
"root"
],
[
"e",
"e7d48d10067559845d2d1f4d929a457cbb215fc20f08f2dca18e3370609ff7ea",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-01-17\n📝 Original message:Well, at least we don't have to worry about cache invalidation.\n\nBen\n\n\nOn Fri, Jan 17, 2014 at 6:46 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:\n\u003e \u003e I must say, this shed is mighty fine looking. It'd be a great place to\n\u003e \u003e store our bikes. But, what colour should we paint it?\n\u003e\n\u003e I think we should paint it this colour:\n\u003e\n\u003e They had uncovered what seemed to be the side of a large coloured\n\u003e globule embedded in the substance. The colour, which resembled some\n\u003e of the bands in the meteor's strange spectrum, was almost impossible\n\u003e to describe; and it was only by analogy that they called it colour\n\u003e at all. Its texture was glossy, and upon tapping it appeared to\n\u003e promise both brittle ness and hollowness. One of the professors gave\n\u003e it a smart blow with a hammer, and it burst with a nervous little\n\u003e pop. Nothing was emitted, and all trace of the thing vanished with\n\u003e the puncturing. It left behind a hollow spherical space about three\n\u003e inches across, and all thought it probable that others would be\n\u003e discovered as the enclosing substance wasted away.\n\u003e\n\u003e I think it really gets to the core of my feelings about this naming\n\u003e discussion.\n\u003e\n\u003e \u003e How about we split the difference and go with \"privacy address\"? As Peter\n\u003e \u003e notes, that's what people actually like and want. The problem with\n\u003e stealth\n\u003e \u003e is it's got strong connotations with American military hardware and\n\u003e perhaps\n\u003e \u003e thieves sneaking around in the night:\n\u003e \u003e\n\u003e \u003e https://www.google.com/search?tbm=isch\u0026q=stealth\n\u003e\n\u003e WOW! AWESOME KICK-ASS PICS!\n\u003e\n\u003e Come to think of it, I could have called it \"incognito addresses\" - a\n\u003e term nice enough that Google and Firefox use it in their browsers - but\n\u003e what's done is done and any further discussion about this is just going\n\u003e to confuse the public. Remember that in the long run all this stuff will\n\u003e be hidden behind payment protocols anyway, and users *won't even know*\n\u003e that under the hood a stealth address is being used, making the name\n\u003e just a technical detail. For now though, lets use the good PR and get\n\u003e some early adopters on board.\n\u003e\n\u003e However, the term 'incognito' probably would be a good one to use within\n\u003e wallet software itself to describe what it's doing when the user clicks\n\u003e the \"I want my transactions to be private\" setting - there are after all\n\u003e fundemental bandwidth-privacy trade-offs in the threat model supposed by\n\u003e both prefix and bloom filters. In this instance the term isn't going to\n\u003e go away.\n\u003e\n\u003e\n\u003e Anyway, back to work: For the actual address format I strongly think we\n\u003e need to ensure that it can be upgrading in a backwards compatible way.\n\u003e This means we have to be able to add new fields - for instance if\n\u003e Gregory's ideas for different ways of doing the SPV-bait came to\n\u003e fruition. Given that \"addresses\" aren't something that should stay\n\u003e user-visible forever, thoughts on just making the actual data a protocol\n\u003e buffers object?\n\u003e\n\u003e Second question: Any performance figures yet on how efficient scanning\n\u003e the blockchain for matching transactions actually is? I'd like to get an\n\u003e idea soon for both desktop and smartphone wallets so we can figure out\n\u003e what kind of trade-offs users might be forced into in terms of prefix\n\u003e length.\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 0000000000000001c9b372ed519ecc6d41c10b42a7457d1ca5acd560a535596b\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e CenturyLink Cloud: The Leader in Enterprise Cloud Services.\n\u003e Learn Why More Businesses Are Choosing CenturyLink Cloud For\n\u003e Critical Workloads, Development Environments \u0026 Everything In Between.\n\u003e Get a Quote or Start a Free Trial Today.\n\u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=119420431\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140117/f1767ee8/attachment.html\u003e",
"sig": "5d708bcb3af759299df6baeb9a0f0325177e74952495ecf672f93a0d3d50e51654edb066a7889fc47bef3fafe1f5094c586b76cb2801655e3e66f3ec566e125e"
}