If you think merge-mined chains represent proof-of-publication in a world of large pools, you misunderstand what the idea is. Fundamentally merge-mining is insecure without the participation of at least a very large fraction of the mining hashing power, which negates the scalability argument for merge-mining.
Don't forget about all the non-mining full nodes that would avoid having to carry the extra burden. Miners are getting financially rewarded for it, so it's much less of a problem for them. And hashing costs dominate up to pretty large scale anyway. That's the problem! If miners are the only ones with the data, then it's not proof of publication. Of course, this shows a flaw in Bitcoin, but at least for now we've been able to paper over that flaw... If anything, not being forced to curate the "garbage dump" in addition to the Bitcoin blockchain would enable more people to run Bitcoin full nodes. I understand that a lot of participants are unwilling/unable to fully verify, but hijacking the Bitcoin blockchain for a zillion other often unrelated and often unwelcome applications just makes the problem worse. I get your point though about parasitic users being incentivised to be, well, parasitic. Also, even if there is ultimately no technical means to prevent blockchain hijacking, this doesn't mean social pressures can't work to some useful degree. Well-respected developers being vocal about it at the very least this gives less abusive alternatives a PR advantage, or can correct the most egregious abuses - like e.g. mastercoin's initial use of non-prunable outputs. TXO commitments are just a small part of solving scalability - they only help with long-term storage and actually make bandwidth scalability significantly worse. They do appear to be a good approach to blockchain sharding - tree-chains makes use of them - but the people who have been claiming they represent some scaling breakthrough misunderstand the technology.
Right, I calculated a little while back something like a ~7 fold increase in bandwidth (for authenticated prefix trees), but my understanding was that they are useful because they enable partial verification/fraud discovery and distributed block construction, which spreads the increased bandwidth load over a much larger number of participants. Is this a misunderstanding? Or just an overestimation of the number of extra participants? Back in ancient times, there was a P2P filesharing network called "Mojo Nation" that attempted to use market based resource allocation for bandwidth, storage, and content indexing.
It didn't really work out for several reasons, but it's probably worth dusting off, fixing its price discovery problems, and repurposing for Bitcoin.
I guess I'm ancient, as I'm actually aware of Mojo Nation  Zooko et. al. were talking about implementing accounting a while ago for their more modest successor project, Tahoe-LAFS, though I'm not sure if they're still planning to do that. |
|
|
|
If you think merge-mined chains represent proof-of-publication in a world of large pools, you misunderstand what the idea is. Fundamentally merge-mining is insecure without the participation of at least a very large fraction of the mining hashing power, which negates the scalability argument for merge-mining.
Don't forget about all the non-mining full nodes that would avoid having to carry the extra burden. Miners are getting financially rewarded for it, so it's much less of a problem for them. And hashing costs dominate up to pretty large scale anyway. In fact, with some cleverness I suspect I could make the entire Mastercoin and Counterparty protocols be purely hash based and unblockable by generic mechanisms; I should put some thought into this...)
Well if the system can be hijacked, then I'm sure some clever people will do it, and this will make all the previous talk about ethical blockchain usage moot. #bitcoin-wizards is where this has been discussed. Working on a more formal paper for tree chains as well. I prefer not to discuss ideas here - much better to discuss ideas on open mediums like email lists that are archived by multiple entities.
Thanks, I saw the tree chain discussion, but haven't read through it carefully yet. Are you not interested in the MMR TXO commitments idea anymore? Looking forward to the paper, I hope you finish it before you begin working on the blockchain hijacking mechanism  |
|
|
|
"Garbage dumbp"
Please, don't write off useful applications for proof-of-publication so quickly.
I don't mean to; there are definitely interesting things that can be done. I just question whether it's necessary to do them on the Bitcoin blockchain. A truly symbiotic application seems like it could work perfectly well using a separate merged mined chain, and atomic cross chain trading. (And if the application is competing with Bitcoin, then all the more reason to keep it the hell off the Bitcoin blockchain, if possible.) What is or isn't a "Bitcoin application" is open to debate. I certainly think decentralized finance has the potential to be valuable, and it will be quite concretely based on Bitcoin as a medium of exchange in actual applications. More to the point, if I wish to, say, use a multisignature protected wallet, I'm creating transactions that take up significantly more blockchain space than those that don't. Of course, I pay for that space in fees, driving up costs for all Bitcoin users... So am I wrong for doing that?
Obviously pretty much nobody would object to that example. Yet consensus seems to be that using the blockchain for completely arbitrary data dumps is a bad idea. So yes the line is blurry, but that doesn't mean it doesn't exist or is safely ignored. My worry is if we don't stick to a strict market-based allocation of proof-of-publication security we're going to see an acceptance in this community of rationing it based on perceived value. Frankly, this is much like net neutrality debates - I believe in applying freedom of choice and non-judgemental market principles rather than having a small group of devs and pool operators decide what is or isn't the valid use of the Bitcoin blockchain.
This implies a rejection of any defined purpose for the blockchain: "it exists for whatever the highest bidders want to use it for". For example, crowded out users that just want to transfer bitcoins back and forth would IMHO be rightly upset by this kind of transformation. Also, it increasingly looks like the scalability stuff I'm working on can be done transparently in a backwards compatible manner - actually implementing that stuff may prove to be less of a disruption than forcing all Bitcoin software to use new address types.
I hope so! Better fundamental scalability is certainly the ideal solution. Since I like to keep up-to-date on these topics, what is your current favoured way to go here? Just the name of the proposal is fine, I can search through the chat logs/forums to get the details. Thanks. |
|
|
|
You don't need OP_RETURN to store data, particularly hashes. The idea being it was to encourage people to store data in the least harmful way possible in outputs that can be obviously pruned; like it or not putting data in the blockchain is useful so people will do it, and there's no good way to stop people from doing so.
As you pointed out in a recent post*, P2SH^2 on the scriptPubKey side and MASTs on the scriptSig side would work to keep the blockchain from becoming a garbage dump. Since both of these changes would be very good for both scalability and privacy, I don't understand why you were so quick to write them off as unlikely. Of course, once data is prunable, it's no different than any other transaction in terms of impact on the system - you're still paying fees on the exact same basis as doing any other transaction.
The problem is that non-Bitcoin applications compete for scarce block space, driving up the cost of transactions for Bitcoin users. As you know, this cost is either felt in the form of fees, or increased centralization if the block size is simply raised to accommodate. I don't think it's unreasonable to say that Bitcoin users ought not be burdened by arbitrary demands of its blockchain. You mentioned it being better to just focus on the root of the problem - fundamental scalability - but the potential solutions I've seen proposed by you seem like very radical changes (far more so than P2SH^2 or MASTs), and the conservative approach appears to be to protect the blockchain from abuse to the greatest extent possible at least until a particular scalability upgrade has been 1) implemented, 2) well-tested, and 3) widely agreed upon.Regarding OP_RETURN though, I agree that it's the proper way of doing damage control (though I worry that it sends the wrong signal to users that this usage is acceptable, and not abusive, and will encourage more of it), but only while P2SH^2 and MASTs are not yet implemented. * My advice for new projects is to support multiple encoding methods, the same was Mastercoin did, so you aren't dependent on the Bitcoin devs. Incidentally there's no practical way to stop all those methods - even P2SH^2, itself a very invasive change to the ecosystem which is unlikely to happen, can't stop encoding data in P2SH scriptSigs without merkleized abstract syntax tree support and risky changes to the scripting language... and that in turn has the big risk that you make upgrades in the future, perhaps because a crypto algorithm has been weakened, much more difficult to implement.
Of course, that's why I'm spending my time working on actually improving fundamental scalability rather than wasting time trying to tell people what to do with a trust-free decentralized system...
|
|
|
|
Can you clarify what you mean by "TXO commitments"? Can't we just have SPV clients do spot-checks (including tracing back to when the coin was generated) and if they find an invaild tx they send a invaild_alert(txhash) type alert?
In the authenticated prefix tree proposal, for example, a digest of the current set of unspent transaction outputs is included in each block, which enables short inclusion proofs. This is similar to the usual Merkle tree of transactions included in each block, except more efficiently updated. These would be needed to efficiently verify txins are valid, since you otherwise can't be sure they haven't already been spent without fully downloading every previous block. |
|
|
|
Nice, but not new ideas. Here's the most recent thread on "fraud proofs": https://bitcointalk.org/index.php?topic=137933.0. For "partial verification", we'd need TXO commitments by miners. Mark Friedenbach (maaku) recently implemented authenticated prefix trees for this, and Peter Todd has proposed an alternative data structure -- a so called Merkle mountain range (MMR) -- that may be more efficient. |
|
|
|
Every full node checks the validity of the coinbase transaction. SPV nodes currently don't, but they could if we switch to using Merkle sum trees.
The power that miners have over the network is strictly limited to choosing the transaction ordering. Their attacks are limited to denial of service (mining empty blocks), double spending (chain reorgs), and censorship (selective rejection of transactions for political reasons).
But even this rests on the assumption that the folks running non-mining, verifying nodes are economically significant enough as a whole to resist miner fraud.
You're right, it is up to every full node to validate the blockchain, but to implement a change in the blockchain, you don't need the majority of users, or miners. You only need the majority of mining operators. Once they adopt a change, they can prevent everyone else from using Bitcoin until they comply with that change. If the majority of mining operators (a very, very small minority of people) said "In order to spend Bitcoin, you must pay a 10% transaction fee (tax)." People would bitch and complain, but rather than letting go of their Bitcoin, they will comply with the new rules. If they decided to set Bitcoin on an inflationary tract, who's going to tell them differently? Uncle Joe, who's entire net worth is measured in Bitcoin? I don't think so. 90% are Uncle Joe, 10% will be cheering because their account balances will skyrocket! Don't underestimate the general apathy of the people, it's a powerful weapon in the right hands. You're seriously oversimplifying this scenario. The dynamics of such an attack are economically and socially complex, but if you think deeply about it, I think you'll find that defences can be mounted that would eventually bankrupt the attackers. Though it would be messy while it played out. You also don't seem to be considering the implications that this attack would have on confidence in the system, if successful. It's essentially an existential threat, and giving in simply isn't an option. |
|
|
|
This is where Bitcoin is headed if we only have a small handful of pool operators controlling the global hash power. What if those few decided to get together and issue a code update that allows them to generate all the BTC they wanted. Every full node checks the validity of the coinbase transaction. SPV nodes currently don't, but they could if we switch to using Merkle sum trees. The power that miners have over the network is strictly limited to choosing the transaction ordering. Their attacks are limited to denial of service (mining empty blocks), double spending (chain reorgs), and censorship (selective rejection of transactions for political reasons). But even this rests on the assumption that the folks running non-mining, verifying nodes are economically significant enough as a whole to resist miner fraud. |
|
|
|
Thanks for your reply. For (1) you could do merged-mining, as it costs practically nothing extra to miners. But then you have to be careful to keep interests aligned - the new chain can't be competing with Bitcoin, and should in fact be seen as complementing it in some not insignificant way. Okay, I think I understand, but with merged-mining the new chain would still have a currency of its own that functions as a reward for miners, no? No. Remember: it costs practically nothing extra to merged mine the new chain, so the incentive to mine doesn't have to be very large - complementing (and not competing with) Bitcoin in some not insignificant way could suffice. (2) could be addressed using identities that have a cost to create, and can be blacklisted if they are abusive. Yes, good point. Who would blacklist them though in a decentralized network? If one of your peers is being abusive, you would blacklist it. Notice though that a single identity gives you the ability to abuse every node once - ideally you want it so that abusing one node gets you on every node's blacklist. Distributing cryptographic proofs of bad behaviour might a way to achieve this. |
|
|
|
Could sending many dust transactions to a stealth address be a way to inconvenience the receiver? Or perhaps a way to force them to reveal sensitive details?
If the value is too small to be worth checking, it could just be ignored. |
|
|
|
For (1) you could do merged-mining, as it costs practically nothing extra to miners. But then you have to be careful to keep interests aligned - the new chain can't be competing with Bitcoin, and should in fact be seen as complementing it in some not insignificant way. (2) could be addressed using identities that have a cost to create, and can be blacklisted if they are abusive. E.g. https://en.bitcoin.it/wiki/Identity_protocol_v1, though I'd say just burn the coins in an OP_RETURN <SIN> transaction, since the proposed announce-commit miner sacrifice scheme requires non-standard transactions. |
|
|
|
Hopefully things will sort themselves out once miners have to really struggle to turn a profit. That day will come eventually Edit: That or lots of bad press about how Bitcoin advocates lied about it having low transaction fees... |
|
|
|
At today's exchange rate of ~800 USD/BTC, this is 0.7 cents.
Thanks. For a standard implementation, the size is closer to 250 bytes, so 50 times higher. That means 35 cents. Was intending to answer this: How low do you think they would go?
* "cost" is in quotations because it's not really a cost per se, but a reduction in expected revenue
It is a cost that should be accounted for. Sure, of course. I just like to be precise, as it has implications when thinking about collective miner strategies. Not relevant here though. |
|
|
|
We can solve the issue another way, by finding methods to reduce the fees (smartfees etc).
How low do you think they would go? Wasn't there a calculation somewhere about the potential block orphan probability vs extra bandwidth. That set the current (or one of the previous) fees. Not sure where the other estimate is, but here's mine: Using the CDF of the exponential distribution to estimate the probability of a block being orphaned during its propagation, the expected orphan "cost"* is approximately c ~= r(1-exp(-t/T)) ~= rt/T where r is the block reward, T is the block period, and t is the fractional hashing power-weighted mean time to get the block to the rest of the miners. (Not too hard to show this precisely.) The latter approximation is valid since t/T ~= 5/600 << 1**. Then the marginal cost to add a transaction is dc ~= r dt/T where dt is the marginal increase in block propagation time. Assuming a functional fee market between users and miners, and a profit margin of m for the miner, then the fee paid is f = (1 + m) dc ~= (1 + m) r dt/T Note that since f doesn't depend on t, only dt, the latency "cost"* is built into the basic "cost"* of mining a block, and shouldn't affect fees, ultimately. Thus, supposing the transaction has been well-propagated in advance, so that only the first D bytes of the txid needs to be broadcast, and assuming the (weighted) mean number of hops to the other miners is n and the mean bandwidth on these paths is B, then we have roughly (with some underlying assumptions) dt ~= nD/B So f ~= (1 + m) D/T n/B r Plugging in some rough estimates: r ~= 25 BTC T ~= 600s m ~= 0.06 n ~= 5 D ~= 5 bytes B ~- 1 Mb/s => f ~= 0.000009 BTC At today's exchange rate of ~800 USD/BTC, this is 0.7 cents. With a high-bandwidth, well-connected minernet, n/B, and thus f, could probably be reduced by one or two orders of magnitude***. This could always be used to counteract any crazy rise in the exchange rate, though it may be considered somewhat of a degradation of decentralization. * "cost" is in quotations because it's not really a cost per se, but a reduction in expected revenue ** http://bitcoinstats.com/network/propagation/*** Edit: actually, hashing and lookup times would become the bottleneck at this point: dt ~= nD/B ~= 3*5*8/10 8 s ~= 10 -6 s and this is ~ the time to do a SHA256 hash. |
|
|
|
Hrm. The problem is that even if the network decided to ask for passport blind-signing, that solution doesn't work for this use case because the attacker can issue passports.
I believe the idea is that the ZKPOP can reveal the country that issued the passport, so when setting up your Tor circuit, you'd select relays from distinct countries. Then a sybil attack against Tor would require international coordination of governments. Though don't governments generally have access to lots of foreign passport scans from border crossings, airport, etc.? |
|
|
|
So why did Mike Hearn go to lenghs to describe passport based verification of nodes? What problem was he proposing this would solve?
2) Flooding networks with peers that look unrelated but actually aren't. Tor has the same problem, so I'm interested in solutions that generalise to all P2P networks. For these proofs of propagation etc are irrelevant. For Bitcoin it might be possible in every case to come up with fancy tricks based on proof of work, though remember someone has to actually write the code for all of these ideas! But I don't see how to avoid the issue with Tor. There just isn't any reasonable way that the Tor directory operators can know if nodes are related today, and if they are, Tor fundamentally breaks. Given that GCHQ has been tasked with breaking Tor (they're thinking of the children you see), advanced sybil attacks on it seem more likely than not in the near future.
|
|
|
|
Today, blocks are distributed fast enough. If we scale to 10k TPS, blocks will need to be about 2 GB, right? Then it will take non-trivial time to transmit blocks over slowish links. That would put miners/pools based in countries with shitty internet connections at a disadvantage.
Miners can ensure that their peers know in advance about the txs they're mining. Then only the first few bytes of the txids would be necessary to uniquely identify them, and this is all that would need to be broadcast in bursts when blocks are found. Broadcasting the first say 5 bytes of the txid, instead of the full ~350 byte transaction, means a 98.6% reduction in necessary bandwidth. So 2GB -> 29MB. |
|
|
|
GCHQ has been tasked with breaking Tor (they're thinking of the children you see), advanced sybil attacks on it seem more likely than not in the near future.
Ugh... Anyway, like I said, I love all the ideas flying about. But ... I'd appreciate it if in future people don't take material that was written to be interesting for a short presentation and make stupid assumptions, like if I talk about one or two solutions that must automatically mean I didn't think about any other solutions, or am a "lazy thinker". It was a 15 minute meetup talk, not a university lecture series.
I wouldn't dare think of you as in any way lazy, and it's a shame that ideas can't be tossed around freely in Bitcoinland without witch-hunts ensuing. |
|
|
|
|
Show Posts
