Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)
On Sun, Jun 21, 2015 at 12:08 AM, Tier Nolan wrote: > The off by 1 bug could be fixed by a soft fork. Since the point is to show > how a non-controversial hard fork works, it doesn't matter much. You mean the timewarp fix can be coded as a softfork instead of a hardfork? How so? If that's the case, do you have a better candidate? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Re: [RFC] Canonical input and output ordering in transactions
-- Forwarded message -- From: "Jorge Timón" Date: Jun 17, 2015 6:59 PM Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions To: "Rusty Russell" Cc: On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell wrote: > Jorge Timón writes: >> On Jun 15, 2015 11:43 PM, "Rusty Russell" wrote: >> >>> Though Peter Todd's more general best-effort language might make more >>> sense. It's not like you can hide an OP_RETURN transaction to make it >>> look like something else, so that transaction not going to be >>> distinguished by non-canonical ordering. >> >> What about commitments that don't use op_return (ie pay2contract >> commitments)? > > I have no idea what they are? :) Here's a short explanation and the code: https://github.com/Blockstream/contracthashtool Here's a longer explanation with a concrete use case (the contract is the invoice): https://www.youtube.com/watch?v=qwyALGlG33Q > Yes, my plan B would be an informational bip with simple code, > suggesting a way to permute a transaction based on some secret. No > point everyone reinventing the wheel, badly. Great. Well, then all I'm saying is that I like this as plan A. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo wrote: > If we want a non-repudiation mechanism in the protocol, we should explicitly > define one rather than relying on “prima facie” assumptions. Otherwise, I > would recommend not relying on the existence of a signed transaction as proof > of intent to pay… Non-repudiation can be built on top of the payment protocol layer. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo wrote: > The Bitcoin network was designed (or should be designed) with the requirement > that it can withstand deliberate double-spend attacks that can come from > anywhere at any time… I disagree with this premise. Please, don't take this as an argument from authority fallacy, but I will cite Satoshi to express what I think the assumptions while using the system should be: "As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers." I can't say for sure what was meant by "attacking the network" in this context but I personally mean trying to rewrite valid and proof-of-work-timestamped history. Unconfirmed transactions are simply not part of history yet. Ordering unconfirmed transactions in a consensus compatible way without a universal clock is impossible, that's why we're using proof of work in the first place. Alternative policies are NOT attacks on the network. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)
This is an attempt to unify views on why and how hardforks can be deployed. I would like to turn this into an informational BIP later after gathering some feedback. Please, do not discuss block size issues here: there's plenty of threads to do so. The scope of this one is only hardforks and softforks in a more abstract way. Sometimes block size changes are used as examples because no other example came to mind (non-blocksize-related examples for the same cases [or others] are a user should be just ignored. But what if the welcomed), and if we go into too much detail they stop being useful as examples. So please, try to avoid going into too much detail about the concrete examples when possible. https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org Please, feel free to make suggestions or bike-shed some of the terms. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn wrote: >> Or alternatively, fix the reasons why users would have negative >> experiences with full blocks > > > It's impossible, Mark. By definition if Bitcoin does not have sufficient > capacity for everyone's transactions, some users who were using it will be > kicked out to make way for the others. Whether that happens in some kind of > stable organised way or (as with the current code) a fairly chaotic way > doesn't change the fundamental truth: some users will find their bitcoin > savings have become uneconomic to spend. He doesn't mean that: he means solving the mempool and crashes and hitting the limit would have. If the chain has limited size it is a scarce resource and people have to bid for it: nothing unexpected or wrong about that. Of course, people that believe the limit should be completely removed eventually because they don't care about mining being decentralized (or fail to see the relation between the two) may have a very different view about this. On Fri, Jun 19, 2015 at 12:08 PM, GC wrote: > Timeframe for transaction fees topping block reward fees => many years in > the future, based on current ratio of block reward to fees. Do you think that this ratio is unrelated to an abundant (non-scarce) block size? When is the right time to allow space pressure to rise that ratio? When the subsidy is at 1.5625, for example, it may be too late to start a non-catastrophic transition from subsidies to fees. I don't claim to know that, but it's something that worries me. No matter how many people say "that's too far away in the future to worry about it", I still worry about it and I'm sure more people do. What if "when it's time to care about it" we discover that we should have started to do things about it long ago to minimize the risks of this transition? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 8:23 PM, Gavin Andresen wrote: > On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos wrote: >> >> Let me take a pass at explaining how I see this. >> >> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is >> the decider but he works under a process that is well understood by >> developers on the project in which he takes under reasonable consideration >> other technical opinions and prefers to have clear agreement among them. > > > Yes. > >> 2) Changes to the consensus rules: As others have said, this isn't >> anyone's decision for anyone else. > > > Yes. > > [...] > > I don't think I agree with "pretty much everybody", because status-quo bias > is a very powerful thing. Any change that disrupts the way they've been > doing things will generate significant resistance -- there will be 10 or 20% > of any population that will take a position of "too busy to think about > this, everything seems to be working great, I don't like change, NO to any > change." But according to Alex's explanation (which I think is very good leaving asides some cases like change of the pow hashing function, for example) there's no individual that can force or veto a change. It is the decision of each individual user and their own "pretty much everybody" may vary. But this "pretty much everybody" is what Mark referred to with the "I know it when I see it." > The criteria for me is "clear super-majority of the people and businesses > who are using Bitcoin the most," and I think that criteria is met. If you recommend users to apply changes when this criterion is met but you know there's still many users who don't agree with the change, then you're acting irresponsibly by promoting a chaotic consensus fork where coins can be spent in both chains at once. Well...unless you're promoting it as an altcoin that simply happens to distribute part of the initial monetary based to bitcoin holders at block X and whose genesis block is equal to bitcoin's genesis block at block X. I guess in that case you wouldn't necessarily be irresponsible. "Miner's vote" is irrelevant here since it cannot tell you anything about users adoption (besides miner's adoption of course). >> 3) Code changes to Core that do change consensus: I think that Wladimir, >> all the other committers besides Gavin, and almost all of the other >> developers on Core would defer to #2 above and wait for its outcome to be >> clear before considering such a code change. > > > Yes, that's the way it has mostly been working. But even before stepping > down as Lead I was starting to wonder if there are ANY successful open > source projects that didn't have either a Benevolent Dictator or some clear > voting process to resolve disputes that cannot be settled with "rough > consensus." But this is only relevant for the point 1. Software projects can have dictators, forks and everything else other free software projects have. But consensus-based p2p blockchains cannot change their rules in the same way, otherwise they're centralized. THERE CANNOT BE A VOTING PROCESS FOR CONSENSUS CHANGES. If anybody can vote, hod do you prevent the sibyls from outvoting everyone? If not everybody can vote, how is the voters' list determined without centralizing the system? If we had a technical solution to this problem we wouldn't need proof of work in the first place!! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine wrote: > > hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up This will have to eventually be done in addition to any other "alternative" unless the plan is to keep rising the limit until it is removed or irrelevant. Maybe this should be the priority? Maybe this is the "alternative" that some no-block-size-limit proponents (meaning people who think that centralization is not a concern when deciding the block size limit) claim nobody was putting forward? Anyway, it's sad that we're always mixing 2 different topics: hardfork deployment and blocksize limit. I wish we talked more about the former, I wish we would have talked about it it long before the block size debate became "urgent" (or at least before it was being perceived as urgent). We've had plenty of time to deploy non-emergency hardforks but apparently no one was interested (say, for fixing miner but known bugs like the timetravel attack). In fact, I plan to eventually propose such a fork, I agree with gavin that "hardforks aren't possible" is not an answer, though finding opposition to a concrete hardfork in a concrete point in time doesn't mean that "hardforks aren't possible". I believe I have proposed many more hardforks than Gavin, all of them rejected and I still hope some of them will eventually make it into bitcoin main. When it was clear that wouldn't be the case I'm afraid the only answer is creating an altcoin (like Mark and I did with Freicoin and "xtcoin" could become [hopefully not destroying bitcoin main in the process]). On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine wrote: > Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core > maintainers simply refuse to lift the 1Mb limit? No one wants to go that > route. An alternate hard-fork proposal like BIP100 that gets consensus, or > a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or > hell even some major changes to the non-consunsus code to make it > adequately handle the situation when blocks fill up, and allow wallet > software to continue working with a send-and-forget use pattern, any of > these would be enough to avoid the need for an XT only hard-fork. > > So far BIP100 is the only one that seems to actually be getting any sort > of momentum toward consensus, and it was proposed... 2 days ago? When the > XT fork was proposed as a last resort, it was when the opponents were (to > my understanding) suggesting we just let blocks fill up, and hopefully > things would just work out on their own. > > > > Aaron Voisine > co-founder and CEO > breadwallet.com > > On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman > wrote: > >> Who is actually planning to move to Bitcoin-XT if this happens? >> >> Just Gavin and Mike? >> >> [image: image1.JPG] >> >> On Jun 15, 2015, at 6:17 PM, Faiz Khan wrote: >> >> I'm quite puzzled by the response myself, it doesn't seem to address some >> of the (more serious) concerns that Adam put out, the most important >> question that was asked being the one regarding personal ownership of the >> proposed fork: >> >> "How do you plan to deal with security & incident response for the >> duration you describe where you will have control while you are deploying >> the unilateral hard-fork and being in sole maintainership control?" >> >> I do genuinely hope that whomever (now and future) wishes to fork the >> protocol reconsider first whether they are truly ready to test/flex their >> reputation/skills/resources in this way... Intuitively, to me it seems >> counterproductive, and I don't fully believe it is within a single >> developer's talents to manage the process start-to-finish (as it is >> non-trivial to hard-fork successfully, others have rehashed this in other >> threads)... >> >> That being said I think it appropriate if Adam's questions were responded >> in-line when Mike is feeling up to it. I think that the answers are >> important for the community to hear when such a drastic change is being >> espoused. >> >> Faiz >> >> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop wrote: >> >>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn wrote: >>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. >>> >>> I worry that if this is the level of care you take with reading and >>> (mis)interpreting Adam's messages, that you might not be taking extreme >>> care with evaluating consensus changes, even while tired or sleeping. I >>> encourage you to evaluate both messages and source code more carefully, >>> especially in the world of bitcoin. However, this goes for everyone and not >>> just you. Specifically, when Adam mentioned your conversations with >>> non-technical people, he did not mean "Mike has talked with people who have >>> possibly not made pull re
Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Jun 15, 2015 11:43 PM, "Rusty Russell" wrote: > Though Peter Todd's more general best-effort language might make more > sense. It's not like you can hide an OP_RETURN transaction to make it > look like something else, so that transaction not going to be > distinguished by non-canonical ordering. What about commitments that don't use op_return (ie pay2contract commitments)? In any case, if the motivation is ordering in multi-party transactions there should be ways to do it without any consequences for other transaction types' privacy. For example you could have a deterministic method that depends on a random seed all parties in the transaction previously share. That way the ordering is deterministic for all parties involved in the transaction (which can use whatever channel they're using to send the parts to also send this random seed) while at the same time the order looks random (or at least not cannonical in a recognisable way) to everyone else. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On May 31, 2015 5:08 PM, "Gavin Andresen" wrote: > > On Sun, May 31, 2015 at 10:59 AM, Jorge Timón wrote: >> >> Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. >> Miner B would still go out of business, bigger blocks still mean more mining and validation centralization > > Sorry, but that's ridiculous. > > If Miner B is leaving 18BTC per block on the table because they have bad connectivity, then they need to pay for better connectivity. Well, I was assuming they just can't upgrade their connection (without moving thei operations to another place). Maybe that assumption is ridiculous as well. > If you are arguing "I should be able to mine on a 56K modem connection from the middle of the Sahara" then we're going to have to agree to disagree. No, I'm not suggesting that. > So: what is your specific proposal for minimum requirements for connectivity to run a full node? The 20MB number comes from estimating costs to run a full node, and as my back-and-forth to Chang Wung shows, the costs are not excessive. Well, you were I think assuming a new desktop connecting from somewhere in the US. I would be more confortable with an eee pc from a hotel in India, for example. But yeah, targeting some concrete minimum specs seems like the right approach for deciding "how far to go when increasing centralization". But "hitting the limit will be chaos" seems to imply that completely removing the consensus maximum blocksize is the only logical solution. What happens when we hit the limit next time? When do we stop kicking the can down the road? When do we voluntarily get that "chaos"? Again, "that's too far away in the future to worry about it" is not a very conving answer to me. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B would still go out of business, bigger blocks still mean more mining and validation centralization. The question is how far I we willing to go with this "scaling by sacrificing decentralization", but the answer can't be "that's to far away in the future to worry about it, right now as far as we think we can using orphan rate as the only criterion". On May 31, 2015 4:49 PM, "Gavin Andresen" wrote: > On Sun, May 31, 2015 at 10:46 AM, Jorge Timón wrote: > >> Here's a thought experiment: >> >> Subsidy is gone, all the block reward comes from fees. >> > I wrote about long-term hypotheticals and why I think it is a big mistake > to waste time worrying about them here: >http://gavinandresen.ninja/when-the-block-reward-goes-away > > > -- > -- > Gavin Andresen > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
On May 30, 2015 10:38 PM, "Gavin Andresen" wrote: > > Mining is a competitive business, the marginal miner will ALWAYS be going out of business. > > That is completely independent of the block size, block subsidy, or transaction fees. No, the later determines who can be profitable. Here's a thought experiment: Subsidy is gone, all the block reward comes from fees. Miner A has great connectivity and mines 20 MB blocks, with an average of 20 btc per block. Miner B has a connectivity such that 2 MB blocks puts it on a reasonable orphan rate, so it gets an average of 2 btc per block mined. But the difficulty is the same for all and it can rise up to miner A breaking even after energy costs. Will miner B be profitable with this setup? The answer is no and miner B will just go out of business. In that sense too, bigger blocks mean more mining centralization. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
On May 27, 2015 12:58 PM, "Peter Todd" wrote: > What I'm not seeing is how the relative nLockTime that nSequence > provides fundamentally changes any of this. This allows the implementation of a rcltv that doesn't make script depend on the current height, in a similar way that cltv uses the nLockTime (which has been compared with the current height already when checking the script). In fact, the implementation could be simpler if the goal of maintaining the original nSequence semantics was ignored ( although not that simpler, but you wouldn't need to use ~ (bitwise not). I'm still not sure whether there should be 2 BIPs for this or just one. > -- > 'peter'[:-1]@petertodd.org > 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bits proposal
On May 27, 2015 11:35 AM, "Tier Nolan" wrote: > Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication? You need 75% to start applying it, 95% to start rejecting blocks that don't apply it. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bits proposal
It would also help to see the actual code changes required, which I'm sure will be much shorter than the explanation itself. On May 27, 2015 5:47 AM, "Luke Dashjr" wrote: > On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote: > > Feel free to comment. As the gist does not support notifying participants > > of new comments, I would suggest using the mailing list instead. > > I suggest adding a section describing how this interacts with and changes > GBT. > > Currently, the client tells the server what the highest block version it > supports is, and the server indicates a block version to use in its > template, > as well as optional instructions for the client to forcefully use this > version > despite its own maximum version number. Making the version a bitfield > contradicts the increment-only assumption of this design, and since GBT > clients are not aware of overall network consensus state, reused bits can > easily become confused. I suggest, therefore, that GBT clients should > indicate > (instead of a maximum supported version number) a list of softforks by > identifier keyword, and the GBT server respond with a template indicating: > - An object of softfork keywords to bit values, that the server will > accept. > - The version number, as presently conveyed, indicating the preferred > softfork > flags. > > Does this sound reasonable, and/or am I missing anything else? > > Luke > > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi wrote: > But this matters if a new node has access to the globally strongest chain. > If attacker is able to block connections to legitimate nodes, a new node > will happily accept attacker's chain. If you get isolated from the network you may not get the longest valid chain. I don't think any other consensus mechanism deals with this better than Bitcoin. > So PoW, by itself, doesn't give strong security guarantees. This problem is > so fundamental people avoid talking about it. > > In practice, Bitcoin already embraces "weak subjectivity" e.g. in form of > checkpoints embedded into the source code. So it's hard to take PoW purists > seriously. Checkpoints are NOT part of the consensus rules, they're just an optimization that can be removed. Try keeping the genesis block as your only checkpoint and rebuild: it will work. You can also define your own checkpoints, there's no need for everyone to use the same ones. In a future with committed utxo the optimization could be bigger, but still, we shouldn't rely on checkpoints for consensus, they're just an optimization and you should only trust checkpoints that are buried in the chain. Trusting a committed utxo checkpoint from 2 years ago doesn't seem very risky. If the code is not already done (not really sure if it was done as part of auto-prune), we should be prepared for reorgs that invalidate checkpoints. So, no, Bitcoin does NOT rely on that "weak subjectivity" thing. -- 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] Long-term mining incentives
On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen wrote: > I think long-term the chain will not be secured purely by proof-of-work. I > think when the Bitcoin network was tiny running solely on people's home > computers proof-of-work was the right way to secure the chain, and the only > fair way to both secure the chain and distribute the coins. > > See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some > half-baked thoughts along those lines. I don't think proof-of-work is the > last word in distributed consensus (I also don't think any alternatives are > anywhere near ready to deploy, but they might be in ten years). Or never, nobody knows at this point. > I also think it is premature to worry about what will happen in twenty or > thirty years when the block subsidy is insignificant. A lot will happen in > the next twenty years. I could spin a vision of what will secure the chain > in twenty years, but I'd put a low probability on that vision actually > turning out to be correct. I think is very healthy to worry about that since we know it's something that will happen. The system should work without subsidies. > That is why I keep saying Bitcoin is an experiment. But I also believe that > the incentives are correct, and there are a lot of very motivated, smart, > hard-working people who will make it work. When you're talking about trying > to predict what will happen decades from now, I think that is the best you > can (honestly) do. Lightning payment channels may be a new idea, but payment channels are not, and nobody is using them. They are the best solution to scalability we have right now, increasing the block size is simply not a solution, it's just kicking the can down the road (while reducing the incentives to deploy real solutions like payment channels). Not worrying about 10 years in the future but asking people to trust estimates and speculations about how everything will burn in 2 years if we don't act right now seems pretty arbitrary to me. One could just as well argue that there's smart hard-working people that will solve those problems before they hit us. It is true that the more distant the future you're trying to predict is, the more difficult it is to predict it, but any threshold that separates "relevant worries" from "too far in the future to worry about it" will always be arbitrary. Fortunately we don't need to all share the same time horizon for what is worrying and what is not. What we need is a clear criterion for what is acceptable for a hardfork and a general plan to deploy them: -Do all the hardfork changes need to be uncontroversial? How do we define uncontroversial? -Should we maintain and test implementation of hardfork whises that seem too small to justify a hardfork on their own (ie time travel fix, allowing to sign inputs values...) to also deploy them at the same time that other more necessary hardforks? I agree that hardforks shouldn't be impossible and in that sense I'm glad that you started the hardfork debate, but I believe we should be focusing on that debate rather than the block size one. Once we have a clear criteria, hopefully the block size debate should become less noisy and more productive. -- 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] CLTV opcode allocation; long-term plans?
I like the reuse with negative numbers more than the current proposal because it doesn't imply bigger scripts. If all problems that may arise can be solved, that is. If we went that route, we would start with the initial CLTV too. But I don't see many strong arguments in favor of using the current trick later when we're actually running out of opcodes, just that "CLTV and RCLTV/op_maturity are semantically related". How semantically related depends on the final form of RCLTV/op_maturity, but I don't think anybody wants to block CLTV until RCLTV is ready. So we could just deploy the initial CLTV (#6124) now and then decide whether we want to reuse it with negatives for RCLTV or if we use an independent op. Can the people that don't like that plan give stronger arguments in favor of the parametrized version? I've missed IRC conversations, so I may be missing something... On Tue, May 12, 2015 at 11:01 PM, Peter Todd wrote: > On Tue, May 12, 2015 at 08:38:27PM +, Luke Dashjr wrote: >> It should actually be straightforward to softfork RCLTV in as a negative >> CLTV. >> All nLockTime are >= any negative number, so a negative number makes CLTV a >> no-op always. Therefore, it is clean to define negative numbers as relative >> later. It's also somewhat obvious to developers, since negative numbers often >> imply an offset (eg, negative list indices in Python). > > Doing this makes handling the year 2038 problem a good deal more > complex. > > The CLTV codebase specifically fails on negative arguments to avoid any > ambiguity or implementation differences here. > > -- > 'peter'[:-1]@petertodd.org > 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 > > -- > 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 > -- 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] CLTV opcode allocation; long-term plans?
This saves us ocodes for later but it's uglier and produces slightly bigger scripts. If we're convinced it's worth it, seems like the right way to do it, and certainly cltv and rclv/op_maturity are related. But let's not forget that we can always use this same trick with the last opcode to get 2^64 brand new opcodes. So I'm not convinced at all on whether we want #5496 or #6124. But it would be nice to decide and stop blocking this. On Sat, May 9, 2015 at 11:12 AM, Peter Todd wrote: > On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: >> > That said, if people have strong feelings about this, I would be willing >> > to make OP_CLTV work as follows: >> > >> > 1 OP_CLTV >> > >> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A >> > future relative CLTV could then be a future soft-fork implemented as >> > follows: >> > >> > 2 OP_CLTV >> > >> > On the bad side it'd be two or three days of work to rewrite all the >> > existing tests and example code and update the BIP, and (slightly) gets >> > us away from the well-tested existing implementation. It also may >> > complicate the codebase compared to sticking with just doing a Script >> > v2.0, with the additional execution environment data required for v2.0 >> > scripts cleanly separated out. But all in all, the above isn't too big >> > of a deal. >> >> >> Adding a parameter to OP_CLTV makes it much more flexible and is the most >> economic use of precious NOPs. >> The extra time required is ok and it would be good to make this change to >> the PR in time for the feature freeze. > > Done! > > https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 > > -- > 'peter'[:-1]@petertodd.org > 12c438a597ad15df697888be579f4f818a30517cd60fbdc8 > > -- > 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 > -- 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] Block Size Increase
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen wrote: > Fee dynamics seems to come up over and over again in these discussions, with > lots of talk and theorizing. > > I hope some data on what is happening with fees right now might help, so I > wrote another blog post (with graphs, which can't be done in a mailing list > post): >http://gavinandresen.ninja/the-myth-of-not-full-blocks > > We don’t need 100% full one megabyte blocks to start to learn about what is > likely to happen as transaction volume rises and/or the one megabyte block > size limit is raised. Ok, the fact that the fee increases the probability of getting included faster already is a good thing, the graphs with the probability of getting included in the next block were less important to me. Although scarce space (beyond what miners chose to limit by themselves) would increase the fee competition, I didn't knew that there is actually some competition happening already. So I guess this diminishes the argument for maintaining the limits longer to observe the results of more scarce space. Still, I think maintaining a lower policy limit it's a good idea, even if we decide not to use it to observe that soon. For example, say we chose the 20 MB consensus limit, we can maintain the policy limit at 1 MB or move it to 2 MB, and slowly moving it up later as needed without requiring everyone to upgrade. Of course, not all miners have to follow the standard policy, but at least it's something. So please take this as a suggestion to improve your proposal. You can argue it like this "if we want to maintain the limits after the hardfork or increase them slowly, for observing fee dynamics with more scarce space or for any other reason, those limits can be partially enforced by the standard policy". I mean, I think that could be a reasonable compromise for that concrete line of arguments. -- 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] Block Size Increase
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn wrote: >> It is an argument against my admittedly vague definition of >> "non-controversial change". > > > If it's an argument against something you said, it's not a straw man, right > ;) Yes, but it was an argument against something I didn't said ;) > Consensus has to be defined as agreement between a group of people. Who are > those people? If you don't know, it's impossible to decide when there is > consensus or not. > > Right now there is this nice warm fuzzy notion that decisions in Bitcoin > Core are made by consensus. "Controversial" changes are avoided. I am trying > to show you that this is just marketing. Nobody can define what these terms > even mean. It would be more accurate to say decisions are vetoed by whoever > shows up and complains enough, regardless of technical merit. Yes, that's why I drafted a definition for "uncontroversial change" rather than "change accepted by consensus". It will still be vague and hard to define, but consensus seems much harder. And, yes, you're right, it is more like giving power to anyone with valid arguments to veto hardfork changes. But as you say, that could lead to make hardforks actually impossible, so we should limit what constitutes a valid argument. I later listed some examples of invalid arguments: logical fallacies, unrelated arguments, outright lies. Certainly I don't think technical merits should count here or that we could veto a particular person from vetoing. We should filter the arguments, not require an identity layer to blacklist individuals. We should even accept arguments from anonymous people in the internet (you know, it wouldn't be the first time). > Unfortunately it's hard to know what other kinds of meet-in-the-middle > compromise could be made here. I'm sure Gavin would consider them if he > knew. But the concerns provided are too vague to address. There are no > numbers in them, for example: > > We need more research -> how much more? Some research at all about fee market dynamics with limited size that hasn't happened at all. If we're increasing the consensus max size maybe we could at least maintain the 1MB limit as a standard policy limit, so that we can study it a little bit (like we could have done instead of removing the initial policy limit). > I'm not against changing the size, just not now -> then when? I don't know yet, but I understand now that having a clearer roadmap is what's actually urgent, not the change itself. > I'm not wedded to 1mb, but not sure 20mb is right -> then what? What about 2 MB consensus limit and 1 MB policy limit for now? I know that's arbitrary too. > Full node count is going down -> then what size do you think would fix that? > 100kb? As others have explained, the number of full nodes is not the improtant part, but how easy it is to run one. I think a modest laptop with the average internet connection of say, India or Brazil, should be able to run a full node. I haven't made those numbers myself but I'm sure that's possible with 1 MB blocks today, and probably with 2 MB blocks too. > It will make mining more centralised -> how do you measure that and how much > centralisation would you accept? This is an excellent question for both sides. Unfortunately I don't know the answer to this. Do you? -- 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] Block Size Increase
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen wrote: > I would very much like to find some concrete course of action that we can > come to consensus on. Some compromise so we can tell entrepreneurs "THIS is > how much transaction volume the main Bitcoin blockchain will be able to > support over the next eleven years." Mhmm, I hadn't thought about this. This makes sense and actually explains the urgency on taking a decision better than anything else I've heard. On Thu, May 7, 2015 at 5:29 PM, Mike Hearn wrote: > If it's not raised, then ... well, then we're in new territory entirely. > Businesses built on the assumption that Bitcoin could become popular will > suddenly have their basic assumptions invalidated. Users will leave. The > technical code change would be zero, but the economic change would be > significant. This, on the other hand, is a non sequitur [1], another type of fallacy. Well, several of them, actually: - If it's not raised, then bitcoin cannot become popular - If it's not raised, then users will leave - Businesses built on the assumption that Bitcoin could become popular were also assuming that it's going to be risen. These statements may even be true, but they're no logical conclusions even if they seem obvious to you. I don't think those claims are strictly true, specially because they involve predictions about what people will do. But if they're true they require some proof or at least some explanation. [1] http://en.wikipedia.org/wiki/Non_sequitur_(logic)#Affirming_the_consequent -- 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] Block Size Increase
On Thu, May 7, 2015 at 4:05 PM, Mike Hearn wrote: >> If his explanation was "I will change my mind after we increase block >> >> size", I guess the community should say "then we will just ignore your >> nack because it makes no sense". > > > Oh good! We can just kick anyone out of the consensus process if we think > they make no sense. > > I guess that means me and Gavin can remove everyone else from the developer > consensus, because we think trying to stop Bitcoin growing makes no sense. > > Do you see the problem with this whole notion? It cannot possibly work. > Whenever you try and make the idea of developer consensus work, what you end > up with is "I believe in consensus as long as it goes my way". Which is > worthless. That is not what I said. Then you demonstrated that it was absurd. That's called a straw man argument and it's a well known fallacy, it is precisely the example of arguments that can be safely ignored. It is an argument against my admittedly vague definition of "non-controversial change". More importantly, I never said anything about "removing anyone", I was always talking about arguments and not people. One person could use fallacious arguments to attack or defend a given proposal and use perfectly valid ones in another, a person can even mix valid and invalid arguments in the same mail. >> One thing is the Bitcoin core project where you could argue that the 5 >> committers decide (I don't know why Wladimir would have any more >> authority than the others). > > > Because he is formally the maintainer. Yes, the maintainer of the Bitcoin core free software project (I cannot stressed this enough, that can be forked by anyone), not the president of Bitcoin the p2p network. > Maybe you dislike that idea. It's so centralised. So let's say Gavin > commits his patch, because his authority is equal to all other committers. > Someone else rolls it back. Gavin sets up a cron job to keep committing the > patch. Game over. > > You cannot have committers fighting over what goes in and what doesn't. > That's madness. There must be a single decision maker for any given > codebase. I'm sure that if they become that stupid, developers would move to a fork of the project in no time. >> Ok, so in simple terms, you expect people to have to pay enormous fees >> and/or wait thousands of blocks for their transactions to get included >> in the chain. Is that correct? > > > No. I'll write an article like the others, it's better than email for more > complicated discourse. Ok, thanks in advance. >> As others have said, if the answer is "forever, adoption is always the >> most important thing" then we will end up with an improved version of Visa. > > > This appears to be another one of those fundamental areas of disagreement. I > believe there is no chance of Bitcoin ending up like Visa, even if it is > wildly successful. I did the calculations years ago that show that won't > happen: > > https://en.bitcoin.it/wiki/Scalability > > Decentralisation is a spectrum and Bitcoin will move around on that spectrum > over time. But claiming we have to pick between 1mb blocks and "Bitcoin = > VISA" is silly. Again, I didn't say any of that. My point is that a network that becomes too "centralized" (like visa, that is centralized vs p2p, not vs distributed) doesn't offer any security or decentralization advantage over current networks (and of course I meant that could happen with larger blocks, not 1 MB blocks). I'm sure that's not what the proponents of the size increase want, and I'm not defending 1 MB as a sacred limit or anything, but my question is "where is the limit for them?" Even a limitless block size would technically work because miners would limit it to limit the orphan rate. So "no hardcoded consensus limit on transaction volume/block size" could be a valid answer to the question "what is the right consensus limit to block size?" for which there's no real right answer because there is a tradeoff between transaction volume and centralization. Should we maintain 1 MB forever? Probably not. Is 20 MB a bad size? I honestly don't know. Is this urgent? I don't think so. Should we rush things when we don't have clear answers to many related questions? I don't think so. You think that it is too soon to start restricting transaction volume in any way. You will answer why in your post. When is the right time and what is the right limitation then? I want to have fee competition as soon as possible, at least temporarily. But you say that it can wait for later. Ok, when do you think we should make that happen then? When 20 MB are full, will that be the right time to let the fee market develop then or will it be urgent to increase the block size again? Should we directly remove the limit then and let miners handle it as they want? If so, why not now? Maybe we can increase to 2 MB, then wait for fee competition, then wait for 2 more subsidy halvings and then increase to 11 or 20 MB? There's so many
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson wrote: > Known: There has been a steady trend towards the mean block size getting > larger. See > https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address= Looking at this graph and in retrospective, we shouldn't have removed the standard policy limit without observing the supposedly disastrous effects of hitting the limit first. Removing the standard limit would have been trivial (bdb issues aside) at any point after seeing the effects. > Known: If we reach the point where all blocks are 1M bytes then there's a > major problem in terms of transaction confirmation. I published an analysis > of the impact of different mean block sizes against confirmation times: > http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35% > to 45% mean block size doesn't have a huge impact on transaction > confirmations (assuming equal fees for all) but once we're up at 80% then > things start to get unpleasant. Instead of 50% of first confirmations taking > about 7 minutes they instead take nearer to 19 minutes. Well, this is only for first confirmations of free transaction. A higher fee should increase your probabilities, but if you're sending free transactions you may not care about them taking longer to be included. > Known: There are currently a reasonably large number of zero-fee > transactions getting relayed and mined. If things start to slow down then > there will be a huge incentive to delay them (or drop them altogether). Well, maybe "instant and free" it's not a honest form of bitcoin marketing and it just has to disappear. Maybe we just need to start being more honest about pow being good for processing micro-transactions: it is not. Hopefully lightning will be good for that. Free and fast in-chain transactions is something temporary that we know will eventually disappear. If people think it would be a adoption disaster that it happens soon, then they could also detail an alternative plan to roll that out instead of letting it happen. But if the plan is to delay it forever...then I'm absolutely against. > Known: There's a major problem looming for miners at the next block reward > halving. Many are already in a bad place and without meaningful fees then > sans a 2x increase in the USD:BTC ratio then many will simply have to leave > the network, increasing centralisation risks. There seems to be a fairly > pervasive assumption that the 300-ish MW of power that they currently use is > going to pay for itself (ignoring capital and other operating costs). I take this as an argument for increasing fee competition and thus, against increasing the block size. > Known: the orphan rate is still pretty-high even with everyone's fast > connections. If we assume that 20M byte blocks become possible then that's > likely to increase. > > Unknown: What are the security implications for larger blocks (this one (at > least) can be simulated though)? For example, could large blocks with huge > numbers of trivial transactions be used to put other validators at a > disadvantage in a variant of a selfish mining attack? I've seen objections > that such bad actors could be blacklisted in the future but it's not clear > to me how. A private mining pool can trivially be made to appear like 100 > pools of 1% of the size without significantly affecting the economics of > running that private mine. No blacklisting, please, that's centralized. In any case, a related known: bigger blocks give competitive advantage to bigger miners. -- 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] Block Size Increase
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn wrote: > I was referring to winter next year. 0.12 isn't scheduled until the end of > the year, according to Wladimir. I explained where this figure comes from in > this article: > > https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d > > It's a fairly simple estimate based on previous growth patterns. Ok, thanks. >> We've successfully reached consensus for several softfork proposals >> already. > > > Are you sure about that? Yes, Peter Todd gave more details. > What if Gavin popped up right now and said he disagreed with every current > proposal, he disagreed with side chains too, and there would be no consensus > on any of them until the block size limit was raised. > > Would you say, oh, OK, guess that's it then. There's no consensus so might > as well scrap all those proposals, as they'll never happen anyway. Bye bye > side chains whitepaper. Well, yes, it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though. >> I just hope that by "What we need to see right now is leadership" you >> don't mean something like "when Gaving and Mike agree it's enough to >> deploy a hardfork" when you go from vague to concrete. > > > No. What I meant is that someone (theoretically Wladimir) needs to make a > clear decision. If that decision is "Bitcoin Core will wait and watch the > fireworks when blocks get full", that would be showing leadership . > albeit I believe in the wrong direction. It would, however, let people know > what's what and let them start to make longer term plans. > > This dillydallying around is an issue - people just make vague points that > can't really be disagreed with (more nodes would be nice, smaller pools > would also be nice etc), and nothing gets done. Well, there's two different things here. One thing is the Bitcoin core project where you could argue that the 5 committers decide (I don't know why Wladimir would have any more authority than the others). But what the bitcoin network itself does it's very different because unlike the bitcoin core software project, the Bitcoin network is decentralized. If the people with commit access go nuts and decide something that's clearly stupid or evil, people can just fork the project because it is free software. You cannot be forced to use specific features of free software, you can always remove them and recompile, that's the whole point. So, no, there's no authority to decide on hardforks and that's why I think that only clearly uncontroversial things can get through as hardforks. >> What you want to avoid at all cost (the block size actually being >> used), I see as the best opportunity we have to look into the future. > > > I think I see one of the causes of disagreement now. > > I will write more on the topic of what will happen if we hit the block size > limit soon, maybe this evening. I have some other tasks to do first. > > Regardless, I don't believe we will get any useful data out of such an > event. I've seen distributed systems run out of capacity before. What will > happen instead is technological failure followed by rapid user abandonment > that pushes traffic back below the pressure threshold and those users > will most likely not come back any time soon. Ok, so in simple terms, you expect people to have to pay enormous fees and/or wait thousands of blocks for their transactions to get included in the chain. Is that correct? >> Ok, this is my plan: we wait 12 months, hope that your estimations are >> correct (in case that my guess was better than yours, we keep waiting >> until June 2017) and start having full blocks and people having to >> wait 2 blocks for their transactions to be confirmed some times. > > > I disagree that'd be the outcome, but good, this is progress. Now we need to > hear something like that from Wladimir, or whoever has the final say around > here. As said above there's no authority to decide on what Bitcoin the p2p network does. Again, that's the whole point. But, yes, I agree that both sides understanding each other better is progress. > With respect to the fee market: I think it's fairer to say Gavin wants a > market to exist, and he also wants supply to be plentiful. 20mb limit > doesn't actually mean every block will be 20mb the day after, no more than >
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 11:25 AM, Mike Hearn wrote: > I observed to Wladimir and Gavin in private that this timeline meant a change > to the block size was unlikely to get into 0.11, leaving only 0.12, which > would give everyone only a few months to upgrade in order to fork the chain > by the end of the winter growth season. That seemed tight. Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I assume that you are expecting full blocks by then, have you used any statistical technique to come up with that date or is it just your guess? Because I love wild guesses and mine is that full 1 MB blocks will not happen until June 2017. > What we need to see right now is leadership and a plan, that fits in the > available time window. > >> >> Certainly a consensus in this kind of technical community should be a >> basic requirement for any serious commitment to blocksize increase. > > > I'm afraid I have come to disagree. I no longer believe this community can > reach consensus on anything protocol related. Some of these arguments have > dragged on for years. Consensus isn't even well defined - consensus of who? > Anyone who shows up? And what happens when, inevitably, no consensus is > reached? Stasis forever? We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete. >> Long-term incentive compatibility requires that there be some fee >> pressure, and that blocks be relatively consistently full or very nearly >> full. > > > I disagree. When the money supply eventually dwindles I doubt it will be fee > pressure that funds mining, but as that's a long time in the future, it's > very hard to predict what might happen. Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future. >> What we see today are >> transactions enjoying next-block confirmations with nearly zero pressure >> to include any fee at all (though many do because it makes wallet code >> simpler). > > > Many do because free transactions are broken - the relay limiter means > whether a free transaction actually makes it across the network or not is > basically pot luck and there's no way for a wallet to know, short of either > trying it or actually receiving every single transaction and repeating the > calculations. If free transactions weren't broken for all non-full nodes > they'd probably be used a lot more. Free transactions are a gift from miners that run an altruistic policy. That's great but we shouldn't rely on them for the future. They will likely disappear at some point and that's ok. In any case, he's not complaining about the lack of free transactions, more like the opposite. He is saying that's very easy to get free transactions in the next block and blocks aren't full so there's no incentive to include fees to compete for the space. We can talk a lot about "a fee market" and build a theoretically perfect fee estimator but we won't actually have a fee market until there's some competition for space. Nobody will pay for space that's abundant just like people don't pay for the air they breath. > What I don't see from you yet is a specific and credible plan that fits > within the next 12 months and which allows Bitcoin to keep growing. Not some > vague handwave like "let's all use the Lightning network" (which does not > exist), or "let's do more research" (Gavin has done plenty of research), or > "but what about the risks" (Bitcoin is full of risks). A plan, with dates > attached, and a strong chance of actually being deployed in time. Ok, this is my plan: we wait 12 months, hope that your estimations are correct (in case that my guess was better than yours, we keep waiting until June 2017) and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What
Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Tue, May 5, 2015 at 10:38 PM, Tier Nolan wrote:
> I think that should be greater than in the comparison? You want it to fail
> if the the height of the UTXO plus the sequence number is greater than the
> spending block's height.
Yes, sorry, I changed it just before sending from "what needs to be
satisfied for the validation error to trigger" to "what needs to be
satisfied for the tx to be valid".
You're right.
> There should be an exception for final inputs. Otherwise, they will count
> as relative locktime of 0x. Is this check handled elsewhere?
>
> if (!tx.vin[i].IsFinal() && nSpendHeight < coins->nHeight +
> tx.vin[i].nSequence)
>return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
Yes, this would be the simplest solution. Another option would be to
have a new tx version in which IsFinal(CTransaction) doesn't check the
inputs sequences to be 0x for the tx to be final.
> Is the intention to let the script check the sequence number?
>
> OP_RELATIVELOCKTIMEVERIFY
>
> would check if is less than or equal to the sequence number.
Yes.
> It does make sequence mean something completely different from before.
> Invalidating previously valid transactions has the potential to reduce
> confidence in the currency.
Well, the semantics of nSequence don't really change completely. In
fact, one could argue that this put it closer to its original
semantics.
But in any case, yes, already signed transaction should remain valid.
No transaction would become invalid, just non-final.
As soon as the height of its inputs plus their respective nSquences
get higher than current height they will become final again.
I cannot think of any use case where a tx becomes invalid forever.
Also, probably most people have usedrelatively low values for
nSequence given the original semantics, just like the relative lock
nSquence will likely be used as well.
> A workaround would be to have a way to enable it in the sigScript by
> extending Peter Todd's suggestion in the other email chain.
>
> <1> OP_NOP2 means OP_CHECKLOCKTIMEVERIFY (absolute)
> <2> OP_NOP2 means OP_RELATIVECHECKLOCKTIMEVERIFY
>
> <3> OP_NOP2 means OP_SEQUENCE_AS_RELATIVE_HEIGHT
To be clear, this proposal is supposed to replace RCLTV, so there
would still be 2 options. But please let's imagine we have infinite
opcodes in this thread and let the "should we design an uglier
scripting langues to save opcodes?" question in the other one.
> OP_SEQUENCE_AS_RELATIVE_HEIGHT would cause the script to fail unless it was
> the first opcode in the script. It acts as a flag to enable using the
> sequence number as for relative block height.
>
> This can be achieved using a simple pattern match.
>
> bool CScript::IsSequenceAsRelativeHeight() const
> {
> // Extra-fast test for pay-to-script-hash CScripts:
> return (this->size() >= 4 &&
> this->at(0) == OP_PUSHDATA1 &&
> this->at(1) == 1 &&
> this->at(2) == 0xFF &&
> this->at(3) == OP_NOP2);
> }
>
> if (!tx.vin[i].IsFinal() && tx.vin[i].scriptSig.IsSequenceAsRelativeHeight()
> && nSpendHeight < coins->nHeight + tx.vin[i].nSequence)
>return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
This gives you less flexibility and I don't think it's necessary.
Please let's try to avoid this if it's possible.
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote:
>>
>> for (unsigned int i = 0; i < tx.vin.size(); i++) {
>> // ...
>> if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
>> return state.Invalid(false, REJECT_INVALID,
>> "bad-txns-non-final-input");
>> // ...
>> }
>
>
>
>
> --
> 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
>
--
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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
Well, apparently the timestamp can be make compatible with Mark's
nSequence-based RCLTV by adding an additional check at the block level
but I was only explaining the concept using heights (which is the most
interesting part IMO).
I'm also not sure I understood the details and I don't want to confuse
people again, so I'll wait for someone else to explain that part.
ACLTV can work with timestamps too unless I'm missing something. It's
just more complexity and I was never convinced that there's enough use
cases relying on timestamps to justify them. But the timestamp
discussion is quite orthogonal to the nSequence-based RCLTV proposal
itself.
On Tue, May 5, 2015 at 2:41 AM, Btc Drak wrote:
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote:
>>
>> What I was describing was an attempt to fix a similar proposal by Mark
>> Friedenbach, but it didn't needed fixing: I was simply
>> misunderstanding it.
>> Mark's RCLTV is completely reorg safe, so there's no need for the 100
>> block restriction. It also keeps the script validation independent
>> from the utxo.
>> Here's is how it works:
>>
>> The operator takes a relative_height parameter and it checks that the
>> nSequence of the input is lower than that parameter.
>>
>> Additionally, a new check at the transaction level:
>>
>> for (unsigned int i = 0; i < tx.vin.size(); i++) {
>> // ...
>> if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
>> return state.Invalid(false, REJECT_INVALID,
>> "bad-txns-non-final-input");
>> // ...
>> }
>>
>> Well, this is assuming that we're only using it with heights and not
>> timestamps.
>> Mark, feel free to elaborate further.
>
>
> Does dropping timestamp refer just to RCLTV or absolutely CLTV also? For
> absolute CLTV I think it's important to have timestamps so that trust fund
> use cases are practical (e.g. spendable on 18th birthday), because the exact
> date a future block will be mined on is unpredictable if it's far enough in
> the future (out by days or even weeks).
>
--
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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
What I was describing was an attempt to fix a similar proposal by Mark
Friedenbach, but it didn't needed fixing: I was simply
misunderstanding it.
Mark's RCLTV is completely reorg safe, so there's no need for the 100
block restriction. It also keeps the script validation independent
from the utxo.
Here's is how it works:
The operator takes a relative_height parameter and it checks that the
nSequence of the input is lower than that parameter.
Additionally, a new check at the transaction level:
for (unsigned int i = 0; i < tx.vin.size(); i++) {
// ...
if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-non-final-input");
// ...
}
Well, this is assuming that we're only using it with heights and not timestamps.
Mark, feel free to elaborate further.
--
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] Where do I start?
Well, if you're interested in learning java while learning bitcoin, probably you should be looking at https://github.com/bitcoinj/bitcoinj or one of its related project (like the android bitcoin wallet based on it). There's a getting sterted page: https://bitcoinj.github.io/#getting-started These links my be useful too: https://bitcoin.org/en/bitcoin-for-developers https://bitcoin.org/en/developer-documentation On Thu, Apr 30, 2015 at 11:35 AM, Telephone Lemien wrote: > Hello, > I'm a beginner in Bitcoin and I want to know, what are things those allo me > to understand Bitcoin protocol and make progress in java to become a good > developper. > Please tell me how I can begin. > Best regards > > 2015-04-30 10:08 GMT+02:00 Jorge Timón : >> >> As Mike says it depends on your interests. But one thing that is almost >> always welcomed is improving the tests, and it is unlikely that it conflicts >> with other people's PRs (unless they're changing that part of the code and >> need to update those tests. Improving documentation is also good and you can >> do that while reading the code. Usually I just start cloning, compiling and >> changing things as I read, "if I understand this correctly, this change >> should not break the tests, if I understand this, this other change should >> break the build", etc. >> But again, is up to you. >> >> On Apr 16, 2015 2:34 PM, "Mike Hearn" wrote: >>> >>> Hey Gabe, >>> >>> That's diving into the deep end for sure! :) >>>> >>>> What are some current things that are lacking in Bitcoin core? Or am I >>>> better off making something else for the ecosystem? >>> >>> That depends on your interests. >>> >>> Many of the highest priority tasks in Bitcoin Core are rather >>> complicated, unfortunately, even for people with experience. You can consult >>> the issue tracker to get a feel for it. >>> >>> Alternatively, there are lots of wallet apps out there and plenty of more >>> straightforward projects on them. However they may have less of a research >>> flavour. >>> >>> >>> -- >>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>> Develop your own process in accordance with the BPMN 2 standard >>> Learn Process modeling best practices with Bonita BPM through live >>> exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>> event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> ___ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >> >> >> -- >> 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 >> > -- 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] Where do I start?
As Mike says it depends on your interests. But one thing that is almost always welcomed is improving the tests, and it is unlikely that it conflicts with other people's PRs (unless they're changing that part of the code and need to update those tests. Improving documentation is also good and you can do that while reading the code. Usually I just start cloning, compiling and changing things as I read, "if I understand this correctly, this change should not break the tests, if I understand this, this other change should break the build", etc. But again, is up to you. On Apr 16, 2015 2:34 PM, "Mike Hearn" wrote: > Hey Gabe, > > That's diving into the deep end for sure! :) > >> What are some current things that are lacking in Bitcoin core? Or am I >> better off making something else for the ecosystem? >> > That depends on your interests. > > Many of the highest priority tasks in Bitcoin Core are rather complicated, > unfortunately, even for people with experience. You can consult the issue > tracker to get a feel for it. > > Alternatively, there are lots of wallet apps out there and plenty of more > straightforward projects on them. However they may have less of a research > flavour. > > > -- > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- 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] Proof of Payment
Forget it, sorry, I misunderstood the proposal entirely, re-reading with more care... On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum wrote: > Hi Jorge, > > I don't think I understand the question. Proof of Payment is used to prove > that you have the credentials needed for a certain transaction. It does not > care where in the blockchain the transaction is. Or if it's in the > blockchain at all. > > /Kalle > > So at the low level, how does a "proof of payment" differ from just proving > that a given transaction is in a given block (what SPV nodes take as proof > of payment today)? > > On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" wrote: >> >> "Or a really high lock_time, but it would not make it invalid, just >> delayed." >> >> Ok, this was a bad idea, since nodes would have to keep it in memory. >> Please disregard that idea... >> >> Kalle >> >> Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" : >> > >> > > >> > > Some more use cases might be: >> > > Waiting in comfort: >> > > - Send a payment ahead of time, then wander over and collect the >> > > goods >> > > after X confirmations. >> > > >> > > Authorized pickup : >> > > - Hot wallet software used by related people could facilitate the use >> > > of 1 of N multisig funds. Any one of the N wallets could collect >> > > goods >> > > and services purchased by any of the others. >> > >> > I like this one, because it shows the power of reusing the transaction >> > data structure. >> > >> > > >> > > Non-monetary gifts: >> > > - Sender exports spent keys to a beneficiary, enabling PoP to work as >> > > a >> > > gift claim >> > > >> > > Contingent services: >> > > - Without Bob's permission, a 3rd party conditions action on a >> > > payment >> > > made from Alice to Bob. For example, if you donated at least .02 BTC >> > > to >> > > Dorian, you (or combining scenarios, any of your N authorized family >> > > members), can come to my dinner party. >> > >> > This is an interesting one. >> > >> > > >> > > I tried out your demo wallet and service and it worked as advertised. >> > > >> > > Could the same standard also be used to prove that a transaction COULD >> > > BE created? To generalize the concept beyond actual payments, you >> > > could >> > > call it something like proof of payment potential. >> > >> > I guess it's possible, but we'd have to remove the txid from the output, >> > since there is none. This is a way of saying "I'm in control of these >> > addresses". The other party/parties can then verify the funds on the >> > blockchain and watch those addresses for changes. Maybe there are some >> > interesting use cases here. Ideas? >> > >> > > >> > > Why not make these proofs permanently INVALID transactions, to remove >> > > any possibility of their being mined and spending everything to fees >> > > when used in this way, and also in cases involving reorganizations? >> > >> > Yes. Initially I thought it would be enough that the funds are already >> > spent, but I think you're right here. Reorgs could be a problem. Worse, you >> > also might want to prove 0-confirmation transactions, in which case it's a >> > huge security problem. Someone might intercept the PoP and publish it on >> > the >> > bitcoin network, spending all the funds. But I still would like wallets to >> > be able to build/verify PoPs with little or no modifications. Could we >> > possibly change the version number on the PoP to something other than 1? >> > Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid, >> > just delayed. Any suggestions here? >> > >> > > >> > > I agree that PoP seems complementary to BIP70. >> > > >> > > >> > >> > Thank you very much for your comments! >> > >> > /Kalle >> >> >> >> -- >> 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 >> > -- 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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
Even if it's new and has not received any feedback, I think my solution to op_maturity is quite clean. But anyway, yes, the non-relative cltv is much simpler in design and doesn't have to wait for the other. On the other hand, I would upgrade it to absolute cltv like you suggested and take the current height as a parameter to verifyScript instead of using the nLockTime as reference. If we know we're going to use it for rcltv/op_maturity, better put add soon rather than later, specially if that will give us a more powerful cltv. If we don't want that height param, we can leave it out of for op_maturity too, but that's the wingle decision about rcltv/maturity that affects cltv so better solve that first. On Apr 27, 2015 9:35 PM, "Peter Todd" wrote: > On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: > > On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón wrote: > > > And a new softfork rule could enforce that all new CTxIn set nHeight > > > to the correct height in which its corresponding prevout got into the > > > chain. > > > That would remove the need for the TxOutputGetter param in > > > bitcoinconsensus_verify_script, but unfortunately it is not reorg safe > > > (apart from other ugly implementation details). > > > > Wait, wait, this can be made reorg-safe and more backards compatible. > > The new validation rule at the tx validation level (currently in > > main::CheckInputs()) would be > > > > So, seems to me that RCLTV opens up a whole rats nest of design > decisions and compromises that CLTV doesn't. Yet CLTV itself is a big > step forward, it's been implemented on Viacoin for the past few months > with no issues found, and has an extremely simple and easy to audit > implementation. > > I think I'm going to argue we implement it as-is in a soft-fork. Pieter > Wuille's been working on a new way to handle soft-fork upgrades in the > block nVersion field, so this would be a good opportunity to add > something simple and well tested, and also make sure the new nVersion > soft-fork mechanism works. Equally, doing both at the same time ensures > we don't burn yet another version bit. > > -- > 'peter'[:-1]@petertodd.org > 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 > -- 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] Proof of Payment
So at the low level, how does a "proof of payment" differ from just proving that a given transaction is in a given block (what SPV nodes take as proof of payment today)? On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" wrote: > "Or a really high lock_time, but it would not make it invalid, just > delayed." > > Ok, this was a bad idea, since nodes would have to keep it in memory. > Please disregard that idea... > > Kalle > > Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" : > > > > > > > > Some more use cases might be: > > > Waiting in comfort: > > > - Send a payment ahead of time, then wander over and collect the goods > > > after X confirmations. > > > > > > Authorized pickup : > > > - Hot wallet software used by related people could facilitate the use > > > of 1 of N multisig funds. Any one of the N wallets could collect goods > > > and services purchased by any of the others. > > > > I like this one, because it shows the power of reusing the transaction > data structure. > > > > > > > > Non-monetary gifts: > > > - Sender exports spent keys to a beneficiary, enabling PoP to work as > a > > > gift claim > > > > > > Contingent services: > > > - Without Bob's permission, a 3rd party conditions action on a payment > > > made from Alice to Bob. For example, if you donated at least .02 BTC > to > > > Dorian, you (or combining scenarios, any of your N authorized family > > > members), can come to my dinner party. > > > > This is an interesting one. > > > > > > > > I tried out your demo wallet and service and it worked as advertised. > > > > > > Could the same standard also be used to prove that a transaction COULD > > > BE created? To generalize the concept beyond actual payments, you > could > > > call it something like proof of payment potential. > > > > I guess it's possible, but we'd have to remove the txid from the output, > since there is none. This is a way of saying "I'm in control of these > addresses". The other party/parties can then verify the funds on the > blockchain and watch those addresses for changes. Maybe there are some > interesting use cases here. Ideas? > > > > > > > > Why not make these proofs permanently INVALID transactions, to remove > > > any possibility of their being mined and spending everything to fees > > > when used in this way, and also in cases involving reorganizations? > > > > Yes. Initially I thought it would be enough that the funds are already > spent, but I think you're right here. Reorgs could be a problem. Worse, you > also might want to prove 0-confirmation transactions, in which case it's a > huge security problem. Someone might intercept the PoP and publish it on > the bitcoin network, spending all the funds. But I still would like wallets > to be able to build/verify PoPs with little or no modifications. Could we > possibly change the version number on the PoP to something other than 1? > Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid, > just delayed. Any suggestions here? > > > > > > > > I agree that PoP seems complementary to BIP70. > > > > > > > > > > Thank you very much for your comments! > > > > /Kalle > > > -- > 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 > > -- 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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón wrote:
> There's another possibility that could keep the utxo out of Script
> verification:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nSequence;
> }
>
> could turn into:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nHeight;
> }
>
> And a new softfork rule could enforce that all new CTxIn set nHeight
> to the correct height in which its corresponding prevout got into the
> chain.
> That would remove the need for the TxOutputGetter param in
> bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
> (apart from other ugly implementation details).
Wait, wait, this can be made reorg-safe and more backards compatible.
The new validation rule at the tx validation level (currently in
main::CheckInputs()) would be
for (unsigned int i = 0; i < tx.vin.size(); i++) {
// ...
if (tx.vin.nHeight + 100 > tx.nLockTime)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-vin-height-reorg-unsafe");
if (coins->nHeight > tx.vin.nHeight)
return state.Invalid(false, REJECT_INVALID,
"bad-txns-vin-height-false");
// ...
}
Existing transactions that have used the deprecated CTxIn::nSequence
for something else will be fine if they've used low nSequences.
The only concern would be breaking some colored coins kernels, but
there's many others implemented that don't rely on CTxIn::nSequence.
Transactions that want to use OP_MATURITY just have to set the
corresponding CTxIn::nHeight and CTransaction::nLockTime properly.
This way op_maturity wouldn't require anything from the utxo and the
final interface could be:
int bitcoinconsensus_verify_script(const unsigned char* scriptPubKey,
unsigned int scriptPubKeyLen,
const unsigned char* txTo,
unsigned int txToLen,
unsigned int nIn, unsigned int nHeight,
unsigned int flags,
secp256k1_context_t* ctx,
bitcoinconsensus_error* err);
--
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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd wrote:
> Thus we have a few possibilities:
>
> 1) RCLTV against nLockTime
>
> Needs a minimum age > COINBASE_MATURITY to be safe.
>
>
> 2) RCLTV against current block height/time
>
> Completely reorg safe.
Yes, can we call this one OP_MATURITY to distinguish it from RCLTV?
> 3) GET_TXOUT_HEIGHT/TIME ADD CLTV
>
> To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age <
> COINBASE_MATURITY. This can be implemented by comparing against
> nLockTime.
Mhmm, interesting.
> All three possibilities require us to make information about the
> prevout's height/time available to VerifyScript(). The only question is
> if we want VerifyScript() to also take the current block height/time - I
> see no reason why it can't. As for the mempool, keeping track of what
> transactions made use of these opcodes so they can be reevaluated if
> their prevouts are re-organised seems fine to me.
I'm totally fine with changing the interface to:
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
, unsigned int txToLen, unsigned nHeight,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);
I prefer op_maturity over RCLTV and there are also gains for absolute
CLTV as you explain later.
When you validate the script inputs of a transaction you already have
a height, either the real final nHeight in ConnectBlock and the miner,
or nSpendHeight in AcceptToMemoryPool.
The costs are meaningless in my opinion, specially when we will
already have to change the interface to add libsecp256k1's context.
I'm infinitely more worried about the other assumption that the 3
solutions are already making.
Changing to
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
, unsigned int txToLen, const CCoinsViewCache& inputs,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);
Is simply not possible because CCoinsViewCache is a C++.
You could solve it in a similar way in which you could solve that
dependency for VerifyTransaction.
For example:
typedef const CTxOut& (*TxOutputGetter)(const uint256& txid, uint32_t n);
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
, unsigned int txToLen, TxOutputGetter utxoGetter,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);
Of course, this is assuming that CTxOut becomes a C struct instead of
a C++ class and little things like that.
In terms of code encapsulation, this is still 100 times uglier than
adding the nHeight so if we're doing it, yes, please, let's do both.
There's another possibility that could keep the utxo out of Script verification:
class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
uint32_t nSequence;
}
could turn into:
class CTxIn
{
public:
COutPoint prevout;
CScript scriptSig;
uint32_t nHeight;
}
And a new softfork rule could enforce that all new CTxIn set nHeight
to the correct height in which its corresponding prevout got into the
chain.
That would remove the need for the TxOutputGetter param in
bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
(apart from other ugly implementation details).
So, in summary, I think the new interface has to be something along these lines:
int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo,
unsigned int nIn,
unsigned int txToLen,
TxOutputGetter utxoGetter, unsigned nHeight, secp256k1_context_t *ctx
unsigned int flags,
bitcoinconsensus_error* err);
> Time-based locks
>
>
> Do we want to support them at all? May cause incentive issues with
> mining, see #bitcoin-wizards discussion, Jul 17th 2013:
>
> https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-17.log
I'm totally fine not supporting time-based locks for the new operators.
Removing them from the regular nLockTime could be more complicated but
I wouldn't mind either.
Every time I think of a contract or protocol that involves time, I do
it in terms of block heights.
I would prefer to change all my clocks to work in blocks instead of
minutes over changing nHeights for timestamps in any of those
contracts.
> --
> 'peter'[:-1]@petertodd.org
> 015e09479548c5b63b99a62d31b019e6479f195bf0cbd935
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1P
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
s7r you may be interested in this video explaining several aspects of malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs It is pre BIP62, but I believe it is very relevant and will hopefully clear some of your doubts. The signer of TX1 will always be able to change the signature and thus the tx ID. On Sat, Apr 18, 2015 at 4:49 PM, s7r wrote: > Understood. That is unfortunate, but not the end of the world. If you > could please give feedback also to these last comments / questions: > > How far are we at this moment from BIP62? Can an user send a > non-malleable tx now, if enforces some additional rules? > > As for the security of the system, it does not fully rely on txids being > non malleable, but see this quote from my previous email: > > [QUOTE] > I am trying to build a bitcoin contract which will relay on 3 things: > - coinjoin / txes with inputs from multiple users which are signed by > all users after they are merged together (every user is sure his coins > will not be spent without the other users to spend anything, as per > agreed contract); > - pre-signed txes with nLockTime 'n' weeks. These txes will be signed > before the inputs being spent are broadcasted/confirmed, using the txid > provided by the user before broadcasting it. Malleability hurts here. > - P2SH > > Another thing I would like to confirm, the 3 pieces of the bitcoin > protocol mentioned above will be supported in _any_ future transaction > version or block version, regardless what changes are made or features > added to bitcoin core? The contract needs to be built and left unchanged > for a very very long period of time... > [/END QUOTE] > > Can you comment on the quote please? > > So, basically transaction malleability could affect the system in the > way that a pre-signed tx which offers the insurance and which is sent to > the user before the user sends the coins (spending user's coins back to > him after a certain period of time) could be invalidated. The insurance > tx signature will still be good, but invalid overall since the input > (txid) being spent does not exist (was altered / modified). The coins > won't be stolen or lost, but a new tx needs to be signed with the > altered (new) txid, for the system to work. > > So, an user creates a transaction TX1 sending the coins to the server > but does not broadcast it. Instead, he provides the txid of TX1 to the > server. Server generates another transaction TX2 which spends TX1 back > to the user, with an nLockTime. User checks and if everything ok > broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2 > will become invalid (since it will be spending an inexistent input), and > the server will need to re-create and sign TX2 with the new > (altered/modified) txid of TX1, as per agreed contract. Should the > server disappear after user broadcasts TX1 and before the > altered/modified txid of TX1 gets confirmed, user's coins are forever > locked. It is true that no third party can benefit from this type of > attack, only the user will result with coins locked, but it is something > which could be used by competition to make a service useless / annoying > / too complicated or less safe to use. > > How could I mitigate this? > > Thanks you for your time and help. > > On 4/17/2015 12:02 PM, Pieter Wuille wrote: >>> Anyone can alter the txid - more details needed. The number of altered >>> txids in practice is not so high in order to make us believe anyone can >>> do it easily. It is obvious that all current bitcoin transactions are >>> malleable, but not by anyone and not that easy. At least I like to >> think so. >> >> Don't assume that because it does not (frequently) happen, that it >> cannot happen. Large amounts of malleated transactions have happened in >> the past. Especially if you build a system depends on non-malleability >> for its security, you may at some point have an attacker who has >> financial gain from malleation. >> >>> >From your answer I understand that right now if I create a transaction >>> (tx1) and broadcast it, you can alter its txid at your will, without any >>> mining power and/or access to my private keys so I would end up not >>> recognizing my own transaction and probably my change too (if my systems >>> rely hardly on txid)? >> >> In theory, yes, anyone can alter the txid without invalidating it, >> without mining power and without access to the sender's private keys. >> >> All it requires is seeing a transaction on the network, doing a trivial >> modification to it, and rebroadcasting it quickly. If the modifies >> version gets mined, you're out of luck. Having mining power helps of course. >> >> After BIP62, you will, as a sender, optionally be able to protect others >> from malleating. You're always able to re-sign yourself. >> >> -- >> Pieter >> > > -- > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in ac
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Oh, no, sorry, it also covers bip62. On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón wrote: > s7r you may be interested in this video explaining several aspects of > malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs > It is pre BIP62, but I believe it is very relevant and will hopefully > clear some of your doubts. > The signer of TX1 will always be able to change the signature and thus > the tx ID. > > On Sat, Apr 18, 2015 at 4:49 PM, s7r wrote: >> Understood. That is unfortunate, but not the end of the world. If you >> could please give feedback also to these last comments / questions: >> >> How far are we at this moment from BIP62? Can an user send a >> non-malleable tx now, if enforces some additional rules? >> >> As for the security of the system, it does not fully rely on txids being >> non malleable, but see this quote from my previous email: >> >> [QUOTE] >> I am trying to build a bitcoin contract which will relay on 3 things: >> - coinjoin / txes with inputs from multiple users which are signed by >> all users after they are merged together (every user is sure his coins >> will not be spent without the other users to spend anything, as per >> agreed contract); >> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed >> before the inputs being spent are broadcasted/confirmed, using the txid >> provided by the user before broadcasting it. Malleability hurts here. >> - P2SH >> >> Another thing I would like to confirm, the 3 pieces of the bitcoin >> protocol mentioned above will be supported in _any_ future transaction >> version or block version, regardless what changes are made or features >> added to bitcoin core? The contract needs to be built and left unchanged >> for a very very long period of time... >> [/END QUOTE] >> >> Can you comment on the quote please? >> >> So, basically transaction malleability could affect the system in the >> way that a pre-signed tx which offers the insurance and which is sent to >> the user before the user sends the coins (spending user's coins back to >> him after a certain period of time) could be invalidated. The insurance >> tx signature will still be good, but invalid overall since the input >> (txid) being spent does not exist (was altered / modified). The coins >> won't be stolen or lost, but a new tx needs to be signed with the >> altered (new) txid, for the system to work. >> >> So, an user creates a transaction TX1 sending the coins to the server >> but does not broadcast it. Instead, he provides the txid of TX1 to the >> server. Server generates another transaction TX2 which spends TX1 back >> to the user, with an nLockTime. User checks and if everything ok >> broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2 >> will become invalid (since it will be spending an inexistent input), and >> the server will need to re-create and sign TX2 with the new >> (altered/modified) txid of TX1, as per agreed contract. Should the >> server disappear after user broadcasts TX1 and before the >> altered/modified txid of TX1 gets confirmed, user's coins are forever >> locked. It is true that no third party can benefit from this type of >> attack, only the user will result with coins locked, but it is something >> which could be used by competition to make a service useless / annoying >> / too complicated or less safe to use. >> >> How could I mitigate this? >> >> Thanks you for your time and help. >> >> On 4/17/2015 12:02 PM, Pieter Wuille wrote: >>>> Anyone can alter the txid - more details needed. The number of altered >>>> txids in practice is not so high in order to make us believe anyone can >>>> do it easily. It is obvious that all current bitcoin transactions are >>>> malleable, but not by anyone and not that easy. At least I like to >>> think so. >>> >>> Don't assume that because it does not (frequently) happen, that it >>> cannot happen. Large amounts of malleated transactions have happened in >>> the past. Especially if you build a system depends on non-malleability >>> for its security, you may at some point have an attacker who has >>> financial gain from malleation. >>> >>>> >From your answer I understand that right now if I create a transaction >>>> (tx1) and broadcast it, you can alter its txid at your will, without any >>>> mining power and/or access to my private keys so I would end up not >>>> recognizing my own transaction and probably my c
Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
That case is very unlikely IMO, but still you can solve it while keeping
hash of the genesis block as the chain id. If a community decides to accept
a forking chain with new rules from block N (let's call it bitcoinB), the
original chain can maintain the original genesis block and the new
community can define N (which is not accepted by bitcoin due to the new
rules) as the genesis block for bitcoinB for the purposes of chain ID. As
said forking bitcoins and bitcoinsB with the same owners doesn't make much
sense to me. If you're creating a new currency you can just as well define
a new chain. If you want to start an initial utxo giving the new coins to
bitcoin holders...I still don't see the point, but you can also do that in
a new chain.
In summary, your example is not a good reason not to adopt a hash of the
genesis block as chain ID.
On Mar 14, 2015 5:22 PM, "Isidor Zeuner"
wrote:
> > That was essentially what we did in the end, we replaced the network
> > identifier ("main"/"test") with the genesis block hash. The result is
> > never going to accidentally work with Bitcoin Core (nor vice-versa), but
> > is readily extensible to any other altcoins that want to use the
> > specification without requiring any sort of central registry.
> >
>
> Interesting approach, and I also think that requiring a central
> registry would be potentially harmful.
>
> However, I think it might not be adequate to think of the network
> identifier as being congruent with the genesis block hash. In the
> theoretical case of the blockchain being continued on two forked
> chains (with two communities which prefer one of the chains each),
> clients would not be prevented from interpreting messages on the wrong
> chain.
>
> Best regards,
>
> Isidor
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik wrote: > "scorched earth" refers to the _real world_ impact such policies would > have on present-day 0-conf usage within the bitcoin community. When I posted this: http://sourceforge.net/p/bitcoin/mailman/message/32263765/ Peter Todd clarified that the concept was referred to as "scorched earth" http://sourceforge.net/p/bitcoin/mailman/message/32264039/ Like I said I don't like the name and would prefer "stag hunting" which is more formal and precise. Some people seem to use the same term for "the potential undesirable consequences of widely deployed replace-by-fee policies". I'm not sure that concept deserves its own term. > All payment processors AFAIK process transactions through some scoring > system, then accept 0-conf transactions for payments. > > This isn't some theoretical exercise. Like it or not many use > insecure 0-conf transactions for rapid payments. Deploying something > that makes 0-conf transactions unusable would have a wide, negative > impact on present day bitcoin payments, thus "scorched earth" And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. -- 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=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
I agree "scorched hearth" is a really bad name for the 0 conf protocol based on game theory. I would have preferred "stag hunt" since that's basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) but I like the protocol and I think it would be interesting to integrate it in the payment protocol. Even if that protocol didn't existed or didn't worked, replace-by-fee is purely part of a node's policy, not part of consensus. >From the whitepaper, 0 conf transactions being secure by the good will of miners was never an assumption, and it is clear to me that the system cannot provide those guaranties based on such a weak scheme. I believe thinking otherwise is naive. As to consider non-standard policies "an attack to bitcoin" because "that's not how bitcoin used to work", then I guess minimum relay fee policies can also be considered "an attack to bitcoin" on the same grounds. Lastly, "first-seen-wins" was just a simple policy to bootstrap the system, but I expect that most nodes will eventually move to policies that are economically rational for miners such as replace-by-fee. Not only I disagree this will be "the end of bitcoin" or "will push the price of the btc miners are mining down", I believe it will be something good for bitcoin. Since this is apparently controversial I don't want to push for replace-by-fee to become the new standard policy (something that would make sense to me). But once the policy code is sufficiently modular as to support several policies I would like bitcoin core to have a CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no policy checks at all). One step at a time I guess... On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes wrote: > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: >> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: >> > >> > Most money/payment systems include some method to reverse or undo >> > payments made in error. In these systems, the longer settlement >> > times you mention below are a feature, not a bug, and give more >> > time for a human to react to errors and system failures. >> > >> >> Settlement has to be final somewhere. That is the whole point of it. >> Transfer costs in current electronic payment systems are a direct >> consequence of their non-finality. That's the point Satoshi was making >> in the introduction to the whitepaper: "With the possibility of >> reversal, the need for trust spreads". > > The problem with that statement is I trust a merchant that I went into > a store and made a payment with personally more than I trust the firmware > on my hard drive [1]. > > The attack surface of devices in your computer is huge. A motivated attacker > just needs to get an intern into a company that makes some kind of component > or system that's in your computer, cloud server, hardware wallet, or what > have you that has firmware capable of reading your private keys. > > With the possibility of mass trojaned hardware, if we are going to trust > the system, it must somehow allow reversal through a human-in-the-loop. > >> There is nothing wrong with having reversible mechanisms built on top >> of Bitcoin, and indeed it makes sense for most activity to happen at >> those higher layers. It's easy to build things that way, but >> impossible to build them the other way: you can't build a >> non-reversible layer on top of a reversible layer. > > We built 'reliable' TCP on top of unreliable ethernet networks. My experience > with networking was if you tried to guarantee message delivery at the lowest > level, the system got exceedingly complicated, expensive, and brittle. > > Most applications, in particular paying someone you already trust, are quite > happy running on reversible systems, and in some cases more reliable and > lower risk. (carrying non-reversible cash is generally considered risky) > > The problem is that if the base currency is assumed to be non-reversible, > then it's brittle and becomes 'too big to fail'. > > Where the blockchain improves on everything else is in transparency. If you > reverse transactions a lot, it will be obvious from an analysis. I would much > rather deal with a known, predictable, and relatively continous transaction > reversal rate (percentage) than have to deal with sudden failures where > some anonymous bad actor makes off with a fortune. > > We already have zero-conf double-spend transaction reversal, why not > explicitly > extend that a little in a way that senders and receivers have a choice to > use it, or not? > > > [1] > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 > > -- > 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 cor
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Thu, Feb 19, 2015 at 6:30 PM, Mike Hearn wrote: >> He didn't said "a project for all possible language bindings", just >> java bindings. Other languages' bindings would be separate projects. > > > Yes/no/sorta. > > Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as > dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages > like Scala, Kotlin, Ceylon, etc. > > It makes more sense to talk about bindings to particular runtimes these > days, rather than particular languages. Oh, I didn't knew that. Thanks for the clarification. -- 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=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Thu, Feb 19, 2015 at 3:09 PM, Tamas Blummer wrote: > On Feb 19, 2015, at 3:03 PM, Bryan Bishop wrote: >> Second, I think that squeezing all possible language bindings into a project >> is also unproductive. > > The language binding would be an independent and separately hosted project > only using the C interface of the libconsensus library. He didn't said "a project for all possible language bindings", just java bindings. Other languages' bindings would be separate projects. -- 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=190641631&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer wrote: > Peter, > We have seen that the consensus critical code practically extends to Berkley > DB limits or OpenSSL laxness, therefore > it is inconceivable that a consensus library is not the same as Bitcoin > Core, less its P2P service rules, wallet and RPC server. Right now libconsensus' only dependency is openSSL. Most of the testing in libsecp256k1 has been in signing rather than verifying signatures (please, anyone with more knowledge in the library don't hesitate to correct me or clarify things). But eventually openSSL will be completely replaced by libsecp256k1. It does not store anything, 0.1 is just a dynamic library with a c API to a single function: VerifyScript(). This function saves the hassle of reimplementing signature checking (which is a really hard part) and reimplementing an interpreter that must function in exactly the same way in many as many other nodes with different software and/or hardware. Guido van Rossum can say "some behaviours in python the language are not specified, so it is ok if cpython and pypy do different things, they're still both running python which is more abstract than any of its implementation". But a consensus system like bitcoin doesn't have the luxury of leaving consensus rules unspecified. And the simplest way to fully specify a language interpreter is by implementing it. But coupling the consensus rules specification with a bigger project like bitcoin core can result in implementation details of that bigger project accidentally and unexpectedly becoming consensus rules. This is what happened with bdb and nobody wants that to happen again, that's the whole point. Note that many parts of the bitcoin protocol (like the p2p messages) are NOT part of the consensus rules. You can have a look at https://github.com/jtimon/bitcoin/commits/consensus2 and maybe you would be surprised about how small they actually are. This branch is incomplete and still a mess that needs to be cleaned up. And none of that is included in libconsensus yet. I was planning on writing a post here asking for feedback on the interfaces for these higher level checks. I'm just putting the code together in the same module, but obviously class CCoinsViewCache cannot be an argument in functions of a c API. > The Core code base is unfriendly to feature extensions because of its > criticality, legacy design and ancient technology. It is also a commodity > that the ecosystem takes for granted and free. > > I honestly admire the core team that works and progresses within these > limits and perception. > > I am not willing to work within the core’s legacy technology limits. Does it > mean I am dicking around? I think not. > It was my way to go down the rabbit hole by re-digging it and I created > successful commercial products on the way. Nobody is attacking alternative implementations. This tool was created mostly with alternative implementations in mind. So input from them it's very welcomed on how to continue libconsensus (or of course correct any flaws in verifyScript if there's any). I just wanted to wait to have some more code to make things easier to explain (and have a clearer idea of it myself). There's a more limited branch on "next steps for libconsensus" in #5669. > It is entirely rational for me to focus on innovation that uses the core as > a border router for this block chain. Sure, I think he is complaining that at the moment that's probably the only safe way to operate with alternative implementations and still have full node guarantees. > I am rather thankful for the ideas of the side chains, that enable > innovation that is no longer measured on unapologetic compatibility with a > given code base, but its services to end user. Sidechains are completely orthogonal to this discussion and, in fact, it would be good to have libconsensuses for sidechains too, since their nodes also need to come to consensus. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Re-enabling simple tx replacement
On Sun, Jan 4, 2015 at 7:31 PM, Gregory Maxwell wrote: > Thanks for presenting your solution as code in any case. It really is a useful > way to communicate and I wish more people did that. +1 -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
On Mon, Dec 29, 2014 at 10:34 PM, Justus Ranvier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 12/29/2014 09:10 PM, Mike Hearn wrote: >> How does adding inputs to a coinbase differ from just having >> pay-to-fee transactions in the block? > > If a miner includes pay-to-fee transactions in a block, those fees > could be claimed by another miner in the case the first miner's block > is orphaned. > > Inputs to a generation transaction can not be similarly poached. > > That difference makes some services possible that would can not be > safely achieved with pay-to-fee transactions. What services? I must be missing something obvious about the motivation. I understand the difference between "paying to myself only when I mine the next block" and "offering fees to whoever mines this tx". But how does allowing miners to pay to themselves in this way help with security and future lower subsidies at all? -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles
On Sun, Dec 21, 2014 at 5:07 PM, Peter Todd wrote: > On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Timón wrote: >> So let's go through an example to see in which ways >> non-proof-of-publication orders are "insecure". >> >> Alice the seller wants to sell 1 unit of A for 100 units of B. >> Bob is willing to pay up to 200 Bs for 1 A. >> >> Let's assume a proof of publication system first, in which the >> execution price is the mean between bid and ask. >> Alice publishes her order. >> Bob could publish his order at price 200 Bs and the order would >> execute at 150 Bs. >> But after seeing Alice's order he knows he doesn't need to pay that >> much, so he publishes and order buying for 100 Bs. >> >> Alice gets 100 Bs (what she signed she wanted) and Bob pays less than >> he was wiling to pay, he pays 100 Bs. Everybody happy. >> >> Now let's assume native assets and sighash_single. > > Incidentally, SIGHASH_SINGLE is just as usable in embedded consensus; > it's not specific to native assets. > >> So again, what's the advantage that proof-of-publication provides TO >> ALICE so that she will be so eager to pay the higher costs to get the >> same deal? > > Like I said the last time this issue was discused on the mailing list, > it's silly to think the seller of an asset starts off with a specific > price they want to sell it at and is happy no matter what happens or how > it gets fufilled. In the real world sellers and buyers want to know > they're connected to actual sellers and buyers - not sybil attackers > trying to shave off a margin for themselves - and are willing to pay a > premium for that. Note all the hatred and vitrol directed towards > high-frequency traders... And like last time we discussed this on the mailing list my opinion differs from yours. You talk about "real world sellers and buyers" but ignore Alice the seller and Bob the buyer in my example. You failed to explain how sybil attackers (Carol) get all those margins. In my example I claim miners get them, what am I missing? How is the same example with a proof-of-publication market any better? Miners can reorder the orders with proof of publication too. If getting orders into mined blocks faster has an advantage miners can charge privileged traders for privileged connections (just like it happens today with "perfectly fair" centralized markets today that feature the high-frequency trading you mention). They could even charge for moving transactions around within the same block if that has any effect on the execution rules. I prefer that miners can get the difference between bids and asks directly to compensate for their hashing power. > How *much* of a premium is an interesting question, and depends a lot on > the specific scenario. For instance I fully expect to see a whole > variety of mediums become used for the proof-of-publication needed, > ranging from directly on a major blockchain to minor/less secure > blockchains like Bitmessage over treechains to centralized-but-audited > proof-of-publication schemes - AKA centralized exchanges - to standard > exchanges. Point is, the concept of proof-of-publication makes these > tradeoffs and options available and lets end-users pick the right one > for their needs. The point is that there's more models for p2p markets beyond those that require proof of publication for their orders, and you're claiming that only those using proof of publication are secure. That's incorrect. > Accurate unbiased price information is worth money. Can you define "Accurate unbiased price information"? > In systems that > allow third-parties to republish asset bids and offers we'll even see > third-parties republishing bids and offers from less secure systems to > more secure systems to get better price discovery. Traders want to trade. The primary function of markets is exchange, not price discovery. >> If this example is not enough to be able to explain the advantage of >> proof-of-publication markets feel free to write a more complex one. > > I gotta ask, have you actually run the design and tradeoffs of > Friemarket's past actual finance types? I have, and it's remarkable how > excited many of them are about cryptographically provable fair price > discovery. "Provably fair price discovery" is probably impossible. But I can imagine how many people could get excited about such a technology. Can you formally define what you mean by this? You see, "fair" implies morality and therefore it's a very subjective term, so it's not obvious to me what you may mean by that. > -- > 'peter'[:-1]@petertodd.org > 00
Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles
st On Sun, Dec 21, 2014 at 6:52 AM, Peter Todd wrote: > On Sun, Dec 21, 2014 at 11:57:51AM +0800, Mark Friedenbach wrote: >> I think you are trying to say something more specific / limited than that, >> and I suggest you adjust your wording accordingly. Decentralized exchange >> would be possible today with vanilla bitcoin using SIGHASH_SINGLE if only >> the protocol supported multiple validated assets (which it could, but >> doesn't). Rather straightforward further extensions to the protocol would >> enable market participants to use a wider class of orders, as well as >> enable the buyer rather than the seller to dictate order sizes via partial >> redemption, as we demonstrate in our Freimarkets paper. > > Do you realise that all those Freimarket's uses are either based on > proof-of-publication, or insecure due to sybil attacks? So let's go through an example to see in which ways non-proof-of-publication orders are "insecure". Alice the seller wants to sell 1 unit of A for 100 units of B. Bob is willing to pay up to 200 Bs for 1 A. Let's assume a proof of publication system first, in which the execution price is the mean between bid and ask. Alice publishes her order. Bob could publish his order at price 200 Bs and the order would execute at 150 Bs. But after seeing Alice's order he knows he doesn't need to pay that much, so he publishes and order buying for 100 Bs. Alice gets 100 Bs (what she signed she wanted) and Bob pays less than he was wiling to pay, he pays 100 Bs. Everybody happy. Now let's assume native assets and sighash_single. Alice publishes her order (out of band, using various channels). Bob could publish his order at price 200 Bs and then a miner would execute at 100 Bs for Alice, at 200 Bs for Bob and pocket 100 Bs as mining fees. But after seeing Alice's order he knows he doesn't need to pay that much, so he publishes and order buying for 100 Bs. Again, Alice gets 100 Bs (what she signed she wanted) and Bob pays pays 100 Bs. The main difference is that Alice didn't had to pay a fee to publish her binding order. Now let's try to articulate your concerns. Your concern is that Carol, isolates Bob preventing him from seeing Alice's order. Then maybe Bob publishes his own order at 200 Bs. If Carol sees both orders while preventing the other participants from seeing them, she can build a tx in which Alice sells at 100, Bob buys at 200, and Carol pockets the difference. But...any smart miner will replace Carol's address with his own when processing the trade, so Carol cannot win this way. Another thing Carol can do is to buy the A herself for 100 Bs, leaving Bob without them. If Alice cares about Bob getting the deal instead of Carol she can do two things: 1) Establish a direct communication channel with Bob 2) Move to a proof of publication system and start paying fees for publishing binding orders. So again, what's the advantage that proof-of-publication provides TO ALICE so that she will be so eager to pay the higher costs to get the same deal? If this example is not enough to be able to explain the advantage of proof-of-publication markets feel free to write a more complex one. -- 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=164703151&iu=/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 12:43 PM, Flavien Charlon wrote: > Storing only a hash > is fine for the most basic timestamping application, but it's hardly enough > to build something interesting. No, storing only a hash is enough for ALL timestamping applications. If you need to broadcast more data then we're not talking about timestamping anymore, but rather proof of publication. Unfortunately (and as it has been already mentioned) many applications don't need proof of publication and yet they are just using the blockchain as a convenient transport mechanism, but that's highly inefficient. It's like if you sent all your mails to all the existing email addresses with the metadata "to be read by: destinat...@yourhost.com". It wouldn't make any sense and it wouldn't scale. A url definitely looks like something that doesn't belong in the chain. -- 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=157005751&iu=/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
As an aside, the decision to make it 40 bytes made sense because it is enough for timestamping. In fact, you can do cheaper and even secret (and thus impossible to censor by miners) timestamping using pay-to-contract [1], which uses exactly 0 extra bytes in your transaction and the blockchain. I remember people asking in #bitcoin-dev "Does anyone know any use case for greater sizes OP_RETURNs?" and me answering "I do not know of any use cases that require bigger sizes". I'm aware that so called "proof of publication" is not equivalent to timestamping, but I wasn't aware at the moment (and I don't think it's very interesting but that's obviously only my opinion, "embedded systems" developers will disagree). [1] Here's a video explaining pay-to-contract in the context of invoicing as a use case: https://www.youtube.com/watch?v=qwyALGlG33Q Here's a generic working implementation: https://github.com/Blockstream/contracthashtool On Sun, Nov 16, 2014 at 7:44 PM, Jorge Timón wrote: > I agree with Luke, we can endlessly discuss the "best defaults" like > the default size allowed for OP_RETURN, minimum fees, anti-dust > policies, first-seen vs replace-by-fee, etc; but the fact is that > policies depend on miners. Unfortunately most miners and pools are > quite apathetic when it comes to configure their own policy. > In my opinion the best we can do is to make it easier for miners to > implement their own policies by abstracting out those parts of the > code. Pull requests like #5071 and #5114 are steps in that direction. > So if you're interested in having more miners accepting 80 bytes > OP_RETURN transactions, I suggest you invest some time reviewing and > testing those PRs. > Although this wasn't its main purpose, separating script/standard was > also a little step in the same direction. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/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
I agree with Luke, we can endlessly discuss the "best defaults" like the default size allowed for OP_RETURN, minimum fees, anti-dust policies, first-seen vs replace-by-fee, etc; but the fact is that policies depend on miners. Unfortunately most miners and pools are quite apathetic when it comes to configure their own policy. In my opinion the best we can do is to make it easier for miners to implement their own policies by abstracting out those parts of the code. Pull requests like #5071 and #5114 are steps in that direction. So if you're interested in having more miners accepting 80 bytes OP_RETURN transactions, I suggest you invest some time reviewing and testing those PRs. Although this wasn't its main purpose, separating script/standard was also a little step in the same direction. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)
On Mon, Nov 3, 2014 at 5:01 PM, Alex Mizrahi wrote: > This isn't applicable in case of sidechains: anybody with sufficient > hashpower will be able to unlock a locked coin on the parent chain by > producing an SPV proof. > "Only if the miners form a shared valid history" isn't a requirement here, > as miner will get bitcoins which aren't in any way connect to sidechain he > have wrecked. Thus there is no incentive to behave honestly. But if the majority of the sidechain miners keep working on the honest chain, anyone can submit a reorg proof during the contest period that invalidates this "unlockment" on the parent chain. Honest sidechain miners will get rewarded in the sidechain, and those rewards will only be valuable if they form a shared valid history. > Whether it is enough depends on a variety of factors, including existence of > other chains miner can mine. > You cannot assume that it is the same situation as with a simple > single-chain model. This is correct. There's many variables at play. > E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining > bitcoins as usual, and in parallel work on an SPV proof to claim these 1000 > BTC. (I assume that merged-mining is allowed.) > In this case the amount of fees which miners could collect by honest mining > on the sidechain is irrelevant, as long as it is smaller than 1000 BTC. As explained many times, sidechains and merged mining are orthogonal: pegged sidechains don't need to use merged mining just as merged mining altchains don't need to be sidechains. Anyway, I think you're somehow assuming that deciding to mine against the sidechain instead of mining for its rewards. This is simply not true. No matter how big the attack incentive is, if you're assuming my 52560 contest period example and that the attacker doesn't control the majority of the hashing power on the sidechain, the probability of achieving a one-year reorg is negligible. In the meantime honest nodes are getting some reward, let's say 0.1 BTC per block. That's 5256 btc/year to the honest nodes vs 0 btc/year for the attacker. If the attacker controls, say, 10% of the network, he's losing 525.6 btc/year in opportunity costs for an extremely small chance of getting 1000 btc. > This is quite different from attacks which can be performed on vanilla > Bitcoin (see below), so I don't think you can say that the security model is > the same. We're not claiming that the security model is the same, we just compare it to Bitcoin's because it's similar in many senses. >> Also says "Given our assumption that p > q, the probability drops >> >> exponentially as the number of blocks the >> attacker has to catch up with increases." > > > Yes, but that doesn't apply to reorganizations which attacker might cause > intentionally. Yes, that's precisely the kind of reorganizations the BITCOIN WHITEPAPER is talking about in section "11 Calculations": reorganizations caused intentionally by an attacker. Please read it again. "q_z = probability THE ATTACKER will ever catch up from z blocks behind". > Hence I think it was disingenuous to include these two very different treats > into one section: > it sounds like you claim that attacker-induced reorganizations are unlikely, > while it isn't the case. If it sounds to you like we're claiming that attacker-induced reorganizations are not likely, maybe we could have expressed it some other way. That was certainly not the intention. That's not true for Bitcoin itself and that's not what we're claiming. >> So the longer the contest period is, the harder it is to succeed with >> a fraudulent transfer. > > > Yes, but "harder" isn't same as "unlikely". Exponentially harder with the number of blocks is good enough for me. > Another problem with this section is that it only mentions reorganizations. > But a fraudulent transfer can happen without a reorganization, as an > attacker can produce an SPV proof which is totally fake. So this is not > similar to double-spending, attacker doesn't need to own coins to perform an > attack. That would be a reorganization too, you can't create a completely fake history for a sidechain, the attacker will share some of the chain's history. Yes, the attacker can create an SPV proof of a fake chain and in that sense, this is different from a regular double-spend. If honest miners control the majority of the hashing power, they will produce a valid chain longer than the fake chain. And then anyone can use that reorg proof to stop the attacker before the contest period. You see, "SPV security" is not the same as "SPV security with more than 52560 confirmations of the transaction I'm receiving". >> I hope this clarifies our assumptions. > > Yep, thanks. It looks like you assume that sidechain security will be > similar to Bitcoin security in the long term. > Now quite the assumptions I've been looking for, but OK... > > I'm sorry for the harsh tone, but I just find it hilarious that people who > explained that pr
Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)
On Mon, Nov 3, 2014 at 1:12 PM, Alex Mizrahi wrote:
>
>> For those following this thread, we have now written a paper
>> describing the side-chains, 2-way pegs and compact SPV proofs.
>> (With additional authors Andrew Poelstra & Andrew Miller).
>>
>> http://blockstream.com/sidechains.pdf
>
>
> Haven't seen any material discussion of this paper in this mailing list, so
> I'll start.
> (Otherwise, I've seen Peter Todd's reaction on reddit.)
>
> This paper fails to demonstrate that sidechains are anything more than a
> wishful thinking.
> It can be distilled down to this:
> "We want such and such features, hence we'll use DMMS, the same thing
> Bitcoin uses, thus it will be secure!"
> Um, no.
> Alt-coins also use DMMS, but aren't as secure as Bitcoin.
>
> So DMMS does not work by itself, it is a mechanism to secure a blockchain
> using economic incentives.
> The sidechains paper does not mention this, as far as I can tell.
>
> In my opinion, this is not acceptable. If you're making a proposal, you need
> to describe what conditions are required for it to work.
>From the introduction "[...]Because signers prove computational work,
rather than proving secret knowledge as
is typical for digital signatures, we refer to them as miners. To
achieve stable consensus on the
blockchain history, economic incentives are provided where miners are
rewarded with fees and
subsidies in the form of coins that are valuable only if the miners
form a shared valid history,
incentivising them to behave honestly.[...]"
Ignoring altrustic miners, the irreversibility of a DMMS chain
obviously depends on the rewards received by miners on that chain.
Nobody is claiming that sidechains will be "as secure bitcoin", any 2
way pegged assets is always "more secure" (probably too vague of a
term in this context) in its original chain.
> Authors are clearly aware of the problem and mention it in section 6 "Future
> directions" 6.1. "Hashpower attack resistance".
> The problem is they do not make it clear that the proposal just makes no
> sense until this is solved.
Since all seigniorage from Bitcoin's initial distribution is spent on
mining subsidies for the main chain, it is not available to subsidize
sidechains too. Thus sidechains, in principle, reward their miners
with the same Bitcoin will use in the future: only transaction fees.
Since some people claim that won't be enough (is not always clear to
me if they believe that won't be enough for sidechains or also for
bitcoin when the subsidies are gone), we included this section with
other ideas we have explored to further. Some of them, like
"time-shifted fees" could be interesting for Bitcoin itself in the
future.
> It doesn't help that the paper itself tries to sweep the problem under the
> rug and has misleading statements.
> Particularly, I'm talking about section "4.2. Fraudulent transfers":
>
> "Reorganisations of arbitrary depth are in principle possible, which could
> allow an attacker to
> completely transfer coins between sidechains before causing a reorganisation
> longer than the contest
> period on the sending chain to undo its half of the transfer. ... If the
> attacker is allowed to return the transferred coins to the original
> chain, he would increase the number of coins in his possession at the
> expense of other users of the sidechain.
> Before discussing how to handle this, we observe that this risk can be made
> arbitrarily small by
> simply increasing the contest period for transfers."
>
> Wow, really? Is this risk stochastic?
>
> The first sentence implies that attacker is able to cause a reorganization
> of an arbitrary depth, but the rest of the section implies that
> reorganizations are a naturally occurring phenomenon.
Reorganizations are both a naturally occurring phenomenon and
something that an attacker may cause to revert history.
Section "11. Calculations" of the Bitcoin whitepaper gives you this
formula (in C code):
#include
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Also says "Given our assumption that p > q, the probability drops
exponentially as the number of blocks the
attacker has to catch up with increases."
In this case, the contest period determines z, the number of blocks
the attacker has to catch up from the honest chain.
So the longer the contest period is, the harder it is to succeed with
a fraudulent transfer.
For example, if a given sidechain chooses 52560 as the contest period
(1 year assuming 10 min blocks), it will be very hard for an attacker
to produce a fake alternative longest-than-the-last-year-of-history
fork to steal coins.
A sidechain with such an extreme contest period would probably not be
very practical th
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
On Mon, Oct 6, 2014 at 1:40 AM, Gregory Maxwell wrote: > Something you might want to try to formalize in your analysis is the > proportion of the network which is "rational" vs > "honest"/"altruistic". Intuitively, if there is a significant amount > of honest hashrate which is refusing to aid the greedy behavior even > at a potential loss to themselves this strategy becomes a loser even > for the purely greedy participants. It would be interesting to > characterize the income tradeoffs for different amounts of altruism, > or whatever convergence problems an attempt by altruistic > participaints to punish the forkers might create. Not only that, greedy miners may actually have an incentive to just follow the longest chain. Say I'm a small miner and I know that the chances of re-mining the high tx and getting that block into the longest chain are minimal or null. Then I will probably prefer to just mine on top of the longest chain. So "If everyone acts rationally in his own interest, then the best choice for the remaining miners is to try to mine a competing block at the same height n including the high-fee transaction, to collect the fee for themselves" is not necessarily true. p * 50 can be lower than q * 25 if p < 2*q. P and q depend on what everyone is doing, not just you. In any case, it is interesting to think about this things since mining subsidies will eventually disappear and then transaction fees will ALWAYS be higher than subsidies. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] How to create a pull tester JAR
Once you ave the jar, you can also build with ./configure --disable-silent-rules --disable-ccache --with-comparison-tool=/path/to/your/BitcoindComparisonTool.jar Instead of the regular ./configure And after that "make check" will run most of the tests the pull tester does. On 8/5/14, Mike Hearn wrote: > No problem. > > The pull tester entry point can be found here: > > https://github.com/bitcoinj/bitcoinj/blob/master/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java > > (nb: in the near future I will be re-namespacing the library from > com.google.bitcoin to org.bitcoinj to reflect that it no longer has > anything to do with Google and then this link will break). > > The code itself is a rather bad example of copy/paste coding and I can say > that, because Matt knows it and already plans to refactor things ;) So if > anyone is thinking of adding tests to the framework coordinate with him > first to ensure you don't end up conflicting with a big refactor/rewrite. > -- Jorge Timón -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Protocol Specification
There's this (not sure how complete it is): https://en.bitcoin.it/wiki/Protocol_specification Also there's a good introduction to technical details here: https://bitcointalk.org/index.php?topic=375524.0 I hope that is useful. On 7/8/14, Matt Whitlock wrote: > Is anyone working on a similar specification document for Satoshi's P2P > protocol? I know how blocks and transactions are structured and verified, > but I'm interested in knowing how they're communicated over the network. > > -- > 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 > -- Jorge Timón -- 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
On 7/4/14, kjj wrote:
> I suspect that there exist no algorithms which cannot be done better in
> an application-specific device than in a general purpose computer. And
> if there is such a thing, then it must necessarily perform best on one
> specific platform, making that platform the de facto application
> specific device.
>
> I'm not sure how one would go about proving or disproving that, but it
> seems very likely to be true.
I assumed this was obvious and self-evident for anyone who knows what
a Turing machine is, but judging from the number of smart people
wasting their time on the pursue of the "anti-ASIC" myth (also known
as pow wankery) it seems I was wrong.
Anything you can do with software you can do with hardware and
viceversa (you can even do it with ropes and fire in Minecraft!!)
Does this really need any proof?
I think it's the hard-pow cultists who have to provide a counterexample.
Very often you just need to query-replace "ASIC" with "specialized
hardware" to prove that what they're saying makes no sense.
> Keeping the algorithm simple, and ASIC-easy, has one other advantage.
> Just about anyone can sit down and design an ASIC for SHA, for example,
> leading to diversity in the marketplace. A harder algorithm can still
> be made into an ASIC (or more generally into an ASD), but will require
> more skilled designers, more expensive fabrication, etc. This actually
> concentrates the ASIC advantage into the hands of fewer people, which
> again, is contrary to the stated goals.
Yep, I think this is the strongest argument against "hard-pow".
But unfortunately you even find people that want "anti-ASIC without
being anti-GPU", which is funny because GPU just has Nvidia and AMD
and because unlike "anti-ASIC", anti-GPU is actually possible (despite
Litecoin's Scrypt having miserably failed on both accounts).
Interestingly enough, Greg Maxwell told me that the energetc advantage
of memory-hard pow ASICs is even greater than the advantage for SHA
ASICs.
Anyway, I'm working on a branch to encapsulate the proof of work that
should serve people to more easily experiment with alternate proofs on
top of bitcoind's code. I plan to use it for private chains ("proof of
signature" or "proof of script" if you prefer), and although it's not
ready yet, some people may be interested or may want to give some
feedback:
https://github.com/jtimon/bitcoin/tree/proof
I don't know if it will make it into master, but by specializing
ProofOfWork with TestnetProofOfWork we could remove
Params().AllowMinDifficultyBlocks() and its checks.
--
Jorge Timón
--
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] Proposed BIP 70 extension
+1 on setting up the payment protocol extensions process more formally. On the feature itself, it is interesting to note that some complementary currencies backed by national currencies offer a discount when converting from fiat to complementary, which has an equivalent effect to this "discount for paying with btc". The main difference is that in local currencies the merchants are a relatively small group and the discount is uniform whereas here each merchant can set his own discount. There's scientific studies on how different currency features like these discounts affect adoption, velocity and other variables. I can ask for them if anyone is interested. On the implementation, I think a percentage/proportion would be preferable over an amount in satoshis. Let's imagine for a second that the bitcoin payment protocol ends up being a generalized and universal payment protocol. The field would be really something like "discount/additional_charge for paying with the chosen currency/payment_method". You could have 0.95 for a 5% discount or 1.05 for a 5% additional charge. Mhmm, maybe a flat discount/charge in addition to the proportional one... On security, being an optional field, I don't see how can it harm anything. It is true that the merchants can lie about the discount, but wallets can be smart or stupid about it, or just completely ignore the field as they wish. Anyway, it feels like a random simple extension as an excuse to develop the extension process. If it gets too complicated we can start with a simpler and less critical one but it's hard for me to imagine it. On 6/25/14, Mike Hearn wrote: >> >> I agree. It would be even sillier to start specifying container formats >> for random one-off "that would be kind of nice, I guess" features. >> > > No, it'd be sensible. > > Here's a list I drew up a long time ago of features I imagined adding to > the payment protocol: > > https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147 > > The protocol is there to contain features! There is zero benefit to > slavishly following some religious notion of purity or minimalism here. The > shared resource in question is just varint encoded integers. So, we should > be guided by what will help our users and what will help adoption. > > Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago. > I want to use something simple to set up the extensions process more > formally. IMO we need a "living document" version of the payment protocol > with all the different extensions out there folded into it, to simplify > programming tasks and ensure field numbers don't collide. > -- Jorge Timón -- 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] Plans to separate wallet from core
On 6/24/14, Justus Ranvier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/24/2014 09:07 AM, Wladimir wrote: >> My main argument for the split is that full nodes and wallets have >> completely different usage scenarios: >> >> - A wallet should be online as little as possible, ideally only >> when you do transactions or want to check for them. >> >> - A full node should be online 24/7 or it is virtually useless to >> the network. > > I think btcd has done this right. > > A wallet is a daemon that runs constantly in the background, just like > the full node. > > The GUI (which is distinct from the wallet) runs as little as > possible. Presumably there's no need for a 1:1 relationship between > wallets and GUIs. I think he means that the wallet shouldn't be running as much as it is currently doing. But yes, I think you're right about wallets and GUIs not necessarily mapping 1:1. -- 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] Plans to separate wallet from core
On 6/24/14, Tamas Blummer wrote: > 3. Services e.g. exchange, payment processor This is where core + > indexing server talking SPV to core is the right choice I think this is my main question, what's the advantage of having the processes talking via the p2p protocol instead of something more direct when you control both processes? Wladimir, of course headers-first is generally good, and of course nobody will be force to separate the code in a way he doesn't like, I was just testing the waters to see what people had in mind, since I realized the ideas could be more different than I had assumed. I don't have any issues with electrum, I'm just not convinced by the arguments that say that the indexes must be necessarily out of the core, specially when some of them could be committed in the future. So I'm all in favor of modularity and competing codebases, I'm just not convinced that the "core full-node" must be necessarily restricted to validation only (for example, I think it should maintain a minimal and non-optimized mining functionality,even if it's only used for testing purposes). So far it is great that everybody seems to agree that the wallet code needs to be separated. Thanks everyone for sharing your views on the subject. -- 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] Plans to separate wallet from core
On 6/24/14, Mike Hearn wrote: > bitcoind already supports SPV mode, that's how bitcoinj clients work. > However the current wallet code doesn't use it, it integrates directly with > the full mode main loop and doesn't talk P2P internally. Which is the fine > and obvious way to implement the wallet feature. I'm not totally convinced > it should become an SPV wallet given the complexity of doing that. But if > you did want to separate the wallet code from the full node then that'd be > the way to do it. > > The question is; what does this buy us, and is it worth the potentially > huge amount of time it could take? My gut feeling is we have bigger fish to > fry. There's plenty of work to do just on the core consensus code, making > Bitcoin Core into a competitive wallet as well would be an additional > burden. Exactly, this is part of my point, the qt-wallet does not support SPV operation at this point, and that complex work should be done after the wallet is separated. Thus the first version of the separated wallet should be functionally equivalent to today's wallet, that is, a full node wallet (even though I understand Wladimir's arguments against full-node wallets). >> I'm sorry, but I still don't know what Electrum has to do with all this. >> > > People use Electrum as shorthand to mean "something a bit like the P2P > network, but with trusted remote servers which build additional databases > and thus support additional commands". Ok, thanks. So a bitcoin core node which maintains and serves additional indexes (say, an utxo index via rpc or something else) is referred to as "an electrum" even though it doesn't use electrum-server. Strange, but now I get it. So in summary: 1) I accept the library approach over the "core-wallet protocol". 2) That doesn't necessarily mean that optionally maintaining additional indexes in the core is not interesting for some use cases (interesting for bitcoind, I don't care much if electrum-server currently does this and more [with more dependencies]). Although Pieter thinks that should also be separated into an "index node" too, but I think that's another discussion. 3) The wallet doesn't currently operate as SPV and that work should be done (if there's enough interest) only after the wallet is separated from the core. -- 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] Plans to separate wallet from core
On 6/23/14, Wladimir wrote: > It's least surprising if the wallet works as a SPV client by default. > Then, users can use it without first setting up a core. Thus the idea > would be to use P2P primarily. So first bitcoind will support SPV mode then we separate the wallet? Are the core and the wallet share any code (say, the p2p messages via a sub-repo or something)? > There could be a mode to use a trusted core by RPC for > mempool/conflicted transaction validation and such. But I'm not sure > about this - as we've seen, pure-SPV wallets work pretty well. If you > want it to act as an edge router you can point a SPV wallet at your > trusted core as well. I thought we would first separate wallet from core (maintaining the full-node wallet status) and then implement an optional SPV mode for the core (and transitively for "qt-wallet", which would support both full and SPV mode). > There are no plans for adding Electrum-like functionality to bitcoind. > There is already Electrum. Let's not reinvent any wheels. I'm sorry, but I still don't know what Electrum has to do with all this. Bitcoin companies often like to interface with the network via bitcoind nodes, what's wrong with their custom wallets consuming some optional indexes from a bitcoind node their run themselves? I'm not proposing a "bitcoind-client" similar to a electrum-client. I thought it was assumed you where still going to run both the core and the wallet and we just wanted to separate the code for better modularity. Seriously, Mike also said something about Electrum too and I'm really lost about what you people mean here. > It does not need to keep a full chain database. But it needs its own > record of the chain, headers-only + what concerns the keys in the > wallet. Why cannot consume that data from a bitcoind node that always run alongside it? I still don't get the plan but it feels like it won't look as DRY as I was expecting... -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Plans to separate wallet from core
I know there are plans to separate the wallet from the core code and I think it's a great idea that will result in cleaner and more modular software. But it seems like my assumptions on how this would be done may be incorrect. I was assuming that the wallet would consume data from a trusted bitcoind core node using rpc or a better interface like an http rest api (see PR #2844). So the core would take care of the hard consensus stuff, and the wallet would maintain its own database with private keys, addresses, balances, etc. and would consume some data contained in bitcoind's database. I also assumed that the interface between wallet and core would include queries to the UTXO (see PR #4351) and maybe TXO (see PR #3652) for getting the historic balances. As said, I'm not sure these assumptions are true anymore so I ask. Is this the plan? Is the plan that the wallet will use the p2p directly and maintain its own chain database? Well, it's something that generally interests me so if anyone can detail the steps for separating the wallet a little bit, maybe I can help with some of the steps. Maybe there's no roadway yet. In that case I would like to advance that discussion in this thread. -- Jorge Timón -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
On 6/16/14, Mike Hearn wrote: > If they decide to change to something like highest-fee-always-wins, then > they (again) centralise things by forcing all instant transactions to pay > GreenAddress and its competitors money - much though I like your product > Lawrence, let's hope they don't collectively lemming us all off a cliff by > doing that ;) Replace-by-fee doesn't imply the use of green addresses (there's other solutions to 0 conf transactions in that context, for example, "scorched earth"). And giving up the non-enforceable first-seen default mining policy doesn't mean "giving up on the Bitcoin experiment" either. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
Does it make sense to implement a generic Policy interface (abstract class) which StandardPolicy extends? Maybe you can then implement a WhitelistPolicy, ReplacebyFeeStandardPolicy, ReplacebyFeeWhitelistPolicy... This would make it simpler for miners to implement their own policies in general. The following functions (maybe more) could become methods of Policy: script IsStandard main IsStandardTx main AcceptToMemoryPool -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/24/14, Mike Hearn wrote: > You can't disentangle the two. Proof of work just makes a block chain hard > to tamper with. What it contains is arbitrary. Honest miners build a block > chain that's intended to stop double spending. Dishonest miners don't. > They're both engaging in proof of work, to different ends. Yes, you can disentangle replace-by-fee policies from "rewriting history" attacks. That's exactly what I'm saying. Proof of work is the most important thing that makes the blockchain hard to tamper with. >> Whatever, let's keep calling stupid miners "honest miners" >> > > No, let's not. Your definition of "smart miner" is one I'd called "stupid > miner" (or possibly "short bitcoin miner"). They are miners who would > reduce the value of their coins, by making their own system less useful. > That's not smart, that's simply short termism taken to an extreme, sort of > like a business owner who puts so much pressure on his employees they all > quit. He might have gained a bit more profit in the short term, but only at > the cost of destroying his business that would have given lower but > sustainable returns over the long term. Whatever, pick the terms yourself but let's just stick to the same ones, please. I've read this argument before, but I simply don't buy it because I disagree with the premise that replace-by-fee reduces the value of the coins (not to mention we shouldn't assume miners stock coins for long). I think replace-by-fee policies are actually an improvement over first-saw-first-included policies. >> This persistent argument from authority is annoying. >> > > Peter always says this too, but it's again an incorrect position. This is > not an argument from authority. I don't know about other occasions with other people but what you just used with me was an argument from authority fallacy. Now you're using a false analogy to try to convince us you didn't. If I was saying "we should change the maximum from 21 M to 100 M because mining subsidies could continue for longer". "Mining subsidies aren't necessarily a good thing" or "That's no justification for a hardfork" or "That could destroy people's confidence in the currency" would be logical arguments. "No, because Satoshi picked 21 M" would be an argument from authority fallacy. >> That's not what I'm saying. Miners that don't mine on top of the >> longest chain are dishonest by my own definition as well. >> > > Right, but I don't accept this definition of honesty. That's not a > definition any man on the street would use: Whatever let's use whatever definitions you want, if I don't like your definition of honesty I will just invent a new term to define my own. > "If you pay for something with forged bank notes and walk out > immediately, you are honest. But if you pay for something with forged bank > notes and hang around for longer than 10 minutes, you are dishonest" Sorry, I don't see the analogy. > That would sound silly to anyone because what's so special about 10 > minutes? It's the act of passing counterfeit money and stealing from the > merchant that's the dishonest act, how long it takes is irrelevant. 10 minutes is what Satoshi picked. Just kidding... > In Bitcoin, the dishonest act by the user is signing for the same output > twice (ignoring special protocols here), and the dishonest act by the miner > is deviating from normal behaviour for a fee to try and trick the recipient > into believing they have been paid. The exact details are something > computer scientists care about, but the average Bitcoin user would not. People need to understand that Bitcoin transactions are not instant. For instants transactions you need to rely somehow on trust, use some trust-less offchain mechanism or use a payment protocol that would make double-spending irrational (like the one described in the other thread that uses replace-by-fee). So I think miner's default behavior should be replace-by-fee. But that doesn't imply that I want miners to rewrite pow-validated history. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
On 4/24/14, Mike Hearn wrote: >> >> This scheme would discourage people from attempting a Finney attack >> because they would end up worse off if they did. >> > Phrased another way, it simply makes every block a Finney attack that > charges the maximum double spending fee possible. This doesn't solve the > problem. This solves regular double-spends, not Finney attacks, but finney attacks (which are not really the easiest attacks in the world) don't get any worse. On 4/24/14, Chris Pacia wrote: > It would work but it's an ugly hack IMO. What do people do if they don't > have extra to pay when making a purchase? I have 200 mbtc and want to buy a > 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me. > > I would much prefer the hassle of a green address notary than always having > to make sure I have double what I need to make a purchase. This scheme wouldn't be mandatory. You can still wait for confirmations or rely somehow on existing trust instead if that's better for you on that situation. > Beyond needing to double balances, what if the shop is selling me a phone > on contract? So the actual cost of the phone is lower than the real price > on the assumption of future revenue. Alice double spends (aka steals) the > phone, paying double the artifically lower cost but still making a good > saving. Bob does not end up with "nothing", he ends up in the red. Sybil attacks aside, Alice can't save anything, period. If she tries she will end up losing it all. I don't see how signing a longer term contract protects her in any way. > But there's a much simpler way to dispose with this idea. Jorge, go down to > your local bars and cafes, and ask them if they'd be willing to accept a > form of payment that allows anyone to steal from them by simply paying > double the purchase price to some other random guy. They *will* look at you > as if you're crazy. Why would they ever do that? They would do that to avoid having to wait for a confirmation or two (I think one is good enough for most small purchases) when being paid by people they don't trust just before they leave. Maybe they prefer to just make people wait if they think that will make them pay up-front. This is completely optional and only an improvement on the current situation. Of course if we're not comparing this with Bitcoin today and we're comparing it to some theoretical mechanism for instant p2p serialization without requiring proof of work then, yes, this concept is not very interesting. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
On 4/24/14, Peter Todd wrote: > ... > With replace-by-fee scorched-earth the success rate of such > double-spends would be significantly reduced as the attacker would need > to get lucky with bad propagation not just once, but twice in a row. Interesting. >> Replace-by-fee and child-pays-for parent cannot be prohibited by a >> protocol rule. >> I believe all miners will eventually implement these policies because >> it is the more rational way for them to prioritize transactions. >> Finally I hope they do because it would make 0-confirmation >> transactions possible as described in this post. >> So I can't find any reasoning against replace-by-fee unless my example >> is terribly flawed. >> Am I missing something? > > A few things: > > 1) Replace-by-fee doesn't protect against sybil attacks; only No worse than the current situation. > 2) Replace-by-fee scorched earth does require you to keep private keys > online to sign the replacements. Not a big deal, but it's yet another > reason why you wouldn't want to use it for high-value stuff. High-value transactions should wait for several confirmations. > 3) It doesn't directly solve finney attacks(1) where the miner mines the > transaction in private. However finney attacks are only relevant if > there is high centralization of hashing power, and all other proposed > mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to > decentralization. (just look at how coinbase reallocation lets large > pools bully smaller miners out of business by blacklisting their blocks) Again, no worse than the current situation. And regular double-spends attacks are much simpler than finney attacks. > One interesting thing with regard to finney attacks and replace-by-fee > though is that enforcing hasher visibility of the blocks they are mining > - what getblocktemplate was meant to do voluntarily - lets any hasher > detect a finney attack double-spend and broadcast it. They have a weak > incentive to do so - the scorched earth reply is a high-fee transaction > of course and pre-broadcasting transactions makes blocks propagate > faster - at which point you're back to a public double-spend. Enforcing > visibility of block contents to hashers is definitely a good thing for > decentralization. Where can I read more about "enforcing hashing visibility of block contents"? Sounds somewhat similar to p2pool to me but I'm not sure I understand it. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/24/14, Mike Hearn wrote: > No! This is a misunderstanding. The mechanism they use to prevent double > spends is to *ignore double spends*. The blocks they created indicate the > ordering of transactions they saw and proof of work is used to arrive at a > shared consensus ordering given the possibility that transactions arrived > at different times. > > I'm continually amazed at how many people seem to see the current algorithm > as the goal in and of itself, instead of an imperfect but workable means of > achieving the actual goal. I'm not saying proof of work is the goal, the goal is still p2p transaction serialization. And that's achieved through proof of work, not through "miner's honesty". > This definition of honesty is not my own, the one Bitcoin has always used. Whatever, let's keep calling stupid miners "honest miners", smart miners "dishonest-by-replace-by fee miners" and miners that do replace by fee and also hash on top of old blocks "utterly dishonest miners". > Obviously if Satoshi had wanted transactions to be double spendable by fee > in the mempool he would have made Bitcoin work that way, instead of coming > up with the nSequence based replacement scheme instead. Maybe Satoshi hadn't thought in depth about replace-by-fee when he wrote the code. Why should we care? If nSequence was a design mistake Satoshi did, should we maintain it to somehow honor him? Maybe the payment protocol shouldn't have been developed because he had some weird ideas about paying to ips? Maybe we shouldn't write any tests because he didn't do so? This persistent argument from authority is annoying. > First-seen *is* a protocol rule, as much as Set-Cookie storing data in a > browser is an HTTP protocol rule. The fact that auditing compliance with it > is harder to do than some others does not make it less of a rule. It is not a protocol rule that validators can use to discriminate the longest valid chain and therefore is not enforceable. Not even through a softfork because miners can't know which transactions other miners saw first. So if it is a protocol rule, I think it shouldn't be. > Again you are hopelessly confused. Miners that are trying to double spend > are *by definition* not making transactions irreversible, they are trying > to make transactions reversible. Miners that mine on top of the longest valid chain are helping in making transactions irreversible whether they implement a first-saw or a replace-by-fee policy. > Look at it this way. There is no inherent reason BitUndo has to undo only > Finney attacks. If it gets sufficient hash power it could offer undoing of > 1-confirm transactions too, right? Sure it'll mostly fail but that's > already a part of its business model. Sometimes it'll get two blocks in a > row and succeed. It's a very minor tweak to what they're doing. Would you > argue these miners are still useful? After all, it's impossible to be > certain after the fact that miners built on top of the "wrong" block > because forks occur naturally. That's not what I'm saying. Miners that don't mine on top of the longest chain are dishonest by my own definition as well. You want to equate replace-by-fee "dishonesty" with trying-to-rewrite-history dishonesty by saying that the transactions that "have been seen" in the network are already history and that's where we disagree. I think only what's in the chain is history and I also think that's the whole point of proof of work. And I also disagree that all the people who think this way are "hopelessly confused". We may be confused, but I think there's always hope for removing confusions provided that there's will to learn, which I think it is at least my case. > What I said is, if you believe all miners are willing to double spend for a > fee then this resolves the experiment as a failure. This is also obvious - > if you can pay miners to go back and rewrite the chain at will, Bitcoin > doesn't work. This is in fact quite polemic and thus obviously not obvious. Bitcoin works because rewriting the chain gets exponentially more expensive as time passes. > Because all miners follow this ridiculous policy, they should be willing to > fork the chain at any point to claim the higher fee on the new tx. After > ... > > Do you see now why your definition of honesty is completely broken? I see now that I may have not properly expressed myself in the earlier post since you clearly misunderstood what I meant by "smart miners". By that I mean miners implementing replace-by-fee and child-pays-for-parent policies Not miners trying to rewrite history, which I agree is about as smart as mining on top of orphan blocks. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http:/
[Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
Here is a solution to the problem of having 0 confirmation transactions that relies on game theory and most miners implementing replace-by-fee and child-pays-for-parent. This has been proposed before http://sourceforge.net/p/bitcoin/mailman/message/30876033/ I'm just going to describe the general idea in more detail. Here's a small draft on how this could work: Alice goes to Bob's store and wants to buy something cheaper than a car, say a smartphone. So Bob says, "it's 200 usd in btc, please pay me 400 usd in btc" So Alice signs a tx with 400 and no fee with her old phone and she just sends it to Bob rather than the network. Bob creates a child transaction keeping 200 and giving 199.9 (0.1 usd fee) back to Alice. But you know, Alice wants to double spend. She double spends 399.8 to herself (0.2 fee) Bob thinks "last chance", he double-spends the child: 200 to Bob, back 199 to Alice (1 usd fee). Alice is stubborn: 398 to Alice (2 usd fee). Bob is really pissed off, double spends the child: 400 in fees. So, ok, Bob lost the phone and got nothing but Alice has paid twice as she needed for the phone. Nobody's happy thus everybody's happy. This is similar to the general game theory "stag hunt" case. The payoff matrix could be something like this: Bob returns change Bob burns in fees -++--- Alice behaves + 1 , + 1- 1, + 1 -++--- Alice double-spends + 3, - 1 - 1, - 1 The game has two Nash equilibria, but cooperation is Pareto efficient. Replace-by-fee and child-pays-for parent cannot be prohibited by a protocol rule. I believe all miners will eventually implement these policies because it is the more rational way for them to prioritize transactions. Finally I hope they do because it would make 0-confirmation transactions possible as described in this post. So I can't find any reasoning against replace-by-fee unless my example is terribly flawed. Am I missing something? -- Jorge Timón http://freico.in/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/23/14, Mike Hearn wrote: >> I guess word "honest" might have different meanings, that can be a source >> of confusing. >> 1. Honest -- not trying to destroy bitcoin >> 2. Honest -- following rules which are not required by the protocol >> > > I'm using it in the same sense Satoshi used it. Honest miners work to > prevent double spends. That's the entire justification for their existence. I thought the mechanism they used to prevent double-spends was proof of work. Therefore dishonest miners where only those who mine on top of a block which is not the longest valid chain they've seen. To distinguish this definition from your own "honest miners are those who decide on double-spends by mining the transaction they saw first" definition I propose to give another new name to the later, instead of changing the definition of the former. So inside the group of honest miners we have some that decide on transactions based on reception times and others that simply maximize their revenue while respecting the protocol rules. I suggest "stupid miners" and "smart miners" respectively as more clear terms for what we're talking about here. > Miners that are deliberately trying to double spend are worse than useless. I completely disagree. Miner's proof of work makes transactions irreversible. Even if zero confirmation transactions weren't possible in a replace-by-fee environment, that's very useful. Even if you always had to wait for transactions to be confirmed with some irreversible proof of work (as described in Satoshi's whitepaper), it doesn't follow that "automatically resolves the Bitcoin experiment as a failure". I don't understand how can you conclude that. But in fact 0 conf txs are possible *precisely* using replace-by-fee, as described in the " 0 confirmation txs using replace-by-fee and game theory" thread. So that conclusion is definitely wrong. On your concrete proposal, it seems to me that you're trying to prevent double-spending without relying on proof of work, which I think it impossible in the context of a truly p2p system. I don't think your current proposal is secure and I fear that at best you will end up with an "invite only" transaction processing network like Ripple.com has with their consensus algorithm and Unique Node Lists: that's not really p2p. -- Jorge Timón http://freico.in/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
I'm not convinced that headers first will result in miners hashing on top of the block with more work without knowing if it's valid yet instead of just keep hashing on top of the longest known-to-be-valid chain. Both options are risky for the miner in some way, and I guess the probability of someone hashing an invalid block above difficulty is too low to be the main concern, but there's intermediate solutions, like say, waiting to validate at least 5% of the block. But I don't see how miners mining headers first would result in empty blocks either. Why wouldn't them validate and include transactions after they have received the full block? They will likely know most of the transaction before receiving the block anyway. In a future where they ONLY live on transaction fees, why would they refuse to validate and include transactions? What are they hashing for then? If anything, looks like a threat to the current situation with huge mining subsidies coming from the seigniorage, not a problem that you would have when the the seigniorage is gone. In any case, it is true that this is mining policy and therefore out of the realm of what the protocol can regulate, so we should assume miners will do whatever it's best for them. The trade-off between tps and centralization remains: if you want higher tx volume, less full nodes will be able to process it. On 4/21/14, Tier Nolan wrote: > On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd wrote: > >> Of course, in reality smaller miners can just mine on top of block >> headers >> and include no transactions and do no validation, but that is extremely >> harmful to the security of Bitcoin. >> > > I don't think it reduces security much. It is extremely unlikely that > someone would publish an invalid block, since they would waste their POW. > > Presuming that new headers are correct is reasonable, as long as you check > the full block within a few minutes of receiving the header. > > If anything, it increases security, since less hashing power is wasted > while the full block is broadcast. > > Block propagation could take the form > > - broadcast new header > - all miners switch to mining empty blocks > - broadcast new block > - miners update to a block with transactions > > If the block doesn't arrive within a timeout, then the miner could switch > back to the old block. > > This would mean that a few percent of empty blocks end up in the > blockchain, but that doesn't do any harm. > > It is only harmful, if it is used as a DOS attack on the network. > > The empty blocks will only occur when 2 blocks are found in quick > succession, so it doesn't have much affect on average time until 1 > confirm. Empty blocks are just as good for providing 1 of the 6 confirms > needed too. > -- Jorge Timón http://freico.in/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Timed testing
Thank you for all the explanations on how to use regtest to reproduce the example scenarios. It seems like a private mode wouldn't be particularly helpful for testing so I won't create a pull request and will just work on the private chains separately from bitcoind. Going back to chainparam modes in general, I've heard Sipa complain some times about regtest being too specific, arguing that some of the behaviors should be specified as independent parameters instead of chainparams attributes. One example could be bool CChainPrams::MineBlocksOnDemand() (see https://github.com/jtimon/bitcoin/commit/5bd4bc7f3694e46568c9276f0cb26402dfb99718 ). If that was an independent parameter that people set to true when using regtest, the blocktime param I was proposing for -timedtest could also be implemented as an independent parameter without any need for a new mode. It's not clear to me if the timedtest parameter would be useful for bitcoind testing or not, but it's just something I've noticed while playing with this part of the code. Sipa, is this the kind of thing you refer to when you say regtest is too specific? Do you have any suggestion on how to solve the issue as part of PR 3824? Well, any suggestions from anyone on how to improve PR 3824 are welcomed, I was just asking specifically to sipa because as said it is my understanding that he had some complaints about regtest and I think this is something simple enough for me to start contributing to bitcoind. Specially given that I was going to review all that part of the code to externally write the private mode anyway. -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Timed testing
On 4/17/14, Mike Hearn wrote: >> >> 2) If I wanted to measure validation performance, to get the number of >> peak tps that could be processed without taking block sides or network >> latency into account, how would I do that? Has anybody tried this >> before? > > > You can just reindex/replay the chain. It's been done many times. Yes, thank you. I guess that's what everybody is doing to measure validation performance. So I guess the timedtest mode doesn't make much sense, at most only as the blocktime parameter defaulting to zero. If bool MineBlocksOnDemand() gets refactored out of ChainParams into a parameter (maybe just use genproclimit ?), you can have the periodic block generation and the generation on demand reusing the same regtest mode. So it seems a new mode only makes sense if the -private mode makes sense, which in turn only makes sense to include in bitcoind if it's useful enough for the network attack simulations, which remains the open question. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Timed testing
On 4/17/14, Gavin Andresen wrote: > How is this different from just running in -regtest mode and asking the > nodes to generate a block after 1 or 2 seconds? There's no difference, the -timedtest mode does exactly that. But automatically instead of having to manually ask for a new block every second. I assume your position is that the difference is too small to justify a new mode, or that you just don't see any value in it. The -private mode, on the other hand, would allow you to simulate proof of work attacks as described in the previous post, but maybe there's a simpler way to do the same solely using regtest/timedtest. Maybe I should have asked the following questions before proposing anything: 1) How does someone simulate a pow race situation without doing any pow right now? Does anybody try these things? How? 2) If I wanted to measure validation performance, to get the number of peak tps that could be processed without taking block sides or network latency into account, how would I do that? Has anybody tried this before? -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Timed testing
I'm implementing a new testing mode that produces blocks periodically. You can get what I have so far here: https://github.com/jtimon/bitcoin/tree/timed It depends on pull request #3824 with some improvements on CChainParams, but after that the changes required to add this new mode are very small: https://github.com/jtimon/bitcoin/commit/445321928a143cb9a6f56777cbb7479dd32c3bcd I guess I need a new genesis block, different magic numbers, etc. So this is definitely not ready. You can run it like this: bitcoind -timedtest -gen=1 blocktime=2000 blocktime defaults to 1000 milliseconds for timedtest mode and 0 for the rest of the modes. What could this testing mode be useful for? Basically, simulations. For example, you could run several nodes implementing different mining policies. Let's say I want to mine 50% of the blocks with standard policy, 25% with policy A and 25% with policy B. I can run 1 one for each of one with block times 2000, 1000 and 1000 respectively. Maybe I want to detect performance bottlenecks by stressing this mode with as many transaction as can be processed, maybe removing the block size limits in the simulations. But this still doesn't serve for hardfork or double-spend attacks simulations without calculating any pow, which would be another interesting feature for a new testing mode. I would like to implement the new mode following as the concept of private chains described in freimarkets: http://freico.in/docs/freimarkets.pdf https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#off-chain-transactions I know this could be considered a "non-bitcoinish" application and therefore be controversial as discussed in PR 3824, so I want to keep the conversation focused on testing use cases useful to bitcoin itself only: additional changes can be implemented elsewhere. One way I think you could support chain races simulations by using a private mode could be the following: 1) The private mode works like the timed mode in how often it produces blocks. 2) In private mode you replace the pow-related fields with a blockPubkeyScript and a lastBlockSigScript fields. In the genesis block, lastBlockSigScript is empty and the initial blockPubkeyScript can be an optional parameter like blocktime. You can set any valid script, probably p2sh, maybe with multisig to allow different nodes to sign. 3) In this context, longer chains mean "more work". Another way to see it is that all blocks just contain work==1 in them. So let's say we want to simulate an attack using 50% standard and 50% attacker blocks. You set up the private mode script to be a 1 of 2 multisig and make each node sign always with the same private key (maybe an additional parameter). You make the attacker reject any blocks from height X that he hasn't signed himself to get the result you wanted: the standard node will produce blocks on top of the longest chain while the attacker will only hash on top of his own blocks. So my question to the community is, how invasive is this to bitcoin's source code? In my opinion, done properly could actually result (apart from getting the new features) in more readable code, not less, since you will probably need to make sure proof of work functionality is properly encapsulated during the implementation process (see PR 3839 for a first step on that direction). But, should I push a private mode to the core or just the timed one and implement the private mode elsewhere? Of course other comments on the parameters, defaults or any other design or implementation details are also welcomed. -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
On 4/7/14, Flavien Charlon wrote: > Ok, I guess I'm not using the proper terminology. It would be listed on the > "Asset" section of the company's balance sheet, is what I meant. No, it's an asset for the owner of the share, not the company, just like the gold plates are not assets for the company when someone else holds them. What you're doing is getting less capital for the company due to the money that is going to pay the gold costs. Are you rising capital or selling gold? It doesn't make sense to do both at once. You need money, why would you spend money on gold before asking for other people's money to build your company? Investors will appreciate the convenience of being able to buy shares of your company and gold separately (or not buy gold at all). It may even be more clear for other use cases different than stocks. Does an IOU written in a gold plate make sense to you? -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
On 4/7/14, Flavien Charlon wrote: > Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become > part of the capital of the company, and can always be recovered by > uncoloring the shares. It's an investment, not an expense, so I think it is > acceptable. This doesn't make much sense to me. If you print shares on gold plates instead of paper, is that gold "part of the capital of the company"? I don't think so. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On 4/5/14, Matt Whitlock wrote: > On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote: >> I like both DD-MM- and -MM-DD. I just dislike MM-DD- and >> -DD-MM. > > Your preferences reflect a cultural bias. The only entirely numeric date > format that is unambiguous across all cultures is -MM-DD. (No culture > uses -DD-MM, or at least the ISO seems to think so.) Probably my acceptance of DD-MM- is caused by cultural bias. The ISO -MM-DD seems what you normally do with indo-arabic numerals: put the more weighted numbers on the left, so I guess it's the most universal (in addition to being standard). -- Jorge Timón http://freico.in/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
I like both DD-MM- and -MM-DD. I just dislike MM-DD- and -DD-MM. On 4/4/14, Jeff Garzik wrote: > On Fri, Apr 4, 2014 at 3:01 AM, Wladimir wrote: >> Personally I'd prefer to standardize on ISO 8601 (-MM-DD) dates as >> well. > > +1 for all-numeric, easily computer parse-able without a lookup table, > and naturally sorts correctly in a lexicographic sort. > > English (or any language) should never be in a date format, on a computer. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jorge Timón http://freico.in/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On 4/1/14, Matt Corallo wrote: > Also, should we really do this with a soft fork when we can take this > opportunity to redesign the whole system with a hard fork? This is out > chance to switch to a whole new script engine! +1 The hard fork also forces the whole community and not a few miners to decide. Well, if it is possible for the community to reach an agreement with such a short time frame... > Matt > > On April 1, 2014 3:00:07 PM EDT, Pieter Wuille > wrote: >>Hi all, >> >>I understand this is a controversial proposal, but bear with me please. >> >>I believe we cannot accept the current subsidy schedule anymore, so I >>wrote a small draft BIP with a proposal to turn Bitcoin into a >>limited-supply currency. Dogecoin has already shown how easy such >>changes are, so I consider this a worthwhile idea to be explored. >> >>The text can be found here: https://gist.github.com/sipa/9920696 >> >>Please comment! >> >>Thanks, >> >>-- >>Pieter >> >>-- >>___ >>Bitcoin-development mailing list >>Bitcoin-development@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jorge Timón http://freico.in/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
I'll make sure I understand your proposal better before commenting much on it, but at a first glance, I don't see how it is incompatible with 2 way peg and merged mining itself. Why wouldn't you want merged mining for the root of your tree? A miner could only chose a leaf block at a time, but it could merged mine with other leafs in other independent trees. Anyway, I'll better comment on the 2 way peg and merged mining issues raised so far. On 3/25/14, Gregory Maxwell wrote: > On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach wrote: >> More importantly, to your last point there is absolutely no way this >> scheme can lead to inflation. The worst that could happen is theft of >> coins willingly put into the pegging pool. But in no way is it possible >> to inflate the coin supply. > > I don't think it would be entirely unfair to describe one of the > possible ways a secondary coin becoming unbacked can play out as > inflation-- after all, people have described altcoins as inflation. In > the worst case its no _worse_ inflation, I think, than an altcoin is-- > however. I think that's an obscure corner case that is not likely going to ever be implemented. If you produce real inflation there will likely be a "bank run". If you're going to implement something equivalent to demurrage you should call it demurrage instead of inflation. And that's only for the pegged coin in the side chain: BITCOINS IN THE MAIN CHAIN WILL NEVER BE INFLATED USING 2P2. So I think it's less confusing if we just say that 2-way peg can't produce inflation in general, and leave "unless you explicitly introduce an inflation mechanism" as a probably unnecessary clarification. > I see your point, but gmaxwell accurately guesses below that when I'm > talking about inflation, I'm including the inflation of the alt too. You don't need inflation on the side chain. You don't need to create another currency to create another chain with different and maybe experimental features, that's the whole point. With merged mining, you're adding up the different created seigniorage subsidies to the same fire to share the heat. With 2-way peg, you don't even need to create a new p2p currency with a seigniorage to burn on hashes or be accused of "pre-mining" as the more ecological alternative in existence. Your chain can secure itself on fees, just like bitcoin in the future. Merged mining will help, but it's not the panacea and you will need to reward miners because that's what your security ultimately depends on. This is mostly about not burning the world, it may not be as interesting to you as improving bitcoin's scalability but you're not doing anyone a favor by presenting both concepts as being incompatible, not even yourself. > With tree-chains that's particularly obvious as the scheme doesn't try > to privilege one chain over another beyond parent-child relationships. If I understand it correctly, all the utxo nodes in the tree implement the same rules so doesn't seem suitable to solve the same problems. I understand that merged mining IS NOT a solution to scalability on its own, having 10 independent 1MB blocks is no worse than 1 10MB block in terms of performance vs centralization. But maybe it's possible to have a 10 GB sharded side-chain (your proposal) that it's merged mined with the main chain and where the currency of the side-chain comes from. So merged mining could help solve the scalability problem indirectly. And 2-way peg could be a useful previous step for your proposal to be deployed "on production", with real bitcoins without forcing all bitcoin users to take the associated risks, only the people who opt in. > Incidentally, I understand that the pegged chains are meant to be > merge-mined. 2 way peg doesn't require merged mining but it is assumed that merged mining will be used since it provides more security than independent mining. I thought you agreed with this and your claim was just that merged mining is less secure than "embedded consensus", something I have never denied, my complain against "embedded consensus" is that it doesn't seem to scale (with Bitcoin as it is today) and can't offer many features that a hardfork merged mined chain could offer (like those explained on our freimarkets proposal). But since you're implying again that "merged mining is superior to independent mining" is generally false, I invite you again to dismantle my example http://sourceforge.net/p/bitcoin/mailman/message/31806950/ or to prove your hypothesis that "is free to attack merged mining chains" by attacking namecoin for free. Either one will serve, my you're not responding to any of the suggestions. Instead, you're saying that "people defending merged mining assume that attackers are economically rational". I think you're referring to me and it's false. Of course the attacker doesn't need to be economically rational. For some unknown reason he's attacking a chain, without questioning the rationality of the attack, I just sum costs, inc
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On 3/22/14, Peter Todd wrote: > Well remember that my thinking re: UTXO is that we need to move to a > system like TXO commitments where storing the entirety of the UTXO set > for all eternity is *not* required. Of course, that doesn't necessarily > mean you can't have the advantages of UTXO commitments, but they need to > be limited in some reasonable way so that long-term storage requirements > do not grow without bound unreasonably. For example, having TXO > commitments with a bounded size committed UTXO set seems reasonable; old > UTXO's can be dropped from the bounded sized set, but can still be spent > via the underlying TXO commitment mechanism. Although not having to download the whole blockchain to operate a trust-less full node is theoretically possible it is not clear that they will work in practice or would be accepted, and we certainly don't have that now. So I don't think future potential theoretical scalability improvements are solid arguments in favor of supporting proof of publication now. > Like I said the real issue is making it easy to get those !IsStandard() > transactions to the miners who are interested in them. The service bit > flag I proposed + preferential peering - reserve, say, 50% of your > peering slots for nodes advertising non-std tx relaying - is simple > enough, but it is vulnerable to sybil attacks if done naively. My point is that this seems relevant to competing mining policies in general. > Right, but there's also a lot of the community who thinks > proof-of-publication applications are bad and should be discouraged. I > argued before that the way OP_RETURN was being deployed didn't actually > give any reason to use it vs. other data encoding methods. > > Unfortunately underlying all this is a real ignorance about how Bitcoin > actually works and what proof-of-publication actually is: I understand that proof of publication is not the same thing as regular timestamping, but requiring permanent storage in the blockchain is not the only way you can implement proof of publication. Mark Friedenbach proposes this: Store hashes, or a hash root, and soft-fork that blocks are only accepted if (a) the data tree is provided, or (b) sufficient work is built on it and/or sufficient time has passed This way full nodes can ignore the published data until is sufficiently buried. > I think we're just going to have to agree to disagree on our > interpretations of the economics with regard to attacking merge-mined > chains. Myself, I'm very, very wary of systems that have poor security > against economically irrational attackers regardless of how good the > security is, in theory, against economically rational ones. The attacker was of course economically irrational in my previous example for which you didn't have any complain. So I think we can agree that a merged mined separated chain is more secure than a non-merged mined separated chain and that attacking a merged mined chain is not free. By not being clear on this you're indirectly promoting non-merged mined altchains as a better option than merged mined altchains, which is what I don't think is responsible on your part. > Again, what it comes down to in the end is that when I'm advising > Mastercoin, Counterparty, Colored Coins, etc. on how they should design > their systems I know that if they do proof-of-publication on the Bitcoin > blockchain, it may cost a bit more money than possible alternatives per > transaction, but the security is very well understood and robust. Fact > is, these applications can certainly afford to pay the higher > transaction fees - they're far from the least economically valuable use > of Blockchain space. Meanwhile the alternatives have, at best, much more > dubious security properties and at worse no security at all. > (announce/commit sacrifices is a great example of this, and very easy to > understand) I agree that we disagree on additional non-validated data in the main chain vs merged mined chains as the best way to implement additional features. But please, you don't need to spread and maintain existing myths about merged mining to make your case. If you insist on doing it I will start to think that the honesty of your arguments is not something important to you, and you just prefer to try to get people on your side by any means, which would be very disappointing. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On 3/22/14, Peter Todd wrote: > There's been a lot of recent hoopla over proof-of-publication, with the > OP_RETURN length getting reduced to a rather useless 40 bytes at > the last minute prior to the 0.9 release. I'm not against about miners accepting transactions that have longer data in non-utxo polluting OP_RETURN than whatever is specified as standard by the reference implementation, maybe it should be risen in standard but I think it was assumed that the most common case would be to include the root hash of some "merklized" structure. My only argument against non-validated proof of publication is that in the long run it will be very expensive since they will have to compete with transactions that actually use the utxo, a feature that is more valuable. But that's mostly speculation and doesn't imply the need for any action against it. I would strongly opposed to against a limitation on OP_RETURN at the protocol level (other than the block size limit itself, that is) and wouldn't mind if they're removed from isStandard. I didn't payed much attention to that and honestly I don't care enough. Maybe this encourages miners to adopt their own policies, which could be good for things like replace-by-fee, the rational policy for miners, which I strongly support (combined with game theory can provide "instant" transactions as you pointed out in another thread). Maybe the right approach to keep improving modularity and implement different and configurable mining policies. > All these methods have some overhead compared to just using OP_RETURN > and thus cost more. I thought the consensus was that op_return was the right way to put non-validated data in the chain, but limiting it in standard policies doesn't seem consistent with that. > Finally I'll be writing something more detailed soon about why > proof-of-publication is essential and miners would be smart to support > it. But the tl;dr: of it is if you need proof-of-publication for what > your system does you're much more secure if you're embedded within > Bitcoin rather than alongside of it. There's a lot of very bad advise > getting thrown around lately for things like Mastercoin, Counterparty, > and for that matter, Colored Coins, to use a separate PoW blockchain or > a merge-mined one. The fact is if you go with pure PoW, you risk getting > attacked while your still growing, and if you go for merge-mined PoW, > the attacker can do so for free. We've got a real-world example of the > former with Twister, among many others, usually resulting in a switch to > a centralized checkpointing scheme. For the latter we have Coiledcoin, > an alt that made the mistake of using SHA256 merge-mining and got killed > off early at birth with a zero-cost 51% attack. There is of course a > censorship risk to going the embedded route, but at least we know that > for the forseeable future doing so will require explicit blacklists, > something most people here are against. The "proof of publication vs separate chain" discussion is orthogonal to the "merged mining vs independent chain" one. If I remember correctly, last time you admitted after my example that merged mining was comparatively better than a separate chain, that it was economically harder to attack. I guess ecological arguments won't help here, but you're confusing people developing independent chains and thus pushing them to a less secure (apart from more wasteful setup) system design. Coiledcoin just proofs that merged mining may not be the best way to bootstrap a currency, but you can also start separated and then switch to merged mining once you have sufficient independent support. As far as I can tell twister doesn't have a realistic reward mechanism for miners so the incentives are broken before considering merged mining. Proof of work is irreversible and it's a good thing to share it. Thanks Satoshi for proposing this great idea of merged mining and thanks vinced for a first implementation with a data structure that can be improved. Peter Todd, I don't think you're being responsible or wise saying nonsense like "merged mined chains can be attacked for free" and I suggest that you prove your claims by attacking namecoin "for free", please, enlighten us, how that's done? It should be easier with the scamcoin ixcoin, with a much lower subsidy to miners so I don't feel bad about the suggestion if your "free attack" somehow works (certainly using some magic I don't know about). -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written
Re: [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
Some comments. On 3/16/14, Adam Back wrote: > 6. a fraud proof is an SPV proof with a longer chain showing that the proof > of burn was orphaned. As discussed, "reorg proof" it's a more appropriate term since the reorg can happen without any fraud. It also prevents the term from being confused with the fraud proof that auditors (full nodes that can't create blocks) produce for private chains. > Apart from pegging from bitcoin to a side-chain, if a private chain is made > with same rules to the side-chain it becomes possible with some > modifications to the above algorithm to peg the side-chain to a private > chain. Private chain meaning a chain with the same format but signature of > single server in place of hashing, and timestamping of the block signatures > in the mined side chain. And then reactive security on top of that by full > nodes/auditors trying to find fraud proofs (rewrites of history relative to > side-chain mined time-stamp or approved double-spends). The reaction is to > publish a fraud proof and move coins back to the side chain, and then > regroup on a new server. (Open transactions has this audit + reactive > model > but as far as I know does it via escrow, eg the voting pools for k of n > escrow of the assets on the private server.) I also proposed the same > reactive audit model but for auditable namespaces [4]. > > Private chains add some possiblity for higher scaling, while retaining > bitcoin security properties. (You need to add the ability for a user to > unilaterally move his coins to the side-chain they came from in event the > chain server refuses to process transactions involving them. This appears > to be possible if you have compatible formats on the private chain and > side-chain). In this case you can't require a side chain proof of burn to move back to the side chain or the funds could be locked by the dishonest private chain operator (accountant in freimarkets[1] terminology). By allowing unilateral withdrawals, you impose on the private chain the task of observing the side chain looking for double-spends, censoring those transactions or maybe updating its committed utxo when it has proofs that the coins have been withdrawn. [1] http://freico.in/docs/freimarkets.pdf https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 3/13/14, Mike Hearn wrote: >> >> You would only need to change it if there was a sub-satoshi hardfork, >> which doesn't seem necessary anytime soon. >> > > + > > We shouldn't make any assumptions about the future price of bitcoin to make >> the decision. >> > > Hmmm ;) Didn't you just make an assumption about the future price? You can just remove my assertion about the likeliness of the need of sub-satoshis and the main claim still stands. > The currencies I'm familiar with are CHF, USD, EUR and GBP, which all have > roughly similar values. I guess such currencies make up the bulk of the > Bitcoin userbase at the moment. Fair enough, not US-centric but western-centric then. In any case the "3000 micros will look like expensive" claim is still very relative. >> "People seem to like mBTC" is just an ad populum fallacy: millions of >> flies can actually be wrong. Also you haven't showed them micros, >> maybe they like it too. > > > Saying "it's already popular and would take work to change" is not really a > fallacy now, is it? No, it's not. That's what I said the current adoption by some wallets and services was the only valid argument immediately after dismantling the actual fallacy. Did you missed that last sentence or are you intentionally using a straw man argument? In summary, yes, that's point is valid, I'm not saying it isn't. I just wanted to keep us away from the rest argument but pointing out they are not logic. I repeat, that's the ONLY valid argument I've heard so far. -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 3/13/14, Troy Benjegerdes wrote: > > > Every volatility bump messes up expectations of what a bitcoin is worth, > so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC > now, and plan uBTC for just after the next price spike to $10KUSD or > whatever, > and then plan on rolling back to mBTC when the price crashes from altcoin > money supply inflation competition. No, even if bitcoin crashes to 1 usd you don't need to change back to BTC, you can keep the existing-accounting-tools friendly micro. That's the whole point, having "one true only unit change". You would only need to change it if there was a sub-satoshi hardfork, which doesn't seem necessary anytime soon. On 3/13/14, Mike Hearn wrote: > I think it is highly optimistic to assume we'll need another 1000x shift > any time soon. By now Bitcoin isn't obscure anymore. Lots of people have > heard about it. Getting from $1 to $1000 was amazing, but it was possible > through huge media coverage. Getting from $1000 to $1,000,000 would take > massive adoption of the kind Bitcoin isn't ready for yet. We shouldn't make any assumptions about the future price of bitcoin to make the decision. On 3/13/14, Mike Hearn wrote: >> >> Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying >> than 3123.45 uBTC. >> > > This is subjective though. To me the first price looks like the price of a > cup of coffee (or I just mentally double it). The second looks like the > price of an expensive holiday. This sounds very US-centric to me. Aren't you thinking in usd? It won't look like an expensive holiday to, say, someone used to Viet Nam Dong (VND), Uzbekistani Som (UZS) or Mongolian Tugrik (MNT). http://coinmill.com/BTC_calculator.html#BTC= 0.00312345 "People seem to like mBTC" is just an ad populum fallacy: millions of flies can actually be wrong. Also you haven't showed them micros, maybe they like it too. So the only valid argument I've heard in favor of mBTC so far is "some wallets/services are doing it wrong already". -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
nt for investing in my >> >> > own >> >> > mining hardware so I can be sure to trade reliably. >> >> > >> >> >> Again, you haven't addressed why the seller cares more about >> >> >> "accurate >> >> >> historic market data" than just his own fees and sell. >> >> >> >> >> >> > You mean a reverse nLockTime that makes a transaction invalid >> >> >> > after a >> >> >> > certain amount of time - that's dangerous in a reorg unfortunately >> >> >> > as >> >> >> > it >> >> >> > can make transactions permenantly invalid. >> >> > >> >> > People who take money from buyers and sellers care most about >> >> > 'accurate >> >> > historic market data'. I just want to exchange my corn for e85, >> >> > fertilizer, >> >> > and electricity, and audit the code that runs accounting for the >> >> > exchange. >> >> > >> >> > I really don't give a shit if there is 'accurate historic market >> >> > data' >> >> > as >> >> > long as **MY** personal trade data is accurate and I got a good >> >> > enough >> >> > price, >> >> > and I know who I'm dealing with. >> >> > >> >> > I know someone smarter than me and with more money, market leverage, >> >> > and >> >> > political connections **WILL** game the system and distort the >> >> > market >> >> > data >> >> > history so they can take more money from buyers and sellers without >> >> > actually >> >> > doing some usefull market function. >> >> > >> >> > As long as use buyers and sellers can see the code, and have a good >> >> > eye >> >> > for >> >> > knowing when someone's pushing the market around, we can just put >> >> > our >> >> > orders >> >> > in and relieve some speculators of their money. >> >> > >> >> > Just get me working code for cross-chain trades, and we'll work on >> >> > the >> >> > accurate historic data problem later. >> >> > >> >> > >> >> > >> >> > Troy Benjegerdes 'da hozer' >> >> > ho...@hozed.org >> >> > 7 elements earth::water::air::fire::mind::spirit::soul >> >> > grid.coop >> >> > >> >> > Never pick a fight with someone who buys ink by the barrel, >> >> > nor try buy a hacker who makes money by the megahash >> >> > >> >> > >> >> > >> >> > -- >> >> > Flow-based real-time traffic analytics software. Cisco certified >> >> > tool. >> >> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow >> >> > Analyzer >> >> > Customize your own dashboards, set traffic alerts and generate >> >> > reports. >> >> > Network behavioral analysis & security monitoring. All-in-one tool. >> >> > >> >> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >> >> > ___ >> >> > Bitcoin-development mailing list >> >> > Bitcoin-development@lists.sourceforge.net >> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> >> >> >> >> >> -- >> >> Jeff Garzik >> >> Bitcoin core developer and open source evangelist >> >> BitPay, Inc. https://bitpay.com/ >> >> >> >> >> >> -- >> >> Flow-based real-time traffic analytics software. Cisco certified tool. >> >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> >> Customize your own dashboards, set traffic alerts and generate >> >> reports. >> >> Network behavioral analysis & security monitoring. All-in-one tool. >> >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >> >> ___ >> >> Bitcoin-development mailing list >> >> Bitcoin-development@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> >> -- >> Jeff Garzik >> Bitcoin core developer and open source evangelist >> BitPay, Inc. https://bitpay.com/ > > -- > > Troy Benjegerdes 'da hozer' > ho...@hozed.org > 7 elements earth::water::air::fire::mind::spirit::soul > grid.coop > > Never pick a fight with someone who buys ink by the barrel, > nor try buy a hacker who makes money by the megahash > > > -- > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jorge Timón http://freico.in/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
On 2/28/14, Peter Todd wrote: > As usual, you don't need a hardfork. > > Anyway, one-sided trade is sufficient to get a functioning marketplace > up and running and test out the many other issues with this stuff prior > to forking anything. I'm totally FOR experimenting with this as it is and I'm happy that Alex/Killerstorm is working on "regular" colored coins. > You can make the same argument against Bitcoin itself you know... > > A Bitmessage-like network would be trivial to front-run via a sybil > attack. It's the fundemental problem with marketplaces - the data > they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about "front running" those parallel networks. I've seen many street markets without "public information" and they work just well. >> I don't think this will be a tragedy, because like we discussed on >> IRC, I don't think the primary goal of markets is price discovery, but >> trade itself. >> >> About historic data, the actual trades are always public, and some >> kind of "archivers" could collect and maintain old orders for historic >> bid and asks, etc. > > And again, how do you know that record is honest? Fact is without > proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. Again, you haven't addressed why the seller cares more about "accurate historic market data" than just his own fees and sell. > You mean a reverse nLockTime that makes a transaction invalid after a > certain amount of time - that's dangerous in a reorg unfortunately as it > can make transactions permenantly invalid. Yes, I'm aware this is a concern for many people and that's why I bring it up when there's an useful use case (we have several important uses in freimarkets). Probably this belongs to another thread or just #wizards, but if I remember correctly, the last discussion we had about this, I think with you and gmaxwell, was more or less like this: -Valid transactions could get invalid with a regorg -Just like with any transaction if a double-spend appears, this just means that you would need to wait for expiry transactions to be somewhat buried to accept payments from it. -That introduces fungibility problems. -True, but doesn't seem a particularly difficult problem (I think we actually drafted some potential solutions, like introducing a maturity rule for expiry transactions) and the advantages outweigh that potential problem IMO. So in summary, I feel like before actually solving the problem we need to rise more awareness on how nice and necessary nExpiryTime would be. Anyway, sorry, I just wanted to point out another use, a deeper discussion about this belongs to another thread. -- Jorge Timón http://freico.in/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
First of all, sorry for the delayed answer. On 2/10/14, Peter Todd wrote: > Got this: [...] Thank you, I knew this wasn't new for us but I doubted we had written it anywhere. As said in those mails, being only able to offer AAA for BTC and not BTC for AAA nor AAA for BBB is enough of a limitation to justify a hardfork IMO. On 2/17/14, Troy Benjegerdes wrote: > Is there a simple way to do cross-chain trades that doesn't need a third > chain to somehow facilitate things? These are the two methods I know for cross-chain trading (no third chain needed in any of them): https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains https://bitcointalk.org/index.php?topic=321228 On 2/14/14, Peter Todd wrote: > You're assuming the seller cares about fairness - why should they? They > offered a price for an asset and someone bought it; exactly which buyer > willing to buy at that price was able to complete the trade is > irrelevant to them. What they do care about is being sure that at > whatever given price they offered 100% of the buyers willing to buy at > that price actually see the offer in a reasonable amount of time - at > the best price the seller will get there will be only a single buyer > after all so you need that solid proof that said buyer was actually able > to get the offer. In fact, I don't think the seller will care enough about this to pay the proof of publication fee either. Assuming sellers can either broadcast the order on a bitmessage-like network or use your proof of publication scheme, the later will be always be more expensive. So my prediction is that most people will just use the simplest, fastest and cheapest method, but I guess only time can tell. I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of "archivers" could collect and maintain old orders for historic bid and asks, etc. As an aside, nLockTime would be nice not to always have to double-spend the inputs of an order to cancel it. -- Jorge Timón http://freico.in/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
Not a lawyer, but I don't see what would prevent me from writing contracts like: "I owe the holder of this contract 10 usd" (IOU) "I owe the holder of this contract 10 usd in beer" (voucher) "I owe the holder of this p2p asset 10 usd in beer" (p2p voucher) Of course, there must be a legal contract outside of the chain for this contracts to be enforceable. Some p2p assets will have them and other's won't. Say Alice pays the dinner (20 usd) and her friend Bob pays her half of the price in p2p usd not legally enforceable IOUs issued by him (10 bob:USD). That's not legally enforceable, so what? If Bob doesn't pay back Alice would lose 10 usd and would not accept bob's IOUs anymore, much like it would had happen with a verbal IOU. The difference is that Alice can sell those bob:USD to other people who trust Bob. Different p2p assets have different legal needs. In any case, I think Peter summarized it very well: "[...]no amount of code can, **by itself**, make data represent a physical or legal entity. Only consensus and/or authorities in the "real world" can do that." On 2/9/14, Troy Benjegerdes wrote: >> > The only 'assertion' of central authority here is people who download >> > and >> > run the code and submit to whatever the code asserts they are supposed >> > to do. >> > >> > At least with the 'central authority' of the big-business bitcoin >> > developer >> > cabal I can read the code before I submit to it's central authority, >> > and >> > this is a significant improvement over amgibuous legislation or >> > proprietary >> > high-frequency trading algorithms. >> >> Standard Disclaimer: Digital asset transfer systems are fundementally >> fancy accounting systems; no amount of code can, by itself, make data >> represent a physical or legal entity. Only consensus and/or authorities >> in the "real world" can do that. Crypto-currencies are only a partial >> exception to that rule, and only because a scarce asset that can be >> transferred digitally appears to have potential to be broadly useful. > > How do I document in the embedded consensus system what the ruling in > a small-claims court about the ownership of a contested asset was? > > Good accounting systems (such as mercurial, and proper double-entry > financial accounting tools) allow reverting a bad commit, or bad data > entry, while maintaining records of the history. Not as good accounting > systems (like git) allow you to re-write history. What's the equivalent > user interface, process, and wire protocol for reversing a fraudulent > transaction while maintaining a full audit trail? > > Courts can't legislate our code, and we can't expect them to download > and trust our 'distributed de-centralized' digital asset tracking system > that will be downloaded from a single centralized developer website > unless we meet them at least halfway, and probably need to propose model > municipal and county ordinances that go along with our code releases. > >> Those considering investing in or otherwise devoting resources to the >> creation of digital asset transfer systems should be warned that their >> value in general remains unproven and losing some or all of your >> investment is very possible, even probable. I myself have doubts that >> these systems serve real-world business needs, but the only way to find >> out is to build them and see. > > I would agree 100% that we need to build them, test the code, use them, > and then *try them in court*, and make sure we can explain in very simple > plain language what an 'embedded consensus system' is to the distributed > de-centralized local court systems. > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jorge Timón http://freico.in/ -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.
fore it gets released. >>> It's not a big problem. When the network load is low, the fee required >>> for a tx to be included should be lower, allowing for smaller Jumbo >>> transactions. When the network load is high, it takes less time to fill >>> a Jumbo transaction. >>> >>> References: >>> Increasing the Network Hashing Power by reducing block propagation time >>> https://bitcointalk.org/index.php?topic=145066.0 >>> >>> CoinJoin: Bitcoin privacy for the real world >>> https://bitcointalk.org/index.php?topic=279249.0 >>> >>> Bitcoin: A Peer-to-Peer Electronic Cash System >>> http://bitcoin.org/bitcoin.pdf >>> >>> -- >>> 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 >> >> -- >> 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 > > -- > 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 > -- Jorge Timón http://freico.in/ -- 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
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/10/14, Peter Todd wrote: > Because there aren't that many pools out there and Ixcoin (and devcoin) > appear to have been lucky enough to servive long enough to get the > support of a reasonably big one. Once you do that, the potential > attackers have PR to think about. (namecoin especially has a PR > advantage) None of this stuff is hard and fast rules after all. But shouldn't your reasoning apply here so that ixcoin would be destroyed by those who aren't even mining it. Because of the "supposedly obvious" harm it does to Bitcoin through competition? > Anyway, I'm starting to think you're reading too much into my statement > "merge mining is insecure", which, keep in mind, I said in relation to a > guy who was trying to recruit devs to implement some unknown "altcoin" > thing. That's precisely my worry. Most of those guys planning to implement random altcoins will conclude after reading you that what they need is not merged mining but yet another independent scrypt coin, or worse, yet another stupid PoW algorithm. > In that context I sure as heck would loudly yell "CAVE DIVING IS FUCKING > DANGEROUS, DON'T DO IT". Sure, that's not quite telling the whole story, > but the message is pretty close to the truth. The people that should be > in the sport are the ones that take a statement like that as a warning > to do their research; I have no reason to think the OP asking for > developers was one of those people. I'm approached many times with questions like "How much would it cost to create a new altcoin?" (Thanks, BlueMatt for creating coingen!!). I try to explain them that there's more currencies beyond p2p currencies and they probably don't need that. I talk them about local currencies, colored coins or open transactions as solution that probably fit their needs much better without the need to bootstrap and antire economy with a network of computer that consumes plenty of resources. If none of that fits them (say, for crazy experiments like datacoin or gridcoin), I recommend them merged mining because is more secure for them, more secure for bitcoin, and better for the environment and everyone in general. Still, for some reason a new non merged mined chain is the most popular choice. Less efficient, less secure, more popular. Why? I wonder if devs warning against merged mining or making stupid predictions like "bitcoin's PoW algorithm won't survive the year" have anything to do with that... >> > Without merge mining if the value to the participants in the new system >> > is greater than the harm done to the participants in the old system the >> > total work on the new system's chain will still be positive and it has >> > a >> > chance of surviving. >> >> No, the "harm to the old system participants" is distributed among all >> the participants, not only miners (assuming miners have any >> speculative position at all). >> I'm not denying that people do crazy and stupid things, but let's at >> least allow the "anti-competition attacker" be equally crazy in both >> cases. > > Distributing harm among n people just reduces the harm for each person > by a factor of n. That may or may not make that harm smaller than > whatever tiny reward mining the chain would be. The harm TO THE MINERS alone (again, assuming they have any position at all in the coins they're mining) is less than the "total harm" to the competing system, assuming that's quantifiable at all. Miners won't think about the "total harm", but only about their share of harm vs their share of just mining the competing system alongside with the old one. >> I have many other explanations for the few currencies that died with >> MM (can you remember any name?). At the beginning all altcoins were >> much smaller and easier to attack, all of them. Bitcoin mining pools >> didn't wanted to update to merged mining and didn't acted very >> rationally about it. >> Namecoin went through a really delicate situation just before >> hardforking to MM, but now is by far the most secure altcoin of them >> all, all thanks to MM. >> All rational bitcoin miners should also mine namecoin. Period. All > > You assume doing so has zero cost - it doesn't. Running namecoind > involves effort and bandwidth on my part. Yeah, true, they will only mine if all those costs are lower than the reward. Only the hashing is "for free". I'm assuming that those costs are very small compared to the reward, that is, that most of the reward pays for hashing and not validation. >> those who consider it competition with their current Bitcoin >> speculative position, should just "attack in the market" by selling >> the namecoins as soon as they get them. >> Providing security for a chain DOES NOT give it an utility or rise its >> demand. >> Operation COSTS DO NOT CAUSE VALUE. > > Lets rephrase that "A secure chain is no more useful than a less secure > chain. A secure chain will not be more valuable than a less secure > chain, all other things being equal." Not exactly, a less
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/10/14, Peter Todd wrote: > Come to think of it, we've got that exact situation right now: the new > Twister P2P Microblogging thing has a blockchain for registering > usernames that could have been easily done with Namecoin, thus in theory > Namecoin owners have an incentive to make sure the Twister blockchain > gets killed at birth. You don't have to MM from birth. That I've already agreed is dangerous. But if you start with SHA256, then merged mining is a trivial fork at least 3 currencies have done successfully. As said we plan to make Freicoin merge-mineable in the future, and we expect to get much more security after we do. The only "adverse" effect may be a temporary drop in price due to the new miners selling all the frc they get until a new price equilibrates with the demand. But that's not really "bad for the currency", just to the holders at that moment. > Pretty easy to do right now too as the hashing power behind Twister is > miniscule and probably will stay that way - the only incentive to mining > is that you get the right to make a "promoted post" - called a spam > message in the codebase - that in theory Twister clients are supposed to > show to their users. Of course, there's absolutely no way to guarantee > that clients actually do that. If a system doesn't compensate its miners in a liquid enough way, the system will probably be insecure, but that's another topic... -- 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
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/10/14, Peter Todd wrote: >> Fair enough. >> Do you see any case where an independently pow validated altcoin is >> more secure than a merged mined one? > > Situations where decentralized consensus systems are competing for > market share in some domain certainely apply. For instance if I were to > create a competitor to Namecoin, perhaps because I thought the existing > allocation of names was unfair, and/or I had technical improvements like > SPV, it's easy to imagine Namecoin miners deciding to attack my > competitor to preserve the value of their namecoins and domain names > registered in Namecoin. Namecoin, Devcoin and Ixcoin are also currencies and therefore compete with Bitcoin. How is that even Ixcoin (clearly a scamcoin that indirectly damages the image of Bitcoin) has survived? My explanation is that miners aren't necessarily holders. It's certain that there's holders who don't mind and "can't do anything about it". In fact, I think many miners sell their mined coins for fiat to cover their investment and costs. The profit margin is reduced as the mining market becomes more competitive, so even for miners it will get very expensive and risky to do stupid things. Talking about stupid things, I don't see many bitcoiners throwing rocks at local currency users or barter clubs nor burning down banks to "protect their investment". Barter is just another competitor in the media of exchange market. > The problem here is that my new system has a substantial *negative* > value to those existing Namecoin holders - if it catches on the value of > their Namecoin investment in the form of coins and domain names may go > down. Thus for them doing nothing has a negative return, attacking my > coin has a positive return minus costs, and with merge-mining the costs > are zero. What percentage of Bitcoin/Namecoin miners do you think own namecoins? How much can they afford to lose to attack competition? > Without merge mining if the value to the participants in the new system > is greater than the harm done to the participants in the old system the > total work on the new system's chain will still be positive and it has a > chance of surviving. No, the "harm to the old system participants" is distributed among all the participants, not only miners (assuming miners have any speculative position at all). I'm not denying that people do crazy and stupid things, but let's at least allow the "anti-competition attacker" be equally crazy in both cases. Miners attacking "competition" for one or more of the chains they mine are acting irrationally in both cases. You're trying to rationalize the actions of the MM attackers, but they're just being stupid, since if they weren't, they would just try to maximize profits. > Of course, this is what Luke-Jr was getting at when he was talking about > scam-coins and merge mining: if you're alt-currency is a currency, and > it catches on, then it dilutes the value of your existing coins and > people who own those coins have an incentive to attack the competitor. > That's why merge-mined alt-coins that are currencies get often get > attacked very quickly. I have many other explanations for the few currencies that died with MM (can you remember any name?). At the beginning all altcoins were much smaller and easier to attack, all of them. Bitcoin mining pools didn't wanted to update to merged mining and didn't acted very rationally about it. Namecoin went through a really delicate situation just before hardforking to MM, but now is by far the most secure altcoin of them all, all thanks to MM. All rational bitcoin miners should also mine namecoin. Period. All those who consider it competition with their current Bitcoin speculative position, should just "attack in the market" by selling the namecoins as soon as they get them. Providing security for a chain DOES NOT give it an utility or rise its demand. Operation COSTS DO NOT CAUSE VALUE. About Luke-Jr's thinking, I don't think it's along those lines. If you create a new chain for the long term, you should try to maximize its security and that currently means you should merged mine with bitcoin. The main rational reason to never do merged mining is to prevent competitive and rational miners from crashing the price of your currency, which is everything a scamcoiner cares about, the price and market cap. Of course Luke-Jr can correct me if that's not how he thinks. -- 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-develop
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/6/14, Peter Todd wrote: > On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote: > It's not meant to prove anything - the proof-of-sacrificed-bitcoins > mentioned(*) in it is secure only if Bitcoin itself is secure and > functional. I referred you to it because understanding the system will > help you understand my thinking behind merge-mining. > > *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct > because you're sacrificing the thing that the chain is about. Now that > has some proof-of-stake tinges to it for sure - I myself am not > convinced it is or isn't a viable scheme. I'm not sure I understand all the differences between proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm still convinced this doesn't have anything to do with MM PoW vs PoW. The idea looks very interesting and I will ask you and adam to understand it better on IRC, but take into account that when you say "merged mining is insecure" some people hear "merged mined altcoins are less secure than non-MM altcoins" (which is false) and somehow conclude "scrypt altchains are more secure than SHA256 altchains". Whether we like it or not, many people believe that scrypt, quark or primecoin PoW algorithms are somehow more secure than SHA256, and claims that "merged mining is insecure" from core bitcoin developers contribute to spread those beliefs and that no new altcoin has been created with the intend of being merged mined for quite a while. I'm not trying to make you or anyone here responsible for the mistakes other people make. But rephrasing your claims as "We're exploring new ideas for altchains that could be more secure than MM..." sounds very different from "MM is insecure, by the way look at this new idea..." >> Feel free to ask for corrections in the example if you think it needs >> them. >> Feel free to bring your edge legal cases back, but please try to do it >> on top of the example. > > You're argument is perfectly valid and correct, *if* the assumptions > behind it hold. The problem is you're assuming miners act rationally and > have equal opportunities - that's a very big assumption and I have > strong doubts it holds, particularly for alts with a small amount of > hashing power. That's why I made the offer above. What you point out is the reason why freicoin started without merged mining, to grow its own independent security first, before starting to be merged mined. > You know, something that I haven't made clear in this discussion is that > while I think merge-mining is insecure, in the sense of "should my new > fancy alt-coin protocol widget use it?", I *also* don't think regular > mining is much better. In some cases it will be worse due to social > factors. (e.g. a bunch of big pools are going to merge-mine my scheme on > launch day because it makes puppies cuter and kids smile) Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? The reason why I participated in the discussion was that I believe that merged mined PoW is more secure than completely-independent-from-bitcoin pow. And I thought that that was the general understanding in the Bitcoin development community. If that's the case, we agree on what's more important to me. About the new proposal, I don't have a firm opinion yet. I'm sorry but I have to understand it better and think about it in more depth. -- 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
Re: [Bitcoin-development] Merge mining
On 1/4/14, David Vorick wrote: > It's meant to be in favor of merge mining. > > Dogecoin uses scrypt, which is a very popular algorithm. Also, MS windows is a very popular operative system. That's a fallacy: http://en.wikipedia.org/wiki/Argumentum_ad_populum > If any large > currency were to be attacked through merge mining, it would probably be > litecoin miners attacking dogecoin. But if you control enough of the > litecoin network to do attack mining against dogecoin, you almost certainly > have a huge vested interest in cryptocurrencies doing well. Wait, wait, is Dogecoin merge-mineable with litecoin? It could be if its developers wanted to, but I highly doubt it. Precisely because of the myths spread against merged mining. > By attacking > dogecoin successfully, you'll cast doubt on the entire cryptocurrency > ecosystem and hurt yourself in the process. You shouldn't make such assumptions about the interests of a potential attacker. For example, even being of the "cryptocurrency ecosystem" I could consider that their slogans and videos are confusing newcomers and they're really harming the general image of p2p currencies by associating them with mad speculation and pump and dump schemes. Being heavily involved in this "ecosystem", I would be very happy if dogecoin disappeared tomorrow. Personally I've never mined anything, but if I had the resources I would actually consider such an attack. Again, I think we're getting off-topic with perrocoin. It hardly has anything to do with MM. > On Sat, Jan 4, 2014 at 5:05 AM, Jorge Timón wrote: > >> On 1/4/14, David Vorick wrote: >> > If you have the resources to attack one of the bigger altcoins, you >> > probably have a significant investment in the cryptocurrency space, and >> > a >> > significant interest in protecting it. Compromising even something like >> > dogecoin would cause a lot of questions to be raised and likely drop >> > the >> > value of bitcoin as well as all the cryptocurrencies using the same >> > work >> > function as dogecoin. >> > >> > Right now, there's very little benefit to attacking a significant >> currency, >> > because it would be very expensive and likely traumatize the whole >> system. >> > Unless it's some power like the NSA, I don't think there's much to >> > worry >> > about. >> >> The launch thread says it clear: "very scrypt, such random, much >> profit, wow, many coin". >> So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt >> like most of the other scamcoins. >> Anyway, I don't see anything in your comment in favor or against >> merged mining... >> > -- Jorge Timón http://freico.in/ -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge mining
On 1/4/14, David Vorick wrote: > If you have the resources to attack one of the bigger altcoins, you > probably have a significant investment in the cryptocurrency space, and a > significant interest in protecting it. Compromising even something like > dogecoin would cause a lot of questions to be raised and likely drop the > value of bitcoin as well as all the cryptocurrencies using the same work > function as dogecoin. > > Right now, there's very little benefit to attacking a significant currency, > because it would be very expensive and likely traumatize the whole system. > Unless it's some power like the NSA, I don't think there's much to worry > about. The launch thread says it clear: "very scrypt, such random, much profit, wow, many coin". So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt like most of the other scamcoins. Anyway, I don't see anything in your comment in favor or against merged mining... -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/3/14, Peter Todd wrote: > On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote: >> > You assume the value of a crypto-currency is equal to all miners, it's >> > not. >> >> They should be able to sell the reward at similar prices in the market. >> Attackers are losing the opportunity cost of mining the currency by >> attacking it, just like with Bitcoin. > > As I showed with my zerocoin example, often that is not the case, e.g. I > do not support anonymity, or *can't* support it because of the local > laws. > > Or for that matter, really boring examples like there's two competing > implementations of some basic idea and we'd rather the winner be picked > on technical merits rather than "I have a grudge and a small pool so > I'll this upstart at birth" For whatever reason, someone wants to attack one chain, fine. But if the market is competitive enough and/or the reward of the MM-coin is high enough comparatively to the biggest ones in the MM group, then it is not profitable to mine. If you make a MM coin, it's fees reward are 5% of BTC + NMC rewards, and a jurisdiction somehow prohibits to mine the new coin (I can't imagine such a law being enforced, but I'll follow your argument), then BTC + NMC miners will just tend to disappear from that jurisdiction. > It's a thought experiment; read my original post on how to make a > zerocoin alt-chain and it might make more sense: > > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html > > Even better might be to use a merge-mined version of Mastercoin as an > example, where the initial distribution of coins is fixed at genesis and > forward from that is independent of the Bitcoin blockchain. I've read it until the end this time, and I have many doubts about proof of sacrifice as a security mechanism. Although it's certainly not proof of stake, it smells similarly to me. I'll have to think more about it. I still think that link doesn't prove anything against merged mining security. >> I think Namecoin has a lower reward for miners than litecoin and still >> has much better security. I haven't run the numbers but, will you deny >> it? >> How many amazon VMs do you need to attack each one of them? > > I'll give you a hint: "marginal cost" Please, don't give me clues and let's discuss the economics, that's precisely what I want and where I think you're getting it wrong. Since you refuse to try to prove that MM is less secure, I'll try myself to prove the opposite. Let's say we have currencies A, B, C and D, with daily rewards of 70, 20, 10 and 10 valuns respectively. A, B and C are merged mined, D is not. So with an equivalent reward to miners and one being merged mined while the other being independent, what's the more secure chain? C or D? Assuming similar hashing algorithms and perfect competition, the cost of producing enough hashing power to obtain 1 valun in rewards from D equals the cost of extracting 1 valun in rewards from the group A + B + C. Let's define 1 valun as the costs in energy and capital resources to produce X GH/s. So we have the following hashrates for each chain: A = 100*X GH/s B = 100*X GH/s C = 100*X GH/s D = 10*X GH/s Now here it comes our attacker paying for amazon servers. The costs in value to rent a server to produce X GH/s during a day cannot be lower than 1 valun, given the earlier assumptions. Let's assume it is equal to 1 valun for simplicity. So the cost to have 50% of D's hashing power for a day is 10 valuns. The cost to to have 50% of C's hashing power for a day is 100 valuns, but, hey, I'll use your hint now. Marginal costs. So I'm using 100 valuns to attack C, but I'm still getting my rewards from A and B as normal. As normal? Let's assume it's as normal first. I would be getting 90 valuns from chains A and B, so 100 - 90 = 10 valuns. Mhmm, it seems that although I need to make a considerably bigger investment in the case of attacking C, in the end the total costs will be the same of attacking D, that is 10 valuns. But, wait, I've doubled the hashrate!! Miners were getting 1 valun in reward per valun in mining costs when the hashrate was 100*X GH/s, now A and B hashrates are 200*X GH/s because I came to mine. Some of them will be smart enough to leave fast, but I will be really getting something between 45 and 90 valuns from honestly mining A + B, not 90 valuns as I was assuming. So it turns out that attacking D is actually cheaper than attacking C. Feel free to ask for corrections in the example if you think it needs them. Feel free to bring your edge legal cases back, but please try to do it on top of the example. PD I'm eager to read your post on BIP32-ish payment
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/1/14, Peter Todd wrote: > On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote: >> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: >> > that you are using merge-mining is a red-flag because without majority, >> > or >> > at least near-majority, hashing power an attacker can 51% attack your >> > altcoin at negligible cost by re-using existing hashing power. >> >> I strongly disagree on this isolated point. Using the same logic, Bitcoin >> is >> vulnerable to an attacker at negligible cost by re-using existing hashing >> >> power from mining Namecoin. Any non-scam altcoin is pretty safe using >> merged >> mining, since any would-be attacker is going to have it in their interests >> to >> invest in the altcoin instead of attacking it. It's only the scam ones >> that >> want to pump & dump with no improvements, that are really at risk here. >> >> The rational decision for a non-scam altcoin, is to take advantage of >> merged >> mining to get as much security as possible. There are also some possible >> tricks to get the full security of the bitcoin miners even when not all >> participate in your altcoin (but this area probably needs some studying to >> get >> right). > > You assume the value of a crypto-currency is equal to all miners, it's > not. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. > Suppose I create a merge-mined Zerocoin implementation with a 1:1 > BTC/ZTC exchange rate enforced by the software. You can't argue this is > a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the > only thing you can do with the coin is get some privacy. The idea of sacrificing something external and make bitcoins appear still sounds crazy to me. I don't see how this pegging contributes in anything to a technical argument against merged mining, just looks like a moral argument against altcoin in general. But anyway, if you're going to make bitcoin's validation dependent on some external chain, it surprises me even more that you prefer that external dependency to be non-merge mineable. > But inevitably > some miners won't agree that enabling better privacy is a good thing, or > their local governments won't. Either way, they can attack the Zerocoin > merge-mined chain with a marginal cost of nearly zero. Ok, so either we assume that the external-pegging hardfork wasn't a consensus or we just forget about the pegging and go back to talk about merged mining in general. Your argument is still "for some reason some miners don't like the MM altcoin and prefer to attack it than to be profitable miners". If I mine BTC + NMC and you only mine BTC, it will be harder for you to compete against me: I can afford higher costs than you for the same BTC reward, since I'm also getting NMC. What you're saying is that Litecoin is more secure than Namecoin because while Litecoin can only be attacked by external attackers and current miners of other scrypt coins, Namecoin can also be attacked the Bitcoin miners that aren't currently mining Namecoin. This doesn't sound very reasonable to me. I think Namecoin is more secure than Litecoin and new coins should be created with SHA256 and merged mining in mind. At least merged mine with Litecoin if the still believe scrypt is so "anti-ASIC" and "centralization-resistant" (in fact Litecoin is more centralized than bitcoin with their shorter block intervals since better connections are favored, but that's another story). Merged mining is not only about not competing for proof of work like Satoshi defended. It is also about wasting resources: the more mining subsidies to different chains, the more wasted resources. By criticizing merged mining you're also indirectly legitimizing the same scamcoin madness you criticize. If you don't plan to merge mine, having SHA256 doesn't make sense because that makes you more fragile to potential bitcoin miners attacks and chainhopers. I don't think we would have this many alts living right now if all proof of work was SHA256. So if the "anti-asic PoW" myth and the absurd emerging morals of "GPU-mining as an universal right" weren't enough, you want to add an equally false "merged mining is insecure" to the collection of arguments supporting the search of the more absurd possible PoW holy grail. Please try to prove that MM is insecure and I'll try to prove your wrong. But we don't need zerocoin or an artificial pegging to discuss about this. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of them? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue
