Re: [Bitcoin-development] On-going data spam
OK, as the start of that conversation is now on the list, I might as well post the other thoughts we had. Or at least that I had :) It's tempting to see this kind of abuse through the lens of fees, because we only have a few hammers and so everything looks like a kind of nail. The problem is the moment you try to define abuse economically you end up excluding legitimate and beneficial uses as well. Maybe Peters patch for uneconomical outputs is different because of how it works. But mostly it's true. In this case, fees would never work - Peter said the guy who uploaded Wikileaks paid something like $500 to do it. I guess by now it's more like $600-$700. It's hard for regular end users to compete with that kind of wild-eyed dedication to the cause. The root problem here is people believe the block chain is a data structure that will live forever and be served by everyone for free, in perpetuity, and is thus the perfect place for uncensorable stuff. That's a reasonable assumption given how Bitcoin works today. But there's no reason it will be true in the long run (I know this can be an unpopular viewpoint). Firstly, legal issues - I think it's very unlikely any sane court would care about illegal stuff in the block chain given you need special tools to extract it (mens rea). Besides, I guess most end users will end up on SPV clients as they mature. So these users already don't have a copy of the entire block chain. I don't worry too much about this. Secondly, the need to host blocks forever. In future, many (most?) full nodes will be pruning, and won't actually store old blocks at all. They'll just have the utxo database, some undo blocks and some number of old blocks for serving, probably whatever fits in the amount of disk space the user is willing to allocate. But very old blocks will have been deleted. This leads to the question of what incentives people have to not prune. The obvious incentive is money - charge for access to older parts of the chain. The fewer people that host it, the more you can charge. In the worst case scenario where, you know, only 10 different organizations store a copy of the chain, it might mean that bootstrapping a new node in a trust-less manner is expensive. But I really doubt it'd ever get so few. Serving large static datasets just isn't that expensive. Also, you don't actually need to replay from the genesis block to bring up a new code, you can copy the UTXO database from somewhere else. By comparing the databases of lots of different nodes together, the chances of you being in a matrix-like sybil world can be reduced to beyond reasonable doubt. Maybe nodes would charge for copies of their database too, but ideally there are lots of nodes and so the charge for that should be so close to zero as makes no odds - you can trivially undercut someone by buying access to the dataset and then reselling it for a bit less, so the price should converge on the actual cost of providing the service. Which will be very cheap. There was one last thought I had, which is that if there's a shorter team need to discourage this kind of thing we can use a network/bandwith related hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist can apply to Bloom filtering such that transactions which are known to be abusive require you to fully download the block rather than select the transactions with a filter. This means that people can still access the data in the chain, but the older it gets the slower and more bandwidth intensive it becomes. Stuffing Wikileaks into the chain sounds good when a 20 line Python script can extract it instantly. If someone who wants the files has to download gigabytes of padding around it first, suddenly hosting it on a Tor hidden service becomes more attractive. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On Tue, Apr 09, 2013 at 12:42:12PM +0200, Mike Hearn wrote: hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist NAK Makes bringing up a new node dependent on other nodes having consistent uptimes, particularly if you are on a low-bandwidth connection. can apply to Bloom filtering such that transactions which are known to be abusive require you to fully download the block rather than select the transactions with a filter. This means that people can still access the NAK No blacklists -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On 4/9/2013 4:09 AM, Peter Todd wrote: On Tue, Apr 09, 2013 at 12:42:12PM +0200, Mike Hearn wrote: hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist NAK Makes bringing up a new node dependent on other nodes having consistent uptimes, particularly if you are on a low-bandwidth connection. can apply to Bloom filtering such that transactions which are known to be abusive require you to fully download the block rather than select the transactions with a filter. This means that people can still access the NAK No blacklists It depends on how clever the spammers get encoding stuff. If law enforcement forensic tools can pull a jpeg header + child porn out of the blockchain, then there's a problem that needs mitigation. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
An approach which I see as workable in the long term is to keep the block header and an array of bitfields representing each transaction's spent and unspent outputs. When someone wants to spend money you ask them for the transaction and ideally you ask them for the transaction and the merkle branch from that transaction to the header. If they want to spend the money they have to carry around the data. Agreed on the legality aspect but another case which is worth considering is what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Perhaps worth contacting an AV company and asking what is the smallest data they have a signature on. Thanks, Caleb On 04/09/2013 06:42 AM, Mike Hearn wrote: OK, as the start of that conversation is now on the list, I might as well post the other thoughts we had. Or at least that I had :) It's tempting to see this kind of abuse through the lens of fees, because we only have a few hammers and so everything looks like a kind of nail. The problem is the moment you try to define abuse economically you end up excluding legitimate and beneficial uses as well. Maybe Peters patch for uneconomical outputs is different because of how it works. But mostly it's true. In this case, fees would never work - Peter said the guy who uploaded Wikileaks paid something like $500 to do it. I guess by now it's more like $600-$700. It's hard for regular end users to compete with that kind of wild-eyed dedication to the cause. The root problem here is people believe the block chain is a data structure that will live forever and be served by everyone for free, in perpetuity, and is thus the perfect place for uncensorable stuff. That's a reasonable assumption given how Bitcoin works today. But there's no reason it will be true in the long run (I know this can be an unpopular viewpoint). Firstly, legal issues - I think it's very unlikely any sane court would care about illegal stuff in the block chain given you need special tools to extract it (mens rea). Besides, I guess most end users will end up on SPV clients as they mature. So these users already don't have a copy of the entire block chain. I don't worry too much about this. Secondly, the need to host blocks forever. In future, many (most?) full nodes will be pruning, and won't actually store old blocks at all. They'll just have the utxo database, some undo blocks and some number of old blocks for serving, probably whatever fits in the amount of disk space the user is willing to allocate. But very old blocks will have been deleted. This leads to the question of what incentives people have to not prune. The obvious incentive is money - charge for access to older parts of the chain. The fewer people that host it, the more you can charge. In the worst case scenario where, you know, only 10 different organizations store a copy of the chain, it might mean that bootstrapping a new node in a trust-less manner is expensive. But I really doubt it'd ever get so few. Serving large static datasets just isn't that expensive. Also, you don't actually need to replay from the genesis block to bring up a new code, you can copy the UTXO database from somewhere else. By comparing the databases of lots of different nodes together, the chances of you being in a matrix-like sybil world can be reduced to beyond reasonable doubt. Maybe nodes would charge for copies of their database too, but ideally there are lots of nodes and so the charge for that should be so close to zero as makes no odds - you can trivially undercut someone by buying access to the dataset and then reselling it for a bit less, so the price should converge on the actual cost of providing the service. Which will be very cheap. There was one last thought I had, which is that if there's a shorter team need to discourage this kind of thing we can use a network/bandwith related hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist can apply to Bloom filtering such that transactions which are known to be abusive require you to fully download the block rather than select the transactions with a filter. This means that people can still access the data in the chain, but the older it gets the slower and more bandwidth intensive it becomes. Stuffing Wikileaks into the chain sounds good when a 20 line Python script can extract it instantly. If someone who wants the files has to download gigabytes of padding around it first, suddenly hosting it on a Tor hidden service becomes more attractive. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal
Re: [Bitcoin-development] On-going data spam
Well, I'm not fundamentally opposed to a blacklist, but it would have to be done in a VERY open manner. I do think the community would agree that storing big data transactions is not the primary purpose of bitcoin. However, there should be some metrics and heuristics that take care of this problem. Notably the dev consensus (sans you, Mike :)) seems to be that uneconomical outputs should be made non-standard. Here is one approach: Block uneconomic UTXO creation https://github.com/bitcoin/bitcoin/pull/2351 I would like to see at least a stopgap solution to data spam in 0.8.2, as it is a clear and present problem. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
However, there should be some metrics and heuristics that take care of this problem. Notably the dev consensus (sans you, Mike :)) seems to be that uneconomical outputs should be made non-standard. I think that patch is ok as it doesn't really have any fixed concept of what is uneconomical. But I haven't thought about it much. As Gavin says, there's an obvious backwards compatibility problem there. It should probably wait until the payment protocol work is done, so the major user of micropayments-as-messages can migrate off them. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On Tue, Apr 9, 2013 at 10:53 AM, Mike Hearn m...@plan99.net wrote: However, there should be some metrics and heuristics that take care of this problem. Notably the dev consensus (sans you, Mike :)) seems to be that uneconomical outputs should be made non-standard. I think that patch is ok as it doesn't really have any fixed concept of what is uneconomical. But I haven't thought about it much. As Gavin says, there's an obvious backwards compatibility problem there. It should probably wait until the payment protocol work is done, so the major user of micropayments-as-messages can migrate off them. wait is only an option if there is an alternate solution already coded and ready for 0.8.2. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On Tue, Apr 09, 2013 at 04:53:47PM +0200, Mike Hearn wrote: there's an obvious backwards compatibility problem there. It should probably wait until the payment protocol work is done, so the major user of micropayments-as-messages can migrate off them. As I pointed out in my initial post on the issue, SatoshiDice is pretty much unaffected by the patch. They just have to deduct enough from incoming bets to make the you lost output economical and they're good to go. IIRC they already deduct fees on low-value bets anyway. On the other hand, the patch makes a clear statement that Bitcoin is not for microtransactions. If succesful it will gradually force a number of users, ad-based faucet sites and the like, to off-chain transactions or off Bitcoin entirely. The payment protocol has nothing to do with that. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
On 09/04/2013 15:39, Caleb James DeLisle wrote: Agreed on the legality aspect but another case which is worth considering is what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Do you mean firewalls or something like snort or other deep packet inspection for the tcp sockets statement? I dont see much of an issue with either. set up your own private testnet and have a play with this http://www.eicar.org/83-0-Anti-Malware-Testfile.html The eicar test virus. Perhaps worth contacting an AV company and asking what is the smallest data they have a signature on. I have tried a few ways of getting the eicar string into the blockchain (on a private testnet) and getting it flagged by AV, however it is a bit tricky (the getting it flagged bit). and tbh you would exclude the bitcoin directory and runtime from antivirus scans so i stopped bothering. I am making vague assumptions about using windows with antivirus. (and linux for deep packet inspection, but the idea is the same whatever.) I found no greater attack surface area (in the blockchain) than cookies... thinking about it a bit more, there is a bit more potential as a bounce pad/egg drop location but not much - no heap spraying as such, or d/c tors, or heap header structs, etc. Im sure someone is sure to come up with something very clever tho. just not me. cheers, steve Thanks, Caleb On 04/09/2013 06:42 AM, Mike Hearn wrote: OK, as the start of that conversation is now on the list, I might as well post the other thoughts we had. Or at least that I had :) It's tempting to see this kind of abuse through the lens of fees, because we only have a few hammers and so everything looks like a kind of nail. The problem is the moment you try to define abuse economically you end up excluding legitimate and beneficial uses as well. Maybe Peters patch for uneconomical outputs is different because of how it works. But mostly it's true. In this case, fees would never work - Peter said the guy who uploaded Wikileaks paid something like $500 to do it. I guess by now it's more like $600-$700. It's hard for regular end users to compete with that kind of wild-eyed dedication to the cause. The root problem here is people believe the block chain is a data structure that will live forever and be served by everyone for free, in perpetuity, and is thus the perfect place for uncensorable stuff. That's a reasonable assumption given how Bitcoin works today. But there's no reason it will be true in the long run (I know this can be an unpopular viewpoint). Firstly, legal issues - I think it's very unlikely any sane court would care about illegal stuff in the block chain given you need special tools to extract it (mens rea). Besides, I guess most end users will end up on SPV clients as they mature. So these users already don't have a copy of the entire block chain. I don't worry too much about this. Secondly, the need to host blocks forever. In future, many (most?) full nodes will be pruning, and won't actually store old blocks at all. They'll just have the utxo database, some undo blocks and some number of old blocks for serving, probably whatever fits in the amount of disk space the user is willing to allocate. But very old blocks will have been deleted. This leads to the question of what incentives people have to not prune. The obvious incentive is money - charge for access to older parts of the chain. The fewer people that host it, the more you can charge. In the worst case scenario where, you know, only 10 different organizations store a copy of the chain, it might mean that bootstrapping a new node in a trust-less manner is expensive. But I really doubt it'd ever get so few. Serving large static datasets just isn't that expensive. Also, you don't actually need to replay from the genesis block to bring up a new code, you can copy the UTXO database from somewhere else. By comparing the databases of lots of different nodes together, the chances of you being in a matrix-like sybil world can be reduced to beyond reasonable doubt. Maybe nodes would charge for copies of their database too, but ideally there are lots of nodes and so the charge for that should be so close to zero as makes no odds - you can trivially undercut someone by buying access to the dataset and then reselling it for a bit less, so the price should converge on the actual cost of providing the service. Which will be very cheap. There was one last thought I had, which is that if there's a shorter team need to discourage this kind of thing we can use a network/bandwith related hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist can apply to Bloom filtering such that transactions which are known to be abusive require you to fully download the
Re: [Bitcoin-development] On-going data spam
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Perhaps worth contacting an AV company and asking what is the smallest data they have a signature on. I stuffed the testnet chain full of the EICAR test string and it hasn't triggered for anyone— it seems that (most?) AV tools do not scan big binary files of unknown type.. apparently. If we encounter a case where they do we can implement storage scrambling: E.g. every node picks a random word and all their stored data is xored with it. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoinj 0.8
I'm happy to announce the release of bitcoinj 0.8, a Java library for writing Bitcoin applications. Both simplified and full verification are supported. BitcoinJ has been used to create everything from end-user wallet apps to network crawlers to SatoshiDice. To get bitcoinj 0.8, check out our source from git and then run *git fetch --all; git checkout **cbbb1a2bf4d1*. This will place you on the 0.8 release in a secure manner. This message was written on Tuesday 9th April 2013 and is signed with the following key, which will be used in all release announcements in future: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m. Signature for previous paragraph: H8itldUGHHt8jXmFwRX/gASXrhG1a/k0VG0vwFMjQCAWDpxgA17ODfSPFNgAOPDnPmT1gLLUlHsEqwXHBoj+JMU= You can also verify the google.com DKIM signature on the official announcementhttps://groups.google.com/forum/?fromgroups=#!topic/bitcoinj-announce/IB7dlc_g9sU . I'm especially happy about this release because for the first time, we have an SPV implementation that is competitive performance-wise with more centralised solutions that rely on custom servers. Wallets based on bitcoinj 0.8 complete first time setup for new users in only a few seconds, eliminating the last source of significant delays. Every operation except key import now completes more or less immediately. *New in this release* - Thanks to Jim Burton, encryption of private keys in the wallet is now supported. Keys are encrypted using an AES key derived using scrypt. - A new SPVBlockStore provides dramatically better performance and bounded disk usage by storing block headers in an mmapped ring buffer. This makes syncing headers for new chains/wallets network limited instead of disk io limited. - A new tool is provided to create lists of block header checkpoints that can then be used to initialize a new block store. This allows most headers to not be downloaded when initializing a new chain/wallet, making first-run of new wallets much faster. - Bloom-filtering capable nodes are now queried for transactions at startup, meaning you can receive payments that weren't confirmed yet even if your wallet wasn't running at the time. - Many static analysis warnings have been cleared. - All event listeners except transaction confidence listeners now run unlocked and core objects have been converted to use cycle detecting locks. Multiple lock inversions were fixed. - DNS seeds are now supported for testnet. - PeerEventListener now lets you catch and process exceptions thrown during peer message processing. This is useful for reporting crashes that don't take out your entire app, but just result in disconnection of a peer. - Matt Corallo's bitcoind comparison tool was merged in. It runs a large set of regression tests that compares the behaviour of bitcoinj in full verification mode against bitcoind. - The vast bulk of the changes in this release are bug fixes, optimizations and minor API improvements. They are too numerous to list here, please refer to the commit logs for details. *API changes:* - Event listeners were previously locked before being called, and the object being listened to was also locked. This is no longer true - your event listeners must be thread safe and the objects that triggered the event may be changing in parallel. - IrcDiscovery is now deprecated, as LFnet has gone offline and DNS seeding can be used for both test and production networks. The code is still there in case you want to use IRC bootstrapping for a private experimental network. - BoundedOverheadBlockStore is now deprecated. It was replaced by SPVBlockStore. The file format has changed, so BOBS will stick around for a while so users can be upgraded. - The Derby based block store has been deleted. It only supported SPV mode and wasn't used much. - The static NetworkParameters methods now vend singleton objects. - WalletEventListener.onCoinsSent is no longer run when a transaction sends to self but the balance doesn't change. *Known issues:* - Transaction confidence listeners are still run with the wallet lock held, which means it's possible to trigger unexpected lock inversions by doing certain things inside them. Also, confidence listeners sometimes run in places where the wallet code is not fully re-entrant, meaning that modifying the wallet whilst inside a confidence listener may cause problems. A simple fix is to run your listener code in a separate thread. A future release will fix this by ensuring that listeners only ever run at the end of wallet mutating operations and with the wallet unlocked. Core objects will also switch to using non-reentrant locks so unexpected reentrancy deadlocks early and reliably. - If multiple peers disconnect simultaneously it's possible for the system to deadlock due to Netty allowing uncontrolled reentrancy when sending outbound
[Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
(1) Define a new address type, P2SH^2 like P2SH but is instead H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is a hash of a P2SH address. (2) Make a relay rule so that to relay a P2SH^2 you must include along the inner P2SH address. All nodes can trivially verify it by hashing it. (2a) If we find that miners mine P2SH^2 addresses where the P2SH wasn't relayed (e.g. they want the fees) we introduce a block discouragement rule where a block is discouraged if you receive it without receiving the P2SH^2 pre-images for it. With this minor change there is _no_ non-prunable location for users to cram data into except values. (and the inefficiency of cramming data into values is a strong deterrent in any case) The same thing could also be done for OP_RETURN PUSH value outputs used to link transactions to data. Make the data be a hash, outside of the txn include the preimage of the hash. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote: Note how we can already do this: P2SH uses Hash160, which is RIPE160(SHA256(d)) We still need a new P2SH *address* type, that provides the full 256 bits, but no-one uses P2SH addresses yet anyway. This will restrict data stuffing to brute forcing hash collisions. It'd be interesting working out the math for how effective that is, but it'll certainely be expensive in terms of time hashing power that could solve shares instead. (1) Define a new address type, P2SH^2 like P2SH but is instead H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is a hash of a P2SH address. (2) Make a relay rule so that to relay a P2SH^2 you must include along the inner P2SH address. All nodes can trivially verify it by hashing it. (2a) If we find that miners mine P2SH^2 addresses where the P2SH wasn't relayed (e.g. they want the fees) we introduce a block discouragement rule where a block is discouraged if you receive it without receiving the P2SH^2 pre-images for it. With this minor change there is _no_ non-prunable location for users to cram data into except values. (and the inefficiency of cramming data into values is a strong deterrent in any case) The same thing could also be done for OP_RETURN PUSH value outputs used to link transactions to data. Make the data be a hash, outside of the txn include the preimage of the hash. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote: On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote: Note how we can already do this: P2SH uses Hash160, which is RIPE160(SHA256(d)) We still need a new P2SH *address* type, that provides the full 256 bits, but no-one uses P2SH addresses yet anyway. This will restrict data stuffing to brute forcing hash collisions. It'd be interesting working out the math for how effective that is, but it'll certainely be expensive in terms of time hashing power that could solve shares instead. Oh, and while we're at it, long-term (hard-fork) it'd be good to change the tx hash algorithm to extend the merkle tree into the txouts/txins itself, which means that to prove a given txout exists you only need to provide it, rather than the full tx. Currently pruning can't prune a whole tx until every output is spent. Make that change and we can prune tx's bit by bit, and still be able to serve nodes requesting proof of their UTXO without making life difficult for anyone trying to spent old UTXO's. The idea is also part of UTXO proof stuff anyway. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
