Re: [Bitcoin-development] Block Size Increase Requirements
Hi Matt, I agree that starting discussion on how to approach this problem is necessary and it's difficult taking positions without details on what is being discussed. A simple hard 20-megabyte increase will likely create perverse incentives, perhaps a method can exist with some safe transition. I think ultimately, the underlying tension with this discussion is about the relative power of miners. Any transition of blocksize increase will increase the influence of miners, and it is about understanding the tradeoffs for each possible approach. On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote: > * I'd like to see some better conclusions to the discussion around > long-term incentives within the system. If we're just building Bitcoin > to work in five years, great, but if we want it all to keep working as > subsidy drops significantly, I'd like a better answer than "we'll deal > with it when we get there" or "it will happen, all the predictions based > on people's behavior today say so" (which are hopefully invalid thanks > to the previous point). Ideally, I'd love to see some real free pressure > already on the network starting to develop when we commit to hardforking > in a year. Not just full blocks with some fees because wallets are > including far greater fees than they really need to, but software which > properly handles fees across the ecosystem, smart fee increases when > transactions arent confirming (eg replace-by-fee, which could be limited > to increase-in-fees-only for those worried about double-spends). I think the long-term fee incentive structure needs to be significantly more granular. We've all seen miners and pools take the path of least resistance; often they just do whatever the community tells them to blindly. While this status quo can change in the future, I think designing sane defaults is a good path for any possible transition. It seems especially reasonable to maintain fee pressure for normal transactions during a hard-fork transition. It's possible to do so using some kind of soft-cap structure. Building in a default soft-cap of 1 megabyte for some far future scheduled fork would seem like a sane thing to do for bitcoin-core. It seems also viable to be far more aggressive. What's your (and the community's) opinion on some kind of coinbase voting protocol for soft-cap enforcement? It's possible to write in messages to the coinbase for a enforcible soft-cap that orphans out any transaction which violates these rules. It seems safest to have the transition has the first hardforked block be above 1MB, however, the next block default to an enforced 1MB block. If miners agree to go above this, they must vote in their coinbase to do so. There's a separate discussion about this starting on: cae-z3oxnjayluehbu0hdwu5pkrj6fpj7yptgbmq7hkxg3sj...@mail.gmail.com I think defaulting some kind of mechanism on reading the coinbase seems to be a good idea, I think left alone, miners may not do so. That way, it's possible to have your cake and eat it too, fee pressure will still exist, while block sizes can increase (provided it's in the miners' greater interests to do so). The Lightning Network's security model in the long-term may rely on a multi-tier soft-cap, but I'm not sure. If 2nd order systemic miner incentives were not a concern, a system which has an enforced soft-cap and permits breaching that soft-cap with some agreed upon much higher fee would work best. LN works without this, but it seems to be more secure if some kind of miner consensus rule is reached regarding prioritizing behavior of 2nd-layer consensus states. No matter how it's done, certain aspects of the security model of something like Lightning is reliant upon having block-space availability for transactions to enter into the blockchain in a timely manner (since "deprecated" channel states become valid again after some agreed upon block-time). I think pretty much everyone agrees that the 1MB block cap will eventually be a problem. While people may disagree with when that will be and how it'll play out, I think we're all in agreement that discussion about it is a good idea, especially when it comes to resolving blocking concerns. Starting a discussion on how a hypothetical blocksize increase will occur and the necessary blocking/want-to-have features/tradeoffs seems to be a great way to approach this problem. The needs for Lightning Network may be best optimized by being able to prioritizing a large mass of timeout transactions at once (when a well-connected node stops communicating). -- Joseph Poon -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On Sat, Apr 25, 2015 at 11:51:37PM -0700, Joseph Poon wrote: > signs the sigScript of the redeemed output. Err, typo, I meant: ... signs the *scriptPubKey* of the redeemed output. -- Joseph Poon -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
ust upgrade > P2SH to support additional OP codes? Assuming you mean the current P2SH scriptPubKey format, it's not possible to do so while making it a soft fork. If you use OP_EQUAL, current nodes will treat "P3SH" transactions as P2SH ones. I'm in favor of keeping P3SH conservative. It's possible to have your cake and eat it too, by enabling script versions within P3SH. If you create P3SH as: OP_DUP <20-byte hash> OP_EQUALVERIFY The redeemScript has the first byte as a version number, and there is also an OP_TRUE pushed right before the redeemScript. The scriptSig would look something like: OP_TRUE <3 redeemScript> When executing the script, the last item on the stack verifies against the hash, then the redeemScript is copied/read, the 3 is popped off (first byte unsigned int), the OP_TRUE is popped off the stack, and the script then executes P3SH "version 3" (again, it is the first byte, NOT an opcode). Any non-known version will return everything as true and not continue with execution of the script, to permit future soft-forks. The OP_TRUE is to ensure there is a OP_TRUE left on the stack just in case for older nodes as this is an EQUALVERIFY. This works because the address, 20-byte hash, has the 3 version number as part of the hash, so it is the recipient who determines the version number. For future soft-forks, it's incredibly flexible, just make the version byte to 4. Prior addresses work the same, and it's not possible to accidentally send it using different scripting versions. Perhaps this can make things upgradeable enough that a malleability sighash flag can go in sooner rather than later. -- Joseph Poon -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ASIC-proof mining
Thanks Mike. Indeed, I am aware of current approach, which is why I was suggesting this as an alternative. I haven't thought about it enough, and perhaps it was too radical a rethinking - just wanted to see what the smarter minds thought. Thanks again. -Randi On 7/5/14, 4:43 AM, Mike Hearn wrote: Is it possible instead to allocate a portion of the reward to " a # of runner up(s)" even though the runner-up(s) block will be orphaned? There's really no concept of a "runner up" because hashing is progress free. It's unintuitive and often trips people up. There's no concept that everyone is 95% of the way to finding a solution and then someone pips you to the post. It's more like playing the lottery over and over again. Doesn't matter how many times you did it before, the next time your chances are the same. A better concept is of rewarding "near miss" solutions which is what we already do of course, via pools, which pay you for shares which don't quite meet the difficulty target but almost do. So the question is how can we implement pools which have this reward structure (which obviously works well) without miners simultaneously giving up their right to block creation either due to technical problems or sheer lazyness. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ASIC-proof mining
Hi All, This is a bit tangential to the conversation, but since the genesis of this conversation is Mike's decentralization blog post, I decided to post here. Perhaps the solution to the mining problem lies in the reward structure rather than in the proof of work/asics. Is it possible instead to allocate a portion of the reward to " a # of runner up(s)" even though the runner-up(s) block will be orphaned? For example, X% of the block reward goes to Y number of runner-ups based on some type of criteria? This will appear to be a bit like a tax on the winner, but it could potentially solve the problem, since a large pool would not want to split the pool up to solve multiple blocks. There are some possible downsides, like probably having to keep those orphaned blocks around in the future, etc. If this is possible, the question that remains then, what would be the criteria for the X% payout/allocation? -Randi -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On naming, please allow consideration of "Confidential address". Less conflation with "private key", connotes confidence, and as the address is known to the transacting parties, it is a precisely accurate name. One of the use cases for these will be in multinational corporate internal international settlement. For a company to use bitcoin for its internal settlement and maintain confidence that competitors will not be able to suss out its transactions, these confidential addresses will be of great use. Stealth connotes stealing, theft, hiding, fear, sneakiness, stealth bombers. Maybe it is a good name, but not the best name. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
