Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
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 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
[Bitcoin-development] Bitcoin Core 0.10.1 released
Bitcoin Core version 0.10.1 is now available from: https://bitcoin.org/bin/bitcoin-core-0.10.1/ The distribution is also available as torrent: https://bitcoin.org/bin/bitcoin-core-0.10.1/bitcoin-0.10.1.torrent magnet:?xt=urn:btih:b6f8da60aaf2007cd6db631637951ae673e31044dn=bitcoin-core-0.10.1tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannouncetr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969tr=udp%3A%2F%2Fopen.demonii.com%3A1337ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F The source code can be found in git under the tag `v0.10.1`, or in `bitcoin-0.10.1.tar.gz` in the distribution. This is a new minor version release, bringing bug fixes and translation updates. It is recommended to upgrade to this version. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading = How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). Downgrade warning -- Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software: * Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this. * The block index database will now hold headers for which no block is stored on disk, which earlier versions won't support. If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex. This does not affect wallet forward or backward compatibility. Notable changes === This is a minor release and hence there are no notable changes. For the notable changes in 0.10, refer to the release notes for the 0.10.0 release at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md 0.10.1 Change log = Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates. RPC: - `7f502be` fix crash: createmultisig and addmultisigaddress - `eae305f` Fix missing lock in submitblock Block (database) and transaction handling: - `1d2cdd2` Fix InvalidateBlock to add chainActive.Tip to setBlockIndexCandidates - `c91c660` fix InvalidateBlock to repopulate setBlockIndexCandidates - `002c8a2` fix possible block db breakage during re-index - `a1f425b` Add (optional) consistency check for the block chain data structures - `1c62e84` Keep mempool consistent during block-reorgs - `57d1f46` Fix CheckBlockIndex for reindex - `bac6fca` Set nSequenceId when a block is fully linked P2P protocol and network code: - `78f64ef` don't trickle for whitelisted nodes - `ca301bf` Reduce fingerprinting through timestamps in 'addr' messages. - `200f293` Ignore getaddr messages on Outbound connections. - `d5d8998` Limit message sizes before transfer - `aeb9279` Better fingerprinting protection for non-main-chain getdatas. - `cf0218f` Make addrman's bucket placement deterministic (countermeasure 1 against eclipse attacks, see http://cs-people.bu.edu/heilman/eclipse/) - `0c6f334` Always use a 50% chance to choose between tried and new entries (countermeasure 2 against eclipse attacks) - `214154e` Do not bias outgoing connections towards fresh addresses (countermeasure 2 against eclipse attacks) - `aa587d4` Scale up addrman (countermeasure 6 against eclipse attacks) - `139cd81` Cap nAttempts penalty at 8 and switch to pow instead of a division loop Validation: - `d148f62` Acquire CCheckQueue's lock to avoid race condition Build system: - `8752b5c` 0.10 fix for crashes on OSX 10.6 Wallet: - N/A GUI: - `2c08406` some mac specifiy cleanup (memory handling, unnecessary code) - `81145a6` fix OSX dock icon window reopening - `786cf72` fix a issue where command line options-action overwrite Preference-action (on OSX) Tests: - `1117378` add RPC test for InvalidateBlock Miscellaneous: - `c9e022b` Initialization: set Boost path locale in main thread - `23126a0` Sanitize command strings before logging them. - `323de27` Initialization: setup environment before starting QT tests - `7494e09` Initialization: setup environment before starting tests - `df45564`
Re: [Bitcoin-development] Proof of Payment
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
Re: [Bitcoin-development] Proof of Payment
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
Re: [Bitcoin-development] Reusable payment codes
Hi Justus: CC'ing mailing list because more bloom filter and HD wallet experts there can chime in for some of these thoughts. I refined some ideas we went over earlier. Here are some critiques/worries about the payment codes. With identities explicitly tied to a payment code, bloom filter clients can have identities tied to them. 1. There will be a 1:1 relationship between a payment code owner and their identity. Presumably the payment code would be strongly and publicly tied to the identity. This makes the notification address strongly tied to the user. An SPV client connecting to a full node who has a list of notification address can tie an identity to a bloom filter and connecting IP. 2. The client can use a bloom filter with a higher false positive rate. An active attacker can counter that by sending several payment codes to an individual user. The user would then add to their bloom filter all the shared addresses between them and the attacker. Even with a high false positive filter, always matching all the attacker's payment codes would strongly tie the user to the filter. Here are some data savings and privacy addition ideas: 65 bytes - 0 bytes extra. 1. Can you choose only even or odd DER encoding? That would save you 1 byte. This would probably throw out 50% of possible addresses though. 2. Can the chain code be fixed or derived from the x value? Could the chain value be the x value itself? (The main question is can a deterministic public seed be represented as a single 32 bit number? Maybe the chain code can be a constant. Maybe it is ok since subsequent pubkeys are derived from this. I only know enough crypto to be dangerous.) That would save you 32 bytes. Someone who understands HD wallets would be better to look at this one. it would probably be a non-standard derivation. That leaves you with 32 bytes to communicate to bootstrap the channel. 3: Since you are already looking at the pubkey of the transaction sending the notification transaction, then you are assuming control of the sending mechanism. If you can be sure to use a disposable bitcoin address to send the notification, then 1 more savings might be possible. Also assuming the above two points are possible. Can you encode the x value into the signature's R value? This would basically make this transaction look like a standard bitcoin transaction and gets rid of the op_return completely. I still like the idea of a common meeting point, a la bitmessage. The receiver of the payment code would trial-decode all payment codes sent to a common pre-specified dead drop address (perhaps a charity address). to send me money, first donate to this charity of my choice. This trades off more work on the receivers part to get some privacy as to the number of people interacting with that receiver. -cheers -Brian Deery -- 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] Reusable payment codes
1. There will be a 1:1 relationship between a payment code owner and their identity. Bear in mind, the spec defines identity to mean: *Identity is a particular extended public/private key pair. * So that's not quite what is meant normally by identity. It's not a government / real name identity or an email address or phone number kind of identity. -- 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] Reusable payment codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 04:46 PM, Mike Hearn wrote: So that's not quite what is meant normally by identity. It's not a government / real name identity or an email address or phone number kind of identity. I expect that mappings would begin to develop between payment codes and government / real name identities, at least as far as that businesses which are required to collect that kind of information would associate it with the payment code(s) known to be used by their customers for their own use. I proposed payment codes in this form because I'd rather see that kind of mapping be limited to the application layer and kept away from the blockchain/network layer. Even if it makes certain kind of application-layer distasteful behavior easier, it's a good trade if doing so can simultaneously provide resistance to graph analysis and make transaction-level censorship more difficult. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVPmusAAoJECpf2nDq2eYjhxIP/3Jw9f6kcEsdFTXouQ5+D5gb MjM8AW7EEA6KXj2PqrPv/H/brorW9/Ugcc8KweCjEdJAKOJV/Bl6sP5ydSZT6pmj A0IFIkbdxKLY9JC3BbmVHuiAFrsL1u2EX5arUC3WNAWeWlVEmAL92cSlAka4BBxy P/wh8xN0b4hsgA602Y4Btkv2fBHLQI9NMxW3AsujP3/S78mSxwKQZz4lYAMCowu8 NL/3toaFhrUsdHsH301jNAnxEEOodMVGmgjg/ZSdvWeHwdsE2J8Q9AJqiFDswjU5 q2kZuKmuJ6EXcGDlhelUuUpfHO34qS3/dyTydcqFrYB6eynZ8nV6S1SHaSlDEM10 b95+EpfIENtYdgAqJxwfbqpibpSEIW7cxCAopF0sSbQ2qv8rwRrcIah7KeARCrc0 e+HDcyLhYkrWrlK28vVmIxkEiQ/nmkTu9dOfoVJgXxcVl9AkiHGjo7QICOZHqfRB TOupk9UUHMmdfZC5vpj9rd+VSXJJEF19ZbGF1QsFSMuxjKTb9jAy7Dk6U/9/xK9Q +mH6QHhKzNKb8GsiowZJq3bF2mEYqmh/BPyQ06gfDLM4yvlTb+k4R6brFzm7tkWG 49hREmHK9w/wZXnH0lMCqMHRY/YqQF5bR3ujq7pB0WHLvbvDoSvyWvGQ9cVrRA24 ASb47sR77R1LlZntoSyy =b7HG -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] 75%/95% threshold for transaction versions
On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote: Hi William, 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. The two are complementary, not competing. BIP62 prevents *non-signers* from mutating the transactions, which is very important. I strongly disagree. There are exactly two cases where mutation matters to normal wallets: 1) Spending unconfirmed change. This can be more efficiently done by double-spending the first tx with a second that pays both recipients. 2) Large reorganizations. Making mutation impossible makes it more likely that after a large reorg all previously confirmed transactions will make it back to the blockchain succesfully. Meanwhile, the whack-a-mole aspect of BIP62 is worrying - it's very likely we'll miss a case. Even right now there are edge cases without good solutions, like how in a multisig environment any of the key holders can mutate transactions. Building wallets that make strong assumptions about malleability and fail if those assumptions turn out to be wrong is poor engineering. The 'Build your own nHashType' proposal enables chained transactions even in the face of *signers* mutating the transaction. I believe that integrating both will lead to the best defense against transaction malleability, and will enable more complicated uses of chained transactions (such as micropayment channels). While I think there are better ways to do 'Build your own nHashType' than what was recently proposed, I strongly agree that for protocols that really, truly, need malleability resistance it's far better to use a purpose-built signature hashing algorithm. -- '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
