nullius [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-12-25 to 2018-01-20
💬 Posted a total of 10 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:09:52

- reply

📅 Original date posted:2018-01-20
📝 Original message:On 2018-01-17 at 22:31:52 +0000, Jefferson Carpenter
<jeffersoncarpenter2 at gmail.com> wrote:
>Bitcoin's difficulty will be maxed out within about 400 years, by
>Moore's law.
On 2018-01-19 at 20:54:52 +0000, Jefferson Carpenter
<jeffersoncarpenter2 at gmail.com> wrote:
>In other words, max difficulty for SHA256 might be significantly faster
>than forcing the first 256 bits of a SHA512 hash...
“Moore’s law” is not a law of nature. Indeed, chipmakers began bumping
up against the limitations of *actual* natural laws about 15—20 years
ago. That is why instead of increasing core clock, they play the tricks
which opened the way for Meltdown and Spectre. Feature size, and thus
transistor counts, will soon enough run into physical limitations, too.
But the scenario you describe does not even require such a discussion.
2^256 work for brute force is on the order of 10^77 hashes. For the
number of atoms in the observable universe, I’ve seen estimates ranging
from 10^78 to 10^82. Thus, you are suggesting that within 400 years,
computers will be able to compute one hash for every myriad of atoms in
the observable universe—perhaps one hash for every *ten* atoms.
Moreover, you suggest that twenty-fourth century computers will do this
fast enough to meet Bitcoin’s ten-minute target rate.
Such a proposition bypasses science, leaps over science fiction, and
lands in the realm of religion. Perhaps a deity could do this—using a
computer made of other than matter, powered by other than energy.
Humans will *never* be capable of such a feat: Not now, and not in a
billion years. Certainly not a mere four centuries hence!
(I do not here positively exclude the possibility, however slim, that
mathematical breakthroughs may yield a preimage attack on SHA-256 which
is significantly better than bruteforce. I *do* positively declare it
impossible that Earth-beings will ever be capable of performing 2^256
work. Or even 2^128 work, for that matter.)
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180120/a113bafd/attachment.sig>

2023-06-07 18:09:46

- reply

📅 Original date posted:2018-01-15
📝 Original message:On 2018-01-15 at 22:47:54 +0000, Enrique Arizón Benito
<enrique.arizonbenito at gmail.com> wrote:
>Hi all,
>
>just new to the list and curious to know if next proposal (or similar)
>for reducing mining-power consumption has already been discussed.
>
>The objective is to reduce the power consumption required while keeping
>the network safe and the miners "motivated" and cooperative to continue
>mining:
>
>The global idea is to introduce the concept of "next-coinbase" for
>miners. This will work something like as follow:
>
>- Any miner submitting a block will submit the "next-coinbase" for any
>new block mined by itself. (This address can be the same one or
>different from the just mined block). The miner keeps the private key
>associated with the "next-coinbase" secret.
>
>- The consensus algorithm will add next checks:
> A hash from, for example, the just mined block and the previous one,
>will have to match up to N bits for the next "next-coinbase" from the
>next block to be valid.
>
> That means that for the next block only 1/2^N bitcoin addresses will
>be accepted from the previously submitted "next-coinbase" list.
>
>Since the last previous block hash can be considered random, miners
>know in advance whether they will be able to participate or not in the
>next block depending on the just submited "next-coinbase". And since
>the "punishment" is distributed uniformely random to all miners no one
>has any advantage over the other. But the global miner netwok will
>consume much less power.
>
>A detail rest: New miners are not allowed in such scheme so next
>addition is needed:
>
>- A miner with no previous "next-coinbase" will need to first mine an
>special block, "new-miner-block", that instead of normal transactions
>will register the new miner and submit a "next-coinbase". This special
>block will not be rewarded with new bitcoins. The only reward will be
>the permission to mine in following blocks. No reward is applied so
>only new miners wanting to "enter" the mining network are expected to
>create such block.
Observation: This totally destroys Bitcoin’s transaction-ordering
security. A “51% attack” could be executed by any miner who has >50% of
the hashpower *proportionate to miners who are allowed to mine a
particular block*, rather than >50% of *global* hashpower. (I infer
that this could be done retroactively, and wave my hands over some of
the details since you did not talk about reorgs.) The same applies as
for attacks requiring 33% or 25% of total hashpower.
Potential attack, assuming that N *must* be based partly or wholly on
the existing set of “next-coinbase” addresses: A large miner could
gradually push N higher, by progressively committing new “next-coinbase”
addresses which differ in the next bit for all previously seen
combinations of bits. Large miners would have a vast advantage over
small miners, insofar as deliberately incrementing N by one more bit
could only be done by a miner who creates 2^(N+1) blocks (= 2 * 2^N).
By such means, it may be possible for a very large miner to eventually
lock out all other miners altogether, and monopolize all Bitcoin mining.
Now, questions:
How is N determined? By a wave of the hands?
What part of which block hash is matched against N bits? You were quite
unclear about this, and other important details. (Much of what I say
here is based on assumptions and inferences necessary to fill in the
blanks.)
How, exactly, are reorgs handled?
How does this interact with the difficulty adjustment algorithm?
Indeed, how is difficulty determined at all under your scheme?
What happens to coinbase fees from a “new-miner-block”? The way I read
your scheme, the “new-miner-block” must necessarily have no payout
whatsoever. But you discuss only “new bitcoins”, which are a
diminishing portion of the block reward, and will eventually reach zero.
Coinbase from fees must go somewhere; but under your scheme, a “new
miner” has no payable address.
What if no existing “next-coinbase” address matches? Is N constrained
to be sufficiently short that a match is guaranteed from the existing
set, then that makes it trivial for large mining farms to collect
addresses and further dominate (or even monopolize) the network in the
attack described above. If it isn’t, then the network could suddenly
halt when nobody is allowed to mine the next block; and that would
enable *this* attack:
What stops a malicious miner (including a “new miner” creating a
“new-miner block”) from deliberately working to create a block with a
hash which does not have N bits matching any of the existing
“next-coinbase” addresses? Contra what you say, block hashes can’t be
“considered random”. Indeed, partial preimage bruteforcing of block
hashes is the entire basis of mining POW.
Asking here more generally than as for the attack described above, what
stops mining farms with large hashpower from submitting many different
“next-coinbase” addresses in many different blocks? If N be small, then
it should be feasible for a large mining farm to eventually register a
set of “next-coinbase” addresses which match any N. **This increases
mining centralization.** If N be large, then this creates the
possibility (or raises the probability) that no address will match, and
nobody will be allowed to mine the next block.
How could miner anonymity be preserved under a scheme whereby each
“next-coinbase” address can be linked to a previous “next-coinbase”
address? The only way to start fresh would be with a prohibitively
expensive no-payout block. Mining can be totally anonymous at present,
and must so remain. Miners are only identified by certain information
they choose to put in a block header, which they could choose to change
or omit—or by IP address, which is trivially changed and is never a
reliable identifier.
How does this even save electricity, when there is much mining equipment
(especially on large mining farms) which cannot be easily shut down and
restarted? (Allegedly, this is one reason why some big miners
occasionally mine empty blocks.) Though I suppose that difficulty would
drop by unspecified means.
Further observations:
This scheme drastically increases the upfront investment required for a
new miner to start mining. To mine even one new block all by oneself,
without a pool, already requires a huge investment. Add to that the
uncompensated energy cost of mining that first block with *no* payout,
and I expect that the bar would be prohibitive to almost all new
entrants. Mining costs and incentives are delicately balanced by the
design of the network. Whereas incumbents are much favoured by your
scheme, further increasing miner centralization. Large incumbents could
also use this to produce a mining permissions market, by selling the
private keys to committed “next-coinbase” addresses.
I have not even tried to imagine what oddball attacks might be possible
for any miner with sufficient hashpower to deliberately cause a small
reorg.
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180116/7325d4d4/attachment-0001.sig>

2023-06-07 18:09:44

- reply

📅 Original date posted:2018-01-13
📝 Original message:Preface: As a longstanding policy, whenever I buy a new hard disk or
decommission an old one, I immediately `dd` it from start to end with a
pseudorandom byte stream. The result is indistinguishable from my disk
encryption setup, which leaves no apparent on-disk headers. I don’t do
this for “plausibility” reasons, but rather, 0. to assure that
immediately upon use, any sectors written with disk encryption cannot be
distinguished from unwritten sectors, and 1. to make things overall more
fun for potential cryptanalysts. I do realize the small problem that I
can’t affirmatively prove any particular disk in my possession to *not*
contain decryptable data; and many of them don’t!
(I think that next, I may start writing my disks with headers for LUKS,
which I do not use...)
Whereupon, I challenge plausible deniability designers to `dd` a 6TB
disk with pseudorandom bytes, then try walking it across the U.S. border
until it gets searched. What could possibly go wrong? Should you be
ordered to decrypt it, the disk *could* be *plausibly* filled with
pseudorandom bytes; and you would not be committing the crime of lying
to an officer, when you truly state that in fact, it *is* filled with
pseudorandom bytes.
Please, I want to see this “plausible deniability” theory in action.
You owe it to your users to test the theory empirically, in
circumstances in which users have here reported applying it.
Now, in reply:
On 2018-01-13 at 02:11:08 +0000, Damian Williamson
<willtech at live.com.au> wrote:
>The same problems exist for users of whole disk encrypted operating
>systems. Once the device (or, the initial password authentication) is
>found, the adversary knows that there is something to see.
Or PGP. Or in a broader sense, Tor. Or in the physical world, a
high-security safe bolted to your floor. Security systems attract
attention. Smart people develop appropriate threat models, keep their
security systems confidential where it is practical to do so (don’t brag
about your high-security safe), and work to increase the popularity of
network security systems (PGP, HTTPS, Tor...) to reduce how much they
stand out.
In the context of this discussion, it does help that Bitcoin is becoming
popular. It would help much more if Trezors and similar devices were as
commonplace as iGadgets. But when considering the potential threats to
any specific individual, the only “plausibility” shield is to not seem
like someone who is likely to have *much*. Of course, this is not a
problem specific to Bitcoin. Depending on the threat, the same danger
applies to owning a substantial amount of gold, cash, or even money in a
bank.
>The objective of plausible deniability is to present some acceptable
>(plausible) alternative while keeping the actual hidden (denied).
>
>If the adversary does not believe you, you do indeed risk everything.
And therein lies the trick. Unsophisticated adversaries such as common
criminals may be fooled, or may not care if they can quickly grab
*something* of value and run away. But if your threat model may
potentially include any adversaries possessed of both brains and
patience, “plausible deniability” solves nothing. Such an adversary
will not likely be satisfied with the standard of “plausibility”. More
likely, the prevailing standard will be: “I wasn’t born yesterday, and
I *know* that you are hiding something.”
>[snip extended prior quotations]
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180113/31b7f887/attachment.sig>

2023-06-07 18:09:43

- reply

📅 Original date posted:2018-01-12
📝 Original message:On 2018-01-12 at 09:50:58 +0000, Peter Todd <pete at petertodd.org> wrote:
>On Tue, Jan 09, 2018 at 12:43:48PM +0000, Perry Gibson wrote:
>>>Trezor's "plausible deniability" scheme could very well result in you
>>>going to jail for lying to border security, because it's so easy for
>>>them to simply brute force alternate passwords based on your seeds.
>>>With that, they have proof that you lied to customs, a serious
>>>offense.
>>The passphrase scheme as I understand it allows a maximum of 50
>>characters to be used. Surely even with the HD seed, that search
>>space is too large to brute force. Or is there a weakness in the
>>scheme I haven't clocked?
>
>While passphrases *can* be long, most user's aren't going to understand
>the risk. For example, Trezors blog(1) doesn't make it clear that the
>passphrases could be bruteforced and used as evidence against you, and
>even suggests the contrary: [...quote...]
I despise the term “plausible deniability”; and that’s really the wrong
term to use in this discussion.
“Plausible deniability” is a transparent excuse for explaining away an
indisputable fact which arouses suspicion—when you got some serious
’splain’ to do. This is usually used in the context of some pseudolegal
argument about introducing “reasonable doubt”, or even making “probable
cause” a wee bit less probable.
“Why yes, officer: I was seen carrying an axe down the street near the
site of an axe murder, at approximately the time of said axe murder.
But I do have a fireplace; so it is plausible that I was simply out
gathering wood.”
I rather suspect the concept of “plausible deniability” of having been
invented by a detective or agent provocateur. There are few concepts
more useful for helping suspects shoot themselves in the foot, or
frankly, for entrapping people.
One of the worst examples I have seen is in discussions of Monero,
whereby I’ve seen proponents claim that even under the worst known
active attacks, their mix scheme reduces transaction linking to a
maximum of 20–40% probability. “That’s not good enough to convince a
jury!” No, but it is certainly adequate for investigators to identify
you as a person of interest. Then, your (mis)deeds can be subjected to
powerful confirmation attacks based on other data; blockchains do not
exist in isolation. I usually stay out of such discussions; for I have
no interest in helping the sorts of people whose greatest concern in
life is what story to foist on a jury.
In the context of devices such as Trezor, what is needed is not
“plausible deniability”, but rather the ability to obviate any need to
deny anything at all. I must repeat, information does not exist in
isolation.
If you are publicly known to be deepy involved in Bitcoin, then nobody
will believe that your one-and-only wallet contains only 0.01 BTC.
That’s not even “plausible”. But if you have overall privacy practices
which leave nobody knowing or suspecting that you have any Bitcoin at
all, then there is nothing to “deny”; and should a Trezor with
(supposedly) 0.01 BTC be found in your possession, that’s much better
than “plausible”. It’s completely unremarkable.
Whereas if you are known or believed to own large amounts of BTC, a
realistic bad guy’s response to your “decoy” wallet could be, “I don’t
believe you; and it costs me nothing to keep beating you with rubber
hose until you tell me the *real* password.”
It could be worse, too. In a kidnapping scenario, the bad guys could
say, “I don’t believe you. Hey, I also read Trezor’s website about
‘plausible deniability’. Now, I will maim your kid for life just to
test whether you told me the *real* password. And if you still don’t
tell me the real password after you see that little Johnny can no longer
walk, then I will kill him.”
The worst part is that you have no means of proving that you really
*did* give the real password. Indeed, it can be proved if you’re lying
by finding a password which reveals a hidden wallet—but *you* have no
means of affirmatively proving that you are telling the truth! If the
bad guys overestimated your riches (or if they’re in a bad mood), then
little Johnny is dead either way.
In a legalistic scenario, if “authorities” believe you have 1000 BTC and
you only reveal a password for 0.01 BTC, the likely response will not be
to let you go. Rather, “You will now sit in jail until you tell the
*real* password.” And again: You have no means of proving that you did
give the real password!
“Plausible deniability” schemes can backfire quite badly.
>Also note how this blog doesn't mention anti-forensics: the wallet
>software itself may leave traces of the other wallets on the computer.
>Have they really audited it sufficiently to be sure this isn't the
>case?
What about data obtained via the network? I don’t *only* refer to
dragnet surveillance. See for but one e.g., Goldfelder, et al., “When
the cookie meets the blockchain: Privacy risks of web payments via
cryptocurrencies” https://arxiv.org/abs/1708.04748 Your identity can be
tied to your wallet all sorts of ways, any of which could be used to
prove that you have more Bitcoin than you’re revealing. Do you know
what databases of cross-correlated analysis data customs agents have
immediate access to nowadays—or will, tomorrow? I don’t.
In the scenario under discussion, that may not immediately prove “beyond
a reasonable doubt” that you lied specifically about your Trezor. But
it could give plenty of cause to keep you locked up in a small room
while your hard drive is examined for evidence that Trezor apps handled
*addresses already known to be linked to you*. Why even bother with
bruteforce? Low-hanging fruit abound.
>1) https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180112/862e70b3/attachment.sig>

2023-06-07 18:09:42

- reply

📅 Original date posted:2018-01-12
📝 Original message:On 2018-01-12 at 08:54:12 +0000, Peter Todd <pete at petertodd.org> wrote:
>While a clunky way to do it, you can use the `-signer` option to tell
>OpenSSL to write the signer's certificate to a file. That certificate
>can then be compared to the one from the repo, which was still in the
>repo as of the (signed!) v0.15.1 tag.
>
>
>Fun fact: OpenTimestamps has git integration, which means you can
>extract a OTS proof from 2016 for that certificate from the repo:
>
> $ git checkout v0.15.1
> $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/certs/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b8236775e4
> $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
> Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.pem'
> Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 EDT
>
>Homework problem: write a paragraph explaining how the proof generated
>by the above three commands are crypto snakeoil that proved little. :)
It says, “Bitcoin attests data existed”. Within the scope of those
three commands, I don’t see any proof of who put it there. Does OTS
check the PGP signatures on *commits* when it does that `git-extract`?
The signature on the v0.15.1 tag is irrelevant to that question; and
FWIW, I don’t see *that* signature being verified here, either.
Second paragraph: Moreover, with the breaking of SHA-1, it *may* be
feasible for some scenario to play out involving two different PEMs with
the same hash, but different public keys (and thus different
corresponding private keys). I don’t know off the top of my head if
somewhere could be found to stash the magic bits; and the overall
scenario would need to be a bit convoluted. I think a malicious
committer who lacked access to the signing key *may* be able to create a
collision between the real certificate, and a certificate as for which
he has the private key—then switch them, later. Maybe. I would not
discount the possibility off-hand. OTS would prove nothing, if he had
the foresight to obtain timestamps proving that both certificates
existed at the appropriate time (which they would need to anyway; it is
not a post facto preimage attack).
>[...]
>
>What's nice about OpenPGP's "clearsigned" format is how it ignores
>whitespace; a replica of that might be a nice thing for OTS to be able
>to do too. Though that's on low priority, as there's some tricky design
>choices(1) to be made about how to nicely nest clearsigned PGP within
>OTS.
>
>
>1) For example, I recently found a security hole related to clearsigned
>PGP recently. Basically the issue was that gpg --verify will return
>true on a file that looks like the following:
>
> 1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a foo-v2.0.tar.gz
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 foo-v1.0.tar.gz
> -----BEGIN PGP SIGNATURE-----
>
> <snip pgp stuff>
> -----END PGP SIGNATURE-----
>
>The system I was auditing then did something like this to verify that
>the file was signed:
>
> set -e # exit immediately on error
> gpg --verify SHA256SUMS.asc
> cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
> <do installation>
>
>While it makes it a bit less user friendly, the fact that PKCS7's
>encoding made it impossible to see the message you signed until it's
>been properly verified is a good thing re: security.
Potential solutions using PGP:
0. Don’t use clearsigning.
1. Use a detached signature.
2. Use `gpg --verify -o -` and pipe that to `grep`, rather than
illogically separating verification from use of data. (By the way,
where is the *hash* verified? Was `grep` piped to `sha256sum -c`?)
3. Have shell scripts written by somebody who knows how to think about
security, and/or who knows how to RTFM; quoting gpg(1):
>Note: When verifying a cleartext signature, gpg verifies only what
>makes up the cleartext signed data and not any extra data outside of
>the cleartext signature or the header lines directly following the dash
>marker line. The option --output may be used to write out the actual
>signed data, but there are other pitfalls with this format as well. It
>is suggested to avoid cleartext signatures in favor of detached
>signatures.
4. Obtain an audit from Peter Todd.
>And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh
>isn't vulnerable to this mistake. :)
P.S., oh my! *Unsigned data:*
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180112/54009101/attachment-0001.sig>

2023-06-07 18:09:26

- reply

📅 Original date posted:2018-01-08
📝 Original message:On 2018-01-08 at 04:22:43 +0000 Gregory Maxwell <greg at xiph.org> wrote:
>I'm happy to see that there is no obvious way to abuse this one as a
>brainwallet scheme!
BIP 39 was designed to make brainwallets secure! If a user generates a
weakling 12-word mnemonic from 16 tiny octets of entropy drawn off the
non-artistic /dev/urandom, then protects its seed with a creative
passphrase haiku about the power of human stupidity, then the result
will have a 128-bit security level. PROVE ME WRONG.
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
BIP 39 tool in progress, currently growing brainw^H^H^H^H^Hpassphrase
support to help poor /dev/urandom: https://github.com/nym-zone/easyseed
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180108/1992463a/attachment-0001.sig>

2023-06-07 18:09:17

- reply

📅 Original date posted:2018-01-08
📝 Original message:On 2018-01-08 at 07:35:52 +0000, 木ノ下じょな <kinoshitajona at gmail.com>
wrote:
>This is very sad.
>
>The number one problem in Japan with BIP39 seeds is with English words.
>
>I have seen a 60 year old Japanese man writing down his phrase (because
>he kept on failing recovery), and watched him write down "aneter" for
>"amateur"...
>
>[...]
>
>If you understand English and can spell, you read a word, your brain
>processes the word, and you can spell it on your own when writing down.
>Not many Japanese people can do that, so they need to copy letter for
>letter, taking a long time, and still messing up on occasion.
>
>[...]
>
>Defining "everyone should only use English, because ASCII is easier to
>plan for" is not a good way to move forward as a currency.
Well said. Thank you for telling of these experiences. Now please,
let’s put the shoe on the other foot.
I ask everybody who wants an English-only mnemonic standard to entrust
*their own money* to their abilities to very, very carefully write this
down—then later, type it back in:
すさん　たんろ　りゆう　しもん　ていおん　しとう
とこや　はやい　おうさま　ほくろ　けちゃっふ　たもつ
(Approximate translation: “Whatever would you do if Bitcoin had been
invented by somebody named Satoshi Nakamoto?”)
No, wait: That is only a 12-word mnemonic. We are probably talking
about a Trezor; so now, hey you there, stake the backup of your life’s
savings on your ability to handwrite *this*:
にあう　しひょう　にんすう　ひえる　かいこう　いのる　ねんし　はあさん　ひこく
とうく　きもためし　そなた　こなこな　にさんかたんそ　ろんき　めいあん　みわく
へこむ　すひょう　おやゆひ　ふせく　けさき　めいきょく　こんまけ
Ready to bet your money on *that* as a backup phrase in your own hands?
No? Then please, stop demanding that others risk *their* money on the
inverse case.
----
If you cheat here by having studied Japanese, then remember that many
Japanese people know English and other European languages, too. Then
think of how much money would be lost by your non-Japanese-literate
family and friends—if BIP 39 had only Japanese wordlists, and your folks
needed to wrestle with the above phrases as their “mnemonics”.
In such cases, the phrases cannot be called “mnemonics” at all. A
“mnemonic” implies aid to memory. Gibberish in a wholly alien writing
system is much worse even than transcribing pseudorandom hex strings.
The Japanese man in the quoted story, who wrote “aneter” for “amateur”,
was not dealing with a *mnemonic*: He was using the world’s most
inefficient means of making cryptic bitstrings *less* userfriendly.
----
I began this thread with a quite simple request: Is “日本語” an
appropriate string for identifying the Japanese language to Japanese
users? And what of the other strings I posted for other languages?
I asked this as an implementer working on my own instance of the
greatest guard against vendor lock-in and stale software: Independent
implementations. — I asked, because obviously, I myself do not speak
all these different languages; and I want to implement them all. *All.*
Some replies have been interesting in their own right; but thus far,
nobody has squarely addressed the substance of my question.
Most worrisome is that much of the discussion has veered into criticism
of multi-language support. I opened with a question about other
languages, and I am getting replies which raise a hue and cry of
“English only!”
Though I am fluent and literate in English, I am uninterested in ever
implementing any standard of this nature which is artificially
restricted to English. I am fortunate; for as of this moment, we have a
standard called “BIP 39” which has seven non-English wordlists, and four
more pending in open pull requests (#432, #442, #493, #621).
I request discussion of language identification strings appropriate for
use with that standard.
(P.S., I hope that my system did not mangle anything in the foregoing.
I have seen weird copypaste behaviour mess up decomposed characters. I
thought of this after I searched for and collected some visually
fascinating phrases; so I tried to normalize these to NFC... It should
go without saying, easyseed output the Japanese perfectly!)
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180108/8bba0a34/attachment.sig>

2023-06-07 18:09:15

- reply

📅 Original date posted:2018-01-05
📝 Original message:I propose and request as an enhancement that the BIP 39 wordlist set
should specify canonical native language strings to identify each
wordlist, as well as short ASCII language codes. At present, the
languages are identified only by their names in English.
Strings properly vetted and recommended by native speakers should
facilitate language identification in user interface options or menus.
Specification of language identifier strings would also promote
interface consistency between implementations; this may be important if
a user creates a mnemonic in Implementation A, then restores a wallet
using that mnemonic in Implementation B.
As an independent implementer who does not know *all* these different
languages, I monkey-pasted language-native strings from a popular wiki
site. I cannot guarantee that they be all accurate, sensible, or even
non-embarrassing.
https://github.com/nym-zone/easyseed/blob/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6/easyseed.c#L99
```
LANG(english, u8"English", "en", ascii_space ),
LANG(chinese_simplified, u8"汉语", "zh-CN",ascii_space ),
LANG(chinese_traditional, u8"漢語", "zh-TW",ascii_space ),
LANG(french, u8"Français", "fr", ascii_space ),
LANG(italian, u8"Italiano", "it", ascii_space ),
LANG(japanese, u8"日本語", "ja", u8"\u3000" ),
LANG(korean, u8"한국어", "ko", ascii_space ),
LANG(spanish, u8"Español", "es", ascii_space )
```
Per the comment at #L85 of the quoted file, I also know that for my
short identifiers for Chinese, “zh-CN” and “zh-TW”, are imprecise at
best—insofar as Hong Kong uses Traditional; and overseas Chinese may use
either. For differentiating the two Chinese writing variants, are there
any appropriate standardized or customary short ASCII language IDs
similar to ISO 3166-1 alpha-2 which are purely linguistic, and not fit
to present-day political boundaries?
My general suggestion is that the specification of appropriate strings
in bitcoin:bips/bip-0039/bip-0039-wordlists.md be made part of the
process for accepting new wordlists. My specific request is that such
strings be ascertained for the wordlists already existing, preferably
from the persons involved in the original pull requests therefor.
Should this proposal be “concept ACKed” by appropriate parties, then I
may open a pull request suggesting an appropriate format for specifying
this information in the repository. However, I will must needs leave
the vetting of appropriate strings to native speakers or experts in the
respective languages.
Prior references: The wordlist additions at PRs #92, #130 (Japanese);
#100 (Spanish); #114 (Chinese, both variants); #152 (French); #306
(Italian); #570 (Korean); #621 (Indonesian, *proposed*, open).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180105/c0a9128b/attachment.sig>

2023-06-07 18:09:15

- reply

📅 Original date posted:2018-01-05
📝 Original message:On 2018-01-05 at 16:04:10 +0000, Sjors Provoost <sjors at sprovoost.nl>
wrote:
>I’m not a fan of language specific word lists within the current BIP-39
>standard. Very few wallets support anything other than English, which
>can lead to vendor lock-in and long term loss of funds if a rare
>non-English wallet disappears.
>
>However, because people can memorize things better in their native
>tongue, supporting multiple languages seems quite useful.
>
>I would prefer a new standard [...] A replacement for BIP-39 [...]
>
>[snip]
>For my above point and some related ideas, see:
>https://github.com/satoshilabs/slips/issues/103
You present some interesting ideas; and I will be much interested in the
Github issue you referenced—thanks for that. However, this discussion
is *far* beyond the scope of my simple proposal and request to add
standardized native language and short-ASCII identifier strings to the
BIP repository. I suggest that readers solely interested in the
existing BIP 39 standard and its direct application to Bitcoin should
stop reading right here.
----
That being said, I should briefly address some of the issues you raise
(with further discussion best continued elsewhere):
I *strongly* urge the importance of language-specific standardized
wordlists. Even an individual who has secondarily acquired reasonable
fluency in English will most likely have the least difficulty
memorizing, transcribing, and otherwise handling a “mother-tongue”
mnemonic. Such an advantage is important in applications whereby even
slight errors can be fatal, and every bit counts. This is to say
nothing of persons who have limited or no English-language knowledge.
Yet for multiple reasons, multilanguage support is only feasible with
standardization. Wordlist creation is a highly specialized task.
Independent implementation of standards is imperative for avoiding
implementation lock-in; and independent implementors (such as I) would
be unable to create sets multi-language wordlists on their own, anyway.
For a view of the language-specific process involved in creating a
wordlist, I invite everybody following this discussion to review BIP
repository PRs #92, #130 (Japanese); #100 (Spanish); #114 (Chinese, both
variants); #152 (French); #306 (Italian); #544 (Korean, rejected); and
#570 (Korean). The rejection of #544 for Korean, and its superseding
with #570 is particularly instructive.
With standardized wordlists, independent implementation is easy. In my
own implementation, the language switching backend (excluding the UI[1])
for multilingual mnemonic generation required only relatively small C
code changes, as seen here[0]:
[0] https://github.com/nym-zone/easyseed/commit/5b6a6668458d96d6ccc4bf19e4fd40fe6ea72fec#diff-20dcf1782b7568b85ea01ed695abeb02
[1] https://github.com/nym-zone/easyseed/commit/1a6e48bbdac9366d9d5d1912dc062dfc3f0db2c6#diff-20dcf1782b7568b85ea01ed695abeb02
Admittedly, the multilingual requirements for seed generation will take
a bit more; and my nonstandard, non-BIP39 ideas which require decoding
words directly back to bits will take yet more. But it is still not
problematic.
I only began writing this tool one week ago, as of today; and it has
been a side project requiring small amounts of time, not a full-time
dedicated task. When I fully complete all aspects of seed generation,
then users will have the option of another simple open-source tool which
*will* be able to output a binary or BIP-32-formatted (“xprv”) 512-bit
seed, given input of an existing mnemonic in any language supported by
official BIP 39 wordlists. Output can then be imported to any wallet
software which supports BIP 32, regardless of the wallet’s langauge
support (and whether or not the wallet supports BIP 39 at all).
**The ease of creating such tools squarely answers your concerns about
vendor lock-in.** And yes, it’s easy. I can attest as a lone coder,
it’s easy for me to create “easyseed” as a side project!
Finally, aside: In the discussion at SLIP repository issue #103, I see
mention of m-of-n SSSS. I have been mentally whiteboarding just such an
application involving mnemonics. Watch for it. <g> It is likely that
I will crib the BIP 39 wordlists, given the impossibility that I could
create my own set of wordlists in many languages. I only wish that the
BIP repository had support for more languages. More! Adding each new
language to my implementation(s) will require approximately one-line
code changes for me.
(Aside further: Why is there not a Dutch wordlist? I should like to
add that, please—meneer Provoost. More wordlists!)
Aside still yet further: Should you be interested in more general
applications of mnemonic phrases for pseudorandom strings, I think you
will like this future feature which currently exists only as an Easter
egg, (un)documented in my commit log:
https://github.com/nym-zone/easyseed/commit/ba77be1b1a1f0c6af50ceba5c89f4adece7e5dff
Further discussion is invited by private mail, in an appropriate public
venue, or otherwise not on a bitcoin-dev thread which makes a simple
request and proposal as to the existing BIP 39 standard—thanks.
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180105/7673c033/attachment.sig>

2023-06-07 18:09:04

- reply

📅 Original date posted:2017-12-25
📝 Original message:I here record for the devs a thought I had a few days ago on the Bitcoin
Forum about BIP 173 Bech32 addresses. I’ve heard Greg Maxwell say that
“Bech32 is designed for human use and basically nothing else”; so I hope
I be not untoward in considering the following human-friendliness
enhancement to entwine with the technical ambit of this list. This MAY
be suitable for mention in an informative specification, or informative
section thereof.
To help gain user familiarity with and acceptance of the
error-correcting, case-insensitive Bitcoin addresses of the future, I
propose a need for what I think marketers call “branding”. The best
branding is that which derives naturally from some intrinsic quality of
a thing; wherefore I look to what may perhaps be a bit of serendipity in
the specification.
I expect that in practical use, one of the great advantages of Bech32
addresses will be the relative ease of communicating them
aloud—especially over the phone. In similar circumstances, when trying
to convey unusual names or pseudorandom strings, I’ve found radio
alphabets to work well at their intended purpose. And when reading
Bech32 Bitcoin addresses in the most popular radio alphabet, they will
always start with a catchy phrase: “Bravo Charlie One”.
That’s memorable, $SEARCH-able, and yet also one of those unique,
otherwise meaningless phrases which gets marketers excited. Keeping to
a word triplet, I hereby submit for consideration as the official
nickname for Bech32 Bitcoin use: “Bravo Charlie Addresses”. These are
the Bitcoin addresses with the magic words, suitable for a motto:
“Bravo Charlie One means money.” Add a logo à la Segwit’s, and raise
user awareness of this exciting new technology!
Beyond the branding issue, recommendations for Bitcoin spelling-alphabet
use in English and other languages may perhaps be a suitable matter for
such standardization as would facilitate coherent user documentation. I
invite discussion.
Of course, this branding only applies directly to Bitcoin Bech32
addresses. The BIP 173 authors were gracious to make the standard
generally adaptable; and it has already seen some uptake amongst
altcoins. I myself am now contemplating how Bech32 would be a superior
human-facing format for key fingerprints for PGP, SSH, and even TLS,
with HRPs of “pgp”, “ssh”, “tls”, etc. and some appropriate means of
embedding the key type just as “bc” embeds the witness version. There
is an urgent general need for a specification which reduces the inherent
pain of wetware in handling pseudorandom strings; and I do think that
anything which familiarizes users with Bech32 in a specific use will be
beneficial to Bech32 adoption generally.
To celebrate, as seen in my sig, I created for myself a new Bravo
Charlie Address which expresses that I am pleased: Now, I have an
error-correcting, case-insensitive address which can receive only
genuine Bitcoin cash money. Because “Bravo Charlie One means money.”
Here’s to the Bitcoin address format of the future!
--
nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171225/b743b321/attachment.sig>