Re: [Bitcoin-development] Punishing empty blocks?
I like the concept except that it only works if every node connected to the miner enforces the rule (if it works). Once any one of the nodes forwards the block, other nodes see it coming from a node that can pass the challenge. I don't think any solution based on node queries will succeed, especially if it requires spontaneous super-majority-of-nodes acceptance. I think it's gotta be based on the block itself and each nodes' own info. If you could spontaneously get all miners to agree not to build off of anti-social blocks (however that is defined) , it would have a chance of making a difference, but individual miners would have an advantage building off the antisocial block because they only need to produce one to create the longest chain (and collect reward) while the miners following the rules need two blocks. --Sent from my overpriced smartphone On May 25, 2012 3:48 AM, Christian Decker decker.christ...@gmail.com wrote: How about a simple proof of work test? This one though does not ask for CPU work but asks the miner for a random old transaction. If the miner really stores the entire blockchain he will not have any problem answering to that getdata request, whereas a botnet would have to ask someone else for it, which could be detected if the response time deviates too much from what has been previously measured (compare it against getdata for the block they advertise). It's not perfect but it allows an estimate of whether it is a chainless miner. Regards, Chris -- Christian Decker On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik jgar...@exmulti.com wrote: On Thu, May 24, 2012 at 8:57 PM, Luke-Jr l...@dashjr.org wrote: Block times are not accurate enough for that. The times in your log are very accurate, assuming your system clock is remotely accurate. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Punishing empty blocks?
We just implemented our own mining tool, soup-to-nuts, and I would say that the likely motivation for what I presume are botnet owners is just economic. It's a lot more work to make sure your merkleing and keeping up-to-date are happening than it is to just get an 80 byte header from a central server, and re-calc a single transaction merkle client-side. Not to mention the extra work to keep track of what version of getmemorypool output you're receiving work for in a broadly distributed pool. For what it's worth, we did this extra engineering work since we care about Bitcoin, but if I just wanted to pull value out of the ecosystem, we would have skipped it. The only solutions to this are economic solutions -- making such 'cheater' blocks less valuable, or increasing the value of the transactions. Also note that botnet operators likely care, in the end, about fiat currency, so going to 25 btc per block in what I think of as transaction fee subsidies won't necessarily impact this -- it's a matter of what happens to exchange rates vs generation rates that will matter. I think we also have to moderate this consideration against the rights (and arguable benefits) of someone wanting to build an express-delivery mining service, one that will provide provably faster certification for those adding a transaction fee of, say, 1 btc. My own experience now in the MMO world is that we have to carefully understand how we deal with griefers who control massive resources (compute or gold-farmers). It may not be a winning battle to choose a solution which harms the rest of the network in exchange for harming the griefers. This is definitely out of the box, but one solution might be to change the difficulty calculations to just ignore 1tx blocks; that would minimize impact on others to a great extent, and would let someone set up an express block service if they chose. I guess we'd have to settle on whether or not such blocks counted towards the issuance countdown as well. Or, we could allow only 1/10 generation fees on such blocks. Peter On Fri, May 25, 2012 at 9:44 AM, Alan Reiner etothe...@gmail.com wrote: I like the concept except that it only works if every node connected to the miner enforces the rule (if it works). Once any one of the nodes forwards the block, other nodes see it coming from a node that can pass the challenge. I don't think any solution based on node queries will succeed, especially if it requires spontaneous super-majority-of-nodes acceptance. I think it's gotta be based on the block itself and each nodes' own info. If you could spontaneously get all miners to agree not to build off of anti-social blocks (however that is defined) , it would have a chance of making a difference, but individual miners would have an advantage building off the antisocial block because they only need to produce one to create the longest chain (and collect reward) while the miners following the rules need two blocks. --Sent from my overpriced smartphone On May 25, 2012 3:48 AM, Christian Decker decker.christ...@gmail.com wrote: How about a simple proof of work test? This one though does not ask for CPU work but asks the miner for a random old transaction. If the miner really stores the entire blockchain he will not have any problem answering to that getdata request, whereas a botnet would have to ask someone else for it, which could be detected if the response time deviates too much from what has been previously measured (compare it against getdata for the block they advertise). It's not perfect but it allows an estimate of whether it is a chainless miner. Regards, Chris -- Christian Decker On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik jgar...@exmulti.com wrote: On Thu, May 24, 2012 at 8:57 PM, Luke-Jr l...@dashjr.org wrote: Block times are not accurate enough for that. The times in your log are very accurate, assuming your system clock is remotely accurate. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Bitcoin-development] Punishing empty blocks?
For what it is worth, I question whether this is a problem. Or, I guess I question whether the best solution to it isn't for people to start including more transaction fees. In fact, I'm not entirely sure that this problem doesn't actually *encourage* people to that solution, which would be very good if true. I would be more comfortable if the reward for mining were more commensurate with the value it provides. Ultimately, of course, that means that each transaction fee would have to be more of a proportion of the value *to the spender* of that transaction being included in the blockchain. (Aside: in order to convey to outsiders that miners are providing a useful service rather than gaining undeserved reward for wasting electricity, I refer to them as distributed transaction verification servers rather than miners whenever possible.) I'm pretty sure that — assuming there isn't some Bitcoin-killing disaster — transaction fees will eventually rise, but sooner might be better, especially with the first coinbase-halving looming. Perhaps people will be motivated to include transaction fees if they know that some miners don't bother to validate their transactions and others do. They may feel motivated to reward the miners that are serving them and punish the ones that are not. (Note: this wouldn't be a valid strategy on their part from a strictly game-theoretic perspective, but if they act on those motivations, then I don't care if it was rational or not.) Also, they may decide that they want to counteract the added delay which those no-transactions miners are adding to *all* transactions (with or without fee), by putting a fee on their transactions in order to make them take less long when they are processed by a miner which does process (some) transactions. Already this visualization, which I typically glance at a few times a day, usually shows a good separation with fee-included transactions sometimes doing much better than (some) free transactions: http://bitcoinstats.org/ However, this graph shows that the aggregate reward to the miners for processing transaction is minimal: http://blockchain.info/charts/transaction-fees?timespan=60daysshowDataPoints=falsedaysAverageString=1show_header=truescale=0address= You can see from the first visualization (assuming it is showing the typical pattern that I've seen) how you risk greater delay by sending your transaction without fees. The no-transactions miners push *all* transactions, fee or no-fee to the right. This may incentivize more people to change their transactions from red diamonds into blue circles, in order to move their transactions further to the left, even though the no-transactions miners are not currently discriminating among the two types. Therefore, the presence of those miners may help push the aggregate fees in that latter graph up, which is something I would very much like to see. Regards, Zooko -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
