{"type":"rich","version":"1.0","author_name":"npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727","author_url":"https://nostr.ae/npub10etkvm8l0jr0jsgdx02dxnhnu5g989dnca90guj5rklwkaplnh3sgjc727","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-01-12\n📝 Original message:\u003e You can always just extend the payment protocol with the new fields as  \n\u003e well, vs making very long addresses.\n\nI should have mentioned that as Task #4. Agree it could be an optional  \nextension and backward compatible. I think for displaying the payment in  \nthe UI after it's been made via PP, we have to fully support sending to a  \nnew standard address type anyway. Probably easiest to implement in PP  \nafter the address and transaction building code is done.\n\nSo '4a' would be building a static PP file given the necessary inputs.  \nWhen I get to that point, I'll send out a draft PP extension with  \nfields/formats if someone else hasn't already. '4b' would be actually  \nadding support for parsing those fields and generating the new transaction  \ntype into bitcoind.\n\nAny thoughts on the prefix, and one vs two pubkey approach? First of all,  \ndo we try to support both equally, or favor one over the other? I was  \nthinking we could have two different 4 byte prefixes but that both render  \nas xSTL/tSTL in Base58 but correspond to the one vs two pubkeys expected.  \nI think the chance of finding a single prefix which looks like xSTL for  \nboth address lengths is 1 in (58^4)^2, so that's probably not going to  \nhappen.\n\n From the payer/user perspective, short stealth vs. long stealth is  \nirrelevant; they both have the same usability properties from the payer  \nperspective. So giving them the same Base58 prefix seems like a good plan.\n\nThe full 4-byte prefix seems worth the usability trade-off versus 1-byte  \nprefix, especially since it will impact the ability to lookup the  \ntransaction on an outside service, which I think a lot of people do to  \nverify their payments. IMO a longer prefix isn't \"wasting bytes\" anywhere  \nthat it really counts.\n\nWe could save two bytes in the address if we required both pubkeys to  \nstart with '03', or save one byte if we required they both start with the  \nsame byte, but again doesn't seem worth it (to me) for the arbitrary  \nrestriction.\n\nThe actual internal wallet code for *receiving* STL payments and updating  \nbalances is more tricky and probably not something I can personally tackle  \nfor bitcoind. Assuming we even want first-class support for generating STL  \naddresses and receiving STL payments in a standard user wallet, someone  \nhas to decide if the STL 'd' / 'd2' keys should be...\n\n   1) Encrypted as usual, and then keep a list of blocks with interesting  \ntransactions, and go through them when the user enters their password?   \nThis would cause balances to update differently than how they do now, but  \nperhaps be more secure.\n\n   2) Kept unencrypted to allow live scanning as usual? Or keep just 'd2'  \nunencrypted, with some new concept of 'unconfirmed' until the user enters  \ntheir password to prove they can spend that TX? That kind of extra step  \nseems OK for a merchant but sounds very scary for an average user.\n\n   3) Kept encrypted under a separate password? Meh...\n\nAnd last thought for now... At some point, we might want to decide on a  \nconvention to highlight these STL addresses as 'reusable' -- but similar  \nquestions around revocability remain. I hope we don't need anything like a  \nUTC expiration time baked in to the address. A static PP file will have an  \nexpiration date either in the certificate or in 'expires' field, so I  \nthink if you want it to expire then use PP?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140112/462cb3bc/attachment.html\u003e"}