Re: [Bitcoin-development] Feedback requested: reject p2p message
But if you are getting soft-forked recent versions of the reference implementation WILL alert you; see this code in main.cpp: Perhaps I'm confused about how we're using the term soft fork. My understanding is that this is where a new upgrade is designed to look valid to old nodes, and if you don't upgrade you rely on the miner majority to get you back on track. For instance, P2SH was done this way - old nodes that didn't upgrade during that transition believed all spends of P2SH outputs were valid, even those spending someone elses coins. In this case, the code you cite won't do anything because your client will never reject a block during a soft-forking upgrade, even if it does something that's supposed to be invalid or nonsensical. If a new block version changes the serialization format or script language or SIGHASH rules such that old clients reject the block, then they will end up on a hard fork and the alerting code will trigger, which is correct and as it should be. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I understand the code correctly, it's not about rejecting blocks. It's about noticing that 50% of recent blocks are declaring a version number that is meaningless to you. Chances are, there's been a soft fork and you should upgrade. On 10/30/13 1:24 AM, Mike Hearn wrote: But if you are getting soft-forked recent versions of the reference implementation WILL alert you; see this code in main.cpp: Perhaps I'm confused about how we're using the term soft fork. My understanding is that this is where a new upgrade is designed to look valid to old nodes, and if you don't upgrade you rely on the miner majority to get you back on track. For instance, P2SH was done this way - old nodes that didn't upgrade during that transition believed all spends of P2SH outputs were valid, even those spending someone elses coins. In this case, the code you cite won't do anything because your client will never reject a block during a soft-forking upgrade, even if it does something that's supposed to be invalid or nonsensical. If a new block version changes the serialization format or script language or SIGHASH rules such that old clients reject the block, then they will end up on a hard fork and the alerting code will trigger, which is correct and as it should be. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScMvBAAoJEAdzVfsmodw4I5sQAL0Wq4e7b6/KX2zl9RmtFl5S qM9ZJkJV8qzirj1hMgVwvnuOj147Vb3EkJujxeMa8ujepXKZ215mMCLnCHPzWPpJ jTtOBn1FCkCUbyt9uSbZ+56NR+ElmSOsDpAJ8IR9VywHriCxm4OIAMCLTR6CKRfr 6NWySvjEMlsSHyr7DFaJTlMqo+KIUWGmP7tdPu1L2AvNE+613dI5q76IjUHYoxhu 2dDtanYUvFCsdLZEnjTr1N45BBf1mTSlPfmA1ZWHgM779h6VIyb0TeO+iCaxpvWp 2RpSDj3+diFdMUK2uu69ZcwkREH0/RoQLOys6U5DfaGkpPtjY0YXB5DwN9quKgzX padWzbQ0flpwWLYOPYrWATz4sWflxZJu6wHAcUkRS5k9crOLVjritXs1205x7YET 0H9jtbqXmBRXidCP2BOZPdq0PGDF8g2VeEHR69JRe3F3dBfSvbgHfKoiF1jpLLqb rttoP+nD4ZRX8FesV2E/DEZgDZJMd8eqDKNDjq7Db4BTDg24Nq2ATNE2fBtenXwI nXVNdmnvjDxjF0weJGlYgaQTfgVwHRxs+j4qgY4VLM0qEYplhHgg+KmOMFUtxAF/ sZv6w56XtCZS3LdNONAJSZzXIcqgmcodiWKVxkTL29dsWKikcBL5cG9ipdfmjQKT eccFOHArsbW3eSfKP/Mb =FSQI -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
On Wed, Oct 30, 2013 at 10:05 AM, Mark Friedenbach m...@monetize.io wrote: If I understand the code correctly, it's not about rejecting blocks. I was referring to the fork alerts that Matt did. They also alert you if there's a missed upgrade. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn m...@plan99.net wrote: I'm really looking forward to this. Currently bitcoinj gets a small but steady stream of bug reports of the form my transaction did not propagate. It's flaky because the library picks one peer to send the transaction to, and then watches it propagate across the network. But if that selected peer refuses the tx for whatever reason, that propagation never comes, and Actually, we'll probably need to explicitly document that a failure to reject is by no means a promise to forward. If a node is using priority queued rate limiting for its relaying then it might accept a transaction from you, but have it fall out of its memory pool (due to higher priority txn arriving, or getting restarted, etc.) before it ever gets a chance to send it on to any other peers. Finding out that it rejected is still useful information, but even assuming all nodes are honest and well behaved I don't think you could count on its absence to be sure of forwarding. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
On Mon, Oct 28, 2013 at 12:37:30PM -0700, Jeremy Spilman wrote: Just an aside... The 1BTC bountry John references below is a 1BTC P2SH output, where the redeemScript he provided does hash to the expected value, and is itself a 2-of-3 multisig, with the following pubkeys, expressed as addresses: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB By comparison, the signatories for the 4BTC bountry are: 1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB On the one hand, the vanity address makes it easy to guess who one of the signatories is, on the other hand, is it bad form to reuse keys for signing? It's a bit more risky from a cryptography perspective, but provided your wallet implementation is done correctly the extra risk is pretty much theoretical. However this has caused real-world coin loss in the past in the case of the Android PRNG flaw - re-using nonces in ECC signing causes the private key to be revealed. I think the real issue here is that John doesn't appear to have asked any of the people whose signatures can release the funds if they were willing to take part. If he had done that, he could have, and should have, gotten separate pubkeys for the purpose of the bounty like was done for Gregory Maxwell's CoinJoin bounty. Instead by not asking he is in reality if not in theory placing demands on people who haven't consented, particularly for the 1BTC bounty where he doesn't control any of the private keys required to release the funds. IMO this is rude and I encourage people not to do this. John, you mentioned wanting to disambiguate bounties, perhaps through a bounty-specific pubkey. I'm not sure I follow, how is that better than just referencing the address of the output, or the TxID, in a 'Table of Bounties'? Or you want to embed a hash of your signed message announcing the bounty? Well, the issue with not disambiguating bounties is that if further funds are sent to the bounty address it's unclear how do you handle those funds. Note how he specified a specific txout for the 1BTC bounty, but specified an address for the 4BTC bounty. Out of curiosity, I suppose right now you just keep pubkeys for the signatories you want to appoint and reuse the same pubkey to create these multi-sigs, or you have to ask for a new one each time? From the signatories perspective, I imagine we're a long way off from a wallet receiving or importing the p2sh, tracking that these outputs as yours, and even more, which contract/bounty they correspond to, and finally a usable way to accumulate signatures and ultimately spend the output to the bounty winner. We're not that far off: I could cook up a Python script to do the signature accumulation and signing in a few hours. There's just not all that much demand yet to fully polish the UI's, and in any case, it'll differ for every specific application. FWIW blockchain.info added multisig escrow support ages ago, then removed it not long after because usage was near zero. -- 'peter'[:-1]@petertodd.org 0001daf527009e07f452eee5dca920d3a9253b682d8bd26783ff signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
