Re: [Bitcoin-development] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The notification transactions are a pain point when it comes to privacy, and yet they must exist in order to to ensure that nobody can lose their money as long as they back up their wallet seed. They could be treated as a backup, however, that clients would not normally rely upon -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVP5DDAAoJECpf2nDq2eYjdLsQAJ/nZKFavcJnCMUQ8hKp6dRq 2+7bAVIWYHuOV6sv/hvG2NaP3u24NYZ/Ji0oD3UAmkJxw9lsZuowwBBs+YAs6JAW KHTl3QtwBh0IP/V90JOZ5Yn72YWXDsNbqy7R3JhEDKOu2wVeiLqWZ2EDgGwiZ0/k aXFJbcVZEKttWYCNoZi0yRMH+S9gbi0LgOwvK9mRzF9IRz07SM1iKQeKPsW1X1UM KNeikFROMS7dHTO5HRGyFcTSwhUf8RJq2kea+4sJtj8Vlb5rURuJanL3Fav+ZZjr RWYubLp9EUrDMm9bciygL8+MKPas8hedHSW2JhjkshWYC/NoCXLBT6SGrrbj2SKL zGGeLYknjwgLTCstKSQlXW3J/xcSFwBztr//o95SwRoIKI7jpuOE6cPfUZVEuTsU Zm7IWuRw/1MMDF89gCtDkBJcX2mTARjiii1Hg0+7vCv6Q/fVgTNUvWEKeNtCNZjh wOiwd4eP1gY4CwX68c+8CfF+NOSXImJTspZJvDQcTge1/bQJNOBn+cMYxjBcJsqL ZUOvkWJqwiFERW7vjMhOVpqIyO38UluwsWgp7nlMl/npfv0ZDIrOqZrswHSTqfdc P8gSaqvpc6cMaLL/ijvOtORkVB9ZlLmlTv6mIYWHeKEf6PjIOZEb2B75zPHFAvrz TKLxjvWgvSJ4l5PrkCFA =1Id2 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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] Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 04:01:00AM -0700, Pieter Wuille wrote: As softforks almost certainly require backports to older releases and other software anyway, I don't think they should necessarily be bound to Bitcoin Core major releases. If they don't require large code changes, we can easily do them in minor releases too. The code changes for absolute CLTV are quite small, and easily ported to any Bitcoin Core version. What's the oldest version you think we need backports for? -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 signature.asc Description: Digital 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
Re: [Bitcoin-development] Bitcoin core 0.11 planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY implemented on Bitcoin will be something like summer 2016, a year and a half after it got adopted on Viacoin. (and a few other alts whose names I forget) Right now the shortest path to adoption would be to release a v0.12 with just a CLTV soft-fork as soon as the BIP66 softfork triggers. While there's been proposal to change the way the upgrade mechanism triggers to a multiple parallel fork scheme, that is quite complex, stateful, and will need lots of review, probably a few months worth; faster would be to continue with the existing mechanism. IMO the main reason to accelerate CLTV is scalability. The only viable scalability improvements possible in the short/medium term that don't entirely rely on trusting third parties are payment channel based. While we have a working payment channel scheme - Jeremy Spilman's refund tx based system - it is fairly complex, needs good and immediate backups, and is susceptible to tx malleability. CLTV fixes those issues robustly. Of course, payment channel schemes can start off with Spilman's scheme first and go to CLTV later, but that is a lot of extra code to be written and later depreciated - I'm sure many authors are dubious about going down that path. Thoughts? On 28 April 2015 03:44:16 GMT-04:00, Wladimir J. van der Laan laa...@gmail.com wrote: Hello all, The release window for 0.11 is nearing, I'd propose the following schedule: 2015-05-01 Soft translation string freeze Open Transifex translations for 0.11 Finalize and close translation for 0.9 2015-05-15 Feature freeze, string freeze 2015-06-01 Split off 0.11 branch Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 2015-07-01 Release 0.11.0 final (aim) In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year. Wladimir -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVP2Wy AAoJEMCF8hzn9LncqOcH/3rDFbgWprqTfk8dKWAItRcY6ZyiQ+dNrqNgymaNP5Ig MNKaTmWYyZRH6PW13JOv72ArXia+D82Mp5reTaLIb3TV5uef2biruOCaH9eI8Uv5 i2PCBLw3uqZIZZ5Qr/7nlp2CaBQIGDK3fg3jx10UyWpg4BxkKP2mLJibMG8l3JcK Moi/kh6lvwySpT8NYtZfXax+5AQ2oLXiSzbFF8P0ioI9fJYaoVCAyS5VEE4KsZnV thOaoPAWoK+spEYKFrjvyXnQXFe6m+KPfRPU3WKYSFhI7m8MW6bKxEnD0Lffo6qU YS6jsE3A0LoKs4kD73ivHcMeXDhO6LXyPAu8zQtgGr8= =Z/GT -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
Re: [Bitcoin-development] Proof of Payment
Hi Jorge, I don't think I understand the question. Proof of Payment is used to prove that you have the credentials needed for a certain transaction. It does not care where in the blockchain the transaction is. Or if it's in the blockchain at all. /Kalle So at the low level, how does a proof of payment differ from just proving that a given transaction is in a given block (what SPV nodes take as proof of payment today)? On Apr 27, 2015 2:42 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Or a really high lock_time, but it would not make it invalid, just delayed. Ok, this was a bad idea, since nodes would have to keep it in memory. Please disregard that idea... Kalle Den 27 apr 2015 14:35 skrev Kalle Rosenbaum ka...@rosenbaum.se: Some more use cases might be: Waiting in comfort: - Send a payment ahead of time, then wander over and collect the goods after X confirmations. Authorized pickup : - Hot wallet software used by related people could facilitate the use of 1 of N multisig funds. Any one of the N wallets could collect goods and services purchased by any of the others. I like this one, because it shows the power of reusing the transaction data structure. Non-monetary gifts: - Sender exports spent keys to a beneficiary, enabling PoP to work as a gift claim Contingent services: - Without Bob's permission, a 3rd party conditions action on a payment made from Alice to Bob. For example, if you donated at least .02 BTC to Dorian, you (or combining scenarios, any of your N authorized family members), can come to my dinner party. This is an interesting one. I tried out your demo wallet and service and it worked as advertised. Could the same standard also be used to prove that a transaction COULD BE created? To generalize the concept beyond actual payments, you could call it something like proof of payment potential. I guess it's possible, but we'd have to remove the txid from the output, since there is none. This is a way of saying I'm in control of these addresses. The other party/parties can then verify the funds on the blockchain and watch those addresses for changes. Maybe there are some interesting use cases here. Ideas? Why not make these proofs permanently INVALID transactions, to remove any possibility of their being mined and spending everything to fees when used in this way, and also in cases involving reorganizations? Yes. Initially I thought it would be enough that the funds are already spent, but I think you're right here. Reorgs could be a problem. Worse, you also might want to prove 0-confirmation transactions, in which case it's a huge security problem. Someone might intercept the PoP and publish it on the bitcoin network, spending all the funds. But I still would like wallets to be able to build/verify PoPs with little or no modifications. Could we possibly change the version number on the PoP to something other than 1? Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid, just delayed. Any suggestions here? I agree that PoP seems complementary to BIP70. Thank you very much for your comments! /Kalle -- 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 -- 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] Proof of Payment
Forget it, sorry, I misunderstood the proposal entirely, re-reading with more care... On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Hi Jorge, I don't think I understand the question. Proof of Payment is used to prove that you have the credentials needed for a certain transaction. It does not care where in the blockchain the transaction is. Or if it's in the blockchain at all. /Kalle So at the low level, how does a proof of payment differ from just proving that a given transaction is in a given block (what SPV nodes take as proof of payment today)? On Apr 27, 2015 2:42 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Or a really high lock_time, but it would not make it invalid, just delayed. Ok, this was a bad idea, since nodes would have to keep it in memory. Please disregard that idea... Kalle Den 27 apr 2015 14:35 skrev Kalle Rosenbaum ka...@rosenbaum.se: Some more use cases might be: Waiting in comfort: - Send a payment ahead of time, then wander over and collect the goods after X confirmations. Authorized pickup : - Hot wallet software used by related people could facilitate the use of 1 of N multisig funds. Any one of the N wallets could collect goods and services purchased by any of the others. I like this one, because it shows the power of reusing the transaction data structure. Non-monetary gifts: - Sender exports spent keys to a beneficiary, enabling PoP to work as a gift claim Contingent services: - Without Bob's permission, a 3rd party conditions action on a payment made from Alice to Bob. For example, if you donated at least .02 BTC to Dorian, you (or combining scenarios, any of your N authorized family members), can come to my dinner party. This is an interesting one. I tried out your demo wallet and service and it worked as advertised. Could the same standard also be used to prove that a transaction COULD BE created? To generalize the concept beyond actual payments, you could call it something like proof of payment potential. I guess it's possible, but we'd have to remove the txid from the output, since there is none. This is a way of saying I'm in control of these addresses. The other party/parties can then verify the funds on the blockchain and watch those addresses for changes. Maybe there are some interesting use cases here. Ideas? Why not make these proofs permanently INVALID transactions, to remove any possibility of their being mined and spending everything to fees when used in this way, and also in cases involving reorganizations? Yes. Initially I thought it would be enough that the funds are already spent, but I think you're right here. Reorgs could be a problem. Worse, you also might want to prove 0-confirmation transactions, in which case it's a huge security problem. Someone might intercept the PoP and publish it on the bitcoin network, spending all the funds. But I still would like wallets to be able to build/verify PoPs with little or no modifications. Could we possibly change the version number on the PoP to something other than 1? Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid, just delayed. Any suggestions here? I agree that PoP seems complementary to BIP70. Thank you very much for your comments! /Kalle -- 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 -- 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] Proof of Payment
So at the low level, how does a proof of payment differ from just proving that a given transaction is in a given block (what SPV nodes take as proof of payment today)? On Apr 27, 2015 2:42 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Or a really high lock_time, but it would not make it invalid, just delayed. Ok, this was a bad idea, since nodes would have to keep it in memory. Please disregard that idea... Kalle Den 27 apr 2015 14:35 skrev Kalle Rosenbaum ka...@rosenbaum.se: Some more use cases might be: Waiting in comfort: - Send a payment ahead of time, then wander over and collect the goods after X confirmations. Authorized pickup : - Hot wallet software used by related people could facilitate the use of 1 of N multisig funds. Any one of the N wallets could collect goods and services purchased by any of the others. I like this one, because it shows the power of reusing the transaction data structure. Non-monetary gifts: - Sender exports spent keys to a beneficiary, enabling PoP to work as a gift claim Contingent services: - Without Bob's permission, a 3rd party conditions action on a payment made from Alice to Bob. For example, if you donated at least .02 BTC to Dorian, you (or combining scenarios, any of your N authorized family members), can come to my dinner party. This is an interesting one. I tried out your demo wallet and service and it worked as advertised. Could the same standard also be used to prove that a transaction COULD BE created? To generalize the concept beyond actual payments, you could call it something like proof of payment potential. I guess it's possible, but we'd have to remove the txid from the output, since there is none. This is a way of saying I'm in control of these addresses. The other party/parties can then verify the funds on the blockchain and watch those addresses for changes. Maybe there are some interesting use cases here. Ideas? Why not make these proofs permanently INVALID transactions, to remove any possibility of their being mined and spending everything to fees when used in this way, and also in cases involving reorganizations? Yes. Initially I thought it would be enough that the funds are already spent, but I think you're right here. Reorgs could be a problem. Worse, you also might want to prove 0-confirmation transactions, in which case it's a huge security problem. Someone might intercept the PoP and publish it on the bitcoin network, spending all the funds. But I still would like wallets to be able to build/verify PoPs with little or no modifications. Could we possibly change the version number on the PoP to something other than 1? Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid, just delayed. Any suggestions here? I agree that PoP seems complementary to BIP70. Thank you very much for your comments! /Kalle -- 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 -- 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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
Even if it's new and has not received any feedback, I think my solution to op_maturity is quite clean. But anyway, yes, the non-relative cltv is much simpler in design and doesn't have to wait for the other. On the other hand, I would upgrade it to absolute cltv like you suggested and take the current height as a parameter to verifyScript instead of using the nLockTime as reference. If we know we're going to use it for rcltv/op_maturity, better put add soon rather than later, specially if that will give us a more powerful cltv. If we don't want that height param, we can leave it out of for op_maturity too, but that's the wingle decision about rcltv/maturity that affects cltv so better solve that first. On Apr 27, 2015 9:35 PM, Peter Todd p...@petertodd.org wrote: On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote: And a new softfork rule could enforce that all new CTxIn set nHeight to the correct height in which its corresponding prevout got into the chain. That would remove the need for the TxOutputGetter param in bitcoinconsensus_verify_script, but unfortunately it is not reorg safe (apart from other ugly implementation details). Wait, wait, this can be made reorg-safe and more backards compatible. The new validation rule at the tx validation level (currently in main::CheckInputs()) would be snip So, seems to me that RCLTV opens up a whole rats nest of design decisions and compromises that CLTV doesn't. Yet CLTV itself is a big step forward, it's been implemented on Viacoin for the past few months with no issues found, and has an extremely simple and easy to audit implementation. I think I'm going to argue we implement it as-is in a soft-fork. Pieter Wuille's been working on a new way to handle soft-fork upgrades in the block nVersion field, so this would be a good opportunity to add something simple and well tested, and also make sure the new nVersion soft-fork mechanism works. Equally, doing both at the same time ensures we don't burn yet another version bit. -- 'peter'[:-1]@petertodd.org 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 -- 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] Bitcoin core 0.11 planning
Hello all, The release window for 0.11 is nearing, I'd propose the following schedule: 2015-05-01 Soft translation string freeze Open Transifex translations for 0.11 Finalize and close translation for 0.9 2015-05-15 Feature freeze, string freeze 2015-06-01 Split off 0.11 branch Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 2015-07-01 Release 0.11.0 final (aim) In contrast to former releases, which were protracted for months, let's try to be more strict about the dates. Of course it is always possible for last-minute critical issues to interfere with the planning. The release will not be held up for features, though, and anything that will not make it to 0.11 will be postponed to next release scheduled for end of the year. Wladimir -- 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 27 Apr 2015, at 21:21, Peter Todd p...@petertodd.org wrote: Even right now there are edge cases without good solutions, like how in a multisig environment any of the key holders can mutate transactions. Can't we add requirement for RFC6979 signatures to mitigate this? Of course, multiple signers can still mutate transaction by choosing a different set (but not the order, thankfully) of signatures. Or when a single signer has multiple participating keys. In some interesting to me scenarios mutation by signer is not critical: it is mutation by non-signers that creates a problem. Do you know of any edge cases when non-signers can mutate transactions which are not covered by BIP62? What would be a more robust approach than whack-a-mole to work around mutability? (Normalized tx ids?) -- 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
