Re: [Bitcoin-development] Opcode whitelist for P2SH?
On Mon, Jul 29, 2013 at 1:17 AM, Luke-Jr wrote: > On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: >> What are your thoughts on creating a whitelist for specific opcodes that >> would apply to scripts serialized using P2SH, retaining the existing >> standard whitelist for scriptPubKeys? (I would still recommend dropping >> pay-to-pubkey and pay-to-multisig due to their potential for dumping data >> in the UTXO set) > > This would be reasonable for miners, but for interoperability between wallets, > some specific standard forms would still be necessary without a much smarter > solver (which would then expand the code required to implement a wallet, which > is unfortunate if not entirely necessary). Indeed. Current designs are all based around pattern matching a script template. Satoshi even described lightweight clients as needing no script engine at all, only the ability to match patterns. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Opcode whitelist for P2SH?
On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: > What are your thoughts on creating a whitelist for specific opcodes that > would apply to scripts serialized using P2SH, retaining the existing > standard whitelist for scriptPubKeys? (I would still recommend dropping > pay-to-pubkey and pay-to-multisig due to their potential for dumping data > in the UTXO set) This would be reasonable for miners, but for interoperability between wallets, some specific standard forms would still be necessary without a much smarter solver (which would then expand the code required to implement a wallet, which is unfortunate if not entirely necessary). -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Distributing low POW headers
On Sun, Jul 28, 2013 at 7:42 PM, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan wrote: > > Distributing headers with 1/64 of the standard POW means that a header > would > > be broadcast approximately once every 9 seconds (assuming a 10 minute > block > > time). This was picked because sending 80 byte headers every 9 seconds > > shouldn't represent much load on the network. > > As Peter said, "much" should be quantified. > It has the same statistic properties as normal blocks just 64 times faster. Even if there is a new block 30 seconds after the previous one, that doesn't cause a burst of 64 low POW block headers in the 30 second window. They are all statistically independent hashing attempts. > Sounds like you are changing economics and requiring miners to have even > better > network connections. This is not a thing to do lightly and it probably a > bad > idea. > No, it just breaks ties. In most cases there would be only 1 contender block, so all miners are equal. If 10% of blocks were ties/orphans, then only 1% of blocks would be a 3-way tie. That probably overestimates the orphan rate. This means the miner has to download 2 blocks 10% of the time and 3 blocks 1% of the time. However, even then, half the network wouldn't have to download the 2nd block of the tie, since they happened to get the winner first. This means 5% extra bandwidth on average. 16 low POW headers at 9 seconds per header is more than 2 minutes for a miner to switch to the other contender. A miner would only lose out if he doesn't notice that block he is mining against is not getting built on by anyone else. He needs to download both tied blocks so that he can switch, but he has 2 minutes to actually switch. I understand Pieter Wuille is working on letting Bitcoin propagate and make > use > of pure block headers, a step towards SPV and partial UTXO mode. > That would need to happen before low POW ones are broadcast. There is a basic set of rules in the first post. At the moment, the client only provides headers when asked, but never broadcasts them. > Orphan measurement would be very useful for a lot of reasons, how about you > think about that first? I think distributing the low POW headers on an advisory basis a reasonable first step. However, just broadcasting the headers is a zeroth step. Miners would probably break ties towards the block that seems to be getting the most hashing anyway. I think for orphan rate, the best is to have a system to link to orphans. This would add the POW of the orphan to the main chain's total. Unfortunately adding fields to the header is hard. It could be done as a coinbase extra-nonce thing. A better option would be if the merkle tree could include non-transactions. The merkle root could be replaced by hash(auxiliary header). This has the advantage of not impacting ASIC miners. Broadcasting all headers would at least allow clients to count orphans, even if they aren't integrated into the block chain. It wouldn't have the potential data rate issues either > and should be a very simple change. I don't think the data rate is really that high. It would be 80 bytes every 9 seconds, or 9 bytes per second. Blocks are 500kB every 10 minutes, or 853 bytes per second. > Just set some threshold relative to the > height of the best block where you will not further propagate and orphan > block(header) and prior to that limit do so freely. I believe the change > would > be 100% compatible with the P2P protocol as it is based on inventories. > Right absolutely. Headers of blocks that add to the block tree within recent history should be forwarded. The inv system would need to be tweaked, since it can only say block and transaction. A block header field would allow the node to say that it only has the header. Alternatively, it would reply with a header message to the getblocks message. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Opcode whitelist for P2SH?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter Todd recently came up with two related, and IMO very good, uses for non-standard transactions to implement both oracles and one-time-password protection of wallet funds. While the wallet fund case could be implemented as only a single standard type, at the cost of generality, the oracle case would be most useful with more arbitrary rules. More generally it is also useful to be able to have scriptPubKeys like the following: n ... m CHECKMULTISIG CHECKSIG BOOLOR and many other similar constructions. What are your thoughts on creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, retaining the existing standard whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set) I'm thinking it should contain the following opcodes, picked for either being already used, or having simple semantics: 0 to 75 byte pushdata PUSHDATA1 1NEGATE OP 1 to OP16 (numbers are allowed through pushdata anyway) IF NOTIF ELSE ENDIF VERIFY RETURN TOALTSTACK FROMALTSTACK (the alt-stack makes stack manipulation in complex ways possible) DROP DUP SWAP EQUAL EQUALVERIFY 0NOTEQUAL BOOLAND BOOLOR RIPEMD160 SHA1 SHA256 HASH160 HASH256 CHECKSIG CHECKSIGVERIFY CHECKMULTISIG CHECKMULTISIGVERIFY Note how this list allows for complex logic, but does not allow for arithmetic, thus not exposing us to a source of problems in the past. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9XMQAAoJEEWCsU4mNhiPyXoIAMz2YZsq+/YUnq5G5AEVmJL/ D7qrLpuI++auMEDoXzt8CqmXbDqci/d70IsBYeHdZkxBp2dah99iDzwIoBhtO/xh XR8m4P+FH+IF6xbuTUAQbBQxr9VuymUatUCmsFzP0YbtPwIzJvUAqJkVeYW1DUXj 6pc9EW3iYdhAvpKNU7A19F6FA96y9m9DyBvY3TCHwzf591Ld1S8ghb9dEuKKYMGl 8TuEMMU/bytZkdD590Ww+f6ukeSOMw9C9+IpAKotB2oq4F4Vkwyzw4rd8sNRAa6c lEDov6UtDSp4ALMfUxw/nxMO8UB43iJhu31KihcjOZpiYvRVeQlM8XLEvAafZvA= =Jph1 -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Two factor wallet with one-time-passwords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 28, 2013 at 1:20 AM, Peter Todd wrote: > FWIW with some minor scripting language additions such as access to txin > and txout contents, along with merklized abstract syntax tree (MAST) > support, we can even implement a version where scriptPubKey's can be > reused: > // Stack now only contains the nonce preceeded by a merkle path linking > // that nonce to the tip of a merkle tree over all nonces. > // > // Verify that path. > SWAP // Move direction flag to the top > IF > SWAP > ENDIF You missed a 'CAT' opcode here. > HASH160 > (repeat above five lines 63 more times) > payment. If they opt for a paper-based one-time-password table they > simply use the 6 word string as an index to their pre-printed OTP > encyclopedia set. I think you should disclose whether or not you have any ties to the pulp and paper business... By my calculations the production of a single OTP table would consume roughly half of all the forest biomass on this planet. > Like the previously described version the security level is still a > healthy 2^64 - again the attacker needs to find a 64-bit pre-image, > considered to be a highly difficult task for any attacker unable to > count from 0 to 2^64 or store a table containing 2^64 values. > > There is the disadvantage of the large storage requirements for both > wallets, however because of the double hashed construction, > H(H(nonce-secret+i)), neither table needs to be kept secret. Thus > without loss of security both tables can be easily stored in a > distributed hash table in the cloud and queried as needed. ROTFL! Your idea is better than you realize, you are just too paranoid for your own good. The thing is the attacker isn't going to be someone paying you funds over your minimum spending limit, which means the size of the table deriving which H(nonce) is selected for a given txid:vout can be significantly smaller. For instance if you want to have 256 total payments before a 50:50 chance of any pair using the same nonce, you only need a table with ~2^16 elements or with 20 byte hashes just a megabyte of data. It is the 16 level merkle proofs that are the problem, 16*21=336 bytes of data in the scriptSig. Then again, that's only 4.5x the size of a single signature, not unreasonable. Also your nested IF statements, while a lovely and hilarious use of MAST, can be replaced by simply creating the merkle tree over the tuples [i,H(nonce_i)] and proving that the nonce_i you provided matched the precommitted tree. Now you only need to provide one merkle proof, not two. But don't let me discourage you, rarely do I see elaborate jokes that also meet the criteria to be a least publishable unit. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9WzMAAoJEEWCsU4mNhiP8wIIAJTESdZiIyrfmrJIQad19He0 nPUB1UGdrcRyYBKfk2bxmIgeTppEneISerAzFpfsZk/R1vLSp2zuFvFLMvaTqF0a nof9dR4ztp753P6O9nLBIK1gcoOagg/FL61Cd1mQzoTjznGioEgk1mCo/Qjb8h9E I43De70j575bvUkq8RQgijctIt463bM7vfdBC6qtgSziL/xrLUDQEJ6Mhqz3rnmX +A2+MPHd/aGnRIcBuN6DFQTMXpjXG2y1CIM45e2gPL5x/vSIXqJoJs9tgGyzuFLG rR34GCsifUKxJyvswG5ue9rNuo5mDkri2jIFx8SlqhfT/b8iWU8JIieoZYGuMiA= =uhmy -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Distributing low POW headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan wrote: > Distributing headers with 1/64 of the standard POW means that a header would > be broadcast approximately once every 9 seconds (assuming a 10 minute block > time). This was picked because sending 80 byte headers every 9 seconds > shouldn't represent much load on the network. As Peter said, "much" should be quantified. Remember that there is a statistical distribution here, what is the probability of how many seconds per headers? > This creates an incentive for miners to take headers into account. If all > the headers were worth less than a full block, then a fork which was losing > would suddenly be winning if a block is found. A fork will only become the > main chain due to a new block, if it is within 16 mini-confirms. Sounds like you are changing economics and requiring miners to have even better network connections. This is not a thing to do lightly and it probably a bad idea. > Second, if a header builds on a header that is in the header tree, then it > is broadcast, even if it doesn't meet full POW (only 1/64 required). This > gives information on which fork is getting the most power. > > It gives information about potential "consensus loss" forks, where a > significant number of miners are following an alternative chain. > > In fact, this is probably worth doing as an initial step. I understand Pieter Wuille is working on letting Bitcoin propagate and make use of pure block headers, a step towards SPV and partial UTXO mode. Orphan measurement would be very useful for a lot of reasons, how about you think about that first? It wouldn't have the potential data rate issues either and should be a very simple change. Just set some threshold relative to the height of the best block where you will not further propagate and orphan block(header) and prior to that limit do so freely. I believe the change would be 100% compatible with the P2P protocol as it is based on inventories. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9WXdAAoJEEWCsU4mNhiPBUYIALgg3ylA5mkciT3W/kb+qXCp spYlPwAU/HVUrd/p6Ra6xAOOa224BE018FHRx7cJ31AQdVPsKhC1XiQCeYMv14Cj 5LstO2VTzxLovfs1lTVnekt+xVo6EHP47Qhmhdfo1AQWHS2njIp2lT9gAlNgMYoI Twu0FLfJFwg14HlueLhTNvGo3TeVpGhTV3HYTbjWGBuPeroaaPCKKQOy/jmA9mnZ 1x4MjQZ+AkGA3+vrinyRZ1FQsp1pOUZMZx5UFYDOOPS3TysxttiHF/Vkdmy9dNVf 5zbXrEDImlariRnyxCf6sn4Fpu9H9bt6yttCez6NHqAoZCwciXyo+UrZjFawSVg= =8gci -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
My signature: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linux distribution packaging and Bitcoin 2013-07-23 This note summarises the dangers inherent in the Linux distribution packaging model for Bitcoin, and forms a request from upstream maintainers to not distribute Bitcoin node software as part of distribution package repositories without understanding the special requirements of Bitcoin. Distributors typically unbundle internal libraries and apply other patches for a variety of generally good reasons, including ensuring that security-critical fixes can be applied once, rather than multiple times for many different packages. In most cases, the common distribution packaging policy has many advantages. However, Bitcoin nodes are an unusual category of software: they implement a complex group consensus in which every client verifies the behaviour of every other exactly. Even an exceptionally subtle change - including apparently harmless bugfixes - can cause a failure to reach consensus. A consensus failure of one client is a security risk to the user of that client. A significant number of nodes failing to reach consensus - as happened in March 2013 due to a change in database libraries[1] - is a critical problem that threatens the functionality and security of the system for all users. For this reason, it is _vital_ that as much of the network as possible uses _unmodified_ implementations that have been carefully audited and tested, including dependencies. For instance, if the included copy of LevelDB in bitcoind is replaced by a system-wide shared library, _any_ change to that shared library requires auditing and testing, a requirement generally not met by standard distributor packaging practices. Because distributed global consensus is a new area of computer science research, the undersigned request that distributors refrain from packaging Bitcoin node software (including bitcoind and Bitcoin-Qt) and direct users to the upstream-provided binaries instead _until they understand the unique testing procedures and other requirements to achieve consensus_. Beyond being globally consistent, upstream binaries are produced using a reproducible build system[2], ensuring that they can be audited for backdoors. 1. https://en.bitcoin.it/wiki/BIP_0050 2. http://gitian.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR9WC5AAoJEEWCsU4mNhiPg6UH/2oHzBWBPaQMhH/GCTHQEi5U 7GSRfqwihIs/M2ROHLNq0HhgWR7mPAh5TTI6+tG95FCGCGNZq0seqw9wW4ZyGCoc VueY51q4hcn23405oLD/QGK2lDxxywWY8XtFYVPqAzXTq6zRzgpNJkjoRtOAUOP7 3PrRkimYYyj0KrqFg+cEvZDT27dkeX+5PXM6Ua0o7h/TlhR2RJPhej5DI8cNLXgA f0t+mES4Apb6zLgnEYYlPp22FR9vuFcJO3z1akhVL4DLUMqr58NYHLVnH1FH0Jhn hVuld159QtCjQ5Qyn19cn86akTQJVi+ikCXqaKriCc2jBFX7TCI8WTDc6aSZpsQ= =oX5d -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
