[Bitcoin-development] python-bitcoinlib: Comprehensive bitcoin library for python
GitHub URL: https://github.com/jgarzik/python-bitcoinlib Repository: git://github.com/jgarzik/python-bitcoinlib.git The python library for pynode has matured sufficiently to have a home of its own. The python-bitcoinlib project attempts to present a lightweight, modular, a la carte interface to bitcoin data structures and network protocols. Features: * Easy object interface to all bitcoin core data structures: block, transaction, addresses, ... * Full transaction script engine * Fully verifies main and testnet block chains (via pynode) * ECDSA verification (OpenSSL wrapper) * Object interface to all known network messages * Binary encoding/decoding (serialization) for full bitcoin protocol interoperability * Passes many of the tests shipped with the bitcoin reference client (bitcoind/Bitcoin-Qt) Like pynode, this library is currently a developer-only release, not recommended for highly secure production sites. Pull requests, comments, questions and donations always welcome. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
My views on censorship resistance in the face of scaling: 1) I expect if I'm not careful about preserving my privacy with the way I use Bitcoin, then I will always run the risk of being censored by miners. This means connecting to the network anonymously, not reusing addresses, and perhaps even mixing my coins. The onus is on me here to avoid censorship, but I'm optimistic that this privacy preservation can be made pretty automatic. 2) I expect anonymity systems to scale to accommodate Bitcoin full nodes, not Bitcoin to stay small to avoid putting pressure on anonymity systems to scale. 3) If 2 is too tall an order, then mining in a pool is always an option. There should always be some countries in the world free enough to allow mining pools to operate, and miners in countries that ban Bitcoin can simply connect to these anonymously. If not, then Bitcoin is toast anyway, is it not? If these miners are really interested in avoiding censoring transactions, then they will do their due diligence and choose a pool that doesn't do this. But even if they don't, censorship can be personally avoided by following 1. On Thu, Mar 7, 2013 at 2:19 PM, Mike Hearn wrote: > As an aside, there's a paper coming out in perhaps a few months that > describes a new way to provide Chaum-style privacy integrated with > Bitcoin, but without the use of blinding and without any need for > banks. It's quite smart, I was reviewing the paper this week. > Unfortunately the technique is too slow and too complicated to > actually integrate, but you'd probably get a kick out of it. It's > based on zero knowledge proofs. You can talk to Ian Miers if you like, > perhaps he'll send you a copy for review. > > Back on topic. > > This idea is not new. I proposed the idea of regulating miners to > freeze certain outputs two years ago: > >https://bitcointalk.org/index.php?action=printpage;topic=5979.0 > > I concluded that it was not a real risk because both mining and > transactions can be done anonymously. > > Your argument rests on the assumption that you can't mine large blocks > anonymously because Tor doesn't scale. Even if we go along with the > idea that Tor is the only way to escape regulation (it's not), you > should maybe take up its inability to move data sufficiently fast with > the developers. Given that they routinely push two gigabits/second > today, with an entirely volunteer run network, I think they'll be > surprised to learn that their project is doomed to never be usable by > miners. > > > -- > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
As an aside, there's a paper coming out in perhaps a few months that describes a new way to provide Chaum-style privacy integrated with Bitcoin, but without the use of blinding and without any need for banks. It's quite smart, I was reviewing the paper this week. Unfortunately the technique is too slow and too complicated to actually integrate, but you'd probably get a kick out of it. It's based on zero knowledge proofs. You can talk to Ian Miers if you like, perhaps he'll send you a copy for review. Back on topic. This idea is not new. I proposed the idea of regulating miners to freeze certain outputs two years ago: https://bitcointalk.org/index.php?action=printpage;topic=5979.0 I concluded that it was not a real risk because both mining and transactions can be done anonymously. Your argument rests on the assumption that you can't mine large blocks anonymously because Tor doesn't scale. Even if we go along with the idea that Tor is the only way to escape regulation (it's not), you should maybe take up its inability to move data sufficiently fast with the developers. Given that they routinely push two gigabits/second today, with an entirely volunteer run network, I think they'll be surprised to learn that their project is doomed to never be usable by miners. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
On Thu, Mar 07, 2013 at 06:42:32PM +0100, Mike Hearn wrote: > To summarize your post - it's another go at arguing for strongly > limited block sizes, this time on the grounds that large blocks make > it easier for $AUTHORITY to censor transactions? Is that right? Yes. Now, can we solve this problem robustly with clever technology, as is done with UTXO fraud proofs? I can't see a way - can you? Gavin asked me to do a projection for what block sizes could be based on technology improving, and I think that analysis should consider carefully to what degree the current system's quite strong censorship resistance will be impacted. It's interesting to be talking about censorship of transactions, right as the support for implementing technical means to block SatoshiDice transactions is highest. If anything, I think Gregory Maxwell's findings he has posted on IRC showing roughly three quarters of transactions in blocks are SatoshiDice related shows how the current large number of validating nodes makes any effort at even discouraging unwanted traffic quite difficult. In other words, it's a strong sign the censorship resistance of Bitcoin works as intended. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
To summarize your post - it's another go at arguing for strongly limited block sizes, this time on the grounds that large blocks make it easier for $AUTHORITY to censor transactions? Is that right? -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Large-blocks and censorship
On Thu, Mar 07, 2013 at 06:00:18AM -0500, Peter Todd wrote: > It's also notably that auditable off-chain transaction systems are > vulnerable. All of the trustworthy ones that don't rely on trusted > hardware require at least some of their on-chain transactions to be > publicly known, specifically so that the total amount of reserves held > by off-chain transaction providers can be audited. At best you can use > Gregory Maxwell's suggestion of maintaining a "reserve" account backed > by funds that rarely move, where new deposits go to non-public addresses > and result in the depositor receiving funds from the reserve account, > but again, if the spendability of those funds is in question, the value > of the reserve itself is also in question. Additionally miners can block > fidelity bond sacrifice transactions easily; again a critical > technologies required to implement some types of off-chain transaction > systems, as well as for many other purposes. Oh, and it occured to me: merge-mining is also vulnerable to the exact same censorship forces. Again, with small blocks running P2Pool is feasible, and P2Pool does merge-mining just fine. With large blocks it's easy for the pool to ignore shares that try to merge mine, so your alt-chains competition is also censored. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Large-blocks and censorship
So with UTXO merkle-sum-fee-trees and fraud notices(1) we can effectively audit the blocks produced by miners and provide a way for SPV nodes to reject invalid blocks without requiring the whole blockchain data. Next step: How do we prevent censorship? Can we at all? Basically while UTXO-style proofs allow anyone to determine if a block is valid, it's fundementally still miners that choose what transactions to accept into blocks in the first place. Unfortunately the very nature of a blockchain is that it is meant to prove that transactions are public and that a consensus exists about what transactions are spendable, thus any attempt to hide the bare technical details, txins and txouts, is futile. Even using encryption doesn't work, because assuming you convinced a miner to accept your encrypted transaction, that just shifts the part that makes the transaction public to the act of revealing the key, which again must be done publicly in the blockchain to prove consensus. As transaction volume makes running a validating node more expensive, we can expect the number of independent pools to decrease, or at the very least make monitoring those pools easier as volumes grow beyond what technologies such as Tor can effectively accomodate. This provides the opportunity to pressure the remaining, identifiable, independent miners into accepting restrictions on what transactions can be mined. It's also notably that auditable off-chain transaction systems are vulnerable. All of the trustworthy ones that don't rely on trusted hardware require at least some of their on-chain transactions to be publicly known, specifically so that the total amount of reserves held by off-chain transaction providers can be audited. At best you can use Gregory Maxwell's suggestion of maintaining a "reserve" account backed by funds that rarely move, where new deposits go to non-public addresses and result in the depositor receiving funds from the reserve account, but again, if the spendability of those funds is in question, the value of the reserve itself is also in question. Additionally miners can block fidelity bond sacrifice transactions easily; again a critical technologies required to implement some types of off-chain transaction systems, as well as for many other purposes. Of course we can just assume that the current pseudo-anonymity of transactions is "good enough", but consider the case of stolen coins: even if the bulk of transactions are effectively anonymous, transactions can always be made public delibrately and miners pressured into preventing the movement of coins declared tainted. Finally it's possible that some kind of chaum token system could be implemented directly in the blockchain, but this has the problem that A: no efficient ones are yet known, let alone demonstrated, and B: unless non-chaum token systems are prohibited by a hard-fork with wide adoption, the censorship risk is miners deciding to not mine any chaum token transactions. It's easy to imagine a government deciding that while they will accept transactions that occure on the public block chain, and are thus at best pseudo-anonymous, are acceptable any attempt to conduct truely anonymous transactions will be forbidden. On the other hand, with small blocks the barriers to entry to becoming a miner remain low, and mining anonymously behind low-bandwidth anti-censorship technologies such as Tor remains feasible. Any attempt by a major pool to censor, IE choose not to mine, a transaction will naturally lead to an opportunity for an anonymous miner to get a profit mining that transaction, thus we can expect transactions to be treated fairly equally on a fee per KB basis. In addition, the ever present possibility of this happening, further discourages large miners from doing so in the first place, and in turn gives those miners additional incentive to resist attempts to restrict what transactions they are allowed to mine. Of course off-chain transaction systems can still practice censorship of transactions on their own, but because the decentralized blockchain still exists communities subject to such censorship can always create their own auditable and secure off-chain transaction systems for their own use. Again, the existence of such systems creates economic incentives to find ways to move value between all off-chain transaction systems regardless of imposed restrictions, and again the overall ability to transfer value freely is maintained. 1) https://bitcointalk.org/index.php?topic=137933.0 -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-d
