Re: [Bitcoin-development] Proof-of-Stake branch?
I can't remember who I saw discussing this idea. Might have been Vitalik Buterin? Yes, he described it in an article a couple of months ago: http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ but it is an old idea. For example, I've mentioned punishment of this kind in discussion about PPCoin when it was released in 2012, and, I think, it was described in Etlase2's Decrit design. Also, I and Iddo did some research on pure proof-of-stake, and it seems to be feasible, in the sense that there are no obvious problems like nothing is actually at stake. (Unfortunately I can't refer to it now as it isn't published yet.) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Replace-by-fee scorched-earth without child-pays-for-parent
Someone who wanted to remain anonymous sent me in this idea, which I'll admit I'm kicking myself for not having thought of earlier. They sent me this hash so they can claim credit for it later should they choose to reveal their identity: bb0de552f81fa356b99fbeef65fa532bb5884efee2cbe92f66509af8d151 When Alice wants to pay Bob x bitcoins, rather than creating a single transaction, tx1, that does that, she creates a pair of transactions, with the second, tx2, spending the same inputs and an input provided by Bob, but paying x*k bitcoins to fees. Should Bob detect a double-spend he simply signs the extra input, making it clear that he intended for the countermeasure to be deployed, and broadcasts tx2. This mechanism has two advantages: 1) child-pays-for-parent isn't required at avoiding changes to the relaying code and letting the counter-transaction propagate quickly. 2) k can be adjusted such that Alice is guaranteed to be worse off for attempting a double-spend even taking into account the probability of getting away with it. For instance, right now if just, say, Eligius adopted replace-by-fee a k value of 20 would still make double-spends unprofitable. However it does require payment protocol support. This lead me to realize that if Alice signs all her inputs with the ANYONECANPAY sighash bit set Bob can get the same effect by adding his own inputs to bump the effective fee. While of course the funds to do so come out of his own pocket, they are balanced out by the payment to him, with the net effect being the same as the child-pays-for-parent version. Additionally in the common case of Bob would like Alice's transaction to go through sooner this also gives Bob the flexibility to add small sized inputs at will to bump fees. (or for that matter Alice, giving a small privacy boost) Using ANYONECANPAY does have one disadvantage in that transactions using it are always malleable. However an attacker doing so is forced to spend funds to do that. Secondly after the recent malleability attacks wallet handling of malleability-related problems has greatly improved. Finally it's worth noting how the k-overpaying version of scorched-earth gives Finney attacking(1) miners - such as BitUndo - incentives to defect knowing that they can earn significantly more fees by publishing their supposedly secret transactions to the p2p network. Equally even in the ANYONECANPAY version merchants may decide that discouraging fraud is worth an overpayment. 1) https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384 -- 'peter'[:-1]@petertodd.org 603b189f99cf2a95ce01835596b5d5fbd8c5725c11f504ee signature.asc Description: Digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal to change payment protocol signing
There is a discussion about clarifying how BIP70 signs payment requests here: https://github.com/bitcoin/bips/pull/41 The issue is what to do with the signature field before signing. The code Mike and I initially wrote does this: request.set_signature(string()); (sets signature to the empty string) I think that is a mistake; it should be: request.clear_signature(); (clears signature field, so it is not serialized at all). So: if you are implementing, or have implemented, the payment protocol, please chime in. I'd like to change the spec and the reference implementation NOW, while BIP70 is still a 'Draft'. Because this type of hey, I'm implementing your standard and it doesn't work the way I think it should mistake is exactly why BIPs take a while before being declared 'Final.' -- -- Gavin Andresen -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
On 27/04/2014 02:05 p.m., Mark Friedenbach wrote: On 04/27/2014 05:36 AM, Sergio Lerner wrote: Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks. I argue that you cannot talk about the most-work chain without actually making an assumption about honest peers. I should have said without invoking moon math or interactive protocols requiring honest peers over jamming-free networks. The interactive protocol was more the point than the honest peers and jamming-free network. Yes, without an honest peer and an un-jammed network, you might never learn about the most-work chain in the first place. But having the security of the proof not depend on query access to an honest full node is absolutely necessary for some applications and certainly desirable in others. The problem is not having or not access to a honest full node. The SPV client MUST have access to a honest full node sometime. The problem is WHEN. One can make the security assumption that during an attack (someone gives you a fake block) you also loose the possibility to reach any honest node. Then SPV proofs come into play. Here are the security assumptions I added to my post about SmartSPV to clarify this: *Security Assumptions * First let’s review the main security assumption of headers-only SPV: * The attacker does not control all your communications with the payment network. This means that there is at least a single connected peer that behaves honestly. This assumption is quite strong and may not hold during short periods of time, such as during application power-on (when only a few peers have been connected), or when moving to a place where the ISP is untrusted. For SmartSPV we’ll require weaker security assumptions: * The attacker cannot control all your communications with the payment network for more than a fixed period of time (e.g. 2016 blocks for Bitcoin or approximately 15 days) * The attacker is rational: it won’t spend an huge amount of money to steal a much smaller amount. This assumptions imply that the attacker may control all your Internet connections while he sends you a malicious block branch containing a fake payment to you. First this is a method that uses NPPs, not SPV proofs. Since the method chooses all peers that are synchronized (have the latest current block) then going back means only skipping a potential short fork (which I suppose has never been more than 3 blocks during normal network conditions). You're looking for a common ancestor, not the checkpoint. So the linear scan is actually O(1). The exact value can be approximated by the sum of the convergent infinite geometrical sequence of forking probabilities, which it's about 1.03 without considering selfish-mining, and probably less than 2.03 considering it. Unless you're connected to attacker nodes which are wildly divergent from each other. It's relatively easy to create a massive fake history of difficulty-1 blocks. Since in my use case (SmartSPV) I proposed you start from the most recent block and go backwards, the attacker must compete in PoW with the real current difficulty informed. Suppose the SPV client looks for 6-block chains backwards starting from the last current block. Suppose you know or estimate the current network difficulty. Suppose a malicious peer creates a fake 6-block chain Cm and the honest peer gives you the 6-block chain Ch. If Ch has not the expected work it's discarded. If both has the expected work, then you better not true any of them and walk their parents until you find a common parent. That's the block you should trust. If you don't have an honest node connected, then the only decide to trust or not Cm is by it's accumulated work (and you have already a bound for it) If you assume honest peers things get very easy. But that's not a safe assumption to be making. With back-link block-history commitments, on the other hand, an interactive protocol allows you to do a binary search to find common ancestors, and have trust that the intermediate links actually exist. So you agree that: you need a periodic connection to a honest node, but during an attack you may loose that connection. This is the assumption we should be working on, and my use case (described in http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/) assumes that. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to
Re: [Bitcoin-development] Proposal to change payment protocol signing
Who cares what it is? Setting to an empty byte array is fine, IMO. The payment protocol is already rolling out. It's implemented in several wallets, BitPay implements it, Coinbase is implementing it, etc. -10 for changing such a basic thing at this point. It'd cause chaos for the early adopters, punishing them instead of rewarding them. It'd seriously hurt adoption of the payment protocol when it's at its most vulnerable. We should mark BIP 70 as accepted and be done with it. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
On 04/28/2014 07:32 AM, Sergio Lerner wrote: So you agree that: you need a periodic connection to a honest node, but during an attack you may loose that connection. This is the assumption we should be working on, and my use case (described in http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/) assumes that. No, that's sortof tangential. What you are solving is some higher level application on top of SPV proofs, compact or otherwise. SPV proofs have many broad applications, such as 2-way pegs where proof-of-work is used to reach consensus over the most-work side-chain header, and a non-51% attack is detectable from observed difficulty and interblock times. Do you need an honest peer to learn about the best chain? Yes. Do you need to *trust* that you have an honest peer? No, because a non-51% attack against you is probabilistically detectable with existing tools. Maybe SmartSPV is useful, maybe not. The application domain is not something I've been concerned with in the past. But what you describe is a higher-level protocol that uses block headers to determine which chain to trust. My simple point from the start has been that you can use back-link commitments and compact SPV proofs to accomplish what you want fewer messages, less bandwidth, and equal security. The two proposals are not in conflict with each other. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to change payment protocol signing
Agreed with Mike. It doesn't really matter what the signature field is set to. Changing the standard now is too hard with too little benefit. On 4/28/14, 12:14 PM, Mike Hearn wrote: Who cares what it is? Setting to an empty byte array is fine, IMO. The payment protocol is already rolling out. It's implemented in several wallets, BitPay implements it, Coinbase is implementing it, etc. -10 for changing such a basic thing at this point. It'd cause chaos for the early adopters, punishing them instead of rewarding them. It'd seriously hurt adoption of the payment protocol when it's at its most vulnerable. We should mark BIP 70 as accepted and be done with it. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ryan X. Charles Software Engineer, BitPay 0xA11B4DDE.asc Description: application/pgp-keys -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
