{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-20\n📝 Original message:Hey Thomas,\n\nHere are some thoughts on a third way we can tackle our BIP 70 usability\nproblem sans servers: by finding an upgrade to QR codes that give us more\nspace and then optimising the hell out of BIP70 to make it fit.\n\n*Better QR codes*\n\nLet's start with this paper, High Capacity Colored Two Dimensional Codes\n\u003chttp://proceedings2010.imcsit.org/pliks/79.pdf\u003e. It develops an upgrade to\nstandard QR codes that extend them with the use of colour. The resulting\ncodes have ~4x the capacity but similar levels of scanning robustness.\n\nThis paper is also interesting: DualCodes\n\u003chttps://books.google.at/books?id=O5a6BQAAQBAJ\u0026pg=PA25\u0026lpg=PA25\u0026dq=%22DualCodes:+Backward+Compatible+Multi-layer+2D-Barcodes%22\u0026source=bl\u0026ots=ql_G8iyXXi\u0026sig=9-VwhFLbkfgh2Fi0tdM3AWOyajA\u0026hl=en\u0026sa=X\u0026redir_esc=y#v=onepage\u0026q=%22DualCodes%3A%20Backward%20Compatible%20Multi-layer%202D-Barcodes%22\u0026f=false\u003e\n\nIt works by overlaying one QR code on top of another using shades of grey.\nThe resulting code is still scannable by older applications (backwards\ncompatibility!) but an enhanced reader can also extract the second code.\nThey explicitly mention digital signatures as a possible use case.\n\nIn both cases the code does not appear to be available but the same\napproach was used: extend libqrcode for creation and ZXing for decoding\n(Android). We could ask the authors and see if they're willing to open\nsource their work.\n\nBIP 70 has the potential to add many features. But most of them, even the\nextensions currently proposed only as ideas, can be expressed with\nrelatively few bytes.\n\nSo with a 4x boost in capacity, or a 2x boost with backwards compat, what\ncould we do?\n\n*Optimised BIP70*\n\nIf we define our own certificate formats and by implication our own CAs,\nthen we can easily make a certificate be 32 bytes for the ECC\nsignature+length of the asserted textual identity, e.g. email address.\n\nCan we go smaller? Arguably, yes. 32 bytes for a signature is for Really\nStrong Security™ (a 256 bit curve), which gives 128 bits of security. If we\nare willing to accept that a strong adversary could eventually forge a\ncertificate, we can drop down to a weaker curve, like a 128 bit cure with\n64 bits of security. This is well within reach of, say, an academic team\nbut would still pose a significant hurdle for run of the mill payment\nfraudsters. If these short CA keys expired frequently, like once a month,\nthe system could still be secure enough.\n\nAs we are defining our own PKI we can make CA keys expire however\nfrequently we like, up to the expiry period of the BIP70 request itself.\nThus certificates that expire monthly is not an issue if the wallet has a\nway to automatically refresh the certificate by using a longer term\nstronger credential that it keeps around on disk.\n\nIf we accept a single payment address i.e. no clever tricks around merge\navoidance, such a QR code could look like this:\n\nbitcoin:1aBcD1234....?x=serialized_payment_request\n\nHowever this requires text mode and wastes bytes at the front for the URI\ntype.\n\nIf we're willing to accept QR codes that can't be read by a standalone app\nand which requires an embedded reader, then we can just scrap the legacy\nand serialise a binary BIP70 request directly into the QR code. Andreas'\nwallet, for example, can already handle this because it has an embedded QR\nreader. I don't know what the situation on iOS is like.\n\nIf we were to use the DualCodes system we could define the primary QR code\nas being an unsigned payment request, and the second layer as being the\nsignature/pki data.\n\n*Getting response data back to the recipient*\n\nOne reason to have a store/forward network is the \"forward\" part: we don't\nonly want to host a static PaymentRequest, but also receive a private\nresponse e.g. for the memo field, or to implement the well known \"Stealth\nAddress\" / ECDH in the payment protocol proposals:\n\nhttps://medium.com/@octskyward/ecdh-in-the-payment-protocol-cb2f81962c1b\n\nStealth addresses try and (ab)use the block chain as a store/forward layer\nand break SPV in the process as well as wasting lots of resources. ECDH in\nBIP70 avoids those issues but at the cost of requiring a separate\nstore-and-forward network with some notion of account privacy.\n\nThese ideas come with another steep price: restoring a wallet from seed\nwords is no longer possible. You must have the extra random data to\ncalculate the private keys for money sent to you :(  If you lose the extra\ndata you lose the money. It can be fixed but only by having wallets\nregularly sweep the sent money to keys derived from the BIP32 seed, meaning\nprivacy-hurting merging and extra traffic.\n\nI don't know of any way to solve this except by using some servers,\nsomewhere, that store the Payment messages for people: potentially for a\nlong period of time. If we have such servers, then having them host BIP70\nrequests is not a big extra requirement.\n\nI have imagined this being a p2p-ish network of HTTPS servers that accept\nPOSTs and GETs. But if we are thinking about alternatives, it could also be\na separate service of the existing Bitcoin P2P network. That's what\nOP_RETURN (ab)use effectively does. But as these messages don't really have\nto be kept forever, a different system could be used: Payment messages\ncould be broadcast along with their transactions and stored at every node,\nwaiting for download. But unlike regular transactions, they are not stored\nforever in a block chain. They are just written to disk and eventually\nerased, perhaps, ordered in a mempool like way where more fee attached ==\nstored for longer, even though the nodes storing the data aren't actually\nreceiving the fee.\n\nA signature over the Payment metadata using the same output keys as the\ntransaction would bind them together for the purposes of broadcast, but\ndoesn't need to be stored after that.\n\nAs the data storage is just a helpful service but not fundamentally\nrequired, nodes could shard themselves by announcing in their addr messages\nthat they only store Payment metadata for e.g. the half which have a hash\nstarting with a one bit. And when outputs are seen being spent, the\nassociated Payment metadata can be erased too, as by then it's fair to\nassume that the users wallet has downloaded the metadata and no longer\ncares about it.\n\nOf course you have then all the regular DoS issues. But any P2P network\nthat stores data on the behalf of others has these.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/7b5c3cb0/attachment-0001.html\u003e"}