<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr">Den lör 24 feb. 2018 08:19Ray Dillinger <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we want scalability, we need to have the miners able to form blocks<br>
rapidly when that's needed.  Let's say there's no one-per-ten-minutes<br>
regulation, and anybody can make a block at any time, whenever they can<br>
fill one up.  In that case we have to motivate them somehow to NOT make<br>
blocks for no reason or with no transactions or with meaningless<br>
transactions. So clearly it couldn't pay a regular block subsidy.<br>
<br>
It is really hard to come up with some means of coin creation that isn't<br>
easily cheated with meaningless transactions by miners who can form<br>
blocks whenever they want.  If anybody has ideas on that front, let's<br>
hear 'em.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I've already posted my idea to solve exactly this on the Bitcoin development mailing list. (didn't get much response, though) </div><div dir="auto"><br></div><div dir="auto">Scale difficulty with block size. </div><div dir="auto"><br></div><div dir="auto">Making large blocks makes it more expensive to solve the proof of work. This is only profitable if creating larger blocks for some reason is profitable to you. </div><div dir="auto"><br></div><div dir="auto">This requires somehow getting paid for making the blocks larger, typically meaning that you are including fee paying transactions from *other* people (fees may be paid via another channel). Bloating it with your own transactions is then only an accounting trick that still lose you money because of increased difficulty. </div><div dir="auto"><br></div><div dir="auto">(This doesn't solve the superrational attack by a rich attacker, but increases the cost.) </div><div dir="auto"><br></div><div dir="auto">The subsidy per block wouldn't necessarily need to scale much. We're still aiming for a consistent block rate, that now adjusts difficulty based on both current average block sizes + block rate. </div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">Also, my favorite solution for efficient large blocks since I first saw somebody mention application of Zero-knowledge proofs to Bitcoin is proof carrying blocks - while the raw blockchain is just as large as before, regular users don't need to keep anything other than the headers - a simple Merkle tree hash root with a Zero-knowledge proof of validity, and the block hash (PoW hash). </div><div dir="auto"><br></div><div dir="auto">All other data is referenced by that Merkle tree hash, and can be served / fetched as necessary (such as payer -> payee) to show the exact contents. </div><div dir="auto"><br></div><div dir="auto">Also this allows secure checkpointing such that all old still relevant data (unspent outputs) can be frequently collected into a compressed block with its own Zero-knowledge proof. This is a safe way to use a rolling blockchain that in practice only grows approximately logarithmically with usage, instead of superlinearly. </div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">Another sidenote, nobody seems to have mentioned tech like Lightning Network (LN) yet.</div><div dir="auto"><br></div><div dir="auto">By using a combination of multisignature transactions, time expiration scripts, notary/relay LN nodes and collateral provided by these nodes, as well as transaction channels (a protocol for two parties to use a valid but non-committed "transaction template" as a running tab for payments), it creates a very robust system with strong theft and abuse resistance properties.</div><div dir="auto"><br></div><div dir="auto">It's a federated system like email, where instead of paying directly via the blockchain, you use a node to coordinate a larger number of payments that then gets routed across the network of relays. These then gets settled periodically on the blockchain. This reduces the amount of traffic that the miners need to handle.</div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">As mentioned above, I'm a fan of Zero-knowledge proofs. My ideal cryptocurrency system would essentially be a system that makes LN "native", supports execution of complex scripts within this system, and which uses Zero-knowledge proofs to create compressed blocks that represents the full state of the system.</div><div dir="auto"><br></div><div dir="auto">This would essentially be a stronger version of what Ethereum promises to be. Programmable money, for real. You would have genuinely smart contracts that can resolve in seconds. By having everybody provide well structured data (signed by the respective publishers) into the system, everybody would have the capabilities that currently only HFT traders and similar has, where everybody can work with public API:s.</div><div dir="auto"><br></div><div dir="auto">It would even allow you to enforce these complex contracts without revealing their contents! </div></div>