rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2017-09-28 📝 Original message:On Fri, Sep 29, 2017 at 1:50 AM, Peter Todd <pete at petertodd.org> wrote: > What do you mean by "an embedded amount"? I ask you to pay 1 Bitcoin to bc1blahblah. ...you make a typo, or a poorly placed cosmic ray switches it in your ram to bc1blohblahbah. No problem, it'll get rejected. (even if the cosmic ray happens just before signing... if the software is robust it'll reencode from the signed transaction and check against the original input. But if instead the typo converts it to 2 Bitcoins or the cosmic ray converts it to 2.34217728... the payment will happily go through, assuming your wallet had enough, and you're stuck asking me to refund you the excess. Sure, you can put amounts in URIs and whatnot, but they're not error protected... so there will always be unprotected poritons where a glitch can radically change the amount. In many cases you know exactly what amount you're asking for when you generate an address. There isn't any reason the amount couldn't be covered by the addresses checksum in those cases. There are a couple ways of doing that... e.g. adding it explicitly, where the checksum includes it but not the address itself; so it errors out if you get it wrong. But this is unfortunate because it can't tell you the expected amount when its wrong. Another way would be to embed the amount in the address, and then the software can tell you the amount the address was expecting and not let you proceed until they match.