Re: [Bitcoin-development] 75%/95% threshold for transaction versions
s7r you may be interested in this video explaining several aspects of malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs It is pre BIP62, but I believe it is very relevant and will hopefully clear some of your doubts. The signer of TX1 will always be able to change the signature and thus the tx ID. On Sat, Apr 18, 2015 at 4:49 PM, s7r s...@sky-ip.org wrote: Understood. That is unfortunate, but not the end of the world. If you could please give feedback also to these last comments / questions: How far are we at this moment from BIP62? Can an user send a non-malleable tx now, if enforces some additional rules? As for the security of the system, it does not fully rely on txids being non malleable, but see this quote from my previous email: [QUOTE] I am trying to build a bitcoin contract which will relay on 3 things: - coinjoin / txes with inputs from multiple users which are signed by all users after they are merged together (every user is sure his coins will not be spent without the other users to spend anything, as per agreed contract); - pre-signed txes with nLockTime 'n' weeks. These txes will be signed before the inputs being spent are broadcasted/confirmed, using the txid provided by the user before broadcasting it. Malleability hurts here. - P2SH Another thing I would like to confirm, the 3 pieces of the bitcoin protocol mentioned above will be supported in _any_ future transaction version or block version, regardless what changes are made or features added to bitcoin core? The contract needs to be built and left unchanged for a very very long period of time... [/END QUOTE] Can you comment on the quote please? So, basically transaction malleability could affect the system in the way that a pre-signed tx which offers the insurance and which is sent to the user before the user sends the coins (spending user's coins back to him after a certain period of time) could be invalidated. The insurance tx signature will still be good, but invalid overall since the input (txid) being spent does not exist (was altered / modified). The coins won't be stolen or lost, but a new tx needs to be signed with the altered (new) txid, for the system to work. So, an user creates a transaction TX1 sending the coins to the server but does not broadcast it. Instead, he provides the txid of TX1 to the server. Server generates another transaction TX2 which spends TX1 back to the user, with an nLockTime. User checks and if everything ok broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2 will become invalid (since it will be spending an inexistent input), and the server will need to re-create and sign TX2 with the new (altered/modified) txid of TX1, as per agreed contract. Should the server disappear after user broadcasts TX1 and before the altered/modified txid of TX1 gets confirmed, user's coins are forever locked. It is true that no third party can benefit from this type of attack, only the user will result with coins locked, but it is something which could be used by competition to make a service useless / annoying / too complicated or less safe to use. How could I mitigate this? Thanks you for your time and help. On 4/17/2015 12:02 PM, Pieter Wuille wrote: Anyone can alter the txid - more details needed. The number of altered txids in practice is not so high in order to make us believe anyone can do it easily. It is obvious that all current bitcoin transactions are malleable, but not by anyone and not that easy. At least I like to think so. Don't assume that because it does not (frequently) happen, that it cannot happen. Large amounts of malleated transactions have happened in the past. Especially if you build a system depends on non-malleability for its security, you may at some point have an attacker who has financial gain from malleation. From your answer I understand that right now if I create a transaction (tx1) and broadcast it, you can alter its txid at your will, without any mining power and/or access to my private keys so I would end up not recognizing my own transaction and probably my change too (if my systems rely hardly on txid)? In theory, yes, anyone can alter the txid without invalidating it, without mining power and without access to the sender's private keys. All it requires is seeing a transaction on the network, doing a trivial modification to it, and rebroadcasting it quickly. If the modifies version gets mined, you're out of luck. Having mining power helps of course. After BIP62, you will, as a sender, optionally be able to protect others from malleating. You're always able to re-sign yourself. -- Pieter -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Oh, no, sorry, it also covers bip62. On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón jti...@jtimon.cc wrote: s7r you may be interested in this video explaining several aspects of malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs It is pre BIP62, but I believe it is very relevant and will hopefully clear some of your doubts. The signer of TX1 will always be able to change the signature and thus the tx ID. On Sat, Apr 18, 2015 at 4:49 PM, s7r s...@sky-ip.org wrote: Understood. That is unfortunate, but not the end of the world. If you could please give feedback also to these last comments / questions: How far are we at this moment from BIP62? Can an user send a non-malleable tx now, if enforces some additional rules? As for the security of the system, it does not fully rely on txids being non malleable, but see this quote from my previous email: [QUOTE] I am trying to build a bitcoin contract which will relay on 3 things: - coinjoin / txes with inputs from multiple users which are signed by all users after they are merged together (every user is sure his coins will not be spent without the other users to spend anything, as per agreed contract); - pre-signed txes with nLockTime 'n' weeks. These txes will be signed before the inputs being spent are broadcasted/confirmed, using the txid provided by the user before broadcasting it. Malleability hurts here. - P2SH Another thing I would like to confirm, the 3 pieces of the bitcoin protocol mentioned above will be supported in _any_ future transaction version or block version, regardless what changes are made or features added to bitcoin core? The contract needs to be built and left unchanged for a very very long period of time... [/END QUOTE] Can you comment on the quote please? So, basically transaction malleability could affect the system in the way that a pre-signed tx which offers the insurance and which is sent to the user before the user sends the coins (spending user's coins back to him after a certain period of time) could be invalidated. The insurance tx signature will still be good, but invalid overall since the input (txid) being spent does not exist (was altered / modified). The coins won't be stolen or lost, but a new tx needs to be signed with the altered (new) txid, for the system to work. So, an user creates a transaction TX1 sending the coins to the server but does not broadcast it. Instead, he provides the txid of TX1 to the server. Server generates another transaction TX2 which spends TX1 back to the user, with an nLockTime. User checks and if everything ok broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2 will become invalid (since it will be spending an inexistent input), and the server will need to re-create and sign TX2 with the new (altered/modified) txid of TX1, as per agreed contract. Should the server disappear after user broadcasts TX1 and before the altered/modified txid of TX1 gets confirmed, user's coins are forever locked. It is true that no third party can benefit from this type of attack, only the user will result with coins locked, but it is something which could be used by competition to make a service useless / annoying / too complicated or less safe to use. How could I mitigate this? Thanks you for your time and help. On 4/17/2015 12:02 PM, Pieter Wuille wrote: Anyone can alter the txid - more details needed. The number of altered txids in practice is not so high in order to make us believe anyone can do it easily. It is obvious that all current bitcoin transactions are malleable, but not by anyone and not that easy. At least I like to think so. Don't assume that because it does not (frequently) happen, that it cannot happen. Large amounts of malleated transactions have happened in the past. Especially if you build a system depends on non-malleability for its security, you may at some point have an attacker who has financial gain from malleation. From your answer I understand that right now if I create a transaction (tx1) and broadcast it, you can alter its txid at your will, without any mining power and/or access to my private keys so I would end up not recognizing my own transaction and probably my change too (if my systems rely hardly on txid)? In theory, yes, anyone can alter the txid without invalidating it, without mining power and without access to the sender's private keys. All it requires is seeing a transaction on the network, doing a trivial modification to it, and rebroadcasting it quickly. If the modifies version gets mined, you're out of luck. Having mining power helps of course. After BIP62, you will, as a sender, optionally be able to protect others from malleating. You're always able to re-sign yourself. -- Pieter -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in
[Bitcoin-development] Fwd: Reusable payment codes
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So this requires making dust payments to a constantly reused address in order to (ab)use the blockchain as a messaging layer. Indeed, this is more SPV compatible; but it seems likely to me that _in practice_ it would almost completely undermine the privacy the idea hoped to provide; because you'd have an observable linkage to a highly reused address. I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee. It would also more than double the data sent for the application where 'stealth addresses' are most important: one-time anonymous donations (in other contexts; you have two way communication between the participants, and so you can just given them a one off address without singling in the public network.) Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses. As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses. This kind of binding was intentionally designed out of the stealth address proposal; I think this scheme can be made to work without any increase in size by reusing the payment code as the ephemeral public key (or actually being substantially smaller e.g. use the shared secret as the chain code, but I should give it more thought) With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. This is fundamentally more expensive to compute; please don't specify uncompressed. Taking the SHA512 of something less than 512 bits seemed wrong. This appears incompatible with multisignature; which is unfortunate. I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. I'm disappointed that there isn't any thought given to solving the scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses. Are you aware of the IBE approach that allows someone to request a third party scan for them with block by block control over their delegation of scanning? I suspect this is a case where we just can't have all the features we want. In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup. Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile. In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address). In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Reusable payment codes
I have pushed an updated version of the proposal which incorporates some of the received feedback and adds a note about the consequences of sharing a payment code-enabled walled on multiple devices: https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier justus.ranv...@monetas.net wrote: On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So this requires making dust payments to a constantly reused address in order to (ab)use the blockchain as a messaging layer. Indeed, this is more SPV compatible; but it seems likely to me that _in practice_ it would almost completely undermine the privacy the idea hoped to provide; because you'd have an observable linkage to a highly reused address. I agree that the output associated with notification transactions would require special handling to avoid privacy leaks. At a minimum they'd require mixing or being donated to miners as a transaction fee. It would also more than double the data sent for the application where 'stealth addresses' are most important: one-time anonymous donations (in other contexts; you have two way communication between the participants, and so you can just given them a one off address without singling in the public network.) Communication is only one way, except for the case in which the recipient wants to send a refund. Assuming no refund and only a single anonymous donation in the lifetime of the sender's identity, payment codes would require 65 bytes vs 40 bytes for stealth addresses. As soon as the sender sends more than one donation to the same recipient, payment codes show an space advantage over stealth addresses. This kind of binding was intentionally designed out of the stealth address proposal; I think this scheme can be made to work without any increase in size by reusing the payment code as the ephemeral public key (or actually being substantially smaller e.g. use the shared secret as the chain code, but I should give it more thought) With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. This is fundamentally more expensive to compute; please don't specify uncompressed. Taking the SHA512 of something less than 512 bits seemed wrong. This appears incompatible with multisignature; which is unfortunate. I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. I'm disappointed that there isn't any thought given to solving the scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses. Are you aware of the IBE approach that allows someone to request a third party scan for them with block by block control over their delegation of scanning? I suspect this is a case where we just can't have all the features we want. In this proposal I optimized for non-reliance on third party services and a guaranteed ability to recover spendable funds from a seed backup. Gaining those two features resulted in some tradeoffs as you noted, but I think there are enough benefits to make them worthwhile. In particular, payment codes could be the basis for a Heartbleed-free payment protocol that can positively identify customers and automatically provide refund capabilities in a merchant-customer relationship. A merchant only requires one payment code which they can safely use for all their customers, meaning they only ever need to associate 65 bytes with their identity to allow customers to make sure they are paying the right entity. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. This would make thefts easier (without involving address reuse as in locking withdrawals to a single P2PKH address). In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Reusable payment codes
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier justus.ranv...@monetas.net wrote: Taking the hash of the secret would then require an extra step to make sure the hash is valid for secp256k1. The x value may not be a valid member of the group, effectively the same as with a hash. Its also very unequally distributed, as only about half the possible values are points on the curve. ack With 97 byte standard OP_RETURN values the ephemeral public key could be appended to the chain code, but that's undesirable for other reasons. Can you elaborate? Storing a ~33 byte (deterministically generated) ephemeral key should be all that is required. Everything else, including the chain code could be derived from it. What reason do you have to include additional data? The goal of the notification transaction is to send the same payment code to every recipient, but obscure the identity of the sender of the notification transaction from third party blockchain observers. The shared secret is used for that purpose, and the sender's public key used for ECDH can't be one derived from the payment code since the recipient doesn't yet know the payment code. The notification transaction needs to communicate the 65 byte payment code along with one ephemeral public key used for ECDH. If that ephemeral key is not located in a signature script, it has to be somewhere else (such as in the same OP_RETURN output as the payment code.) Taking the SHA512 of something less than 512 bits seemed wrong. Why should it? Adding the Y does not increase the entropy at all. As an aside, I think this can be reformulated to only need 256 bits of output, and then the need for yet-another-hash-function could be avoided in some cases. Already fixed in https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 but it would be good to get confirmation of whether the way I fixed it is valid. In this proposal I optimized for non-reliance on third party services The requirement for inputs is a guaranteed dependency on third party services; so if thats whats being optimized for here it must go (well, I think it must go for the reason of avoiding blocking users from using other schemes to control their coins too..). I'm not sure what you mean by the requirement for inputs is a guaranteed dependency on third party services At the proposal currently stands, an SPV wallet will have no trouble sending or receiving notification transactions without access to a third party service. The recipient just needs to see the transactions associated with its notification address. The point about restricting the types of scripts used as inputs is valid, but I think workarounds are available. If nothing else, the sender can make a suitable input using it's own (suitably mixed) coins first. I agree. I could not find a straightforward way to express a multisignature payment code in less than 80 bytes. A prior stealth address proposal here handled them fine with only a single ephemeral point in the op_return. It does result in a longer address (is that what you're referring to with '80 bytes'?) I considered defining an additional path level for deterministic m-of-n multisig and adding a few bytes to the payment code to express those parameters, but thought it would be too limiting since it would preclude multisig with truly independent keys. It is a thing that could be done, however. Exchanges could restrict bitcoin withdrawals to a single payment code known to be associated with their identified customer. In some jurisdictions the ability to prove that withdrawals are sent to a positively-identified party, rather than arbitrary third parties, might move some Bitcoin businesses out of money transmitter territory into less onerous regulatory situations. But this mandates horrible key management practices, reliance on a single hardcoded private key which you cannot change; even if it might be compromised or lost to the wind. It's less horrible than sticking to a single address because it doesn't wedge privacy, I agree; but care should be taken that a tortured dance for confused regulatory cargo-cult reasons doesn't mandate people not engage in sound practices like periodic key rotation. :) Cold storage is still available (if admittedly less convenient than in traditional wallets). I would expect exchanges in practice to allow for payment codes to be changed, just with non-trivial waiting periods and plenty of human overview. It would be an infrequent event compared to the frequency of withdrawals. Various schemes which use public key authentication instead of passwords for web site authentication could be used to continually verify that the user hasn't lost access to the key. -- One dashboard for servers and applications across
Re: [Bitcoin-development] Reusable payment codes
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier justus.ranv...@monetas.net wrote: https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki This link contains an RFC for a new type of Bitcoin address called a payment code Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses which provide useful features such as positively identifying senders to recipients and automatically providing for transaction refunds. So this requires making dust payments to a constantly reused address in order to (ab)use the blockchain as a messaging layer. Indeed, this is more SPV compatible; but it seems likely to me that _in practice_ it would almost completely undermine the privacy the idea hoped to provide; because you'd have an observable linkage to a highly reused address. It would also more than double the data sent for the application where 'stealth addresses' are most important: one-time anonymous donations (in other contexts; you have two way communication between the participants, and so you can just given them a one off address without singling in the public network.) Alice selects the first exposed public key of the first input of the transaction So this creates strong binding that we would really strongly like to avoid in the network; basically what this says is that You can only pay to person X if you use scheme Y for your own Bitcoins-- who says any of your inputs have a ECDH pubkey at all? Of if they do, who says its one that you have access to the private key for for use in this scheme (e.g. it could be in a HSM that only signs according to a policy). We should avoid creating txout features that restrict what kind of scriptPubkey the sender can use, or otherwise we'll never be able to deploy new signature features. (We can see how long P2SH took to gain adoption because some wallets refused to implement sending to it, even though doing so was trivial). This kind of binding was intentionally designed out of the stealth address proposal; I think this scheme can be made to work without any increase in size by reusing the payment code as the ephemeral public key (or actually being substantially smaller e.g. use the shared secret as the chain code, but I should give it more thought) Also, SPV wallets do not need to have access to the public keys being spent by a particular transaction they learn about; providing that access is fundamentally expensive and pushes things back towards centralization. in uncompressed DER format This is fundamentally more expensive to compute; please don't specify uncompressed. This appears incompatible with multisignature; which is unfortunate. I do very much like the fact that this scheme establishes a shared chain once and then doesn't need to reestablish; this was one of the improvements I wanted for the stealth address. I'm disappointed that there isn't any thought given to solving the scanning privacy without forcing non-private pure-overhead messaging transactions on heavily reused addresses. Are you aware of the IBE approach that allows someone to request a third party scan for them with block by block control over their delegation of scanning? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On Thu, Apr 16, 2015 at 9:12 AM, s7r s...@sky-ip.org wrote: Thanks for your reply. I agree. Allen has a good point in the previous email too, so the suggestion might not fix anything and complicate things. The BIP 62 approach to malleability isn't the only option. Another approach is to sign the transaction in such a way that the input txid's are allowed to change without invalidating the signatures. That way, if malleability happens, you just adjust you transaction to match and re-broadcast. That proposal is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md The Build your own nHashType thread on this mailing list contains the discussion. I personally prefer this solution, since it nails the problem completely with one simple and obvious change. The BIP 62 approach is more like a game of wac-a-mole. -William -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson swanson...@gmail.com wrote: On Thu, Apr 16, 2015 at 9:12 AM, s7r s...@sky-ip.org wrote: Thanks for your reply. I agree. Allen has a good point in the previous email too, so the suggestion might not fix anything and complicate things. The BIP 62 approach to malleability isn't the only option. Another approach is to sign the transaction in such a way that the input txid's are allowed to change without invalidating the signatures. That way, if malleability happens, you just adjust you transaction to match and re-broadcast. That proposal is here: This is not a free choice. There are several concerns, from mild to severe, that arise when you do not sign enough. In particular not covering the ID allows for transaction replay which can result in monetary losses far more severe than any possible mishandling of malleability could result in. Byzantine attackers can costlessly replay your old transactions any time anyone reuses an address, even accidentally (which cannot be easily prevented since they can race). Other fun effects also show up like being able to backwards compute signatures to result in a kind of limited covenant- coins which can only be spent a particular way which has some implications for fungibility. (See here for a discussion in general of covenants: https://bitcointalk.org/index.php?topic=278122.0) There are no free lunches; the proposal linked to there is itself a game of wack-a-mole with assorted masking flags; many of which we have no notion of if they're useful for any particular application(s); and it doesn't provide tools to address the replay issue; and in order to 'improve' malleability via that mechanism you must always mask out the inputs completely; meaning you'd always be exposed to replay and not just in specialized 'contract' applications where there won't be address reuse could be a strong assumption enforced by the application. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki This link contains an RFC for a new type of Bitcoin address called a payment code Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses which provide useful features such as positively identifying senders to recipients and automatically providing for transaction refunds. Payment codes can be publicly advertised and associated with a real-life identity without causing a loss of financial privacy. Compared to stealth addresses, payment codes require less blockchain data storage. Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair, while stealth addresses require 40 bytes per transaction. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo 2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h /wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9 EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+ SGApMBd4Q89fKzL2djae =Dypr -END PGP SIGNATURE- -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
