Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer el33th4...@gmail.com wrote: Most things I've seen working in this space are attempting to minimize the data transfered. At least for the miner-interested case the round complexity is much more important because a single RTT is enough to basically send the whole block on a lot of very relevant paths. Agreed. Yaron's scheme is magical because it is non-interactive. I send you a packet of O(expected-delta) and you immediately figure out the delta without further back and forth communication, each requiring an RTT. Oh that does sound interesting— its the property I was trying to approximate with the FEC.. It achieves the one-shot, but there is overhead. One plus we have is that we can do some tricks to make some computational soundness arguments that we'd actually get average performance on average (e.g. that someone can't author transactions in such a way as to jam the process). In any case, I have no horse here (I think changing the client so it's multithreaded is the best way to go), but Yaron's work is pretty cool and may be applicable. Thank you, I've certantly queued the paper for reading. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine vois...@gmail.com wrote: Well, you could always create a transaction with a different signature hash, say, by changing something trivial like nLockTime, or changing the order of inputs or outputs. Is that what you're talking about? Or is there some sophistry I'm ignorant of having to do with the elliptic curve math in the signature itself? No, though thats true too. I was talking about the properties of the DSA nonce: An attacker is not obligated to follow your protocol unless you can prevent him. You can _say_ use derandomized DSA all you like, but he can just not do so, there is no (reasonable) way to prove you're using a particular nonce generation scheme without revealing the private key in the process. The verifier cannot know the nonce or he can trivially recover your private key thus he can't just repeat the computation (well, plus if you're using RFC6979 the computation includes the private key), so short of a very fancy ZKP (stuff at the forefront of cryptographic/computer science) or precommiting to a nonce per public key (e.g. single use public keys), you cannot control how a DSA nonce was generated in the verifier in a way that would prevent equivalent but not identical signatures. (I believe there was some P.O.S. altcoin that was vulnerable because of precisely the above too— thinking specifying a deterministic signer would prevent someone from grinding signatures to improve their mining odds... there are signature systems which are naturally randomness-free: most hash based signatures and pairing short signatures are two examples that come to mind... but not DSA, schnorr, or any of their derivatives). -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Signature with negative integer?
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore m...@ricmoo.com wrote: Hey all, I'm wondering if anyone can help explain to me tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d... A rather timely post. See the other thread on BIP0062. What you're looking at is an example of a well-known-to-implementers-here where invisible and undocumented over permissiveness in interpreting invalid encoding in a cryptographic library (OpenSSL in our case) which would have been probably-not-unwelcome in many other protocol uses results in an unexpected consensus critical normative rule in Bitcoin. Modern releases of Bitcoin core will no longer relay or mine them but they're still valid in blocks should they show up. BIP62 proposes, among other things, soft-forking (backwards compatible) changes that will strictly limit the DER encoding to avoid ambiguity. If adopted by the network implementations would still need to grandfather in existing weird transactions but could do so on a txid by txid basis since there would be no more broken encoding permitted in blocks, and use different DER decoding code without risk of consensus inconsistency (so long as it uses der decoding which is functionally identical to what BIP62 requires— of course). -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
On Fri, Jul 18, 2014 at 4:53 PM, Gavin Andresen gavinandre...@gmail.com wrote: Two more half-baked thoughts: We should be able to assume that the majority of transaction data (except for coinbase) has already been propagated. As Jeff said, incentivizing nodes to propagate transactions is a very good thing (the signature cache already gives a small incentive to miners to propagate and not 'hoard' transactions). Maybe a stupid idea - but couldn't we make that assumption a surety by starting the 'set synchronization process' as soon as the miner starts crunching on a certain block, instead of when it broadcasts it? So the peers are prepared, and the actual block broadcast is just the header + coinbase tx. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
On Jul 18, 2014 4:56 PM, Wladimir laa...@gmail.com wrote: On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net wrote: The rationale doesn't seem to apply to rule #4, what's so special about that one? 4. Non-push operations in scriptSig Any non-push operation in a scriptSig invalidates it. Having non-push operations in the scriptSig is a source of malleability, as there can be multiple sequences of opcodes that evaluate to the same result. Well yes, but that is true for each of the rules and is already covered by the previous specification in BIP62. Making it mandatory even for old transaction does not really protect much against malleability as there are several other sources of malleability that cannot be made mandatory in old transactions left. The reason for including #4 is just allowing this does not benefit anyone. -- Pieter -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
Thanks g.maxwell, your explanation of *why* you can't just generate k in a way that the verifier can duplicate is really helpful. This also servers as a great illustration why engineers should never try to designing their own crypto protocols! I knew enough to know not try that at least. Aaron Voisine breadwallet.com On Fri, Jul 18, 2014 at 11:56 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine vois...@gmail.com wrote: Well, you could always create a transaction with a different signature hash, say, by changing something trivial like nLockTime, or changing the order of inputs or outputs. Is that what you're talking about? Or is there some sophistry I'm ignorant of having to do with the elliptic curve math in the signature itself? No, though thats true too. I was talking about the properties of the DSA nonce: An attacker is not obligated to follow your protocol unless you can prevent him. You can _say_ use derandomized DSA all you like, but he can just not do so, there is no (reasonable) way to prove you're using a particular nonce generation scheme without revealing the private key in the process. The verifier cannot know the nonce or he can trivially recover your private key thus he can't just repeat the computation (well, plus if you're using RFC6979 the computation includes the private key), so short of a very fancy ZKP (stuff at the forefront of cryptographic/computer science) or precommiting to a nonce per public key (e.g. single use public keys), you cannot control how a DSA nonce was generated in the verifier in a way that would prevent equivalent but not identical signatures. (I believe there was some P.O.S. altcoin that was vulnerable because of precisely the above too— thinking specifying a deterministic signer would prevent someone from grinding signatures to improve their mining odds... there are signature systems which are naturally randomness-free: most hash based signatures and pairing short signatures are two examples that come to mind... but not DSA, schnorr, or any of their derivatives). -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
