Christophe Biocca [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-11-06 to 2015-09-11
💬 Posted a total of 33 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:25:20

- reply

📅 Original date posted:2014-08-19
📝 Original message:If your threat model is passive listeners, it seems to me that simply
establishing a symmetric key for each connection at handshake time
using diffie-hellman is all you need. No public private crypto needed
at all.
The whole thing seems like a bit of security theater unfortunately.
The kind of attacker that can pull off widespread passive listening is
probably able and willing to do active MITM. It's not a huge
incremental cost.
Instead, those users that do have a need for security should probably
connect to the network using Tor or I2P, which can give much better
security guarantees than anything being discussed here.
On Tue, Aug 19, 2014 at 12:58 PM, Angel Leon <gubatron at gmail.com> wrote:
> "
> I suggest that Bitcoin Core should generate a public/private key pair and
> share the public one with peers."
>
> I've not read the p2p protocol of Bitcoin core, but I suppose the initial
> handshake between 2 peers would be the ideal place to exchange a public
> keys.
>
> would it make sense to generate a new random pair of keys per each peer you
> connect to?
> then each subsequent message to every peer gets encrypted differently,
> keeping each conversation isolated from each other encryption-speaking.
>
> These keys would have nothing to do with your wallet, they're just to
> encrypt any further communication between peers post-handshake. Would that
> be of any use to "This could provide privacy and integrity but not
> autentication."?
>
> http://twitter.com/gubatron
>
>
> On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
>>
>> On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
>> <justusranvier at riseup.net> wrote:
>> > If that's not acceptable, even using TLS with self-signed certificates
>> > would be an improvement.
>>
>> TLS is a huge complex attack surface, any use of it requires an
>> additional dependency with a large amount of difficult to audit code.
>> TLS is trivially DOS attacked and every major/widely used TLS
>> implementation has had multiple memory disclosure or remote execution
>> vulnerabilities even in just the last several years.
>>
>> We've dodged several emergency scale vulnerabilities by not having TLS.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:18:53

- reply

📅 Original date posted:2014-04-20
📝 Original message:If you absolutely want a name for some small unit (which may be
valuable, not knocking that part of the idea), please use anything
other than "bits", which is already a massively overloaded term that
will confuse the hell out of people:
Harddrive costs measured in "bits per gigabyte"?
An itunes movie download that costs 200,000 bits and takes 804.2
megabytes of space?
Or a 10-megabit internet connection costing 10,000,000 bits per month?
It's especially bad given that bitcoin will likely be adopted first
for online use, where the competing (and more recognized) meaning of
"bit" is most prevalent.
Not to mention the overlap within bitcoin itself, with people already
using "millibits" in conversation as a shorthand for mBTC. Hence one
new "bit" is exactly 1/1000 of the old "millibit".
Make something up if you have to, or just use satoshis.
On Sun, Apr 20, 2014 at 10:28 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> People on this list are mostly engineers who have no problem dealing with
> magnitudes and have rather limited empathy for people who have a problem
> with them.
> They also tend to think, that because they invented money 2.0 they would not
> need to care of finance’s or people’s current customs.
>
> The importance of their decisions in these questions will fade as people
> already use wallets other than the core.
>
> Bring this particular discussion elsewhere, to the wallet developer.
>
> BTW the topic was discussed here several times, you have my support and Jeff
> Garzik’s.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:
>
> The average person is not going to be confident that the prefix they
> are using is the correct one,
>
>
> The use of any 'prefix' is one of choice and entirely unnecessary, and there
> are already established 'divisions' in u/mBTC for those that feel they need
> to use such things.
>
> people WILL send 1000x more or less than
> intended if we go down this road,
>
>
> Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3
> dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not
> once in 20 years has anyone ever 'sent' more or less than intended - oh,
> they've 'intended' to underpay just fine, but never *unintended*.
>
> I propose that users are offered a preference to denominate the
> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
> equals one million bits (bits) and one bit equals 100 satoshis.
>
>
> I propose that for people unable to understand what a bitcoin is, they can
> just use satoshi's and drop this entire proposal.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>