Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions
On Jun 15, 2015 11:43 PM, Rusty Russell ru...@rustcorp.com.au 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 gavinandre...@gmail.com wrote: On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc 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 gavinandre...@gmail.com wrote: On Sun, May 31, 2015 at 10:46 AM, Jorge Timón jti...@jtimon.cc 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] Version bits proposal
On May 27, 2015 11:35 AM, Tier Nolan tier.no...@gmail.com 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] Consensus-enforced transaction replacement via sequence numbers
On May 27, 2015 12:58 PM, Peter Todd p...@petertodd.org 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
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 l...@dashjr.org 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 Mon, May 11, 2015 at 7:29 PM, Gavin Andresen gavinandre...@gmail.com 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] Long-term mining incentives
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi alex.mizr...@gmail.com 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] 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 p...@petertodd.org 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: nLockTime 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: relative nLockTime 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] 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 p...@petertodd.org 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] Block Size Increase
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen gavinandre...@gmail.com 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 1:29 PM, Mike Hearn m...@plan99.net 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 they're all 1mb today. Miners may discover that if they go beyond 5mb
Re: [Bitcoin-development] Block Size Increase
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson d...@hashingit.com wrote: Known: There has been a steady trend towards the mean block size getting larger. See https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= 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 4:52 PM, Gavin Andresen gavinandre...@gmail.com 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 m...@plan99.net 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 6:11 PM, Mike Hearn m...@plan99.net 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] 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?
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 m...@plan99.net 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_15utm_medium=emailutm_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] 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 lemienteleph...@gmail.com 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 jti...@jtimon.cc: 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 m...@plan99.net 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_15utm_medium=emailutm_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] 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 ka...@rosenbaum.se 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 ka...@rosenbaum.se 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 ka...@rosenbaum.se: 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] 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 ka...@rosenbaum.se 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 ka...@rosenbaum.se: 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 p...@petertodd.org 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 jti...@jtimon.cc 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 snip 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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc 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 p...@petertodd.org 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 diff 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/1PM EDT
Develop
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 s...@sky-ip.org 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 accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises
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 jti...@jtimon.cc 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 s...@sky-ip.org 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
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 cryptocurrenc...@quidecco.de 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 jgar...@bitpay.com 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=190641631iu=/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 ho...@hozed.org 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 corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
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 m...@plan99.net 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=190641631iu=/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 ta...@bitsofproof.com wrote: On Feb 19, 2015, at 3:03 PM, Bryan Bishop kanz...@gmail.com 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=190641631iu=/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 ta...@bitsofproof.com 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] BIP: Voluntary deposit bonds
On Mon, Dec 29, 2014 at 10:34 PM, Justus Ranvier justus.ranv...@monetas.net 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 p...@petertodd.org 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 02661192e72bdc83e6c8101371520159531301aa1437cc2c -- 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=164703151iu
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=154624111iu=/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 jti...@jtimon.cc 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=154624111iu=/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 1:12 PM, Alex Mizrahi alex.mizr...@gmail.com 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 math.h
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 though, since honest users would have to wait more than
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 alex.mizr...@gmail.com 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 proof-of-stake is not going to work because an
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
On Mon, Oct 6, 2014 at 1:40 AM, Gregory Maxwell gmaxw...@gmail.com 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=160591471iu=/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 m...@plan99.net 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=153845071iu=/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 b...@mattwhitlock.name 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] 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 m...@plan99.net 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, Mike Hearn m...@plan99.net 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/24/14, Tamas Blummer ta...@bitsofproof.com 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, Justus Ranvier justusranv...@gmail.com 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
[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 m...@plan99.net 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/23/14, Mike Hearn m...@plan99.net 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
[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/24/14, Mike Hearn m...@plan99.net 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://p.sf.net/sfu/ExoPlatform
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
On 4/24/14, Peter Todd p...@petertodd.org 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 m...@plan99.net 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] 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 tier.no...@gmail.com wrote: On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org 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
[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] Timed testing
On 4/17/14, Mike Hearn m...@plan99.net 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
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] Feedback request: colored coins protocol
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com 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] Feedback request: colored coins protocol
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com 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] 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 jgar...@bitpay.com wrote: On Fri, Apr 4, 2014 at 3:01 AM, Wladimir laa...@gmail.com 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/5/14, Matt Whitlock b...@mattwhitlock.name 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
On 4/1/14, Matt Corallo bitcoin-l...@bluematt.me 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 pieter.wui...@gmail.com 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 gmaxw...@gmail.com wrote: On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach m...@monetize.io 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,
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On 3/22/14, Peter Todd p...@petertodd.org wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data 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 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
Re: [Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
Some comments. On 3/16/14, Adam Back a...@cypherspace.org 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, Troy Benjegerdes ho...@hozed.org wrote: cynic hat: on 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 m...@plan99.net 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 m...@plan99.net 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] moving the default display to mbtc
On 3/13/14, Mike Hearn m...@plan99.net 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] Decentralized digital asset exchange with honest pricing and market depth
::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=126839071iu=/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=126839071iu=/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=126839071iu=/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=126839071iu=/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 p...@petertodd.org 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=126839071iu=/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 p...@petertodd.org 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 ho...@hozed.org 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 p...@petertodd.org 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=126839071iu=/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 ho...@hozed.org 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=121051231iu=/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=124407151iu=/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.
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=119420431iu=/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=119420431iu=/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 p...@petertodd.org 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=119420431iu=/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 p...@petertodd.org 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=119420431iu=/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/6/14, Peter Todd p...@petertodd.org 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=119420431iu=/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 david.vor...@gmail.com 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 1/3/14, Troy Benjegerdes ho...@hozed.org wrote: 'make' should check the hash. An attacker could replace that part of the makefile. Anyway, I think this is more oriented for compiled binaries, not for people downloading the sources. I assume most of that people just use git. The binary should check it's own hash. I'm afraid this is not possible. The operating system should check the hash. There's package management systems like apt-secure that do exactly this. -- 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=84349831iu=/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/1/14, Peter Todd p...@petertodd.org 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. With AppDynamics, you get 100% visibility into your
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/3/14, Peter Todd p...@petertodd.org 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 protocol, bloom filters and prefix filters, so I hope I'm not distracting you too much with this. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 12/31/13, Mike Hearn m...@plan99.net wrote: remember suggesting that we whack Google Analytics or some other statistics package on when the new website design was done and that was rejected for similar reasons (organisations are bad). Analytics software would be useful. I suggest using Piwik or another free software alternative instead of Google's package. -- 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
On 12/10/13, Ryan Carboni ryan.jc...@gmail.com wrote: You're just closed minded. No, at least to persons have explained you why your proposal is not feasible. If you wanted to learn, you would have made questions on why those parts of your proposal are unfeasible. There have been many proposals about stablecoins in bitcointalk and other forums (for example, the initial proposals freicoin subforum). I have participated in several of them trying to find a solution and I'm now convinced that this is impossible to implement in a secure AND P2P system. This is off-topic for this forum, specially if (as you've shown to us) you are not interested in learning why this proposal is unfeasible. -- Jorge Timón http://freico.in/ -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Popularity based mining (variable block reward)
This has been asked very recently: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development And a thousand times on bitcointalk. On 12/10/13, Jameson Lopp jameson.l...@gmail.com wrote: no reliance on external data ... depending on various factors (coin valuation/exchange rate ಠ_ಠ -- Jameson Lopp Software Engineer Bronto Software On 12/10/2013 11:23 AM, Jan Kučera wrote: Basically there would be no reliance on external data as the network itself would decide on reward height and everybody node would be free to do so. Each network node would determine the popularity on its own depending on various factors (coin valuation/exchange rate, number of transactions and many others) and basically come up with its own block reward value. -- 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=84349831iu=/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/ -- 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
This will probably sound stupid to most of you, but I'll say it anyway. The aim of mnemonics is to easily remember, isn't it? But the approach of removing offensive words is probably counterproductive to achieving that end. These words cause a greater emotional impact in our human moral psyches. If we were willing to use that fact in our advantage to optimize the maximum unforgettableness criterion, we should actually prefer the most generally offensive words in that list. Specially if they can combine with each other to produce more offensive results, basically the opposite of what we're doing. Isn't legalize murder dirty jew much easier to remember for most people than sandwich house yellow cauliflower? I guess that even if I'm right, this will be hard to explain to users and I'm not offering myself to do it. So I completely understand if the people working on this BIP simply ignore this unforgettable wordlist proposal like if it was just a bad taste joke. Using the sub-optimal (in terms of human memory) politically correct wordlist probably won't be that much worse. On 10/24/13, slush sl...@centrum.cz wrote: We've reflected many comments about BIP39 wordlist from the community and I think the wordlist is much better now. Specifically we removed many of theoretically offensive words as well as we implemented algorithm for detecting words with similar characters (cat/eat) and we resolved these duplicities. I'm now quite happy with the wordlist and I want to ask you for next (final?) round of comments. From other features, we added password protection of seed and seed hardening (against bruteforcing) using Rijndael cipher. This has been chosen because its blocksize can be 128, 192 or 256 bits, so it fits length of desired seeds. Also there are Rijndael implementations in every language. Btw password protection has one interesting feature - plausible deniability. It allows user to have one mnemonic and by using it with different passwords, it will generate different BIP32 wallets (wink wink) I want to be pretty clear that we need to close this topic somehow, because we want to use such algorithm in Trezor (which deadline is coming quick) and also other wallet developers want to implement such algorithm into clients to be compatible with Trezor. There were quite strict requirements for such algorithm (like the possibility to convert mnemonic to seed as well as seed to mnemonic) and I think we found a good solution. I'm wildly asking you for constructive comments, but saying it's a crap, I don't like it won't help anything. Thanks, slush On Thu, Sep 12, 2013 at 6:02 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: I removed some more but I haven't added enough back in. It was taking far longer than expected so I gave up, but maybe someone else can try to add some more: https://github.com/MatthewLM/python-mnemonic/blob/master/mnemonic/wordlist/english.txt On 12 Sep 2013, at 13:11, Pavol Rusnak st...@gk2.sk wrote: On 10/09/13 23:03, Matthew Mitchell wrote: Maybe it would have been better without the aggressive words? I revisited the wordlist and replaced around 67 words that can be found offensive in some context. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/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/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
Re: [Bitcoin-development] A critique of bitcoin open source community
I think it's great to move BIPs to github. I also agree with the states - directories mapping. Git manages moved files well. On 10/21/13, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote: On 2013-10-21, at 2:44 AM, Arto Bendiken a...@bendiken.net wrote: Indeed. The BIP analogs that immediately come to mind would be the enhancement proposal processes for Python, XMPP, and BitTorrent: Bitcoin's BIP process is directly based off of Python's PEP process. Quote from BIP 1, History: This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified. -- Jorge Timón http://freico.in/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Faster databases than LevelDB
On 9/17/13, Mike Hearn m...@plan99.net wrote: Nobody has written code to use a better format, migrate old wallets, etc. ACK, thanks. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
Removing getwork and the old miner and packaging a better miner seems the best solution for the reasons already mentioned. Not directly related, but this remembered me that we planned to remove the accounting features on freicoin. We don't want to adapt them for demurrage and we think business shouldn't use it and should code their own accounting system instead. One that keeps a full log of the accounting, etc. Unfortunately the first exchange to support freicoin (cryptonit) used this feature for accounting user balances on the exchange. So the question is, is there any good reason to maintain this? Is any serious business really using this or anyone at all? I'm talking about removing the following rpc calls: getaccount getaddressesbyaccount getbalance getreceivedbyaccount listaccounts listreceivedbyaccount move sendfrom setaccount ...and modifying these: getnewaddress listreceivedbyaddress listtransactions sendmany I think this would also leave a cleaner API, but I'm just interested on what the objections would be to this removal. How crazy does this sound? Should we reconsider their removal for freicoin, proceed or create a pull request for bitcoin? -- Jorge Timón http://freico.in/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
One way sacrifice (btc to zerocoin) is a non-issue since there's no modification required for bitcoin and you can't do anything to prevent it anyway. The controversial thing is sacrificing something outside bitcoin's chain and new btc appearing. On merged mining. It is true that merged attacking the other chain is free, but it is still more profitable to just follow the rules and mine the other coin!! If someone considers that something he can sell in a market for btc is negative value...well, he's just dammed stupid. Proof of work is designed for rational actors, if you stop assuming miners are more or less rational everything falls apart. It is possible that the extra value is too little for some miners to bother. But the extra costs of validating something else are so little compared to chance-hashing that miners not merged mining namecoin right now are just stupid (irrational agents). You can merged mine and sell for btc right away. On prime proof of work...for me it's interseting only because it's moving towards SCIP-based mining but that should be the goal. Like Mark said, let's cure cancer while mining. That would end all mining is wasteful arguments about this great security system. This would make Ripple's consensus mechanism less attractive. People talking about new scrypts harder to ASIC-mine when that's the elephant in the room... Sorry, I'm going off-topic. SCIP-based merged mining for the win. On 7/15/13, Peter Todd p...@petertodd.org wrote: On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote: One very real issue for alt-currencies that don't peg to Bitcoin is that market liquidity is a bitch. By almost all standards current global Bitcoin liquidity is already very, very low. Too low for many transactions that come across my desk at least. There are a lot of reasons for that low liquidity, but to try and float a new pair for which the likely initial counter-asset is going to be Bitcoin means minuscule liquidity. Being able to have automated Bitcoin-Zerocoin P2P trading without an exchange is also significantly more desirable from a privacy standpoint. Basically it reduces the privacy risks of doing the exchange to spending the Zerocoins in the first place. -- 'peter'[:-1]@petertodd.org 00878c30a45104c48fd4e8037cb5b3ba1e14dc4d8bef72eff1be -- Jorge Timón http://freico.in/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
I was talking about bi-directional sacrifice. If zerocoin has it, I want the same on top of freicoin so that btc/frc can be traded p2p. Why zerocoin and not the 20 other altchains are going to ask for it? Ripplers will want it too, why not? All the arguments in favor of this pegging use zerocoin's point of view. Sure it would be much better for it, but are additional costs to the bitcoin network and you cannot do it with every chain. Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Bitcoins are worth because it costs to mine them is a Marxian labor thory of value argument. It's the other way arround as Menger taught us. On 7/13/13, Adam Back a...@cypherspace.org wrote: On Sat, Jul 13, 2013 at 11:51:14AM +0200, Jorge Timón wrote: I don't see the need to peg zerocoins to bitcoins. Without a bitcoin peg on the creation cost of zerocoins, it is hard for a new alt-coin to have a stable value. Bitcoin itself is volatile enough. Generally the available compute for mining is what it is, adding more alt-coins just dillutes the compute available for a given coin. (Modulo different mining functions like scrypt vs hashcash there is some non-overlapping available compute because different hardware is more efficient, or even cost-effective at all). Merge mining is less desirable for the alt-coin - its mining is essentially free, on top of bitcoin mining. Cost free is maybe a weaker starting point bootstrapping digital scarcity based market price. I think that serves to explain why bitcoin sacrifice as a mining method is a simple and stable cost starting point for an alt-coin. I think this could be highly controversial [alt-coin pegging]. Maybe everybody likes it, but can you expand more on the justifications to peg the two currencies? Bitcoin sacrifice related applications do not require code changes to bitcoin itself, which avoids the discussion about fairness of which alt-coin is supported, and about sacrifice-based pegging being added or not. I dont think it necessarily hurts investors in bitcoins as it just creates some deflation in the supply of bitcoin. If you're requiring one chain look at the othe for validations (miners will have to validate both to mine btc) you don't need the cross-chain contract, you can do it better. You can sacrifice bitcoins as a way to mine zerocoins without having the bitcoin network validate zerocoin. For all bitcoin clients care the sacrifice could be useless. Bi-directional sacrifice is more tricky. ie being allowed to re-create previously destroyed bitcoins, based on the sacrifice of zerocoin. That would have other coin validation requirements. But I am not sure 1:1 is necessarily far from the right price - the price is arbitrary for a divisible token, so 1:1 is as good as any. And the price equality depends on the extra functionality or value from the characteristics of the other coin. The only thing I can see is zerocoin is more cpu expensive to validate, the coins are bigger, but provide more payment privacy (and so less taint). Removing taint may mean that zercoins should be worth more. However if any tainted bitcoins can be converted to zerocoin via sacrifice at 1:1, maybe the taint issue goes away - any coins that are tainted to the point of value-loss will be converted to zerocoin, and consequently the price to convert back should also be 1:1? You could do something like this: https://bitcointalk.org/index.php?topic=31643.0 p2p transfer is a good idea. Adam -- Jorge Timón http://freico.in/ -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
Sorry about that. Maybe more important, what's wrong with bitcoin and zerocoin being different currencies with an exchange rate completely decided by the market instead of trying to force 1:1 ??? On 7/13/13, Jorge Timón jti...@monetize.io wrote: I'm not sure I understand the whole proposal, but it seems to me that having different characteristics, bitcoins and zerocoins would be different currencies. I don't see the need to peg zerocoins to bitcoins. It is great to have an anonymous p2p currency, maybe some bitcoin users that use bitcoin because of the transparency they allow (public funds expenditures could be more transparent than they have ever been) don't like this hard-fork. Well, maybe this is not the main reason, but I think this could be highly controversial. Maybe everybody likes it, but can you expand more on the justifications to peg the two currencies? If you're requiring one chain look at the othe for validations (miners will have to validate both to mine btc) you don't need the cross-chain contract, you can do it better. Instead of doing this: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains You could do something like this: https://bitcointalk.org/index.php?topic=31643.0 This very idea has been proposed recently by othe people, but I can't find where. The problem with this is of course scalabilty. Once you do it for what chain, why not the others? You can't validate 100 chains to mine bitcoin even if they're all merged mined: that's asking miners too much. If zerocoin enjoys this privilege why not, for example? As some of you may know, Mark Friedenbach and I are working on a protocol modification to support issuance of arbitrary assets. Would be something like colored coins but better, we're calling it FreiMarkets. Of course these assets are not p2p like bitcoin or freicoin themselves: they have a centralized issuer. But if you allowed to sacrifice real bitcoins (as opposed to IOUs denominated in BTC like you have, for example, in ripple) so they appear in Freicoin's chain and turn them back, you could have p2p bitcoins inside Freicoin's chain. Maybe ripplers want that too. If FreiMarkets prove to work well on freicoin and be scalable enough, maybe a lot of scamcoins apply the hardfork too and they want to have p2p btc in their chain as well. Maybe I could have explained this without even mentioning FreiMarkets, but my point is that you're asking for a lot like it was nothing. Zerocoin-bitcoin fungibility hardfork is opening a little pandora's box. Are we ready? I was waiting for others to comment and I'm surprised that no one else has made any objection yet. But if no one's going to point out the controvery that is so obvious to me, I feel almost like a responsability to act like a Devil's advocate here. So if you make bitcoin and zerocoin fungible, I want bitcoins to be transferrable to freicoin's chain. And I warn you there will be many more people asking for the same thing on other chains. What criteria will we have to say yes or no? More On 7/12/13, Peter Todd p...@petertodd.org wrote: On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote: Do people think that should work? It seems to me it should with minimal, bitcoin changes. I think the rule for either-or mining should be as simple as skipping the value / double-spend validation of the blocks that are zerocoin mining blocks. Obviously zerocoin blocks can themselves end up on forks, that get resolved, but that fork resolution can perhaps be shared? (Because the fork resolution is simply to accept the longest fork). Yeah, there's been a lot of doom and gloom about zerocoin that is frankly unwarrented. For instance people seem to think it's impossible to make a blockchain with zerocoin due to the long time it takes to verify transactions, about 1.5 seconds, and never realize that verification can be parallelized. Anyway the way to do it is to get out of the model of large blocks and think about individual transactions. Make each transaction into its own block, and have each transaction refer to the previous one in history. (zerocoin is inherently linear due to the anonymity) Verification does *not* need to be done by every node on every transaction. Make the act of creating a transaction cost something and include the previous state of the accumulator as part of a transaction. Participants verify some subset of all transactions, and should they find fraud they broadcast a proof. Optionally, but highly recomended, make it profitable to find fraud, being careful to ensure that it's never profitable to create fraud then find it yourself. Anyway Bitcoin is limited to 7tx/s average so even without probabalistic verification it'd be perfectly acceptable to just limit transactions to one every few seconds provided you keep your blocksize down to one transaction so the rate isn't bursty. You're going to want
Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
On 4/10/13, Peter Todd p...@petertodd.org wrote: Oh, and while we're at it, long-term (hard-fork) it'd be good to change the tx hash algorithm to extend the merkle tree into the txouts/txins itself, which means that to prove a given txout exists you only need to provide it, rather than the full tx. Currently pruning can't prune a whole tx until every output is spent. Make that change and we can prune tx's bit by bit, and still be able to serve nodes requesting proof of their UTXO without making life difficult for anyone trying to spent old UTXO's. The idea is also part of UTXO proof stuff anyway. I thought about this before, I like the idea very much. Would such a fork be controversial for anyone? Would anyone oppose to this for some reason I'm missing? -- Jorge Timón http://freico.in/ -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocking uneconomical UTXO creation
That solution seems good enough to me. Smartcoin users would just need to move their assets before 10 years, totally acceptable. And regular users don't need to think about it since they're probably always sending more than they pay in fees. On 3/11/13, Benjamin Lindner b...@benlabs.net wrote: On Mar 11, 2013, at 12:54 PM, Mike Hearn m...@plan99.net wrote: With regards to trying to minimize the size of the UTXO set, this again feels like a solution in search of a problem. Even with SD abusing micropayments as messages, it's only a few hundred megabytes today. That fits in RAM, let alone disk. If one day people do get The problem of UTXO in principal scales with the block size limit. Thus it should be fixed BEFORE you consider increasing the block size limit. Otherwise you just kick the can down the road, making it bigger. concerned about the working set size, miners can independently set their own policies for what they confirm, for instance maybe they just Problem is the skewed incentive structure. Rational miners will always include dust output with fees, because the eternal cost of UTXO is payed by the network and future miners, not the current/individual miner. On Mar 11, 2013, at 7:01 AM, Jorge Timón jtimo...@gmail.com wrote: On 3/10/13, Peter Todd p...@petertodd.org wrote: It's also been suggested multiple times to make transaction outputs with a value less than the transaction fee non-standard, either with a fixed constant or by some sort of measurement. As said on the bitcointalk thread, I think this is the wrong approach. This way you effectively disable legitimate use cases for payments that are worth less than the fees like smart property/colored coins. this. Just activate a non-proportional demurrage (well, I won't complain if you just turn bitcoin into freicoin, just think that non-proportional would be more acceptable by most bitcoiners) that incentives old transactions to be moved You could delegate the decision to the user with a rule like: if (outputfee): limit lifetime of the UTXO to 10 years. if (outputfee): unlimited lifetime Then, when a user creates a transaction, he can decide whether he wants to have limited or unlimited lifetime. The rationale for limiting the lifetime for (outputfee) transactions is that they may have no inherent economic incentive to be spend. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Can this tx be formed?
Say Alice signs and broadcasts a tx with input Ai, with SIGHASH_SINGLE to Ao and SIGHASH_ANYONECANPAY Bob signs and broadcasts a tx with input Bi, with SIGHASH_SINGLE to Bo and SIGHASH_ANYONECANPAY Can Carol complete the tx so that it is valid to be published in the chain? It only has to make Ai + Bi + Ci + F = Ao + Bo + Co but it all must be contained in a single transaction. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Key retirement and key compromise
Just create a new wallet and send everything to a new address. I don't think additional tools for this are needed. On 2/23/13, Roy Badami r...@gnomon.org.uk wrote: Has anyone been thinking about providing tools to allow users to cope with key compromise - or more generally, to manage key retirement etc? atm, if you suspect that your keys may be liable to compromise then what would you have to do? You'd have to create a new wallet (on a new computer? or is it easy to have two coexisting installs on one computer?) And then you'd have to make one or more payments from the old wallet to the new wallet, to transfer the coins. It's a pain, and you've lost your address book, your transaction history, etc. And unless you keep the old wallet about, too, you're a bit stuck if someone makes a payment to one of the old addresses. It's something that most users would baulk at unless they're really sure they're at significant risk. Of course, there are a spectrum of scenarios, ranging from having an unencrypted wallet stolen by someone who knows what it is, through to deciding that the passphrase you used to use when you only had a few dollars worth of BTC maybe isn't good enough now you've got tens of thousands of dollars worth of coins. Or maybe you have no reason to suspect there is a risk of compromise, but just have a corporate key management policy that recommends retiring keys after a period of time. What would be really nice is for bitcoin to have a big key compromise button, which would automatically transfer all coins to newly generated addresses (optionally with a pause between generation and transaction - to allow for a new wallet backup). Optionally, too, the compromised/retired addresses could be marked with a flag such that if someone sends coins to that address bitcoind immediately generates a transaction to transfer the coins to address(es) which are good. I know deterministic wallets have many proponents - but personally I like having a bag of keys - with the idea that over a period of time, old keys will routinely be retired and their balances automatically transfered to newly generated keys. If someone really manages to crack the passphrase on that 10-year-old wallet backup they got hold of, then if would be nice to minimise the damage they could do... And, of course, I want a big panic button that allows me to automatically transfer all my coins to new addresses ASAP if I suddenly do something stupid, like accidentally type my passphrase into my IRC window :-) Thoughts? Is this functionality that there is any interest in developing within the official client? If there is any interest in this then obviously the first step would be to specify exactly what functionality is wanted... roy -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Implementing trading across chains
Well, if it's even possible to trade across chains with Ripple (and I don't know of any reason shouldn't be), you will have to wait to the release of the full node (validator) code, for now only a javascript web client is open sourced. But it seems they at least have plans for contracts judging from the wiki: https://ripple.com/wiki/Contracts On 2/13/13, Petr Praus p...@praus.net wrote: Jorge, thanks for bitcoinx tip, I didn't know about it and it's certainly related. I'll have a closer look Regarding Ripple, I tried it but as far as I can tell, it doesn't have any contract enforcement (by technical means) built in. On 11 February 2013 05:03, Jorge Timón jtimo...@gmail.com wrote: Hi, you may be interested in a couple of related projects. Colored coins uses satoshis to represent smart property, shares, IOUs of another currency...Colored coins can be atomically traded for bitcoin. If you implement the trade across chains contract they would also be tradeable for another chain currencies like namecoin or freicoin. http://www.bitcoinx.org/ Ripple is a concept by which people that trust each other on a network are able to pay with IOUs transitively. It has a new p2p implementation that is still on development. The new implementation is very similar to bitcoin in certain senses but it has no mining. Bitcoin IOUs can be traded there. https://ripple.com/ Good luck with the implementation, this is a good feature to have, even if it's not on the main client. On 2/8/13, Petr Praus p...@praus.net wrote: Hi, I intend to implement trading across chains in a P2P manner (as described by Mike Hearn in https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains). Note, this is indended more as an alternative chain development, I don't have any plans for merging it back into main client (not because I don't want to, but because I think it wouldn't be accepted). Before I dive into it, I thought it might be a good idea to ask here if the community has any useful ideas or comments on this topic? Thanks to Gary Rowe I know about Open Transactionshttps://github.com/FellowTraveler/Open-Transactions. They can do multicurrency trading too, but it's objectives are quite ambitious and I'm looking at making relatively small changes in the mainline Bitcoin client rather than diving into something entirely new. A little background on why am I doing this, can be found herehttps://groups.google.com/d/topic/bitcoinj/lmVSF8yaJHk/discussion. In short it's part of research towards my Master's thesis (more precisely, an excuse to hack on Bitcoin and sell it as research :)) which should be about multicurrency (alternative chains) in Bitcoin. Thanks, Petr PS: I hope I'm not too off topic here, but thishttps://bitcointalk.org/index.php?topic=15527.0 thread indicates it should be fine to post alternative development questions on this. -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Implementing trading across chains
Hi, you may be interested in a couple of related projects. Colored coins uses satoshis to represent smart property, shares, IOUs of another currency...Colored coins can be atomically traded for bitcoin. If you implement the trade across chains contract they would also be tradeable for another chain currencies like namecoin or freicoin. http://www.bitcoinx.org/ Ripple is a concept by which people that trust each other on a network are able to pay with IOUs transitively. It has a new p2p implementation that is still on development. The new implementation is very similar to bitcoin in certain senses but it has no mining. Bitcoin IOUs can be traded there. https://ripple.com/ Good luck with the implementation, this is a good feature to have, even if it's not on the main client. On 2/8/13, Petr Praus p...@praus.net wrote: Hi, I intend to implement trading across chains in a P2P manner (as described by Mike Hearn in https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains). Note, this is indended more as an alternative chain development, I don't have any plans for merging it back into main client (not because I don't want to, but because I think it wouldn't be accepted). Before I dive into it, I thought it might be a good idea to ask here if the community has any useful ideas or comments on this topic? Thanks to Gary Rowe I know about Open Transactionshttps://github.com/FellowTraveler/Open-Transactions. They can do multicurrency trading too, but it's objectives are quite ambitious and I'm looking at making relatively small changes in the mainline Bitcoin client rather than diving into something entirely new. A little background on why am I doing this, can be found herehttps://groups.google.com/d/topic/bitcoinj/lmVSF8yaJHk/discussion. In short it's part of research towards my Master's thesis (more precisely, an excuse to hack on Bitcoin and sell it as research :)) which should be about multicurrency (alternative chains) in Bitcoin. Thanks, Petr PS: I hope I'm not too off topic here, but thishttps://bitcointalk.org/index.php?topic=15527.0 thread indicates it should be fine to post alternative development questions on this. -- Jorge Timón http://freico.in/ http://archive.ripple-project.org/ -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Atomic coin swapping?
I'm very interested in this. I was expecting transitive/multi-hop transactions (Ripple) with colored coins, and I don't understand why is not possible. From https://en.bitcoin.it/wiki/Contracts --- SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, are signed; it's only the scripts that are not. Intuitively, it means I agree to put my money in, if everyone puts their money in and the outputs are this. --- Why Signing the input scripts as well would obviously make it impossible to construct a transaction? I don't understand that part. I think a new SIGHASH_* type that doesn't pay attention to that obviously is needed to achieve what we want. Say we want the following transaction: A 1 satoshi - B 1 satoshi - C 100 btc - A It would be necessary to sign the following: Inputs: from srcA, from srcB, Outputs: 1 satoshi to destB, 1 satoshi to destC, 100 btc to destA from srcC is not really necessary. This same scheme can be used for n-hops. What am I missing? On 9/22/12, Jeff Garzik jgar...@exmulti.com wrote: Forum URL: https://bitcointalk.org/index.php?topic=112007.0 gmaxwell was talking about colored coins[1] in IRC recently. They are potentially interesting in the context of distributed bonds[2], which I am currently pursuing with pybond[3]. Here is the problem I am trying to solve, does the crowd have an answer? 1. Alice transfers a 1-satoshi colored coin to Bob. 2. Bob transfers 100 BTC to Alice. May be restricted to 1 txout, if that eases implementation details. 3. Steps #1 and #2 happen as an atomic unit, all-or-none. 4. Alice and Bob must both approve this atomic transfer of coins, with appropriate signatures. Is this possible within the current bitcoin system? As far as I can see, the answer is no but maybe I'm missing something. My best guess to the answer is possible, but requires a new SIGHASH_* type? [1] https://bitcointalk.org/index.php?topic=106449.0 [2] https://bitcointalk.org/index.php?topic=92421.0 [3] https://github.com/jgarzik/pybond -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
On 5/3/12, Andreas Schildbach andr...@schildbach.de wrote: Can we add Bitcoin Wallet? Someone said to me that the cell phone apps they had tried were still too slow. I'm still using an old phone so I didn't know well what to answer him. I recomended him bitcoin wallet and bitcoin spinner, but I warned him that I haven't really used them. It would be nice to also have a list with smartphone clients near the list that is being prepared. -- Jorge Timón -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On 4/12/12, Jeff Garzik jgar...@exmulti.com wrote: 1. N = 1 or 2 or whatever the community prefers. Ideally enough time for a third-tier miner, mining strange TXs, finds a block. 2. H1 = height of block chain, when a TX is received 3. H2 = H1 + (144 * N) 4. If block chain height reaches H2, and TX has not made it into a block, drop TX from memory pool Why not just adding a field expiration_block = H2? It seems more explicit and flexible than using a 144 * N constant. You're changing the protocol anyway, right? Another question, aren't different peers going to get different H1 for the same tx? -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A better Spanish translation for vulnerability page
Hi, I've made some corrections. Se ha descubierto un fallo potencial de seguridad en Bitcoin-Qt para Windows. Si tienes Bitcoin-Qt para Windows en alguna versión entre 0.5 y 0.6, deberías salir del programa, y actualizar a la versión 0.5.3.1 o 0.6rc4 AHORA. La aplicación de línea de comandos (bitcoind), las versiones Mac y Linux de Bitcoin-Qt, y las versiones anteriores a 0.5 no están afectadas. Debido a la naturaleza de este fallo, creemos que sería muy difícil para un atacante hacer algo más que bloquear el proceso de Bitcoin-Qt. Sin embargo, debido a que existe la posibilidad de que un cierre inesperado permita la ejecución de código remoto, consideramos esto una incidencia crítica. Si tienes alguna pregunta, visita el canal IRC #bitcoin-dev en Freenode. Puedes descargar el software actualizado desde SourceForge: 0.6rc [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/] 0.5.3.1 para Windows y 0.5.3 para Linux [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/] Hope this helps On 3/19/12, Jean-Pierre Rupp jpie...@xeno-genesis.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Una potencial falla de seguridad ha sido descubierta en Bitcoin-Qt para Windows. Si tienes Bitcoin-Qt para Windows en alguna versión entre 0.5 y 0.6, deberías salir del programa, y actualizar a la versión 0.5.3.1 o 0.6rc4 AHORA. La aplicación de línea de comandos (bitcoind), las versiones Mac y Linux de Bitcoin-Qt, y las versiones anteriores a 0.5 no están afectadas. Debido a la naturaleza de esta falla, creemos que sería muy difícil para un atacante hacer algo más que colgar (cerrar) el proceso de Bitcoin-Qt. Sin embargo, porque existe la posibilidad que un cierre inesperado permita la ejecución de código remoto, consideramos esto un incidente crítico. Si tienes alguna pregunta, visita el canal IRC #bitcoin-dev en Freenode. Puedes descargar el software actualizado desde SourceForge: 0.6rc [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/] 0.5.3.1 para Windows y 0.5.3 para Linux [https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/] - -- Be Happy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9m4DYACgkQ77Wxq1L+vC74wgCfX4kF+BiKjO51UOgZmRib4kMP W6sAn016/jDXOfV/WeonqtqB3GuhzG+t =pqWY -END PGP SIGNATURE- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcement: libcoin
Sounds great. Does it support merged mining? Also, I'm a bit skeptic about it being chain agnostic. I want to implement a chain with demurrage and I think I'll need to also change coinWallet and not only create an implementation of the interface Chain. Anyway, this will make the task much easier. Thank you. Until I have the time to code it, there's a little bounty (7.3 btc) for this in case you're interested. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
It may be a political issue, but I don't think wikipedia becomes a political organization for being against censorship. This is not about left or right. Is about free speech, one of the basic principles not only of freedom but also of democracy. And as Gregory shows it clearly affects bitcoin directly. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
