Re: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: Outbound connections rotation)
DKIM is hardly a PoW; signing is cheap and gets cheaper all the time. I used to work in the email business and big bulk mailers all spent far more CPU time on other aspects of their business, the overhead of DKIM is irrelevant. PoW didn't work in the anti spam world because it (amongst other problems) mixes up bulk mail and spam, which are not the same thing. Very common conceptual error though. humans also don't care if their patience is put to the test by having to wait until one Tor exit node is finally unbanned, or by waiting for the connection PoW to finish because it temporarily got harder due to an attack. They don't? This is news to me. Humans always care. One of the surest ways to hurt your online business is to have a slow website because lots of users will give up rather than tolerate a few seconds of latency. At Google we actually had formulas that could relate a change in web search latency to revenue impact. So humans very much care! I actually doubt that any reasonable mobile wallet will use the new Tor support bitcoinj by default, for example, because it imposes quite some startup cost when the downloaded consensus isn't fresh, and slow startup is painful. It could be optimised but nobody has done that. For long running desktop wallets where startup time can be amortised over hours or days, I guess it makes more sense. I agree that PoW tokens might make sense as a last resort if nodes can't even put a connection at the bottom of a priority queue and you're right that it may be a useful tool in a shared toolbox. However if we reach the point where users are all being PoWd then we're already pretty hosed and it's probably close to game over :( I'd say, better have a few Tor-based users realize that they should look for a fixed update because their client has to do PoW for connecting, rather than having all Tor-based users locked out. I think Tor is a separate issue. If an attacker wants to either force all users off Tor, or force them via a handful of exits, then this attack is quite detectable already and wallets could already decide to simply give up on Tor at that point automatically. No PoW needed. Well, ideally, nodes would disconnect a banned IP with some kind of notice saying why it was banned, but that's a small improvement. Still, users should be notified that something is unusual. If we're talking mainstream success then users by and large do not care about technical mumbo jumbo like peer to peer networks or Tor (that's the thing drug dealers and pedos use???). They just want the damn thing to work reliably. So notifying them is unhelpful - it's not actionable. They would just see a message like The wizzle sprocket is kaput - keep working? YES NO and then everyone presses yes. Stuff like Tor plays well in the crypto community but it's very hard to actually switch on by default, because it needs to have absolutely no cost at all, otherwise you'll just annoy the vast majority who don't want to pay for very abstract and hard to quantify privacy benefits. So I think it's worth considering the DoS problem and Tor somewhat separately, even though they're related. The solution to a crafty privacy-attacking DoS that tries to make exits useless is don't use Tor at all. The solution to the entire Bitcoin network is under attack is much harder. It's unclear to me we can ever solve it convincingly - banks don't connect together using private networks in which anonymity is forbidden because they're stupid. They do it because it solves DoS attacks in one solid move and they feel it's worth the high cost. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon flavien.char...@coinprism.com wrote: My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel The number one user of the blockchain as a storage and transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from doing so. In fact they use multi-sig outputs which is worse than OP_RETURN since it's not always prunable, and yet let them store much more than 40 bytes. For Open Assets https://github.com/OpenAssets/open-assets-protocol, we need to store a URL in the OP_RETURN output (with optionally a hash) plus some bytes of overhead. 40 bytes comes really short for that. The benefit of having a URL in there is that any storage mechanism can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcode the storing mechanism in the protocol (and even then, a hash is not enough to address a HTTP or FTP resource). Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting. I've counted the number of OP_RETURN outputs in the blockchain for the month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659 blocks. Assuming they were all 40 bytes (the average is probably less than half of that), that means an increase of 14.37 bytes per block. Considering a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data in average. Increasing to 80 bytes will have a negligible impact on bandwidth and storage requirements, while being extremely useful for many use cases where a hash only is not enough. While I am not opposing the proposal, I am not sure about your statistics because while Counterparty is not currently using OP_RETURN encoding, you should factor in the number of CP transactions that would have been OP_RETURNs if they had been permitted (100,000 since inception according their blog[1] with monthly charts at their block explorer[2]). Refs: [1] http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/ [2] http://blockscan.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On Nov 17, 2014 7:39 AM, Pieter Wuille pieter.wui...@gmail.com wrote: That is inevitable for any wallet that offers any functionality beyond just maintaining a balance and the ability to send coins. In particular, anything that wishes to list previous transaction (with timestamps, history, metadata, messages sent using t What HD wallets (or any type of deterministic derivation scheme) offer is the fact that you can separate secret data and public data. You only need one safe backup of the master secret key - all the rest can at most result in privacy loss and not in lost coins. -- Pieter I agree but right now wallets not using stealth will only lose metadata, not coins, if their computer crashes and they have the seed backed up. But if a user wants to upgrade to stealth, they then risk losing metadata AND coins if they either didn't manually back up after every transaction or use a centralized cloud backup service. That's if OP_RETURN is not utilized for storage. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
While I am not opposing the proposal, I am not sure about your statistics because while Counterparty is not currently using OP_RETURN encoding, you should factor in the number of CP transactions that would have been OP_RETURNs if they had been permitted (100,000 since inception according their blog[1] with monthly charts at their block explorer[2]). Sure, but even if they are not permitted to store their data in OP_RETURN, they will still store it in the blockchain in bare multisig outputs, so it's not contributing to an overhead (in fact, it would consume less space in the blockchain if they used OP_RETURN). On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak btcd...@gmail.com wrote: On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon flavien.char...@coinprism.com wrote: My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel The number one user of the blockchain as a storage and transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from doing so. In fact they use multi-sig outputs which is worse than OP_RETURN since it's not always prunable, and yet let them store much more than 40 bytes. For Open Assets https://github.com/OpenAssets/open-assets-protocol, we need to store a URL in the OP_RETURN output (with optionally a hash) plus some bytes of overhead. 40 bytes comes really short for that. The benefit of having a URL in there is that any storage mechanism can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcode the storing mechanism in the protocol (and even then, a hash is not enough to address a HTTP or FTP resource). Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting. I've counted the number of OP_RETURN outputs in the blockchain for the month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659 blocks. Assuming they were all 40 bytes (the average is probably less than half of that), that means an increase of 14.37 bytes per block. Considering a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data in average. Increasing to 80 bytes will have a negligible impact on bandwidth and storage requirements, while being extremely useful for many use cases where a hash only is not enough. While I am not opposing the proposal, I am not sure about your statistics because while Counterparty is not currently using OP_RETURN encoding, you should factor in the number of CP transactions that would have been OP_RETURNs if they had been permitted (100,000 since inception according their blog[1] with monthly charts at their block explorer[2]). Refs: [1] http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/ [2] http://blockscan.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
