[Bitcoin-development] network disruption as a service and proof of local storage
The problem of pseudo-nodes will come over and over. The cat and mouse chase is just beginning. It has been discussed some times that the easiest solution world be to request some kind of resource consumption on each peer to be allowed to connect to other peers. Gmaxwell proposed Proof of Storage here: https://bitcointalk.org/index.php?topic=310323.msg3332919#msg3332919 I proposed a (what I think) is better protocol for Proof of Storage that I call Proof of Local storage here https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/ . It's better because it does not need the storage of additional data, but more importantly, it allows you to prove full copy of the blockchain is being maintained by the peer. This is specially important now that Bitnodes is trying a full-node incentive program that may be easily cheated (http://qntra.net/2015/02/pseudonode-proxy-fools-bitcoin-full-node-incentive-program/) Proof of local storage allows a node to prove another peer that he is storing a LOCAL copy of a PUBLIC file, such as the blockchain. So the peer need not waste more resources (well, just some resources to encode/decode the block-chain). The main idea is to use what I called asymmetric-time-encoding. Basically you encode the block-chain in a way that it takes 100 more times to write it than to read it. Since the block-chain is an append-only (write-only) file, this fit good for our needs. For instance (and as a simplification), choosing a global 1024-bit prime, then splitting the block-chain in 1024-bit blocks, and encrypting each block using Polihg-Hellman (modexp) with decryption exponent 3. Then encryption is at least 100 times slower than decryption. Before PH encryption each node must xor each block with a pseudo-random mask derived from the public IP and the block index. So block encryption could be: BlockEncryptIndex(i) = E(IP+i,block(i))^inv(3) (mod p), where inv(3) is 3^-1 mod (p-1). E() could be a fast tweaked encryption routine (tweak = index), but we only need the PRNG properties of E() and that E() does share algebraic properties with P.H.. Two protocols can be performed to prove local possession: 1. (prover and verifier pay a small cost) The verifier sends a seed to derive some n random indexes, and the prover must respond with the hash of the decrypted blocks within a certain time bound. Suppose that decryption of n blocks take 100 msec (+-100 msec of network jitter). Then an attacker must have a computer 50 faster to be able to consistently cheat. The last 50 blocks should not be part of the list to allow nodes to catch-up and encrypt the blocks in background. 2. (prover pay a high cost, verified pays negligible cost). The verifier chooses a seed n, and then pre-computes the encrypted blocks derived from the seed using the prover's IP. Then the verifier sends the seed, and the prover must respond with the hash of the encrypted blocks within a certain time bound. The proved does not require to do any PH decryption, just take the encrypted blocks for indexes derived from the seed, hash them and send the hash back to the verifier. The verifier validates the time bound and the hash. Both protocols can me made available by the client, under different states. For instance, new nodes are only allowed to request protocol 2 (and so they get an initial assurance their are connecting to full-nodes). After a first-time mutual authentication, they are allowed to periodically perform protocol 1. Also new nodes may be allowed to perform protocol 1 with a small index set, and increase the index set over time, to get higher confidence. The important difference between this protocol and classical remote software attestation protocols, is that the time gap between a good peer and a malicious peer can be made arbitrarily high, picking a larger p. Maybe there is even another crypto primitive which is more asymmetric than exponent 3 decryption (the LUC or NTRU cryptosystem?). In GMaxwell proposal each peer builds a table for each other peer. In my proposal, each peer builds a single table (the encrypted blockchain), so it could be still possible to establish a thousands of connections to the network from a single peer. Nevertheless, the attacker's IP will be easily detected (he cannot hide under a thousands different IPs). It's also possible to restrict the challenge-response to a portion of the block-chain, the portion offset being derived from the hash of both IP addresses and one random numbers provided by each peer. Suppose each connection has a C-R space equivalent to 1% of the block-chain. Then having 100 connections and responding to C-R on each connection means storing approximate 1 copy of the block-chain (there may be overlaps, which would need to be stored twice) , while having 1K connections would require storing 10 copies of the blockchain. Best regards, Sergio -- Dive into the World of
[Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top stack element, adds the height of the output being spent and then has identical semantics to CLTV. A slightly different API (and different name) was described by maaku at http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154 which does a better job of saving softfork-available opcode space. There are two major drawbacks to adding such an operation, however. 1) More transaction information is exposed inside the script (prior to CLTV we only had the sigchecking operation exposed, with a CLTV and RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions). 2) Bitcoin Core's mempool invariant of all transactions in the mempool could be thrown into one overside block and aside from block size, it would be valid becomes harder to enforce. Currently, during reorgs, coinbase spends need checked (specifically, anything spending THE coinbase 100 blocks ago needs checked) and locktime transactions need checked. With such a new operation, any script which used this new opcode during its execution would need to be re-evaluated during reorgs. I think both of these requirements are reasonable and not particularly cumbersome, and the value of such an operation is quite nice for some protocols (including settings setting up a contest interval in a sidechain data validation operation). Thoughts? Matt On 10/01/14 13:08, Peter Todd wrote: I've written a reference implementation and BIP draft for a new opcode, CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at: https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki The reference implementation, including a full-set of unittests for the opcode semantics can be found at: https://github.com/petertodd/bitcoin/compare/checklocktimeverify pre BIP: Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd p...@petertodd.org Status: Draft Type: Standards Track Created: 2014-10-01 /pre ==Abstract== This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future. ==Summary== CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it compares the top item on the stack to the nLockTime field of the transaction containing the scriptSig. If that top stack item is greater than the transation nLockTime the script fails immediately, otherwise script evaluation continues as though a NOP was executed. The nLockTime field in a transaction prevents the transaction from being mined until either a certain block height, or block time, has been reached. By comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we indirectly verify that the desired block height or block time has been reached; until that block height or block time has been reached the transaction output remains unspendable. ==Motivation== The nLockTime field in transactions makes it possible to prove that a transaction output can be spent in the future: a valid signature for a transaction with the desired nLockTime can be constructed, proving that it is possible to spend the output with that signature when the nLockTime is reached. An example where this technique is used is in micro-payment channels, where the nLockTime field proves that should the receiver vanish the sender is guaranteed to get all their escrowed funds back when the nLockTime is reached. However the nLockTime field is insufficient if you wish to prove that transaction output ''can-not'' be spent until some time in the future, as there is no way to prove that the secret keys corresponding to the pubkeys controling the funds have not been used to create a valid signature. ===Escrow=== If Alice and Bob jointly operate a business they may want to ensure that all funds are kept in 2-of-2 multisig transaction outputs that require the co-operation of both parties to spend. However, they recognise that in exceptional circumstances such as either party getting hit by a bus they need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny, to act as a third-party. With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer not to have immediate access to the funds to discourage bad actors from attempting to get the secret keys from him by force. However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of the form: IF now + 3 months CHECKLOCKTIMEVERIFY DROP Lenny's pubkey CHECKSIGVERIFY
[Bitcoin-development] My thoughts on the viability of the Factom token
Repost of https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo for archival/disclosure purposes: I'm very skeptical about the long-term viability of Factom and the value of the Factom token. The idea behind Factom is to create a proof-of-publication medium where facts for some purpose can be published; the token incentivises people to maintain the infrastructure required for that medium. You can think of Factom as a two layer system, with Factom servers provide a layer that in turn is used by secondary proof-of-publication ledgers. By publishing records in the Factom layer you prove that the secondary layer of actual facts is being maintained honestly. For instance one such secondary layer might be the property records of a city using a digital Torrens title system¹ to maintain land titles. Let's look at how this works step by step: * You would know your digitally represented land title was valid because it was in the city's ledger and the digital signatures verify. * You in turn know the *copy* of that ledger that you posess is the official version because you can inspect the ledger maintained by the Factom servers. * You know that ledger is the official Factom layer - not a fork of that ledger - because you can run the Factom consensus protocol against the Bitcoin blockchain. * You know you have the only Bitcoin blockchain and not a fork because of the Bitcoin Proof-of-Work consensus algorithm. That's four steps in total. The problem is step #3 - the Factom consensus layer - requires you to trust the Factom servers. The issue is if the Factom servers ever publish a Factom ledger anchor in the Bitcoin blockchain but don't make the data available you have no way of proving that your Factom-secured ledger - e.g. the city's property title records - is the only copy out there and you're not trying to defraud someone. Those servers are voted in by a (quite complex) consensus algorithm, but ultimately they are trusted third parties that can break your ability to prove your Factom-secured records are honest. Of course in practice if this happens people will just accept it and patch their software to ignore the failure... but then why use Factom at all? You can do the exact same thing with *far* less complexity by just securing your ledger directly in the Bitcoin blockchain, skipping step #3 and the dependency on trusted third parties. (I don't mean putting the ledger itself in the chain, just hashes of it) The only disadvantage to securing your records directly in the Bitcoin blockchain is you have to pay transaction fees to do it. However currently those fees are very small - they'll always be about the cost to make a transaction - and if they do increase it's easy to create meta-ledgers based on explicit trust relationships. For instance a bunch of cities can get together to establish a meta-ledger for all their per-city property title systems, perhaps using efficient threshold-signature² multisig to ensure that a majority of those cities have to sign off on any updates to the meta-ledger. Of course all these Factom alternatives can be argued to bloat the blockchain - but how are we going to force people to use less secure alternatives to just using the blockchain? It's impossible to stop people from securing ledgers in the blockchain technically; our only way to do it is via social pressure like writing angry posts on reddit and lawsuits. tl;dr: For the Facom token to rise in value we need Bitcoin transaction fees to rise greatly, and/or people to choose to use much more complex and less secure systems in preference to much more simple systems. Disclaimer: I've been hired by Factom to review the Factom protocol. I also am working on a competing library called Proofchains that among other things can be used to secure ledgers using Bitcoin directly. That funding model for that effort is to convince individual clients that they need the technology and should pay me to develop it. 1) http://en.wikipedia.org/wiki/Torrens_title 2) https://bitcoinmagazine.com/19528/threshold-signatures-new-standard-wallet-security/ -- 'peter'[:-1]@petertodd.org 0de14334f9da364dc660a7cb1d7b695c08a3472e94d3512a signature.asc Description: Digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
Thanks Jan, we added several additional checks for non-standard protocol responses, and also made the client revert to DNS seeding more quickly if it runs into trouble, so it's now more robust against sybil/DOS attack. I mentioned in the coindesk article that I didn't think what your nodes were doing was intended to be malicious with respect to network disruption. It's our job to better handle non-standard or even malicious behavior from random p2p nodes. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Mar 16, 2015 at 1:44 AM, Jan Møller jan.mol...@gmail.com wrote: What we were trying to achieve was determining the flow of funds between countries by figuring out which country a transaction originates from. To do that with a certain accuracy you need many nodes. We chose a class C IP range as we knew that bitcoin core and others only connect to one node in any class C IP range. We were not aware that breadwallet didn't follow this practice. Breadwallet risked getting tar-pitted, but that was not our intention and we are sorry about that. Our nodes DID respond with valid blocks and merkle-blocks and allowed everyone connecting to track the blockchain. We did however not relay transactions. The 'service' bit in the version message is not meant for telling whether or how the node relays transactions, it tells whether you can ask for block headers only or full blocks. Many implementations enforce non standard rules for handling transactions; some nodes ignore transactions with address reuse, some nodes happily forward double spends, and some nodes forward neither blocks not transactions. We did blocks but not transactions. In hindsight we should have done two things: 1. relay transactions 2. advertise address from 'foreign' nodes Both would have fixed the problems that breadwallet experienced. My understanding is that breadwallet now has the same 'class C' rule as bitcoind, which would also fix it. Getting back on the topic of this thread and whether it is illegal, your guess is as good as mine. I don't think it is illegal to log incoming connections and make statistical analysis on it. That would more or less incriminate anyone who runs a web-server and looks into the access log. At lease one Bitcoin service has been collecting IP addresses for years and given them to anyone visiting their web-site (you know who) and I believe that this practise is very wrong. We have no intention of giving IP addresses away to anyone, but we believe that you are free to make statistics on connection logs when nodes connect to you. On a side note: When you make many connections to the network you see lots of strange nodes and suspicious patterns. You can be certain that we were not the only ones connected to many nodes. My takeaway from this: If nodes that do not relay transactions is a problem then there is stuff to fix. /Jan On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn m...@plan99.net wrote: That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol specs better and became just regular nodes that happen to keep logs, would that still be a violation? If so, what about blockchain.info? It'd be shooting ourselves in the foot to try and forbid block explorers given how useful they are. If someone non-maliciously runs some nodes with debug logging turned on, and makes full system backups every night, and keeps those backups for years, are they in violation of whatever pseudo-law is involved? I think it's a bit early to think about these things right now. Michael Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be interested to know their thoughts on all of this. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
What we were trying to achieve was determining the flow of funds between countries by figuring out which country a transaction originates from. To do that with a certain accuracy you need many nodes. We chose a class C IP range as we knew that bitcoin core and others only connect to one node in any class C IP range. We were not aware that breadwallet didn't follow this practice. Breadwallet risked getting tar-pitted, but that was not our intention and we are sorry about that. Our nodes DID respond with valid blocks and merkle-blocks and allowed everyone connecting to track the blockchain. We did however not relay transactions. The 'service' bit in the version message is not meant for telling whether or how the node relays transactions, it tells whether you can ask for block headers only or full blocks. Many implementations enforce non standard rules for handling transactions; some nodes ignore transactions with address reuse, some nodes happily forward double spends, and some nodes forward neither blocks not transactions. We did blocks but not transactions. In hindsight we should have done two things: 1. relay transactions 2. advertise address from 'foreign' nodes Both would have fixed the problems that breadwallet experienced. My understanding is that breadwallet now has the same 'class C' rule as bitcoind, which would also fix it. Getting back on the topic of this thread and whether it is illegal, your guess is as good as mine. I don't think it is illegal to log incoming connections and make statistical analysis on it. That would more or less incriminate anyone who runs a web-server and looks into the access log. At lease one Bitcoin service has been collecting IP addresses for years and given them to anyone visiting their web-site (you know who) and I believe that this practise is very wrong. We have no intention of giving IP addresses away to anyone, but we believe that you are free to make statistics on connection logs when nodes connect to you. On a side note: When you make many connections to the network you see lots of strange nodes and suspicious patterns. You can be certain that we were not the only ones connected to many nodes. My takeaway from this: If nodes that do not relay transactions is a problem then there is stuff to fix. /Jan On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn m...@plan99.net wrote: That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol specs better and became just regular nodes that happen to keep logs, would that still be a violation? If so, what about blockchain.info? It'd be shooting ourselves in the foot to try and forbid block explorers given how useful they are. If someone non-maliciously runs some nodes with debug logging turned on, and makes full system backups every night, and keeps those backups for years, are they in violation of whatever pseudo-law is involved? I think it's a bit early to think about these things right now. Michael Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be interested to know their thoughts on all of this. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
