Re: [bitcoin-dev] Codex32

[Russell O'Connor via bitcoin-dev]

On Sun, Feb 19, 2023 at 5:13 PM Andrew Poelstra via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Feb 19, 2023 at 10:13:33AM -1000, David A. Harding wrote:
>
> I'm curious about whether there's a way to prevent this attack without
> > otherwise compromising the properties of the code?  For example, some
> > extra data that Bob can carry around (or memorize) for verifying the
> > shares haven't changed, but which is not otherwise needed for recovery
> > (so there's no problem if it's lost).
> >
>
> Unfortunately not, as near as I can tell ... one way to think of this is
> that Alice can flip a lot of random tiles then "error correct" it to get
> a new valid, but incorrect, seed. So as long as we support error
> correction it'll be possible to wreck seeds in this way.
>
> It's actually even worse than this ... as long as there's a clearly
> defined "checksum" at the end of a share, Alice will be able to mangele
> tiles and then just re-compute the checksum at the end.
>
> So what we really need to prevent this is something like a MAC: where
> Bob has a secret value which gets input into the checksum somehow, which
> Alice can't create valid checksums without knowing. Unfortunately I
> don't see any way to do this with linear codes. With a hash-based
> "checksum" a la BIP39 it would definitely be possible, but of course,
> not hand-computable.
>

Speaking off the cuff and as a non-cryptographer (i.e do NOT rush off and
do this without any vetting) but Christopher Allen once referred me to an
cypher tile set called LS47 .  If we
set aside the cypertext, I suspect we can form a MAC by recording some
random initial tile configuration, running the LS47 algorithm, and
recording the final tile configuration.  These records are not sensitive as
(presumably!) the share data is not recoverable from just knowing these two
configurations.  So one can keep these records with you, digitally sign
them or whatever, and then take them to your share on a regular basis to
rerun the LS47 algorithm to see if you still get the same final state from
the initial state.

Perhaps something more specific to Bech32 could be designed, but otherwise
this (alleged) MAC process isn't Codex32 specific.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Refreshed BIP324

[Anthony Towns via bitcoin-dev]

On Fri, Feb 17, 2023 at 10:13:05PM +, Pieter Wuille via bitcoin-dev wrote:
> > I think it's probably less complex to close some of the doors?
> > 2) are short ids available/meaningful to send prior to VERACK being
> > completed?
> Ah, I hadn't considered this nuance. If we don't care about them being 
> available before VERACK negotiation, then it may be possible to introduce a 
> way to negotiate a different short id mapping table without needing a 
> mechanism for *re*-negotiating.

I think you still need/want two negotiation steps -- once to tell each
other what tables you know about, once to choose a mutually recognised
table and specify any additions.

> > I think the things missing from the current list (and not currently in
> > use by bitcoin core) are:
> > bip 61: REJECT
> > bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO
> Do you feel REJECT should be included?

I don't think it matters much; reject messages are both rare and include
a reason so you'd only be saving maybe 12 bytes out of 62 (~20%)
for maybe 6000 messages a day per peer that sends reject messages,
so 72kB/day/reject-peer?

> Perhaps a possibility is having the transport layer translate 
> short-command-number-N to the 12-byte command "\x00\x00..." + byte(N), and 
> hand that to the application layer, which could then do the mapping?

Presuming the transport layer also continues to reject commands that
have a '\x00' byte at the start or in the middle (ie !IsCommandValid()),
that seems pretty reasonable...

Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Codex32

[Christopher Allen via bitcoin-dev]

An easy but possibly very important tip:

If you use only UPPER CASE alpha and numbers in codex32, and avoid most
punctuation, it makes QR rendering of it significantly smaller. This is
because the QR code to the ISO SPEC, when seeing lowercase, assumes the
value is binary, then converts it to a two byte value. If instead, the
codex32 is all upper, and it uses only the 45 allowed characters (see
https://www.thonky.com/qr-code-tutorial/alphanumeric-table) , it will leave
it single byte and try to compress it. Of course it doesn’t compress well,
but that is OK because it at least didn’t double the size first.

See our research on this topic at
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-003-uri-binary-compatibility.md

A superior QR codec can do better (see our
https://github.com/BlockchainCommons/QRCodeGenerator or
https://www.nayuki.io/page/qr-code-generator-library) but many platforms
and more basic QR codecs will double the size of the QR if you have any
lower case.

— Christopher Allen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Codex32

[Andrew Poelstra via bitcoin-dev]

On Sun, Feb 19, 2023 at 10:13:33AM -1000, David A. Harding wrote:
> On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:
> > the draft lists several benefits over SLIP-0039.
> 
> The only benefit over SLIP39 that I see explicitly mentioned in the
> draft BIP is "simple enough for hand computation".  In the FAQ[1] on the
> project's website, I see some additional reasons:
>

Oh, you're right! I think we removed this text in one of our revisions.
I'll see if it makes sense to put it back.

> | This scheme is essentially the same as SLIP39, with the following
> differences:
> |
> | - The checksum is longer, slightly stronger, and designed to be
> |   computable by hand.
> |
> | - Our encoding is more compact, giving us room for a bit of more
> |   metadata, which is also designed to be readable by hand.
> |
> | - Unlike SLIP39, we do not support passphrases or hardening of any
> |   form.
> |
> | - Unlike SLIP39, we have no hardware wallet support. But we hope that
> |   will change!
> 

These are roughly the benefits -- a more compact encoding which is
always a fixed width. We also list "not supporting features such as
passphrases" as a benefit, for users who don't need/want this.

> 
> 
> When I first saw the post about this, it was unclear to me that it was a
> serious project, but I've become increasingly interested as I researched
> it.  I'm not personally that interested in generating entropy from dice
> or encoding shares by hand---it's already imperative that I acquire a
> trustworthy computer and load it with trustworthy software in order to
> use my seed securely, so I might as well have it generate my seeds and my
> recovery codes for me.
>

Yes, we've been a bit coy about how serious this project is, because on
its face it's such a silly thing. But for my part, I've been using it
for real coins for over a year and I consider it to be serious.

> What really did catch my attention, but which was kind of buried in the
> project documentation, is the ability to verify the integrity of each
> share independently without using a computer.  For example, if I store a
> share with some relative who lives thousands of kilometers away, I'll be
> able to take that share out of its tamper-evident bag on my annual
> holiday visit, verify that I can still read it accurately by validating
> its checksum, and put it into a new bag for another year.  For this
> procedure, I don't need to bring copies of any of my other shares,
> allowing them (and my seed) to stay safe.
> 

This is good feedback. I strongly agree that this is the big selling
point for this -- that you can vet shares/seeds which *aren't* being
actively used, without exposing them to the sorts of threats associated
with active use.

We should make this more prominent in the BIP motivation.

> 
> I do have one question after watching an excellent video[2] about the
> motivation for this system.  In the video, one of the threat models
> described is a disarrangement of the words in a metal backup system.
> The implication seems to be that this would be an accidental
> disarrangement, which obviously the Codex32 checksum would catch during
> periodic offline verification.  But what about deliberate modification
> of a recovery code?  For example, Bob doesn't keep his seed loaded on
> any computer; it only exists in Codex32 shares which Bob plans to
> combine together in 20 years when he retires, although he makes regular
> deposits to the pubkeys derived from the seed's master xpub.  Mallory is
> able to obtain access to Bob's shares, allowing her to immediately steal
> his current funds---but also allowing her to replace them with
> similar-looking
> shares with the same metadata and valid checksums so that Bob
> continues making deposits to the wallet.
> 
> I'm curious about whether there's a way to prevent this attack without
> otherwise compromising the properties of the code?  For example, some
> extra data that Bob can carry around (or memorize) for verifying the
> shares haven't changed, but which is not otherwise needed for recovery
> (so there's no problem if it's lost).
>

Unfortunately not, as near as I can tell ... one way to think of this is
that Alice can flip a lot of random tiles then "error correct" it to get
a new valid, but incorrect, seed. So as long as we support error
correction it'll be possible to wreck seeds in this way.

It's actually even worse than this ... as long as there's a clearly
defined "checksum" at the end of a share, Alice will be able to mangele
tiles and then just re-compute the checksum at the end.

So what we really need to prevent this is something like a MAC: where
Bob has a secret value which gets input into the checksum somehow, which
Alice can't create valid checksums without knowing. Unfortunately I
don't see any way to do this with linear codes. With a hash-based
"checksum" a la BIP39 it would definitely be possible, but of course,
not hand-computable.

BTW, to execute this attack Alice doesn't 

Re: [bitcoin-dev] Codex32

[David A. Harding via bitcoin-dev]

On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:

the draft lists several benefits over SLIP-0039.


The only benefit over SLIP39 that I see explicitly mentioned in the
draft BIP is "simple enough for hand computation".  In the FAQ[1] on the
project's website, I see some additional reasons:

| This scheme is essentially the same as SLIP39, with the following 
differences:

|
| - The checksum is longer, slightly stronger, and designed to be
|   computable by hand.
|
| - Our encoding is more compact, giving us room for a bit of more
|   metadata, which is also designed to be readable by hand.
|
| - Unlike SLIP39, we do not support passphrases or hardening of any
|   form.
|
| - Unlike SLIP39, we have no hardware wallet support. But we hope that
|   will change!

From having perused the extended documentation myself, I think I would
personally note the following differences.

- Alphabet: Codex32 uses the bech32 alphabet rather than SLIP39's
  alphabet consisting of English words.  The benefit to human-language
  words is easier memorization for those proficient in the particular
  language (in this case, SLIP39 only allows the use of English).  A
  disadvantage, IMO, is that it encourages the practice of memorization
  (which does have a few advantages but also a lot of drawbacks).

  Interestingly, Codex32 addresses what I think is the main problems of
  memorization: difficult-to-prove successful recollection.  Someone who
  wants to reliably keep seed-related material only in their head
  needs to practice recalling it on a regular basis, but for BIP39,
  SLIP39, Aezeed, etc... there's no way for them to confirm they
  successfully recalled it short of going through the entire recovery
  process; they probably just judge how confident they feel about the
  recollection and assume that feeling like they recalled it correctly
  is the same thing as recalling it correctly.

  Codex32 allows the individual to periodically perform their
  recollection on paper in a private room without electronics and use
  nothing but a pen and some loookup tables (or a paper device) to
  verify that they recalled the string correctly (and its checksum can
  help with correcting up to several errors, although you might need a
  computer for error location and correction assistance).

- Hierarchy: Codex32 does not natively provide support for nested 
  whereas SLIP39 does.  E.g., in SLIP39, you can require 2-of-3 for
  {me, family, friends} where me is 2-of-3 {fire_safe, bank_safe,
  buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and friends
  are 2-of-5 {d, e, f, g, h}.  I assume you can do the same with Codex32
  by using the share for one level as the secret for the next level,
  although this is not described in the protocol.

- Versioning: Codex32's metadata can store version information for
  wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), although
  this would cut into the space available for users to set their own
  metadata and it is not specified in the draft BIP.  SLIP39 also
  doesn't specify anything about implicit path versioning and, AFAICT,
  doesn't have any room to store such metadata without reducing seed
  entropy.

- Plausible deniability dummy wallets: Codex32 doesn't support this;
  SLIP39 does.  Much has been written by other people about whether
  dummy wallets are a good idea or not, with strong opinions on both
  sides, so maybe we can just leave it at that.

---

When I first saw the post about this, it was unclear to me that it was a
serious project, but I've become increasingly interested as I researched
it.  I'm not personally that interested in generating entropy from dice
or encoding shares by hand---it's already imperative that I acquire a
trustworthy computer and load it with trustworthy software in order to
use my seed securely, so I might as well have it generate my seeds and 
my

recovery codes for me.

What really did catch my attention, but which was kind of buried in the
project documentation, is the ability to verify the integrity of each
share independently without using a computer.  For example, if I store a
share with some relative who lives thousands of kilometers away, I'll be
able to take that share out of its tamper-evident bag on my annual
holiday visit, verify that I can still read it accurately by validating
its checksum, and put it into a new bag for another year.  For this
procedure, I don't need to bring copies of any of my other shares,
allowing them (and my seed) to stay safe.

---

I do have one question after watching an excellent video[2] about the
motivation for this system.  In the video, one of the threat models
described is a disarrangement of the words in a metal backup system.
The implication seems to be that this would be an accidental
disarrangement, which obviously the Codex32 checksum would catch during
periodic offline verification.  But what about deliberate modification
of a recovery code?  For example, Bob doesn't 

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[alicexbt via bitcoin-dev]

Hi vjudeu,

Before I respond to your email, I would like to share the [python script][0] 
that could be used to do 3 things:

1) List peers
2) Broadcast a transaction to peers and see if it was relayed
3) Ban peers that did not relay your transaction

The primary goal of this script is testing however it can be used by anyone as 
it does not make sense to waste resources connecting to peers that do not relay 
your transactions. There is another [solution][1] for users to ensure all 
transactions get relayed properly.

Note: There could be some false positives and it mainly uses libbtc

> Yes, I disapprove spamming the blockchain. But because people will rather die 
> than stop it, creating some kind of official alternative is needed. I think 
> most of the time it is not needed to store that data on-chain, all that is 
> needed, is just proving they existed, and that they are connected to a 
> certain transaction (so, it is about timestamping, not about storage).

Why do you think people don't stop and willing to pay for inscribing something 
on-chain although it could be done for free using BitTorrent? As far as 'spam' 
is concerned these are bitcoin transactions until you open ordinals explorer or 
believe in ordinals theory to track the ownership of inscription. There are 
some bitcoin transactions that I could consider spam and have no interest in 
keeping them on my disk. However I believe people should be free to do anything 
with their money and I don't care about the content or intent of any bitcoin 
transaction as long as its valid, paid fee etc. (except vulnerability) Blocks 
cannot exceed their limit and I was prepared for a fee market with new limits 
since segwit got activated.

Here's my opinion why people don't stop doing it and we could always disagree:

Money or financial transactions have been done differently in countries, 
cultures, communities etc. across the world. People have done inscriptions on 
paper money issued by governments for graffiti, political, personal or other 
reasons. Since years inscriptions have been on different types of [coins][2]. 
Example: Jahangir issued many gold and silver [coins with poetic verses][3] on 
them and was the only Mughal emperor to bestow the right of coinage to his 
royal consort.

Some positives of inscriptions that I have observed in last couple of weeks:

- More users interested in running full nodes (non-pruned) and trying bitcoin 
wallets, lightning etc.
- Taproot usage increased
- More developers interested in learning bitcoin development and looking for 
libraries, docs etc.
- Demand for block space has increased
- ~50 BTC paid in fees to miners for creating inscriptions until now

It creates more opportunities for bitcoin developers and everyone involved in 
bitcoin.

[0]: 
https://ordinals.com/content/f39b5f0a9e9af05da03ab0c52a407972b9678e8db80160febd6bd899acebe141i0
[1]: https://github.com/casey/ord/pull/1783
[2]: https://en.wikipedia.org/wiki/Coinage_of_India
[3]: 
https://web.archive.org/web/20180705070913/https://www.mintageworld.com/blog/coins-of-jahangir/


/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, February 17th, 2023 at 8:26 PM, vjudeu via bitcoin-dev 
 wrote:


> 
> I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. 
> Because "OP_FALSE OP_IF  OP_ENDIF" is effectively the same as 
> "OP_NOP", and putting NOPs in many places is considered non-standard. The 
> same is true for "OP_TRUE OP_NOTIF  OP_ENDIF", and also there are 
> many variants, where someone could use "OP_FALSE OP_NOT" instead of 
> "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" 
> (instead of putting "OP_TRUE").
> 
> 
> There are endless combinations, and even if there will be a rule to evaluate 
> constant values on the input stack, and put OP_NOP, where any non-empty set 
> of opcodes will evaluate into nothing, then still, there are ways to include 
> spam on-chain. So, the question is: how strict should those rules be?
> 
> > "I disapprove of what you say, but I will defend to the death your right to 
> > say it."
> 
> 
> Yes, I disapprove spamming the blockchain. But because people will rather die 
> than stop it, creating some kind of official alternative is needed. I think 
> most of the time it is not needed to store that data on-chain, all that is 
> needed, is just proving they existed, and that they are connected to a 
> certain transaction (so, it is about timestamping, not about storage).
> 
> When it comes to the solution, I think a commitment to a signature should 
> handle all cases. In this way, it can be done for any address type that can 
> support OP_CHECKSIG. To validate such commitment, all that is needed, is 
> converting R-value of a signature into the Taproot address, and then checking 
> if a given commitment matches such key.
> 
> > I agree with Peter that, given that users have found ways to store 
> > arbitrary amounts