Re: [Bitcoin-development] comments on BIP 100
I think he's more talking about like extension-blocks, however they are actually soft-forkable even (and keep the 21m coins obviously) See See https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html and Tier Nolan tech detail https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html Discussion / claimed properties on https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ Adam On 15 June 2015 at 19:53, Raystonn . rayst...@hotmail.com wrote: The solution is to hard-fork and merge-mine. This way, both can live, and mining power is not divided. No, this would essentially be blessing an increase to 42M bitcoins, half on each chain. You could expect a severe market price correction if this were to happen. From: Rebroad (sourceforge) Sent: Monday, June 15, 2015 4:16 AM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 My understanding of this debate is that there are some people who want to keep Bitcoin at 1MB block limit, and there are some who want to increase it. I for one am curious to see how 1MB limited bitcoin evolves, and I believe we can all have a chance to see this AND hard-fork bitcoin to remove the block size restriction. To remove the 1MB limit required a hard fork. This is not disputed. It's what we do with the original (1MB limit) bitcoin that concerns me (and other's I am sure). What I would like to see is both being allowed to live. Harry Potter and Voldermort! (Except neither are evil!) The solution is to hard-fork and merge-mine. This way, both can live, and mining power is not divided. Dogecoin recently hardforked and this hardfork also involved switching to merge-mining, so it's been done successfully. So, simply, bitcoin as it is doesn't need to actually fork, but instead, at a certain block size, a forked bitcoin with the blocksize lmit removed will start to be merge-mined alongside bitcoin. Miners can be ready for this. Wallets can be ready for this - in fact, for most wallets and merchants they will possibly want to default to the bigger blocksize fork since this caters for more transactions per block. We still don't know how removing the block limit will pan out and what other problems with scalability will arise in the future, so by preserving the original bitcoin, we keep diversity, and people won't feel their investments in bitcoin are being unnecessarily put at risk (as their investments will stay in both the new and the old bitcoin). The bitcoin core developers can implement a patch like the one recently used for dogecoin, to allow the chain to fork at a set point, where at which point, bitcoins will be split into the new and the old. Branding will be an important issue here I think, so that there is as little confusion as possible. I think this is a small price to pay in return for not killing the original bitcoin (even if it's true that Satoshi did intend to remove the 1MB limit at some point). If I'm missing something obvious please let me know. On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn m...@plan99.net wrote: The fact that using a centralized service is easier isn't a good reason IMHO. It disregards the long-term, and introduces systemic risk. Well sure, that's easy for you to say, but you have a salary :) Other developers may find the incremental benefits of decentralisation low vs adding additional features, for instance, and who is to say they are wrong? But in cases where using a decentralized approach doesn't *add* anything, I cannot reasonably promote it, and that's why I was against getutxos in the P2P protocol. It does add something though! It means, amongst other things, I can switch of all my servers, walk away for good, discard this Mike Hearn pseudonym I invented for Bitcoin and the app will still work :) Surely that is an important part of being decentralised? It also means that as the underlying protocol evolves over time, getutxos can evolve along side it. P2P protocol gets encrypted/authenticated? Great, one more additional bit of security. If one day miners commit to UTXO sets, great, one more additional bit of security. When we start including input values in the signature hash, great ... one more step up in security. Anyway, I didn't really want to reopen this debate. I just point out that third party services are quite happy to provide whatever developers need to build great apps, even if doing so fails to meet some kind of perfect cryptographic ideal. And that's why they're winning devs. Now back to your regularly scheduled block size debates ... -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC funds invested in companies, we owe it to them that we be open and transparent here. I would really prefer on a personal nor professional basis to be having this conversation period, never mind in public, but Mike - your and Gavin's decision to promote a unilateral hard-fork and code fork are extremely high risk for bitcoin and so there remains little choice. So I apologise again that we have to have this kind of conversation on a technical discussion list. This whole thing is hugely stressful and worrying for developers, companies and investors. I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor (without accusing you of any of those - I understand you personally just want to scale bitcoin, but are inclined to knock heads and try to force an issue you see, rather than work collaboratively). For you (and everyone) - Should there be a summit of some kind, that is open attendance, and video recorded so that people who are unable to attend can participate too, so that people can present the technical proposals and risks in an unbiased way? (It is not theoretical question, I may have a sponsor and host - not Blockstream, an independent, its a question for everyone, developers, users, CTOs, CEOs.) So here I come back to more frank questions: Governance The rest of the developers are wise to realise that they do not want exclusive control, to avoid governance centralising into the hands of one person, and this is why they have shared it with a consensus process over the last 4 years. No offence but I dont think you personally are thinking far enough ahead to think you want personal control of this industry. Maybe some factions dont trust your motives, or they dont mind, but feel more assured if a dozen other people are closely reviewing and have collective review authority. - Do you understand that attempting to break this process by unilateral hard-fork is extremely weakening of Bitcoin's change governance model? - Do you understand that change governance is important, and that it is important that there be multiple reviewers and sign-off to avoid someone being blackmailed or influenced by an external party - which could potentially result in massive theft of funds if something were missed? - Secondarily do you understand that even if you succeed in a unilateral fork (and the level of lost coins and market cap and damage to confidence is recoverable), that it sets a precedent that others may try to follow in the future to introduce coercive features that break the assurances of bitcoin, like fungibility reducing features say (topically I hear you once proposed on a private forum the concept of red-lists, other such proposals have been made and quickly abandoned), or ultimately if there is a political process to obtain unpopular changes by unilateral threat, the sky is the limit - rewrite the social contract at that point without consensus, but by calculation that people will value Bitcoin enough that they will follow a lead to avoid risk to the system? Security As you probably know some extremely subtle bugs in Bitcoin have at times slipped past even the most rigorous testings, often with innocuous but unexpected behaviours, but some security issues Some extremely intricate and time-sensitive security defect and incident response happens from time to time which is not necessarily publicly disclosed until after the issue has been rolled out and fixed, which can take some time due to the nature of protocol upgrades, work-arounds, software upgrade via contacting key miners etc. We could take an example of the openSSL bug. - How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? - Are you a member of the bitcoin security reporting list? On 15 June 2015 at 11:56, Mike Hearn m...@plan99.net wrote: I will review both and mostly delegate to Gavin's good taste around the details, unless there is some very strong disagreement. But that seems unlikely. ... Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests aren't scored in any way. The final decision rests with the maintainer as in ~all open source projects. As you know the people who have written 95% of the code (and reviewed, and tested, and formally proved segments etc) are strenuously advising not to push any consensus
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
It might be as well to keep the archive but disable new posts as otherwise we create bit-rot for people who linked to posts on sourceforge. The list is also archived on mail-archive though. https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ Adam On 14 June 2015 at 22:55, Andy Schroder i...@andyschroder.com wrote: Hello, I'd support moving to a Linux Foundation e-mail list. I am also against google groups. I agree that the gesture of moving indicates that SourceForge is not playing nice on other issues and that moving this list shows their behavior is being acknowledged. I understand your reason for wanting to delete the Source Forge account (after reading the links). However, the only problem with that is that the SourceForge archive is the oldest one I've found with some early messages from Satoshi. Myself finding Bitcoin after its inception, as well as this mailing list even later on, it's nice to be able to review the archives. SourceForge's interface to those archives is pretty bad though. I'm not sure if there is any way to get older messages archived on sites like gmane or mail-archive? Does anyone know? You mentioned importing the list archive as part of the migration plan, but I guess is this easy to do from SourceForge? Andy Schroder On 06/14/2015 06:12 AM, Warren Togami Jr. wrote: Discomfort with Sourceforge For a while now people have been expressing concern about Sourceforge's continued hosting of the bitcoin-dev mailing list. Downloads were moved completely to bitcoin.org after the Sept 2014 hacking incident of the SF project account. The company's behavior and perceived stability have been growing to be increasingly questionable. http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer November 2013: GIMP flees SourceForge over dodgy ads and installer https://lwn.net/Articles/646118/ May 28th, 2015: SourceForge replacing GIMP Windows downloads http://seclists.org/nmap-dev/2015/q2/194 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads. When this topic came up over the past two years, it seemed that most people agreed it would be a good idea to move. Someone always suggests Google Groups as the replacement host. Google is quickly shot down as too controversial in this community, and it becomes an even more difficult question as to who else should host it. Realizing this is not so simple, discussion then dies off until the next time somebody brings it up. http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607 Somebody brought it up again this past week. It seems logical that an open discussion list is not a big deal to continue to be hosted on Sourceforge, as there isn’t much they could do to screw it up. I personally think moving it away now would be seen as a gesture that we do not consider their behavior to be acceptable. There are also some benefits in being hosted elsewhere, at an entity able to professionally maintain their infrastructure while also being neutral to the content. Proposal: Move Bitcoin Dev List to a Neutral Competent Entity Bitcoin is a global infrastructure development project where it would be politically awkward for any of the existing Bitcoin companies or orgs to host due to questions it would raise about perceived political control. For example, consider a bizarro parallel universe where MtGox was the inventor of Bitcoin, where they hosted its development infrastructure and dev list under their own name. Even if what they published was 100% technically and ideologically equivalent to the Bitcoin we know in our dimension, most people wouldn't have trusted it merely due to appearances and it would have easily gone nowhere. I had a similar thought process last week when sidechains code was approaching release. Sidechains, like Bitcoin itself, are intended to be a generic piece of infrastructure (like ethernet?) that anyone can build upon and use. We thought about Google Groups or existing orgs that already host various open source infrastructure discussion lists like the IETF or the Linux Foundation. Google is too controversial in this community, and the IETF is seen as possibly too politically fractured. The Linux Foundation hosts a bunch of infrastructure lists and it seems that nobody in the Open Source industry considers them to be particularly objectionable. I talked with LF about the idea of hosting generic Bitcoin-related infrastructure development lists. They agreed as OSS infrastructure dev is already within their charter, so early this week sidechains-dev list began hosting there. From the perspective of our community, for bitcoin-dev it seems like a great fit. Why? While they are interested in supporting general open source development, the LF has literally zero stake in this. In addition to
[Bitcoin-development] comments on BIP 100
Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails actually not getting blocked!). http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf may have changed since the original [1] Over the original proposal: 1. there should be a hard cap, not indefinitely growing. 2. there should be a growth limiter (no more than X%/year) 3. I think the miners should not be given a vote that has no costs to cast, because their interests are not necessarily aligned with users or businesses. I think Greg Maxwell's difficulty adjust [2] is better here for that reason. It puts quadratic cost via higher difficulty for miners to vote to increase block-size, which miners can profitably do if there are transactions with fees available to justify it. There is also the growth limiter as part of Greg's proposal. [3] I think bitcoin will have to involve layering models that uplift security to higher layers, but preserve security assurances, and smart-contracts even, with protocols that improve the algorithmic complexity beyond O(n^2) in users, like lightning, and there are multiple other candidates with useful tradeoffs for various use-cases. One thing that is concerning is that few in industry seem inclined to take any development initiatives or even integrate a library. I suppose eventually that problem would self-correct as new startups would make a more scalable wallet and services that are layer2 aware and eat the lunch of the laggards. But it will be helpful if we expose companies to the back-pressure actually implied by an O(n^2) scaling protocol and don't just immediately increase the block-size to levels that are dangerous for decentralisation security, as an interventionist subsidy to save them having to do basic integration work. Otherwise I think whichever any kind of kick the can some 2-5 years down the road we consider, we risk the whole saga repeating in a few years, when no algorithmic progress has been made and even more protocol inertia has set in. Adam [1] original proposal comments on reddit https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/ [2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html [3] growth limited proposal for flexcap by Greg Maxwell https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
Mike Hearn m...@plan99.net wrote: Which is why there will soon be a fork that does it. I understand why you would be keen to scale bitcoin, everyone here is. But as you seem to be saying that you will do a unilateral hard-fork, and fork the code-base simultaneously, probably a number of people have questions, so I'll start with some: ( I noticed some of your initial thoughts are online here https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast https://epicenterbitcoin.com/podcast/082/ ) - Are you releasing a BIP for that proposal for review? - If the reviewers all say NACK will you take on board their suggestions? - On the idea of a non-consensus hard-fork at all, I think we can assume you will get a row of NACKs. Can you explain your rationale for going ahead anyway? The risks are well understood and enormous. - How do you propose to deal with the extra risks that come from non-consensus hard-forks? Hard-forks themselves are quite risky, but non-consensus ones are extremely dangerous for consensus. - If you're going it alone as it were, are you proposing that you will personally maintain bitcoin-XT? Or do you have a plan to later hand over maintenance to the bitcoin developers? - Do you have contingency plans for what to do if the non-consensus hard-fork goes wrong and $3B is lost as a result? As you can probably tell I think a unilateral fork without wide-scale consensus from the technical and business communities is a deeply inadvisable. While apparently some companies have expressed interest in increased scale, I can only assume they do no yet understand the risks. I suggest before they would actually go ahead that they seek independent advice. Of the overall process, I think you can agree we should not be making technical decisions with this level of complexity and consensus risk with financial implications of this magnitude under duress of haste? This seems otherwise a little like the moral hazard of the 2008 financial collapse that Satoshi put the quote in the genesis block about. I think its best that we progress as Jeff Garzik has done to have engineering discussions centre around BIPs, running code for review, simulation and careful analysis. I understand this has been going on for a long time, and some people are frustrated with the rate of progress, but making hasty, contentious or unilateral actions in this space is courting disaster. Please use your considerable skills to, along with the rest of the community, work on this problem collaboratively. I can sincerely assure you everyone does want to scale bitcoin and shares your long term objective on that. Adam -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
That would also introduce the anomaly of a script that was once valid becoming later invalid, when nothing varies other than time. That is not super compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorged. (Not a huge flexibility loss as you can implement not after by making it the previous holders responsibility to spend a not before back to themselves.) Adam On 2 June 2015 at 13:52, Stephen stephencalebmo...@gmail.com wrote: Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE. Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid. Best, Stephen On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script. I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time. On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time. I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute nLockTime, and it does so in a way that is semantically compatible with the originally envisioned use of sequence numbers for fast mempool transaction replacement. The disadvantages are that external constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and re-purposing nSequence as a relative lock-time precludes its use in other contexts. The latter point has been partially addressed by having the relative lock-time semantics be enforced only if the most-significant bit of nSequence is set. This preserves 31 bits for alternative use when relative lock-times are not required. The BIP draft can be found at
[Bitcoin-development] soft-fork block size increase (extension blocks)
Hi Gavin Sorry for slow response broken threading - mailbox filled up only saw your response on archive. I do earnestly think opt-in block-size increases are politically cleaner (gives different people different sized blocks by their own volition without forcing a compromise) and less risky than hard forks. Particularly if a hard-fork were really provoked without clear and wide consensus - dragons lay there. Then ask the various wallet developer how long it would take them to update their software to support something like this, I don't think thats any particular concern, extension block payments are forwards and backwards compatible. Businesses who are keen to have more transactions, would make it their problem to implement in their wallet, or ask the wallet vendor/maintainer they're working with to do it. Nothing breaks if they dont use it. The people that have the need for it will work on it. Market at work. If it turns out they dont really have a need for it, just projected huge numbers for their business plan that say dont materialise, well no foul. and do some UI mockups of what the experience would look like for users. I am not a UX guy, but for example it might be appropriate for tipping services or other micropayments to use an extension block. Or small retail payments. They can choose what address they use. Merchants, integrators etc can do likewise. It gives plenty enough scope that people can work with useful trade-offs while others work on lightning. If there are two engineering solutions to a problem, one really simple, and one complex, why would you pick the complex one? Because the more complex one is safer, more flexible, more future proof and better for decentralisation (and so as a bonus and might actually get done without more months of argument as its less contentious because it gives users choice to opt-in). Bitcoin itself is complex, a central ledger is simpler but as we know uninteresting which is to say this is a security tradeoff. Obviously I do appreciate KISS as a design principle, and utility of incremental improvements, but this is a security trade-off we're discussing here. I am proposing a way to not weaken security, while getting what you think is important - access to more TPS with a higher centralisation tradeoff (for those who opt-in to it, rather than for everyone whether that tradeoff is strongly against their interests or not). The decentralisation metrics are getting worse, not better, see Greg Maxwell's comments http://www.reddit.com/r/Bitcoin/comments/37vg8y/is_the_blockstream_company_the_reason_why_4_core/crqg381 This would not by those metrics be a good moment in history to make the situation worse. Especially if the complex solution has all of the problems of the simple one (20MB extension blocks are just as dangerous as 20MB main blocks, yes? If not, why not?) Not at all, thats the point. Bitcoin has a one-size fits all blocksize. People can pool mine the 8MB extension block, while solo or GBT mining the 1MB block. Thats more centralising than staying at 1MB (because to get the fees from the extension block some people without that kind of bandwidth are pool mining 8/9th of the lower security/decentralisation transactions. But its less centralising than a fixed blocksize of 9MB (1+8 for apples/apples) because realistically if those transactions are not spam, they would've happened offchain, and offchain until we get lightning like systems up, means central systems which are worse than the slight centralisation of 8MB blocks being single servers and prone to custody security failure. I think you made that point yourself in a recent post also. Sound good? ;) Seriously I think its the least bad idea I've heard on this topic. As an aside, a risk with using companies as a sounding board, is that you can get a misleading sense of consensus. Did they understand the tradeoff between security (decentralisation) and blocksize. Did they care? Do they represent users interests? Would they have voted instead for extension blocks if it was presented in similar terms? (I have to imagine they might have preferred extension blocks given the better story if you gloss over complexity and tradeoffs). Adam -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] soft-fork block size increase (extension blocks)
Mike wrote: Businesses who are keen to have more transactions, would make it their problem to implement in their wallet, or ask the wallet vendor/maintainer they're working with to do it. Nothing breaks if they dont use it. I don't see how this is the case. If an exchange supports extension blocks and I withdraw from that to a wallet that doesn't, the money will never arrive from my perspective. Yet the exchange will claim they sent it and they will wash their hands of the matter. Disaster. To be clear in case you are missing part of the mechanism.: it is forward and backwards compatible meaning a 1MB address can receive payments from an 8MB address (at reduced security if it has software that doesnt understand it) and a 1MB address can pay an 8MB address by paying to an OP_TRUE that has meaning to the extension block nodes. A 1MB client wont even understand the difference between a 1MB and 8MB out payment. An 8MB client will understand and pay 1MB addresses in a different way (moving the coin back to the 1MB chain). So its opt-in and incrementally deployable. Exchanges could encourage their users to use wallets that support 8MB blocks, eg by charging a fee for 1MB transactions. If 1MB blocks experience significant fee pressure, this will be persuasive. Or they could chose not to and eat the cost. This is all normal market adoption of a new cheaper technical option (in this case with a tradeoff of reduced security/more centralisation for those opting in to it). Because the more complex one is safer, more flexible, more future proof and better for decentralisation I disagree with all of those points. I find Lightning/Stroem etc to be more dangerous, less flexible, and worse for decentralisation. I explain why here: Extension blocks lightning are unrelated things. While I understand the need for being practical, there is IMO, amongst engineering maxims something as far as being too pragmatic, dangerously pragmatic even. We cant do stuff in bitcoin that has bad carry costs, nor throw out the baby with the bathwater. The situation is just that we are facing a security vs volume tradeoff and different people will have different requirements and comfort zones. If I am not misremembering, I think you've sided typically with the huge block, big data center only end of the spectrum. What I am proposing empowers you to do experiments in that direction without getting into a requirements conflict with people who value more strongly the bitcoin properties arising from it being robustly decentralised. I am not sure personally where the blocksize discussion comes out - if it stays as is for a year, in a wait and see, reduce spam, see fee-pressure take effect as it has before, work on improving improve decentralisation metrics, relay latency, and do a blocksize increment to kick the can if-and-when it becomes necessary and in the mean-time try to do something more long-term ambitious about scale rather than volume. Bitcoin without scale improvements probably wont get the volume people would like. So scale is more important than volume; and security (decentralisation) is important too. To the extreme analogy we could fix scale tomorrow by throwing up a single high perf database, but then we'd break the security properties arising from decentralisation. We should improve both within an approximately safe envelope IMO. Adam -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
So lets rephrase that and say instead more correctly it is the job of miners (collectively) to be well connected globally - and indeed there are incentivised to be or they tend to receive blocks at higher latency and so are at increased risk of orphans. And miner groups with good block latency in-group and high hashrate are definitionally the well connected, so the cost of getting good connectivity to high hashrate groups is naturally borne by people outside of those groups. Or thats the incentive anyway. Adam On 1 June 2015 at 19:30, Mike Hearn m...@plan99.net wrote: I don't see this as an issue of sensitivity or not. Miners are businesses that sell a service to Bitcoin users - the service of ordering transactions chronologically. They aren't charities. If some miners can't provide the service Bitcoin users need any more, then OK, they should not/cannot mine. Lots of miners have come and gone since Bitcoin started as different technology generations came and went. That's just business. -- ___ 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
[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction
I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons. The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an extension block (say 10MB) and the existing 1MB block. The extension block is committed to in the 1MB chain. Users can transfer bitcoin into the extension block, and they can transfer them out. The interesting thing is this makes block sizes changes opt-in and gives users choice. Choice is good. Bitcoin has a one-size-fits-all blocksize at present hence the block size debate. If a bigger block-size were an opt-in choice, and some people wanted 10MB or even 100MB blocks for low value transactions I expect it would be far easier a discussion - people who think 100MB blocks are dangerously centralising, would not opt to use them (or would put only small values they can afford to lose in them). There are some security implications though, so this also is nuanced, and more on that in a bit. Fee pressure still exists for blocks of difference size as the security assurances are not the same. It is plausible that some people would pay more for transactions in the 1MB block. Now there are three choices of validation level, rather than the normal 2-levels of SPV or full-node, with extension blocks we get a choice: A) a user could run a full node for both 1MB and 10MB blocks, and get full security for both 1MB and 10MB block transactions (but at higher bandwidth cost), or B) a user could run a full node on the 1MB block, but operate as an SPV node for the 10MB block, or C) run in SPV mode for both 1MB and 10MB blocks. Similarly for mining - miners could validate 1MB and 10MB transactions (solo mine or GBT-style), or they could self-validate 1MB transactions and pool mine 10MB transactions (have a pool validate those). 1MB full node users who do not upgrade to software that understands extension blocks, could run in SPV mode with respect to 10MB blocks. Here lies the risk - this imposes a security downgrade on the 1MB non-upgraded users, and also on users who upgrade but dont have the bandwidth to validate 10MB blocks. We could defend non-upgrade users by making receiving funds that came via the extension block opt-in also, eg an optional to use new address version and construct the extension block so that payments out of it can only go to new version addresses. We could harden 1MB block SPV security (when receiving weaker extension block transactions) in a number of ways: UTXO commitments, fraud proofs (and fraud bounties) for moving from the extension block to the 1MB block. We could optionally require coins moving via the extension block to the 1MB block to be matured (eg 100 blocks delay) Anyway something else to evaluate. Not as simple to code as a hard-fork, but way safer transition than a hard-fork, and opt-in - if you prefer the higher decentralisation of 1MB blocks, keep using them; if you prefer 10MB blocks you can opt-in to them. Adam On 29 May 2015 at 17:39, Raystonn . rayst...@hotmail.com wrote: Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution. Regarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners. Someone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well. From: Tier Nolan Sent: Friday, May 29, 2015 7:22 AM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote: On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com wrote: But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. How do you define that the movement is successful? Sorry again, I
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
The general idea for replace by fee is that it would be restricted so as to make it safe, eg all the original addresses should receive no less bitcoin (more addresses can be added). The scorched earth game theory stuff (allowing removing recipients) is kind of orthogonal. Adam On 26 May 2015 at 19:22, Danny Thorpe danny.tho...@gmail.com wrote: What prevents RBF from being used for fraudulent payment reversals? Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast a double spend of that transaction to pay Alice nothing? Your only cost is the higher network fee of the 2nd tx. Thanks, -Danny On Mon, May 25, 2015 at 5:10 PM, Peter Todd p...@petertodd.org wrote: On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing the fee on a single tx -- Creating an spending a P2PKH output uses 34 bytes of txout, and 148 bytes of txin, 182 bytes total. Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. I forget to click on the priority fee option, so it goes out with the minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, creating a new transaction t2 that's 192 bytes in size. I want to pay 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of transaction fees. On the other hand, had I use RBF, my wallet would have simply rebroadcast t1 with the change address decreased. The rules require you to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new fee level, or 218uBTC of fees in total. Cost savings: 48% Case 2: Paying multiple recipients in succession Suppose that after I pay Alice, I also decide to pay Bob for his hard work demonstrating cryptographic protocols. I need to create a new transaction t2 spending t1's change address. Normally t2 would be another 226 bytes in size, resulting in 226uBTC additional fees. With RBF on the other hand I can simply double-spend t1 with a transaction paying both Alice and Bob. This new transaction is 260 bytes in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth consumed broadcasting it, resulting in an additional 36uBTC of fees. Cost savings: 84% Case 3: Paying multiple recipients from a 2-of-3 multisig wallet The above situation gets even worse with multisig. t1 in the multisig case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC in fees. With RBF we rewrite t1 with an additional output, resulting in a 399 byte transaction, with just 36uBTC in additional fees. Cost savings: 90% Case 4: Dust defragmentation My wallet has a two transaction outputs that it wants to combine into one for the purpose of UTXO defragmentation. It broadcasts transaction t1 with two inputs and one output, size 340 bytes, paying zero fees. Prior to the transaction confirming I find I need to spend those funds for a priority transaction at the 1mBTC/KB fee level. This transaction, t2a, has one input and two outputs, 226 bytes in size. However it needs to pay fees for both transactions at once, resulting in a combined total fee of 556uBTC. If this situation happens frequently, defragmenting UTXOs is likely to cost more in additional fees than it saves. With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 bytes in size, paying 374uBTC. Even better, if one of the two inputs is sufficiently large to cover my costs I can doublespend t1 with a 1-in-2-out tx just 226 bytes in size, paying 226uBTC. Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF costs you more than you save -- 'peter'[:-1]@petertodd.org 134ce6577d4122094479f548b997baf84367eaf0c190bc9f -- 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
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
Well so for example it could have an additional input (to increase the BTC paid into the transaction) and pay more to an existing change address and higher fee, or add an additional change address, and leave a larger fee, or if you had a right-sized coin add an additional input that all goes to fees. (As well as optionally tacking on additional pending payments to other addresses funded from the higher input). Adam On 26 May 2015 at 22:29, s7r s...@sky-ip.org wrote: What is wrong with the man testing some ideas on his custom branch? This is how improvements come to life. I saw in the BIPs some really interesting ideas and nice brainstorming which came from Peter Todd. Now, my question, if replace by fee doesn't allow me to change the inputs or the outputs, I can only add outputs... what can I do with this feature? If I sent a tx and want to replace it with a higher fee one, the higher fee one can only have maybe additional change addresses or another payment, if the inputs suffice? Do we have any real use cases? P.S. is it planned to include this by default in bitcoin core 10.0.3 or it will remain just on Peter's branch? On 5/26/2015 11:30 PM, joli...@airmail.cc wrote: You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks and you have big banks as clients. Shit like replace-by-fee and leading the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out. Peter Todd - 8930511 Canada Ltd. 1214-1423 Mississauga Valley Blvd. Mississauga ON L5A 4A5 Canada https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511 On 2015-05-26 00:10, Peter Todd wrote: On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing the fee on a single tx -- Creating an spending a P2PKH output uses 34 bytes of txout, and 148 bytes of txin, 182 bytes total. Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. I forget to click on the priority fee option, so it goes out with the minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, creating a new transaction t2 that's 192 bytes in size. I want to pay 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of transaction fees. On the other hand, had I use RBF, my wallet would have simply rebroadcast t1 with the change address decreased. The rules require you to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new fee level, or 218uBTC of fees in total. Cost savings: 48% Case 2: Paying multiple recipients in succession Suppose that after I pay Alice, I also decide to pay Bob for his hard work demonstrating cryptographic protocols. I need to create a new transaction t2 spending t1's change address. Normally t2 would be another 226 bytes in size, resulting in 226uBTC additional fees. With RBF on the other hand I can simply double-spend t1 with a transaction paying both Alice and Bob. This new transaction is 260 bytes in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth consumed broadcasting it, resulting in an additional 36uBTC of fees. Cost savings: 84% Case 3: Paying multiple recipients from a 2-of-3 multisig wallet The above situation gets even worse with multisig. t1 in the multisig case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC in fees. With RBF we rewrite t1 with an additional output, resulting in a 399 byte transaction, with just 36uBTC in additional fees. Cost savings: 90% Case 4: Dust defragmentation My wallet has a two transaction outputs that it wants to combine into one for the purpose of UTXO defragmentation. It broadcasts transaction t1 with two inputs and one output, size 340 bytes, paying zero fees. Prior to the transaction confirming I find I need to spend those funds for a priority transaction at the 1mBTC/KB fee level. This transaction, t2a, has one input and two outputs, 226 bytes in size. However it needs to pay fees for both transactions at once, resulting in a combined total fee of 556uBTC. If this situation happens frequently, defragmenting UTXOs is likely to cost more in additional fees than it saves. With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 bytes in size, paying 374uBTC. Even better, if one of the two inputs is sufficiently large to cover my costs I can doublespend t1 with a 1-in-2-out tx just 226 bytes in size, paying 226uBTC. Cost savings: 32% to 59%, or even infinite if defragmentation
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
I think the point is the replacement tx spends the same inputs (plus additional inputs), so if the original tx is accepted, and your replacement rejected, thats good news - you dont have to pay the higher fee, the extra input remains unspent (and can be used later for other purpose) and the extra change address is unused. (If you had bundled extra transactions into the replacement, spending from the additional inputs, then you'll need to resubmit those as a separate transaction). (You have to keep in mind re-orgs so for example the original tx could be put into a block, and then that block could get reorged by another block that grows into a longer chain with the replacement tx in it (or vice versa)). Adam On 26 May 2015 at 23:09, Danny Thorpe danny.tho...@gmail.com wrote: Thanks for the clarification. So, since RBF applies only to pending transactions in the mempool awaiting incorporation into a block, there is a window of opportunity in which the pending tx is incorporated into a block at the same time that the spender is constructing and publishing a replacement for that pending tx. The replacement transaction would be rejected by the peer network as a double spend because it conflicts with the now confirmed original tx, and the spender will have to go back and create a new stand-alone transaction to accomplish what they hoped to do with an RBF replacement. So an implementation that wishes to take advantage of RBF will still need to have a plan B implementation path to handle the corner case of a replacement tx being rejected as a double spend. Is this correct? I'm just trying to get my head around the implementation cost vs benefit of RBF in the context of my applications. Thanks, -Danny On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille pieter.wui...@gmail.com wrote: It's just a mempool policy rule. Allowing the contents of blocks to change (other than by mining a competing chain) would be pretty much the largest possible change to Bitcoin's design -- ___ 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
I think its fair to say no one knows how to make a consensus that works in a decentralised fashion that doesnt weaken the bitcoin security model without proof-of-work for now. I am presuming Gavin is just saying in the context of not pre-judging the future that maybe in the far future another innovation might be found (or alternatively maybe its not mathematically possible). Towards that it would be useful to try further to prove this one way or another (prove that proof of stake cant work if that is generically mathematically provable). Adam On 12 May 2015 at 14:24, Pedro Worcel pe...@worcel.com wrote: Disclaimer: I don't know anything about Bitcoin. 2) Proof-of-idle supported (I wish Tadge Dryja would publish his proof-of-idle idea) 3) Fees purely as transaction-spam-prevention measure, chain security via alternative consensus algorithm (in this scenario there is very little mining). I don't understand why you would casually mention moving away from Proof of Work, I thought that was the big breakthrough that made Bitcoin possible at all? Thanks, Pedro 2015-05-13 4:10 GMT+12:00 Gavin Andresen gavinandre...@gmail.com: Added back the list, I didn't mean to reply privately: Fair enough, I'll try to find time in the next month or three to write up four plausible future scenarios for how mining incentives might work: 1) Fee-supported with very large blocks containing lots of tiny-fee transactions 2) Proof-of-idle supported (I wish Tadge Dryja would publish his proof-of-idle idea) 3) Fees purely as transaction-spam-prevention measure, chain security via alternative consensus algorithm (in this scenario there is very little mining). 4) Fee supported with small blocks containing high-fee transactions moving coins to/from sidechains. Would that be helpful, or do you have some reason for thinking that we should pick just one and focus all of our efforts on making that one scenario happen? I always think it is better, when possible, not to bet on one horse. On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin thom...@electrum.org wrote: Le 12/05/2015 15:44, Gavin Andresen a écrit : Ok, here's my scenario: https://blog.bitcoinfoundation.org/a-scalability-roadmap/ It might be wrong. I welcome other people to present their road maps. [answering to you only because you answered to me and not to the list; feel free to repost this to the list though] Yes, that's exactly the kind of roadmap I am asking for. But your blog post does not say anything about long term mining incentives, it only talks about scalability. My point is that we need the same kind of thing for miners incentives. -- -- Gavin Andresen -- 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 -- 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] Mechanics of a hard fork
Well this is all very extreme circumstances, and you'd have to assume no rational player with an interest in bitcoin would go there, but to play your analysis forward: users are also not powerless at the extreme: they could change the hash function rendering current deployed ASICs useless in reaction for example, and reset difficulty at the same time, or freeze transactions until some minimum hashrate is reached. People would figure out what is the least bad way forward. Adam On May 7, 2015 3:09 PM, Roy Badami r...@gnomon.org.uk wrote: On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Surely, in that scenario Bitcoin is dead. If the fork you prefer has only 1% of the hash power it is trivially vulnerably not just to a 51% attack but to a 501% attack, not to mention the fact that you'd only be getting one block every 16 hours. A hardfork is safe when 100% of (economically relevant) users upgrade. If miners don't upgrade at that point, they just lose money. This is why a hashrate-triggered hardfork does not make sense. Either you believe everyone will upgrade anyway, and the hashrate doesn't matter. Or you are not certain, and the fork is risky, independent of what hashrate upgrades. Beliefs are all very well, but they can be wrong. Of course we should not go ahead with a fork that we believe to be dangerous, but requiring a supermajority of miners is surely a wise precaution. I fail to see any realistic scenario where 99% of miners vote for the hard fork to go ahead, and the econonomic majority votes to stay on the blockchain whose hashrate has just dropped two orders of magnitude - so low that the mean time between blocks is now over 16 hours. And the march 2013 fork showed that miners upgrade at a different schedule than the rest of the network. On May 7, 2015 5:44 PM, Roy Badami r...@gnomon.org.uk wrote: On the other hand, if 99.99% of the miners updated and only 75% of merchants and 75% of users updated, then that would be a serioud split of the network. But is that a plausible scenario? Certainly *if* the concensus rules required a 99% supermajority of miners for the hard fork to go ahead, then there would be absoltely no rational reason for merchants and users to refuse to upgrade, even if they don't support the changes introduces by the hard fork. Their only choice, if the fork succeeds, is between the active chain and the one that is effectively stalled - and, of course, they can make that choice ahead of time. roy -- 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 -- 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
[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
I agree with Mike Jeff. Blowing up 0-confirm transactions is vandalism. bitcoin transactions are all probabilistic. there is a small chance 1-confirm transactions can be reversed, and a different but also usable chance that 0-confirm transactions can be reversed. I know 0-confirm is implemented in policy and not consensus, but it provides fast transactions and a lot of the current ecosystem is using it for low value transactions. why would anyone want to vandalise that. to echo Mike bitcoin itself kind of depends on some honest majority, we can otherwise get to situations soon enough where its more profitable to double-spend than mine honestly as subsidy drops and transaction values increase even without 0-confirm transactions. subsidy doesnt last forever (though it lasts a really long time) and even right now if you involve values that dwarf subsidy you could make a criminally rational behaviour that was more profitable. we even saw 0-confirm odds-attacks against satoshi dice clones. but if we assume the criminal rational model, its a is a race to the bottom logic, and bitcoin is already broken if we have someone who wants to go for it with high values. that'd be scorched earth also. (I read the rest of the arguments, i understood them, I disagree, no need to repeat in reply.) So how about instead, to be constructive, whether you agree with the anti-arson view or not, lets talk about solutions. Here's one idea: We introduce a new signature type that marks itself as can be spent by miners if a double-spend is seen (before 1-confirm.) We'd define a double-spend as a spend that excludes outputs to avoid affecting valid double-spend scenarios. And we add behaviour to relay those double-spends (at priority). We may even want the double-spend to be serialisation incomplete but verifiable to deter back-channel payments to pretend not to receive one, in collusion with the double-spending party. Now the risk to the sender is if they accidentally double-spend. How could they do that? By having a hardware or software crash where they sent a tx but crashed before writing a record of having sent it. The correct thing to do would be to transactionally write the transaction before sending it. Still you can get a fail if the hardware irrecoverably fails, and you have to resume from backup. Or if you run multiple non-synced wallets on the same coins. Typically if you recover from backup the 1-confirmation window will have passed so the risk is limited. The feature is opt-in so you dont have to put high value coins at risk of failure. (Its related to the idea of a one-use signature, where two signatures reveals a simultaneous equation that can recover the private key; except here the miner is allowed to take the coins without needing the private key). Its soft-forkable because its a new transaction type. ps I agree with Greg also that longer-term more scalable solutions are interesting, but I'd like to see the core network work as a stepping stone. As Justus observed: the scalable solutions so far have had non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain 0-confirm. Adam On 22 February 2015 at 04:06, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: 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. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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 -- Download BIRT iHub F-Type - The
Re: [Bitcoin-development] bloom filtering, privacy
If you want to be constructive and index transactions that are not p2sh but non-simple and contain checksig so the address is visible, you could do that with a block bloom filter also. I wasnt sure if the comments about the need to batch requests was about downloading headers filters, or about transactions, there is no harm downloading headers bloom filters without Tor - there is no identity nor addresses revealed by doing so. So over Tor you would just be fetching transactions that match the address. For downloading transactions unless you frequently receive transactions you wont be fetching every block. Or are you assuming bloom filters dialled up to the point of huge false positives? You said otherwise. Mid-term I'd say you want some basic request tunneling as part of bitcoin, that maybe isnt Tor, to avoid sharing their fate if Tor controversies are a risk to Tor service. Some of the bitcoin-Tor specific weak points could maybe then be addressed. Relatedly I think bitcoin could do with a store-and-forward message bus with privacy and strong reliability via redundancy (but less redundancy maybe than consensus all-nodes must receiving and agree and store forever). That provides an efficient store-and-forward SPV receivable stealth-address solution that doesnt suck: send the recipient their payment, if they like it they broadcast it themselves. As a bonus store-and-forward message mixes are better able to provide meaningful network privacy than interactive privacy networks. You could spend over the same channel You seem to be saying at one point that Tor is useless against pervasive eavesdropper threat model (which I am not sure I agree with, minimally it makes them work for the info and adds uncertainty; and not been paying super close attention but I think some of the Snowden releases suggest Tor is a net win) and secondly that other types of attackers are disinterested (how do we know that?) or maybe that you dont care about privacy vs them (maybe some users do!) It would certainly be nice to get real privacy from a wider range of attackers but nothing (current situation) is clearly worse; using block bloom filters we'd make the pervasive case harder work, and the nosy full node learn nothing. Adam On 21 February 2015 at 13:28, Mike Hearn m...@plan99.net wrote: Let's put the UTXO commitments/anti-fraud proofs to one side for a moment. I would like to see them happen one day, but they aren't critical to these protocols and are just proving to be a distraction. Then they make fresh random connections to different nodes and request download of the respective individual transactions from the full node. ... About privacy the node can make different random connections to different nodes to fetch addresses . The full node cant correlate the addresses as belonging to the same person by correlating the download requests for them, because they are made via different nodes. Apologies for the wall of text, but I don't think this will work nor solve any real problem. And I must justify such a strong statement clearly. First: technical issues When you download the per-block Bloom filter and test, what you get back is a set of script elements (addresses, keys, OP_RETURN tags etc). But then in the next step you are saying that you connect to random peers and request individual transactions. We don't know that at this point. All we know are a set of addresses that possibly matched. So I think what you mean is wallets connect to random peers and request transactions in block N that match a given set of addresses. This is what Bloom filtering already does, of course. Doing the test against the per-block filter first doesn't seem to buy us much because with thousands of transactions per block, even a very tiny FP rate will still trigger a match on every single one. The second problem I see is that we can't do this in parallel because of the following edge case: wallet contains key K and someone sends it money using an OP_CHECKSIG output. The input which spends this output does not contain any predictable data, thus we do not know what to look for in the following blocks to detect a spend of it until we have seen the first transaction and know its hash. In practice this means we must either scan through the chain in sequence and update our matching criteria if we see such an output (this is what the Bloom filtering protocol already does server-side), or we must constrain the user such that output scripts always force repetition of predictable data - this is what mostly happens today due to pay-to-address outputs, but not always, and correctness is more important than completeness. If we can't do it in parallel then we must suffer a node round-trip for every single block we traverse, because we can't request long runs of blocks with a single command. That latency will kill performance dead. It's a non starter. But let's imagine we don't care about
[Bitcoin-development] bloom filtering, privacy
I saw there was some discussion on this topic on the bitcoinj list. (I dont think I can post there without subscribing probably.) Someone had posted about the lack of privacy provision from the current implementation parameters and real-world factors similar to described in this academic paper http://eprint.iacr.org/2014/763.pdf Mike had posted a detailed response on the topic on why its complex and becomes bandwidth inefficient to improve it usefully. https://groups.google.com/forum/#!msg/bitcoinj/Ys13qkTwcNg/9qxnhwnkeoIJ The basic summary of which I think is that its not even intended to provide any practical privacy protection, its just about compacting the query for a set of addresses. So I was wondering what about changing to committing a bloom filter of the addresses in the block. Its seems surprising no one thought of it that way before (as it seems obvious when you hear it) but that seems to address the privacy issues as the user can fetch the block bloom filters and then scan it in complete privacy. (Someone appeared on bitcoin wizards IRC a while back and made this observation.) From there its a question of fetching the candidate TXOs. Am I missing anything? Adam -- 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] bloom filtering, privacy
Mike Hearn wrote: Adam Back wrote: Its seems surprising no one thought of it that way before (as it seems obvious when you hear it) but that seems to address the privacy issues as the user can fetch the block bloom filters and then scan it in complete privacy. And then what? So you know the block matches. But with reasonable FP rates every block will match at least a few transactions (this is already the case - the FP rate is low but high enough that we get back FPs on nearly every block). So you end up downloading every block? I mean because the user is scanning he can binary search which set of addresses from his wallet are possibly in the block and then request the specific addresses and some will be false positives and some real, but with the bloom commitment (and UTXO trie organised commitment) he can verify that the positive hits are correct via the merkle path, and that the false positives are not being wrongly withheld by obtaining merkle path proof that they are not in the trie. Adam On 20 February 2015 at 16:54, Mike Hearn m...@plan99.net wrote: Hey Adam, Mike had posted a detailed response on the topic on why its complex and becomes bandwidth inefficient to improve it usefully. To clarify, we could improve privacy and still preserve usefully high performance, it's just a lot of complicated programming work. You need to find out from the OS how much bandwidth you have to play with, for example, and do all the very complex tracking to surf the wave and keep yourself in roughly the right place. The basic summary of which I think is that its not even intended to provide any practical privacy protection, its just about compacting the query for a set of addresses. The original intent of Bloom filtering was to allow both. We want our cake and we want to eat it. The protocol can still do that, with sufficiently smart clients. The problem is that being sufficiently smart in this regard has never come to the top of the TODO list - users are always complaining about other things, so those things are what gets priority. It's not IMO a protocol issue per se. It's a code complexity and manpower issue. Its seems surprising no one thought of it that way before (as it seems obvious when you hear it) but that seems to address the privacy issues as the user can fetch the block bloom filters and then scan it in complete privacy. And then what? So you know the block matches. But with reasonable FP rates every block will match at least a few transactions (this is already the case - the FP rate is low but high enough that we get back FPs on nearly every block). So you end up downloading every block? That won't work. Eventually, wallets need to stop doing linear scans of the entire block chain to find tx data. That worked fine when blocks were 10kb, it's still working OK even though we scaled through two orders of magnitude, but we can imagine that if we reach 10mb blocks then this whole approach will just be too slow. The main reason wallets are scanning the chain today (beyond lack of protocol support for querying the UTXO set by script), is that they want to show users time-ordered lists of transactions. Financial apps should show you payment histories, everyone knows this, and without knowing roughly when a tx happened and which inputs/outputs were mine, providing a useful rendering is hard. Even with this data the UI is pretty useless, but at least it's not actually missing. By combining Subspace and BIP70 we can finally replace the payments list UI with actual proper metadata that isn't extracted from the block chain, and at that point non-scanning architectures become a lot more deployable. -- 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] bloom filtering, privacy
The idea is not mine, some random guy appeared in #bitcoin-wizards one day and said something about it, and lots of people reacted, wow why didnt we think about that before. It goes something like each block contains a commitment to a bloom filter that has all of the addresses in the block stored in it. Now the user downloads the headers and bloom data for all blocks. The know the bloom data is correct in an SPV sense because of the commitment. They can scan it offline and locally by searching for addresses from their wallet in it. Not sure off hand what is the most efficient strategy, probably its pretty fast locally anyway. Now they know (modulo false positives) which addresses of theirs maybe in the block. So now they ask a full node for merkle paths + transactions for the addresses from the UTXO set from the block(s) that it was found in. Separately UTXO commitments could optionally be combined to improve security in two ways: - the normal SPV increase that you can also see that the transaction is actually in the last blocks UTXO set. - to avoid withholding by the full node, if the UTXO commitment is a trie (sorted) they can expect a merkle path to lexically adjacent nodes either side of where the claimed missing address would be as a proof that there really are no transactions for that address in the block. (Distinguishing false positive from node withholding) Adam On 20 February 2015 at 17:43, Mike Hearn m...@plan99.net wrote: Ah, I see, I didn't catch that this scheme relies on UTXO commitments (presumably with Mark's PATRICIA tree system?). If you're doing a binary search over block contents then does that imply multiple protocol round trips per synced block? I'm still having trouble visualising how this works. Perhaps you could write down an example run for me. How does it interact with the need to download chains rather than individual transactions, and do so without round-tripping to the remote node for each block? Bloom filtering currently pulls down blocks in batches without much client/server interaction and that is useful for performance. Like I said, I'd rather just junk the whole notion of chain scanning and get to a point where clients are only syncing headers. If nodes were calculating a script-(outpoint, merkle branch) map in LevelDB and allowing range queries over it, then you could quickly pull down relevant UTXOs along with the paths that indicated they did at one point exist. Nodes can still withhold evidence that those outputs were spent, but the same is true today and in practice this doesn't seem to be an issue. The primary advantage of that approach is it does not require a change to the consensus rules. But there are lots of unanswered questions about how it interacts with HD lookahead and so on. -- 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?)
Strongly with Peter on this. That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments; it tells you that the risk is exponentially worse and people should use and rally around libconsensus. I would advise any bitcoin ecosystem part, wallet, user to not use software with consensus protocol rw-writes nor variants, you WILL lose money. You could view bitcoin as a digital signature algorithm speculatively tinkering with the algo is highly prone to binary failure mode and unbounded funds loss. Want to be clear this is not a political nor emotive issue. It is a critical technical requirement for security if users of software people write. Please promote this meme. Adam On Feb 14, 2015 6:24 AM, Tamas Blummer ta...@bitsofproof.com wrote: Peter, You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library, 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. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: Or you can be stereotypical programmers and dick around on github for the next ten years chasing stupid consensus bugs in code no-one uses. 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. It is entirely rational for me to focus on innovation that uses the core as a border router for this block chain. 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. Tamas Blummer Bits of Proof -- 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] SIGHASH_WITHINPUTVALUE
its an always offline node, so it knows nothing really other than a BIP 32 hierarchy of keys a signature request. So the signature request has to drag with it information to validate what the value is, in order to be sure not to sign away 99% to fees. Signing the transaction value and having the network validate that the value in the sig matches full nodes view of the tx value avoids that issue. Simple, elegant, but... we have no live beta mechanism, and hence risk testing makes that tricky. Plus the full network upgrade issue if its not backwards compatible. Adam On 23 January 2015 at 16:08, Tamas Blummer ta...@bitsofproof.com wrote: You mean an isolated signing device without memory right? An isolated node would still know the transactions substantiating its coins, why would it sign them away to fees ? Tamas Blummer On Jan 23, 2015, at 4:47 PM, slush sl...@centrum.cz wrote: Correct, plus the most likely scenario in such attack is that the malware even don't push such tx with excessive fees to the network, but send it directly to attacker's pool/miner. M. On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner etothe...@gmail.com wrote: Unfortunately, one major attack vector is someone isolating your node, getting you to sign away your whole wallet to fee, and then selling it to a mining pool to mine it before you can figure why your transactions aren't making it to the network. In such an attack, the relay rules aren't relevant, and if the attacker can DoS you for 24 hours, it doesn't take a ton of mining power to make the attack extremely likely to succeed. On 01/23/2015 10:31 AM, Tamas Blummer wrote: Not a fix, but would reduce the financial risk, if nodes were not relaying excessive fee transactions. Tamas Blummer -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ 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 20 December 2014 at 14:48, Peter Todd p...@petertodd.org wrote: We need the following primitives operating on message m, pubkey p, and a valid signature sig1 for m, p: AntiReplaySign(m, p, sig1) - sig2 VerifyAntiReplaySig(m, p, sig2) - True or False Additionally once AntiReplaySign() has been used once for a given pubkey it is impossible to re-run the primitive on a different message m'. This is of course impossible to implement with math alone, but we can implement it with a trusted third party. Well while you cant prevent it you could render it insecure enabling miners to take funds. That could work via a one-show signature; normal ECDSA being address a=H(Q), public key Q=dG, R=kG, r=R.x, s=(H(m)+rd)/k, signature (r,s), verify: a=?H(Q) and sR=?H(m)G+rQ one-show being: a=H(Q,R), verify being: a=?H(Q,R) and sR=?H(m)G+rQ. Now that is unsafe to double-spend by design as only that specific R is usable and as we know reusing R with different messages leaks the private key because: s=(H(m)+rd)/k and s'=(H(m')+rd)/k implies sk=H(m)+rd and s'k=H(m')+rd so k=(H(m)-H(m'))/(s'-s), and d=(sk-H(m))/r. Adam -- 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=/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
It seems to me that people maybe arriving at the idea that they should put transaction data in the blockchain for three related reasons: a) its there and its convenient; and b) they are thinking about permanent storage and being able to recover from backup using a master seed to a bip32 address-set and want that logic to extend to the extra features; c) they are thinking out of band, but they think they are forced to send the data there in order to achieve atomicity. I think the data that is sent on the blockchain is design-compressed minimal necessary to achieve transaction integrity, and its important for scalability that we keep it that way. About the rationales for using that scarce scalability impacting channel: a) convenience: is not a great reason to my mind. there are lots of channels: email, web forms, point2point various transports NFC, TCP, HTTP for payment protocol or extensions or new protocols. I think there could be a need for a reliable privacy preserving store and forward decentralised infrastructure to act as a channel for such purposes. Until then email could be pretty convenient, if you dont get the message due to spam filter etc ask them to resend. Or a web storage locker related to the app. b) backup: the blockchain is not an efficient reliable generic backup mechanism because its broadcast. there are cheaper and relatively simple ways to get end2end secure backup, the main challenge of which is having secure keys and not forgetting them. bitcoin already has that covered as its a central requirement of blockchain security. If you want to archive your payment protocol receipts store them on some cloud storage service or disk encrypted with related keys. for example tahoe-lafs is optimised for the decentralised long-term storage kind of use. c) atomicity. as an example application requiring atomicity that may use op_return stealth addresses where if the stealth auxiliary message was sent out of band, then if message is lost, and the sender didnt keep it or cant be relied on to care, then the money could be permanently lost to both parties. It occurred to me recently the kind of use requiring atomicity as stealth address in c) can be achieved by sending both the extra message (the stealth packet) AND the signed bitcoin transaction over the reliable store forward (eg email for now). Then the recipient can do the calculations involving the auxiliary message and payment message, and relay the message to the blockchain IFF they receive the message (and chose to accept it). If they dont receive the message they can ask for it to be resent. And if the payment is unclaimed the sender still owns it and can double-spend to avoid risk of later spending in their replacement message, or double-spend to self if the recipient declines the payment. This has privacy, efficiency and SPV advantages over sending to the blockchain. I think we could make a case that as a design principle auxiliary data could do with a bitcoin-related but separate reliable store and forward channel, as email has been sufficiently spammed to end up with loss of reliability. So I think a payment message transport would be good here: invoices receipts, and other things necessary for applications, transaction disputes, records for normal p2p trades and business functions reliable store and forward substrate with decentralisation privacy. For email the existing mechanism with closest semantics, add-on privacy features exist: mixmaster, nymservers, webmail + encryption, webmail over Tor etc for privacy related uses. Slow transports can offer better security than interactive transports. Adam On 17 November 2014 10:35, Pieter Wuille pieter.wui...@gmail.com wrote: On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner etothe...@gmail.com wrote: On 11/16/2014 02:04 PM, Jorge Timón wrote: 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. For reference, there was a brief time where I was irritated that the size had been reduced to 40 bytes, because I had an application where I wanted to put ECDSA in signatures in the OP_RETURN, and you're going to need at least 64 bytes for that. Unfortunately I can't remember now what that application was, so it's difficult for me to argue for it. But I don't think that's an unreasonable use case: sending a payment with a signature, essentially all timestamped in the blockchain. You can still send the signature out of band (for example using the payment protocol), and just have the transaction commit to a hash of that signature (or message in general), either using an OP_RETURN output to store the hash, or using the pay-to-contract scheme that Jorge mentioned above. That has exactly the same timestamping properties. My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport
Re: [Bitcoin-development] death by halving
Some thoughts about Alex's analysis: - bitcoin price may increase (though doubling immediately might be unlikely) after the halving (because the new coins are in short supply). Apparently there is some evidence of a feedback loop between number of freshly mined coins sold to cover electrical costs ongoing (which depends on halving also), in that there are claims that the btc price experiences some downwards pressure when margins are slim as miners sell almost all of them when the electrical cost takes most of the profit, and otherwise tend more to hold coins longer term. - that people who cant make money mining with 1/2 reward will resort to attacking the network rather than living with it for 2weeks until difficulty adjustment). actually it will be longer than two weeks if its going to result in a difficulty fall. - that the miners wont act in their own meta-interest to aim for the plausible new hashrate supported by the lower reward. mining equipment investment horizon being 3-6mo+ so it can easily make economic sense to subsidise it for a bit to smooth the transition. - fees might go up to unjam the network also, so the people benefitting from the transactions utility also help cover the transition costs. or maybe someone makes an assurance contract to pay the short fall and phase it out over a few months to smooth the shift. - there is a wide range of electrical efficiency, and some are much worse than others so there maybe a convenient equilibrium where there are enough left who can still profit. - alternatively you might say why not 1/100th reward reduction per 2 week period rather than 1/2 every 4 years, a difficulty retarget could be a convenient point to do that. Adam On 25 October 2014 11:06, Alex Mizrahi alex.mizr...@gmail.com wrote: # Death by halving ## Summary If miner's income margin are less than 50% (which is a healthy situation when mining hardware is readily available), we might experience catastrophic loss of hashpower (and, more importantly, catastrophic loss of security) after reward halving. ## A simple model Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the total revenue miner receives over a period of time, and C_e is the cost of electricity spent on mining over the same period of time. (Note that for the sake of simplicity we do not take into account equipment costs, amortization and other costs mining might incur.) Also we will assume that transaction fees collected by miner are negligible as compared to the subsidy. Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy halving and bitcoin and electricity prices stay the same, then mining is no longer profitable after the halving. Indeed, suppose the revenue after the halving is R' = R/2. MIM = (R-C_e)/R 0.5 R/2 C_e. R' = R/2 C_e. If revenue after halving R' doesn't cover electricity cost, a rational miner should stop mining, as it's cheaper to acquire bitcoins from the market. ~~~ Under these assumptions, if the majority of miners have MIM less than 0.5, Bitcoin is going to experience a significant loss of hashing power. But are these assumptions reasonable? We need a study a more complex model which takes into account changes in bitcoin price and difficulty changes over time. But, first, let's analyze significance of 'loss of hashpower'. ## Catastrophic loss of hashpower Bitcoin security model relies on assumption that a malicious actor cannot acquire more than 50% of network's current hashpower. E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double Spending_ paper which shows that as long as the malicious actor controls only a small fraction of total hashpower, attacks have well-define costs. But if the attacker-controlled hashrate is higher than 50%, attacks become virtually costless, as the attacker receives double-spending revenue on top of his mining revenue, and his risk is close to zero. Note that the simple model described in the aforementioned paper doesn't take into account attack's effect on the bitcoin price and the price of the Bitcoin mining equipment. I hope that one day we'll see more elaborate attack models, but in the meantime, we'll have to resort to hand-waving. Consider a situation where almost all available hashpower is available for a lease to the highest bidder on the open market. In this case someone who owns sufficient capital could easily pull off an attack. But why is hashpower not available on the market? Quite likely equipment owners are aware of the fact that such an attack would make Bitcoin useless, and thus worthless, which would also make their equipment worthless. Thus they prefer to do mining for a known mining pools with good track record. (Although hashpower marketplaces exist: https://nicehash.com/ they aren't particularly popular.) Now let's consider a situation where mining bitcoins is no longer profitable and the majority of hashpower
Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)
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 Adam On 16 March 2014 15:58, Adam Back a...@cypherspace.org wrote: So an update on 1-way pegging (aka bitcoin staging, explained in quoted text at bottom): it turns out secure 2-way pegging is also possible (with some bitcoin change to help support it). The interesting thing is this allows interoperability in terms of being able to move bitcoin into and out of a side chain. The side chains may have some different parameters, or experimental things people might want to come up with (subject to some minimum compatibility at the level of being able to produce an SPV proof of a given form). At the time of the 1-way peg discussion I considered 2-way peg as desirable and it seemed plausible with bitcoin changes, but the motivation for 1-way peg was to make it less risky to make changes on bitcoin, so that seemed like a catch-22 loop. Also in the 2-way peg thought experiment I had not realized how simple it was to still impose a security firewall in the 2-way peg also. So Greg Maxwell proposed in Dec last year a practically compact way to do 2-way pegging using SPV proofs. And also provided a simple argument of how this can provide a security firewall. (Security firewall means the impact of security bugs on the side-chain is limited to the people with coins in it; bitcoin holders who did not use it are unaffected). [1] How it works: 1. to maintain the 21m coins promise, you start a side-chain with no in-chain mining subsidy, all bitcoin creation happens on bitcoin chain (as with 1-way peg). Reach a reasonable hash rate. (Other semantics than 1:1 peg should be possible, but this is the base case). 2. you move coins to the side-chain by spending them to a fancy script, which suspends them, and allows them to be reanimated by the production of an SPV proof of burn on the side-chain. 3. the side-chain has no mining reward, but it allows you to mint coins at no mining cost by providing an SPV proof that the coin has been suspended as in 2 on bitcoin. The SPV proof must be buried significantly before being used to reduce risk of reorganization. The side-chain is an SPV client to the bitcoin network, and so maintains a view of the bitcoin hash chain (but not the block data). 4. the bitcoin chain is firewalled from security bugs on the side chain, because bitcoin imposes the rule that no more coins can be reanimated than are currently suspend (with respect to a given chain). 5. to simplify what they hypothetical bitcoin change would need to consider and understand, after a coin is reanimated there is a maturity period imposed (say same as fresh mined coins). During the maturity period the reanimation script allows a fraud proof to spend the coins back. A fraud bounty fee (equal to the reanimate fee) can be offered by the mover to incentivize side-chain full nodes to watch reanimations and search for fraud proofs. 6. a fraud proof is an SPV proof with a longer chain showing that the proof of burn was orphaned. There are a few options to compress the SPV proof, via Fiat-Shamir transform to provide a compact proof of amount work contained in a merkle tree of proofs of work (as proposed by Fabien Coelho link on http://hashcash.org/papers/) with params like 90% of work is proven. But better is something Greg proposed based on skip-lists organized in a tree, where 'lucky' proofs of work are used to skip back further. (Recalling that if you search for a 64-bit leading-0 proof-of-work, half the time you get a 65-bit, quarter 66-bit etc.) With this mechanism you can accurately prove the amount of proof of work in a compressed tree (rather than ~90%). 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
Re: [Bitcoin-development] BIP process
please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Adam * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. On 15 October 2014 16:46, Mike Hearn m...@plan99.net wrote: Great idea. Jeff Garzik was looking for a better mailing list solution than SourceForge, but assuming there isn't a clearly better solution I think we should create a strictly moderated bitcoin-bips@lists.sourceforge list. Let's stay away from SF.net or any mailman-controlled lists if at all possible. They break DKIM signatures which means they're no longer compatible with Yahoo, all mail from Yahoo users gets spamfoldered immediately. Google Groups gets this right. Perhaps other list operators do too. Groups also has moderation features. -- 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://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
I think you can do everything with the existing script level nlocktime in some kind of turing completeness sense (maybe); but there is a complexity cost that often you have to resort to extra dependent transaction(s) (and work-around malleability until that is fully fixed) just to get the effect. When I tried building things that need nlocktime I found it quite inconvenient that it was wasnt a function rather than a script property, so I like this proposal. Adam On 9 October 2014 04:13, Alan Reiner etothe...@gmail.com wrote: By the way, I really like this proposal. I haven't spent much time thinking about the deeper subtleties and risks associated with it, but I see a lot of opportunities. One just came to mind that I didn't see mentioned in his original proposal: Non-Interactive Recurring payments with ID-association: You want to make N recurring payments of 1 BTC each month to a service. Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number approximately X months in the future (one for each month). The script allows the customer to move the coins at any time, but after the locktime the merchant/service has signing access. The merchant software will continually watch for and sweep all coins that become available via this mechanism and credit the appropriate customer account. The customer maintains control of the funds until payment time, the merchant can automatically collect it each month without requiring user interaction, and the customer can cancel it just by spending it elsewhere before the locktime. This scheme has an added benefit: both the merchant's address and the user's address is in the script. Given an appropriate scheme for linking addresses to accounts (perhaps sending the service a watch-only BIP32 branch), the service can use the other address in the script to recognize and link that payment to the user's account. This allows you to continue paying and extending your subscription without having to explicitly link each payment to the account. The wallet will simply make sure to use a return address that is in a BIP32 branch that was provided to the service during signup, and the service will automatically extend your subscription every month based on that info when it sweeps payments. Along with everything else that was mentioned by Peter in his original proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a simple improvement. -Alan On 10/08/2014 06:26 AM, Wladimir wrote: On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote: That is easy to change; I'll submit a pull request. That's certainly a useful improvement. It won't help the existing userbase though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. The next minor release (0.9.4) could have Gavin's change already. I don't think CHECKLOCKTIMEVERIFY will make it into the next major release though. Once headers-first and pruning is merged (which is expected to be a matter of weeks). I'd like to split off the 0.10 branch and give it some time to stabilize with a feature freeze, then do a release before the end of the year. So 0.11, in say 6 months, would be soonest. Wladimir -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___
[Bitcoin-development] good bitcoin summary paper in more detail than Satoshi paper (Re: Bitcoin Protocol Specification)
Actually I read the paper now as it was linked somewhere else also, and its quite good. So now I can summarize it: Its a writeup of bitcoin in 29 pages, which covers things in the original bitcoin paper but with more detail of formats, scripts with some examples, formats etc. Quite nice paper, concise presentation of many bitcoin details that are otherwise hard to put together, requiring examining source or asking people knowledgeable at algorithm/code level. http://enetium.com/resources/Bitcoin.pdf Adam On Sun, May 18, 2014 at 04:38:53PM +0200, Adam Back wrote: Suggestion: maybe you want to write and post here a paragraph summarizing the topic of your paper so people can know if they feel qualified and if they need to review it from their interests. Adam On Sun, May 18, 2014 at 03:35:33PM +0200, Krzysztof Okupski wrote: Dear all, I'd like to kindly ask, those of you that have a bit of spare time, to take a look at a Bitcoin protocol specification I've written. It is still in development and, as some of you have already indicated, needs improvement. I'd be very thankful if some of you could take the time to review it. If there are any errors or suggestions from your side, I'd gladly hear them. My e-mail can be found on the front page of the document: http://enetium.com/resources/Bitcoin.pdf Warm greetings, Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] patents...
someone recently wrote (not pointing fingers, nor demanding a spirited defense from that person, its a generic comment): PS: the device has patents pending btw about patents, I wonder if people who feel the need to do that, would you consider putting those patents into like a linux foundation defensive pool? I imagine a number of other bitcoin companies have patented things, but if you think ahead a little bit, or look at prior ecash history, patents held by individuals or companies can be outright dangerous. We saw this in the past eg the digicash patents after the company went bankrupt were sold by the investor to some random large company that parked it in its huge pile of patents, didnt use it, and prevented anyone else from using it - stalling Chaum dependent payment innovation for perhaps 5 years until the thing expired, and a Chaum patent expiry party was held. Just some food for thought. hmm Yes and this topic now is more than a bit non dev related. Sorry about that. There seems to be no convenient mailing list format for non-dev stuff or I would Cc and set Reply-To for example? (Web forums somewhat suck IMO). Adam -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Protocol Specification
Suggestion: maybe you want to write and post here a paragraph summarizing the topic of your paper so people can know if they feel qualified and if they need to review it from their interests. Adam On Sun, May 18, 2014 at 03:35:33PM +0200, Krzysztof Okupski wrote: Dear all, I'd like to kindly ask, those of you that have a bit of spare time, to take a look at a Bitcoin protocol specification I've written. It is still in development and, as some of you have already indicated, needs improvement. I'd be very thankful if some of you could take the time to review it. If there are any errors or suggestions from your side, I'd gladly hear them. My e-mail can be found on the front page of the document: http://enetium.com/resources/Bitcoin.pdf Warm greetings, Chris -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] mid-term bitcoin security (Re: Warning message when running wallet in Windows XP (or drop support?))
Big picture/mid-term I think air-gaps and zero-trust ecosystem components are the only solution. (zero-trust meaning like real-time auditability, or type 2/type 3 exchanges based on atomic-swap, trustless escrow etc). Need a mass-production and air-drop of trezors :) There is one more problem address-substitution via untrusted network/user and weak site with 1mil lines of swiss-cheese security app-store. So some kind of address authentication TOFU. Aside from X509 bloatware which could be extended from payment protocol to do that, I'd argue for a native simple TOFU format like Alan Reiner's multiplier * base approach (where base is the TOFU handle). And/or something like the IBE address proposal (which gives a bandwidth efficiently SPV queryable way to check if funds received). Worst case if weil-pairing gets broken it auto-devolves to the current status quo. Btw not to reignite the stealth vs reusable address bike shedding, but contrarily I was thinking it maybe actually better to try to rebrand address as invoice number. People understand double paying an invoice is not a good idea. And if they receive the same invoice twice they'll query it. Adam On Wed, Apr 16, 2014 at 11:41:48AM +0200, Wladimir wrote: On Wed, Apr 16, 2014 at 10:45 AM, Melvin Carvalho [1]melvincarva...@gmail.com wrote: XP with a trezor would work fine tho? Probably - but that's a very rare edge case. People that are security conscious enough to buy a Trezor will not run XP. Also I don't dare to say that there is not some way to sociaal-engineer the user with malware on a compromised OS even with a trezor. Maybe: for 0.9.2 add a warning message and push people to upgrade (either to Win8.1 or something else), then in the next major release 0.10.0 drop XP support completely. Wladimir References 1. mailto:melvincarva...@gmail.com -- 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 -- 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] Warning message when running wallet in Windows XP (or drop support?)
Not to get snarky or OS elitist but as I understand it windows security, even during its support period has been measured in low digit number of days in the year when is NOT an outstanding known remote root compromise or combination of remote user compromise + priviledge escalation. Add in phishing, watering holes, malware and the average windows computer is probably compromised a dozen times over. Apparently for sometime it was not easily possible to secure it install boot - install OS, connect to network to download security updates, IP range scanned and compromised faster than you can patch it. Adam On Wed, Apr 16, 2014 at 05:28:27PM +0200, Wladimir wrote: On Wed, Apr 16, 2014 at 5:20 PM, Pieter Wuille [1]pieter.wui...@gmail.com wrote: On Wed, Apr 16, 2014 at 5:12 PM, Kevin [2]kevinsisco61...@gmail.com wrote: I think we should get to the bottom of this. Â Should we assume that xp is not secure enough? Yes. It will quickly grow extremely insecure. People will be actively analyzing patches to post-XP versions to find security problems that are patched there, to see if they can be exploited on XP. Wladimir -- 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] Payment Protocol for Face-to-face Payments
Maybe its time to explore raw ECDSA signed message based certs. btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der format. And they contain a 2048-bit RSA server key, and 2048-bit RSA signatures (256byte each right there = 512bytes). And even 2048 is weaker than 256-bit ECDSA. Adam On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote: On 03/20/2014 01:12 PM, Adam Back wrote: Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago). You will want to stay below 500 bytes for convenient scanning. That said, I'm convinced there is a lot of room for scanning improvements. How much of the payment protocol message size comes from use of x509? As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about 4000 bytes on top of that. As you can see, we have quite some room for improvements to PR payload (PaymentDetails). X.509 certification will probably not be possible via QR, at least not until specialized CA's will issue space-efficient certs (using ECDSA?). -- 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] Payment Protocol for Face-to-face Payments
According to Bernstein it's patent FUD (expired, ancient and solid prior art). http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html Adam On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote: Oh, one other reason I found - apparently RIM, at least in the past, has been telling CA's that they need to pay mad bux for the Certicom ECC patents. So that's another reason why most certs are still using RSA. -- 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
[Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)
Freidenbach, Luke Dashjr. The 2-way peg seems to have first been described by Greg. Greg thought of 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2]. (As a ZK-SNARK could compactly prove full validation of a side chain rules). There was also something seemingly similar sounding but not described in detail by Alex Mizrahi in the context of color coins in this post [3]. Adam [1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt [2] https://bitcointalk.org/index.php?topic=277389.40 [3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554 [4] http://www.cypherspace.org/p2p/auditable-namespace.html On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote: Coming back to the staging idea, maybe this is a realistic model that could work. The objective being to provide a way for bitcoin to move to a live beta and stable being worked on in parallel like fedora vs RHEL or odd/even linux kernel versions. Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x stable and leap-frogs as beta becomes stable after testing. Its a live beta, meaning real value, real contracts. But we dont want it to be an alt-coin with a floating value exactly, we want it to be bitcoin, but the bleeding edge bitcoin so we want to respect the 21 million coin limit, and allow coins to move between bitcoin and betacoin with some necessary security related restrictions. There is no mining reward on the betacoin network (can be merge mined for security), and the way you opt to move a bitcoin into the betacoin network is to mark it as transferred in some UTXO recognized way. It cant be reanimated, its dead. (eg spend to a specific recognized invalid address on the bitcoin network). In this way its not really a destruction, but a move, moving the coin from bitcoin to betacoin network. This respects the 21 million coin cap, and avoids betacoin bugs flowing back and affecting bitcoin security or value-store properties. Users may buy or swap betacoin for bitcoin to facilitate moving money back from betacoin to bitcoin. However that is market priced so the bitcoin network is security insulated from beta. A significant security bug in beta would cause a market freeze, until it is rectified. The cost of a betacoin is capped at one BTC because no one will pay more than one bitcoin for a betacoin because they could alternatively move their own coin. The reverse is market priced. Once bitcoin beta stabalizes, eg say year or two type of time-frame, a decision is reached to promote 1.0 beta to 2.0 stable, the remaining bitcoins can be moved, and the old network switched off, with mining past a flag day moving to the betacoin. During the beta period betacoin is NOT an alpha, people can rely on it and use it in anger for real value transactions. eg if it enables more script features, or coin coloring, scalabity tweaks etc people can use it. Probably for large value store they are always going to prefer bitcoin-stable, but applications that need the coloring features, or advanced scripting etc can go ahead and beta. Bitcoin-stable may pull validated changes and merge them, as a way to pull in any features needed in the shorter term and benefit from the betacoin validation. (Testing isnt as much validation as real-money at stake survivability). The arguments are I think that: - it allows faster development allowing bitcoin to progress features faster, - it avoids mindshare dilution if alternatively an alt-coin with a hit missing feature takes off; - it concentrates such useful-feature alt activities into one OPEN source and OPEN control foundation mediated area (rather than suspected land grabs on colored fees or such like bitcoin respun as a business model things), - maybe gets the developers that would've been working on their pet alt-coin, or their startup alt-coin to work together putting more developers, testers and resources onto something with open control (open source does not necessarily mean that much) and bitcoin mindshare branding, its STILL bitcoin, its just the beta network. - it respects the 21 million limit, starting new mining races probably dillutes the artificial scarcity semantic - while insulating bitcoin from betacoin security defects (I dont mean betacoin as a testnet, it should have prudent rigorous testing like bitcoin, just the very act of adding a feature creates risk that bitcoin stable can be hesitant to take). Probably the main issue as always is more (trustable) very high caliber testers and developers. Maybe if the alt-coin minded startups and developers donate their time to bitcoin-beta (or bitcoin-stable) for the bits they are missing, we'll get more hands to work on something of reusable value to humanity, in parallel with their startup's objectives and as a way for them to get their needed features, while giving back to the bitcoin community, and helping bitcoin progress faster. Maybe bitcoin
Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Also the other limitation for ECDSA is that there is no known protocol to create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without either a sending its private key to b or viceversa (or both to a third party). With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a (secure) direct multiparty signature quite difficult. ps probably only 1 party needs to hash their key P=aG H(P) - - Q=bG P - Adam On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote: If both parties insist on seeing a hash of the other party's public key before they'll show their own public key, they can be sure that the public key is not chosen based on the public key they themselves presented. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)
I think you Peter Jeremy figured it out - dont disagree with the explanation details. And it seems better explained between the two posts than I did. I think Peter is right that you do not need an explicit prefix, the prefix after decryption can be a chosen number of leading 0s and this gives a tunable amount of false positives. You already have privacy becaue the query is only revealed to the semi-trusted full node, and its query scope is limited to one or a chosen batch of blocks. But you can if desired add additional ambiguity as Peter described by reducing the number of bits of 0 in the decrypted block. There is no need for matching a specific prefix as its already a recipient specific calculation. (It means the actual encrypted value where it is chosen would have to mimic false positives: random with n-bits of trailing 0s and expected probability distribution). It should be compatible for combining with sharding or public prefixes, as Peter mentioned but for short public prefixes those still has some (reduced) blockchain ledger logged possibility to reduce anonymity set when combined with flow analysis. Maybe you could vary a public prefix per block. Eg the public prefix for a given user is the LSBits of the per block IBE derived pubic key for a given user. I am not sure if that helps or hinders. Maybe it hurts anonymity set because the analyst (Eve) is given multiple chances over time to exclude an analysed flow candidate. It would desirable to find a non-IBE way to do this. (And more computationally efficient / precomputable / indexable) Or you could use different address types depending on the circumstance: one-use, stealth, or IBE. Kind of difficult to automate that (to know what the user is planning to do with it) and avoid user confusion. Clearly users are quite confused and the convenient and understandable thing is to have a (safely) reusable address. Adam On Sun, Feb 02, 2014 at 07:26:10AM -0500, Peter Todd wrote: On Sun, Feb 02, 2014 at 01:16:20AM -0800, Jeremy Spilman wrote: Consequently you can now securely and very network/space efficiently securely delegate searching a block by computing the private key for the IBE pub key that any sender would use for that block, and sending it as a query to a random (or node-capture defended random selected node). The node can decrypt the encrypted bloom baits with it, but remains powerless to correlate with bloom baits to other payments received by the same user in bother blocks. I'm not sure I've fully wrapped my head around it. d/Q- Identity key E - Generate an epoch-pubkey: E = Q * H1(epoch) r/P- Ephemeral privkey/pubkey, or discoverable from inputs S = r * K - Shared secret (ECDE) There needs to be two separate payor pubkeys, which I called elsewhere the Filter and Recover pubkeys - the latter I think corresponds to what you meant by identity key. From those two pubkeys two separate shared secrets are derived. The key idea is that you can encrypt a short string of zeros with the Filter pubkey using ECDH and place the resulting filter bait in the transaction. This lets the payor give the secret key corresponding to that pubkey to a semi-trusted third party. That third party can then trial decrypt all filter bait seen in transactions in the blockchain, and every time the decrypted string has a sufficient number of zeros it's considered a filter pass and the transaction is given to the payor. For n zero bits one in 2^n transactions will match at random, which sets your false positive rate. Basically think of it as a way to outsource the work required for zero-prefix stealth addresses, but with (less) of a sacrifice of anonymity compared to just giving the third-party your recovery pubkey. Identity-based encryption only comes into it because it's nice to be able to further limit what transactions the server knows about to specific time intervals rather than forver into the future. Interestingly both schemes can be used at once - a short public prefix combined with a second private filter. What's interesting there is that the public prefix can do a first-pass filtering, with the second private filter relatively long but still providing plausible deniability - you can always claim 100% of the matching transactions were false positives because you didn't receive any funds! The full node then uses this privkey to decrypt the same byte in all the transactions in that epoch/block which match the expected layout/template, e.g. given a certain length OP_RETURN, pull the specific byte and decrypt. This decrypted byte is then in turn used as bloom bait which may or may not cause the transaction to be sent back to the SPV client. There's no bloom filters involved; as I said before bloom bait is a misleading name. Filter bait is a better term given it's a generic concept. What encryption scheme is being used here? XOR with the ECDH-calculated nonce is fine. (run the nonce
[Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)
I think I figured out a proof of existance for a space efficient way to do better than bloom filters/prefix/bloom-bait. (Must have been dreaming on it as I woke up with the idea following Peter's suggestion to try prove instead if its possible or not:). I wrote up the details here: https://bitcointalk.org/index.php?topic=431756.new In summary with a use of novel application of IBE (*) based on weil-pairing so the recipient can send a delegation private key that is specific to the block being queried. It means the node that services the query has no ability to correlate with queries in other blocks from the some user. The sender derives a pub=IBE-extract(master-pub, id=previous block hash). The above link has more explanation, links and costs/risks. I think it maybe within possibility to do further than this because it is not technically necessary to delegate decryption, only to delegate filtering, which can be a simpler requirement so there remains perhaps (speculatively) a possibility to do it without introducing weil pairing hardness problem or using eg I mentioned public key steganography or something like that if there is anything similarly efficient but with more widely used hardness assumptions. Adam (*) analogous to the way IBE is used as a building block for Non-Interactive Forward Secrecy (NIFS) On Fri, Jan 24, 2014 at 11:13:30AM -0500, Peter Todd wrote: On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote: Now while it would be clearly a very nice win if reusable addresses could be made SPV-like in network characteristics and privacy, but we dont have a plausible mechanism yet IMO. [...] If we can find some efficient crypto to solve that last one, we could even adopt them generally if it was efficient enough without needing interactive one-use address release. Conversely, it'd be interesting if someone can dig up a proof showing that doing much better than Gregory's ambiguity tradeoff is impossible. -- 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] Bait for reusable addresses
I think prefix has analysis side effects. There are (at least) 4 things that link payments: the graph of payment flows, timing, precise amounts, IP addresses, but with prefix a 5th: the prefix allows public elmination of candidates connections, I think that may make network flow analysis even more effective than it has been. So SPV can be tuned as Mike just said, and as Greg pointed out somewhere bloom is more private than prefix because its a wallet to node connection, not a node broadcast, and Mike mentioned embedded Tor in another post to boost node-capture issues with hostile network. So reusable addresses are cool for full node recipients (0-bit prefix) or trusted server offload (your own desktop, VPS, or trusted service provider node, and solve real problems for the use case of static and donation addresses particularly with this second delegatable key for no-funds at risk search (which is even good as Jeremey said for your own node, in a offline wallet use case). Now while it would be clearly a very nice win if reusable addresses could be made SPV-like in network characteristics and privacy, but we dont have a plausible mechanism yet IMO. Close as we got was Greg's enhancement of my/your bloom bait/prefix concept to make multiple candidate baits to provide some ambiguity (still allows elimination, just slightly less of it). If we can find some efficient crypto to solve that last one, we could even adopt them generally if it was efficient enough without needing interactive one-use address release. Maybe we should ask some math/theoretical crypto people if there is anything like public key watermarking or something that could solve this problem efficiently. For the related but different case of transaction level authenticity I like Alan's server derived but communicated scalar base to allow the client to do at least TOFU. Payment protocol may add another level of identity framework on top of TOFU addresses (at a lower level than the payment messages defined now), and without then needing a batch upload of offline signed secondary address sigature that Mike described a while back, at least in person, maybe online somewhere (an add on with similar purpose and effect to Alan's TOFU, but then with revocation, identity and certification for merchants). I have not talked about payment protocols main app level function I think we all understand and agree on the purpose and use of the server and optional client certs in that. People may wish to add other cert types later (eg PGP, SSH etc) but this version covers the common merchant tech, and allows client-side certs to be experimented with for identity also (eg imagine as a way to enrol with regulated entities like exchanges.) Tell me if I am misunderstanding anything :) Adam On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote: brittleness. The real world experience is that users, or to be exact wallet authors, turn down SPV privacy parameters until bloom filters have almost no privacy in exchange for little bandwidth usage. That's not fundamental though, it just reflects that the only implementation of this is used on a wide range of devices and doesn't yet have any notion of bandwidth modes or monitoring. It can and will be resolved at some point. -- 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] BIP0039: Final call
Because the mnemonic is an encoding of a 128-bit random number using its hash as a private key (or derived part of one) is not a problem, its just an alternate alphabet encoding of the random private key. Not being able to generically understand the checksum. Seems tricky to solve other than say brute force eg H(mnemonic||1) mod 2^k == 0 where k is the amount of check digit redundancy. But that might be expensive for a trezor if k is very big at all. And then key = H(mnemonic). Adam On Mon, Jan 20, 2014 at 05:35:02PM -0500, Peter Todd wrote: On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote: On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz wrote: Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific wordlist, so every client can use its very own list of preferred words. Generated mnemonic can be then applied to any other BIP39-compatible client. Please follow current draft at https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. So, because the [mnemonic]-[bip32 root] is just hashing, you've effectively made your mnemonic sentence into a brainwallet? Since every mnemonic sentence can now lead to a bip32 root, and only the client that created the mnemonic can verify the mnemonic passes its checksum (assuming all clients use different wordlists, the only client that can help you if you fat-finger the sentence is the client that created it)? That issue is more than enough to get a NACK from me on making the current BIP39 draft a standard - I can easily see that leading to users losing a lot of money. Have any wallets implemented BIP39 this way already in released code? -- 'peter'[:-1]@petertodd.org 9c3092c0b245722363df8b29cfbb86368f4f7303e655983a -- 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 -- 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] Payment protocol and reliable Payment messages
He's probably thinking of fair advertising rules. There are regulations motivated by consumer protection/advertising standards (prevents merchant listing attractive prices in media, and then when consumer goes to pay the merchant says oh actually that doesnt include X and Y, and the minimum price is 10% more after the user has already partly committed to the purchase. Ryanair, an airline near and dear to Europeans ;) is infamous for aggressive use of such tactics. Or worse systematic abuse of sorry that was a pricing mistake. In trading situations its even more important, you're facing a dynamic price, and revocable bids after acceptance but before payment allow system gaming. There were court cases about such things and trading systems gamed. So I think this is the use case to consider. Payment request is an offer, payment message is an acceptance, transaction broadcast is settlment. After acceptance the asker must not be allowed to retract ther ask. Going back to Pieter's comment it seems there are two approaches: i) send payment message to merchant, merchant broadcasts tx to network to claim funds; ii) user broadcasts tx, and sends payment message to merchant. In case i) the user is relying on the merchant in terms of retraction, for many use-cases that doesnt matter, or consumer law says they can do that in some places. Though transferable proof the merchant is systematically retracting advertised offers could be indirectly useful as it maybe evidence of unfair trading, which can result in censure for the merchant! In case ii) I think Andreas has a point. Maybe the way to do that is to also bind the transaction to the payment message. Eg include the hash of the payment message in the tx (circular ref may have to use multisig approach?), or as Timo Hanke's paper where the offer/acceptance contact hash is bound to the address (ie the address paid is Q'=H(Q+H(contract)G). Adam On Tue, Jan 14, 2014 at 11:45:59AM +0100, Mike Hearn wrote: Imagine you get a good offer (payment request) from a merchant. You would like to accept that offer, however the merchant has changed his mind. Usually if the merchant has not delivered, then at that point it's not a problem and he is allowed to change his mind. It's only if they change their mind *after* you pay that it's a problem, right? -- 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 -- 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] Stealth Addresses
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G and therefore that Util.SingleSHA256() multiplies by G internally? Adam -- 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] Dedicated server for bitcoin.org, your thoughts?
You know if you want to make some form of investment, you might like make an attempt to look them up on the internet, check the phone number in a phone book or directory enquiries, look for references and reviews? So it is with the hash of the binary you are about to trust with your investment funds. I dont think its such a difficult question. Ask your more technical friends to confirm this hash is correct. Its interesting that hashes are more trustworthy than signatures, since all the NSLs and backdoors, its hard to trust a signature. I have the same problem with linux distros that want to install hundreds of components downloaded over the internet, based on signatures. I would far rather a merkle hash of the distribution at that point in time, which authenticates directly any of the optional downloadable components. (Or better yet a distro that like comes on a CD and doesnt download anything... Amazing how most CD and even DVD iso images immediately download stupid things like fonts??? What were they thinking? I downloaded fedora 4GB of stuff and they need to download a font just to get past step 2 of the installer? Thats a sensless, retrograde, selective backdoor opportunity.) Adam On Fri, Jan 03, 2014 at 11:22:35AM +, Tier Nolan wrote: On Fri, Jan 3, 2014 at 9:59 AM, Drak [1]d...@zikula.org wrote: Which is why, as pointed out several times at 30c3 by several renowned figures, why cryptography has remained squarely outside of mainstream use. It needs to just work and until you can trust the connection and what the end point sends you, automatically, it's a big fail and the attack vectors are many. sarcasmI can just see my mother or grandma manually checking the hash of a download... /sarcasm Maybe a simple compromise would be to add a secure downloader to the bitcoin client. The download link could point to a meta-data file that has info on the download. file_url= hash_url= sig_url= message=This is version x.y.z of the bitcoin client It still suffers from the root CA problem though. The bitcoin client would accept Gavin's signature or a core team signature. At least it would provide forward security. It could also be used to download files for different projects, with explicit warnings that you are adding a new trusted key. When you try to download, you would be given a window Project: Some Alternative Wallet Signed by: P. Lead Message: Confirm download Yes No However, even if you do that, each trusted key is only linked to a particular project. It would say if the project and/or leader is unknown. References 1. mailto:d...@zikula.org -- 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 -- 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] An idea for alternative payment scheme
Seems like you (Nadav) are the third person to reinvent this idea so far :) I wrote up some of the post-Bytecoin variants here: https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530 The general limitation so far is its not SPV compatible, so the recipient has to test each payment to see if its one he can compute the private key for. Or the sender has to send the recipient out of band the derivation key. However at present most of the bitcoin infrastructure is using the bitcoin broadcast channel as the communication channel, which also supports payer and payee not being simultaneously online. You have to be careful also not to lose the key. You dont want a subsequent payer data loss event to lose money for the recipient. You want the message to be sent atomically. It does seem like a very attractive proposition to be able to fix the address reuse issue. Admonishment to not reuse addresses doesnt seem to have been successful so far, and there are multiple widely used wallets that reuse addresses (probably in part because they didnt implement HD wallets and so are scared of losing addresses due to backup failure risks of non HD wallets and fresh addresses). Adam On Fri, Jan 03, 2014 at 10:30:38AM -0800, Gregory Maxwell wrote: On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote: I had an idea for a payment scheme that uses key derivation, but instead of the payee deriving the addresses, the payer would do it. It would work like that: The payee publishes his master public key The payer generates a random receipt number (say, 25 random bytes) The payer derives an address from the master public key using the receipt number and pays to it The payer sends the receipt to the payee The payee derives a private key with that receipt and adds it to his wallet Allow me to introduce an even more wild idea. The payee publishes two public keys PP PP2. The payer picks the first k value he intends to use in his signatures. The payer multiplies PP2*k = n. The payer pays to pubkey PP+n with r in his first signature, or if none of the txins are ECDSA signed, in an OP_RETURN additional output. The payer advises the payee that PP+(pp2_secret*r) is something he can redeem. But this is technically optional because the payee can simply inspect every transaction to check for this condition. This is a (subset) of a scheme by Bytecoin published a long time ago on Bitcoin talk. It has the advantage that if payer drops his computer down a well after making the payment the funds are not lost, and yet it is still completely confidential. (The downside is particular way I've specified this breaks using deterministic DSA unless you use the OP_RETURN, ... it could instead be done by using one of the signature pubkeys, but the pubkeys may only exist in the prior txin, which kinda stinks. Also the private keys for the pubkeys may only exist in some external hardware, where a OP_RETURN nonce could be produced when signing). These schemes have an advantage over the plain payment protocol intended use (where you can just give them their receipt number, or just the whole key) in that they allow the first round of communication to be broadcast (e.g. payee announced to EVERYONE that he's accepting payments) while preserving privacy. -- 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 -- 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
[Bitcoin-development] bitcoin 1.x 0.x in parallel (Re: is there a way to do bitcoin-staging?)
Yeah but that sounds pretty much like test-net and starts a new digital scarcity on an alpha-qa level network, with an implied promise that maybe if you're lucky your coins might survive the alpha testing and have some value. I'm not talking about some slightly stabler version of test-net. Probably bitcoin staging is the wrong name. I mean like development of bitcoin 1.x in parallel with bitcoin 0.x which includes like test net for both, and strong (though maybe not quite as high) assurance of qa and care as bitcoin 0.x. Just as a way to get features like Mark Freidenbach's freimarket script extensions, and some of the disabled scripts validated on 1.x testnet and then after rigorous testing deployed onto 1.x Because they are new features even with good testing that introduces non-zero risk, hence the 1 way peg idea. Welcome to suggest better names for the idea... Of course maybe the other issue is insufficient people with the skills and motivation to support two parallel efforts. It gives somewhere to code and test and then deploy clearly useful things but that dont warrant a hard fork. Adam Melvin wrote: I think there may be a simpler way to do this. Create a new genesis block for a staging network, but in all other aspects, as far as possible, keep the properties the same as bitcoin. Do not actively be opposed to it being traded, but people need to know that, although there is no intention to reset the chain, new and potentially not fully tested, changes can be rolled into the network. Anyone mining staging coins should be prepared for the value to go to zero. Perhaps also a straw poll voting system could be set up for those that own staging coins could sign messages saying which patches they would like to test out next. When patches are stable in the staging area, they could be promoted to the main net ... -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ 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
While we're discussing the emotive (though actually of real relevance for bitcoin user comprehension and sentiment) I couldnt resisnt to add some trivia reference it is amusing that a currency rarely in history had to deflate (remove 0s) rather than inflate (add 0s). Viz this hyperinflated fifty trillion zimbabwe dollar note I carry in my wallet for bitcoin contrast/amusement purposes: http://www.ebay.com/itm/50-TRILLION-ZIMBABWE-DOLLARS-CURRENCY-MONEY-US-SELLER-/110671104681 I like Alan's suggestion to show both to avoid denomination confusion. That is the one danger, and high risk given irrevocability. Adam -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)
Might leak less wiggle room and be simpler/more robut to validate that *everything* has to be the same except for the amount going to one (presumed change) address. A privacy leak I know, but dont do that - ie send enough change the first time. And network analysis has shown change addresses arent adding hardly any privacy. We need more robust privacy fixes independently. I do not support damaging the 0-conf feature, so I think this later approach is a better track for revising fees. Adam On Mon, Nov 04, 2013 at 05:52:43AM -0500, Peter Todd wrote: On Mon, Oct 28, 2013 at 07:17:50AM +, John Dillon wrote: This discussion seems to be a lot of hot air over a simple observation that estimates are imperfect and always will be. I do not understand you vehement opposition the notion that a backup is a good thing except in the context that replacement to change fees is halfway to profit-seeking replacement by fee. Peter Todd: You did a fair bit of leg work for replace-by-fee. Seems to me that replace-for-fee will help prep infrastructure to eventual replace-by-fee usage, while avoiding some of the politics around zero-conf transactions. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
I think its a mistake relying directly on X509, its subject to corrpution attacks, involves ASN.1 and enough openSSL X.500 encoding abiguity (or other code base) to be a security nightmare. Why not make the payment messages signed by bitcoin keys. If someone wants to associate with X.509 they can put a bitcoin address on their SSL site. If someone can get into your site deeply enough to modify your SSL served code and you're trying to run ecommerce you have other problems. Never the less if they care they can clear sign the bitcoin addr with xmlsig and their X.509 private key, and/or with PGP and a WoT. I think its smarter to pollute bitcoin main with X509. Make a little helper util if there are not enough xmlsig tools that you cant pick one up opensource for multiple languages. This then avoids the binding to Tor - you can publish a bitcoin address authenticated anyway you like. Eg tahoe-LAFS auth/integrity, i2p, tor, pgp - you name it. Maybe I voice this opinion a bit late in the cycle, but I think it would do bitcoin a favor otherwise its a camels nose in the tent into the TLAs that control their own X.509 CAs, or issue NSL letters for CA private keys, or forged certs. It's all happening and thanks to Snowden we now have even more evidence... Adam On Fri, Oct 25, 2013 at 09:06:48PM -0700, Gregory Maxwell wrote: On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote: Is there any point to additional encryption over tor (which afaik is already encrypted end-to-end)? Is there a safe way to make this work through tor entry nodes/gateways? The x.509 in the payment protocol itself is for authentication and non-repudiation, not confidentiality. It's used to sign the payment request so that later there is cryptographic evidence in the event of a dispute: He didn't send me my alpaca socks! Thats not the address I told you to pay! He told me he'd send my 99 red-balloons, not just one! No way, that was the price for 1 red-balloon! Just using SSL or .onion (or whatever else) gets you confidentiality and authentication. Neither of these things get you non-repudiation. It'd be nice to have a way to support namecoin-provided keys too... The payment protocol is extensible, so I hope that someday someone will support namecoin authenticated messages (but note: this requires namecoin to support trust-free SPV resolvers, otherwise there is no way to extract a compact proof that can be stuck into a payment request) and GPG authenticated messages. But those things will require a fair amount of code (even fixing the namecoin protocol in the nmc case), and GPG could be done just by externally signing the actual payment request like you'd sign any file... and considering the sorry state of their _practical_ usability, I don't think they're worth doing at this time. By contrast, I _think_ the tor onion support would require only a relatively few lines of code since it could just be the existing x.509 mechanism with just a simple special validation rule for .onion, plus a little tool to repack the keys. I think it would easily be more widely used than namecoin (though probably both would not really be used, as gavin notes). w/ Gavin's comments I'll go check in with the tor folks and see if anyone has ever though of doing this before and if there is already a canonical structure for the x.509 certs used in this way. -- 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 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] two comments on brain-wallet security (and BIP 38)
So I had a go at deciphering BIP 038 in summary what I think its doing is (ommitting lot and sequence and deterinistic IVs for simplicity): user: x1 = Scrypt( salt=random, pass ) P = x1*G send (salt, P) to coin manufacturer - manufacturer: x2 = random 24bytes Q = x2*P k = Scrypt( salt2=H(Q)||salt, pass=P ) e = AES_k( x2 ) manufacturer puts es inside coin. - send coin, (salt, e, Q) to user then optionally creates conf code: B = x2*G c = AES_k( B ) - send conf code c to user verify code c: (by recreating P, then k from Q P, decrypt c to get B, check Q = x1*B) x1 = Scrypt( salt, pass ) P = x1*G k = Scrypt( salt2=H(Q)||salt, pass=P ) Which seems reasonable enough, however its unfortunate that you have to repeat the Scrypt work at setup. One thing that occurs to me eg as mentioned by Rivest et al in their time-lock puzzle paper is that it is easy to create work, if you are ok with parallelizable symmetric constructions (like scrypt(i) or PBKDF2(i) with i iterations) without *doing* the work during setup. It seems to me therefore that the above protocol could avoid the javascript overhead issue that forces users to choose a weak iteration level if they want to create the wallet in that way. eg create a 32-bit random salt, replace scrypt(i=16384, salt, pass) with scrypt(i=1,salt, pass) to be brute forced based on deleted salt. Immediate 2^32 = 4billion iteration salt without any significant setup cost. (Or if you want to limit the parallelism say scrypt(i=65536, salt, pass) with a deleted 16-bit salt. That should be parallelizable up to 65536 GPU cores (32x 7970 chips). Symmetric time-lock puzzles can achieve decrypt asymmetry without repeating the work at setup... (Rivest et al goes on to avoid using that symmetric construct with an RSA related mechanism, because they are trying to lock information for an approximate future date, rather than protected by a specific amount of grinding work.) I proposed a different blind (securely server-offloadable) deterministic proof of work relating to (asymmetric RSA-style) time-lock puzzles. The difference from time-lock is it is made blind (so the work can be securely offloaded without the server learning your password or resulting key) and can be easily made parallelizable also which is desirable for server offload. https://bitcointalk.org/index.php?topic=311000.new#new I think that could take brain-wallets to a new level of security, if you protect the amount by an amount of computation proportional to the value, eg 0.1% or 0.01% redemption cost paid to blind proof of work miners. Adam -- 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] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)
An update on the homomorphic coins, some more math validation a test implementation needs to be done, but a surprisingly good outcome so far of predicted 2.5kB homomorphic valued coin. Only coin splitting has to incur the 2.5kB range proof. Coin adding, full spending and mining is free, because adding existing range proofed and validated coins cant overflow by definition (21 mil coin cap). You can also (obviously I guess) add a homomorphicaly encrypted 0 value to a few other peoples coin balance to get a kind of taint mitigation. https://bitcointalk.org/index.php?topic=305791.msg3294618#msg3294618 Adam On Tue, Oct 01, 2013 at 09:11:43PM +0200, Adam Back wrote: Err actually not (efficient) I made a mistake that came out when I started writing it up about how the t parameter in the proof relates to bitcoin precision and coin representation (I thought t=2, but t=51). Damn! Back to the not so efficient version (which is more zerocoin-esque in size/cost), or the more experimental Schoenmaker non-standard p, q non EC one, or other creative ideas to change the coin representation to simplify the proof (of which this was a failed attempt). See the bitcointalk thread for details. https://bitcointalk.org/index.php?topic=305791.new#new Adam On Tue, Oct 01, 2013 at 04:26:03PM +0200, Adam Back wrote: On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: This kind of thing - providing external audits of customer accounts without revealing private data - would be generally useful beyond taxation. If you have any solutions, I'd be interested to hear them (although bitcoin-dev is probably not the right place yet). Thanks for providing the impetus to write down the current state, the efficient version of which I only figured out a few days ago :) I have been researching this for a few months on and off, because it seems like an interesting construct in its own right, a different aspect of payment privacy (eg for auditable but commercial sensistive information) but also that other than its direct use it may enable some features that we have not thought of yet. I moved it to bitcointalk: https://bitcointalk.org/index.php?topic=305791.new#new Its efficient finally (after many dead ends): approximately 2x cost of current in terms of coin size and coin verification cost, however it also gives some perf advantages back in a different way - necessary changes to schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs, or k of n multiparty sigs for the verification cost and signature size of one pair of ECS signatures, for n 2 its a space and efficiency improvement over current bitcoin. Adam -- 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=60134071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)
On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: This kind of thing - providing external audits of customer accounts without revealing private data - would be generally useful beyond taxation. If you have any solutions, I'd be interested to hear them (although bitcoin-dev is probably not the right place yet). Thanks for providing the impetus to write down the current state, the efficient version of which I only figured out a few days ago :) I have been researching this for a few months on and off, because it seems like an interesting construct in its own right, a different aspect of payment privacy (eg for auditable but commercial sensistive information) but also that other than its direct use it may enable some features that we have not thought of yet. I moved it to bitcointalk: https://bitcointalk.org/index.php?topic=305791.new#new Its efficient finally (after many dead ends): approximately 2x cost of current in terms of coin size and coin verification cost, however it also gives some perf advantages back in a different way - necessary changes to schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs, or k of n multiparty sigs for the verification cost and signature size of one pair of ECS signatures, for n 2 its a space and efficiency improvement over current bitcoin. Adam -- 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=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)
Err actually not (efficient) I made a mistake that came out when I started writing it up about how the t parameter in the proof relates to bitcoin precision and coin representation (I thought t=2, but t=51). Damn! Back to the not so efficient version (which is more zerocoin-esque in size/cost), or the more experimental Schoenmaker non-standard p, q non EC one, or other creative ideas to change the coin representation to simplify the proof (of which this was a failed attempt). See the bitcointalk thread for details. https://bitcointalk.org/index.php?topic=305791.new#new Adam On Tue, Oct 01, 2013 at 04:26:03PM +0200, Adam Back wrote: On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: This kind of thing - providing external audits of customer accounts without revealing private data - would be generally useful beyond taxation. If you have any solutions, I'd be interested to hear them (although bitcoin-dev is probably not the right place yet). Thanks for providing the impetus to write down the current state, the efficient version of which I only figured out a few days ago :) I have been researching this for a few months on and off, because it seems like an interesting construct in its own right, a different aspect of payment privacy (eg for auditable but commercial sensistive information) but also that other than its direct use it may enable some features that we have not thought of yet. I moved it to bitcointalk: https://bitcointalk.org/index.php?topic=305791.new#new Its efficient finally (after many dead ends): approximately 2x cost of current in terms of coin size and coin verification cost, however it also gives some perf advantages back in a different way - necessary changes to schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs, or k of n multiparty sigs for the verification cost and signature size of one pair of ECS signatures, for n 2 its a space and efficiency improvement over current bitcoin. Adam -- 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=60134791iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?
There are some policy decision points in the protocol (and code) that may become centralized risks or choke points that undermine the p2p nature. So the extent that those can be argued to have in principle have a technical fix, it could be quite interesting to research the necessary technology (advanced crypto, byzantine networking argument etc) that could address them. eg payee/payer blacklisting by a large group of miners and committed transaction proposal to address it. However even for that type of thing I think bitcoin-dev would probably rather focus eg on something that has reached the stage of having a BIP. Eg it might be better to discuss early stage or speculative ideas on bitcointalk.org technical thread. https://bitcointalk.org/index.php?board=6.0 taxation in particular there are examples where even the political sphere accepts significantly anonymous taxation. eg for europeans with certain types of investment in a swiss bank, the swiss bank sends however many million as a single payment across all users per european country to their passport home country (minus 25% cut for the swiss government). Perhaps such things could be possible for bitcoin. Again I think bitcoin talk would be a good place for such a discussion if that was the OP question indirectly. Adam On Sun, Sep 29, 2013 at 06:32:10PM +1000, Gavin Andresen wrote: On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham [1]n...@asdf.co.nz wrote: I subscribe to this list so I can keep up-to date with bitcoin development, can we keep philosophy and tax evasion out of it? Yes, that's off-topic for this mailing list. Lets stick to technical issues that we can solve by writing code. -- -- Gavin Andresen References 1. mailto:n...@asdf.co.nz -- 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=60133471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=60133471iu=/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 think bi-directional sacrifice is probably not needed to assure a close to 1:1 bi-directional peg. (Bi-directional sacrifice meaning also to convert a zerocoin to a bitcoin you sacrifice a zerocoin and bitcoin would be modified to accept a zerocoin sacrifice as a way to replace a previously sacrificed bitcoin). I say that because if users who want zerocoins can obtain them at 1:1 exchange via sacrifice (a mathematical peg), it is of no additional cost to them to instead buy them from someone who previously obtained them via sacrifice for bitcoin (rather than sacrificing a new bitcoin). So presumably for goodwill, or nominal fee (a small discount), people would buy rather than sacrifice where there is availability. Adam On Sun, Jul 14, 2013 at 07:22:10PM +, John Dillon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón jti...@monetize.io wrote: 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. Seems that Peter is describing a system that requires no changes at all to the Bitcoin codebase and thus there are no costs whatsoever. Peter: I'm a bit confused by this concept of bi-directional sacrifice though, I assume there exists only a sacrifice in one direction right? Wouldn't selling a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx moving it to the new owner only happens if a specific form of bitcoin tx happens too? 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. Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC channel and on bitcointalk as well if memory serves. I advise you to look up his description of the problem, almost everything he writes on the topic of crypto-coin theory is spot-on correct. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915 SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ= =b40P -END PGP SIGNATURE- -- 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
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 -- 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
[Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
Hi I presume everyone saw the announce from Matthew Green Ian Miers at JHU on the release of libzerocoin: https://github.com/Zerocoin/libzerocoin So now that raises the question of how can people experiment with real money with zerocoin. I think its fair to summarize there is resistance to merging into bitcoin as it slows validation, bloats the blockchain, and also a policy aspect it also imports cryptographic privacy into bitcoin. On the forum thread on zerocoin math etc I suggested maybe people interested to explore bitcoin could create an all-zerocoin alt-coin that is either-or mined and p2p exchangeable for bitcoin. 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). what about making an all zerocoin based alt-coin (no bitcoins, nothing but zerocoins), that is either-or mined with bitcoin. Then people can trade in and out of zerocoins by buying or selling them for bitcoin with an atomic transaction, probably p2p without some trusted exchange like mtgox. Either-or mined (as distinct from merge-mined) I mean that each mined coin set is either a set of 25 bitcoins or a set of 25 zerocoins. If its a zerocoin set its not a valid bitcoin set, and if its a bitcoin its not a valid zerocoin. I'm not sure the zerocoins or bitcoins have to do much with mining events for the other network other than check they have the expected number of bits as they wont automatically know how to validate the other network. Some miners may choose to validate both networks, but thats a choice for them. In that way people can experiment with zerocoin, without bloating the block chain, complicating bitcoin, and without slowing validation on the bitcoin network. And the two coins should have approximately the same cost (and maybe therefore value, though the price would be subject to demand/supply and any taint discount for bitcoins; zerocoins are taint free, or perfectly blended taint at least). Adam -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
This maybe simpler and trivially compatible with existing type2 public keys (ones that are multiples of a parent public key): send an ECDSA signature of the multiplier, and as we know you can compute (recover) the parent public key from an the ECDSA signature made using it. Adam On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote: [q-th root with unknown no discrete log artefact] If it was a concern I guess you could require a proof of knowledge of discrete log. ie as well as public key parent, multiplier the address must include ECDSA sig or Schnorr proof of knowledge (which both demonstrate knowledge of the discrete log of Q to base G.) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Agreed. What I mean is a coinbase for parity-priced alt-coin would be intentionally considered (and required by the alt-coin to be considered) an invalid bitcoin address, and vice versa. The difference is for this purpose it is both valid alt-coin coinbase (as well as unspendable bitcoin coinbase). Adam On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote: On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote: I had one thought towards this which is a different kind of merged mining. I think a fair merged mining aiming for price parity would be done by the miner having to choose the altcoin or btc at mine time, and altcoin chain considering btc mine unspendable and bitcoin considering ac unspendable. One way to look at what you are describing is to say you want to prove your sacrifice of potential BTC earnings. That goes back to the PoW hashcash stuff I mentioned earlier, and is accomplished by simply mining shares with an unspendable coinbase to prove you did work that could have resulted in Bitcoins, but didn't. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
I had one thought towards this which is a different kind of merged mining. I think a fair merged mining aiming for price parity would be done by the miner having to choose the altcoin or btc at mine time, and altcoin chain considering btc mine unspendable and bitcoin considering ac unspendable. In terms of validation which miners are currently doing to help SVP clients, it implies verification of both chains. Or more incrementally each mine should indicate in its serialization which chain it has validated. This wa about a hypothethical pure zerocoin altcoin hence zc/zerocoin: Maybe we can say that a mergemine does not count as a validation of the network for the respective network unless there is serialization in the coinbase indicating that the network is validated. In that way you could have zerocoin mined and zerocoin validated, zero mined and bitcoin validated (strange but possible), zerocoin mined and both zero and bit coin validated, and also the same for bitcoin mined and zerocoin validated (strange but possible), bitcoin mined and bitcoin validated (normal bitcoin ignoring zerocoin) and bitcoin mined and bitcoin and zerocoin validated. Then the validation events on zerocoin network might not be as frequent. Maybe miners will tend to validate both networks as then they can claim fees on both networks, even if the protocol prevents direct merged mining on both networks (one or the other mined, and whatever chains validated as indicated by coinbase serialization). (I described it in this thread https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768 which is mostly about understanding zerocoin, but digressed at that point to a hypothetical pure zerocoin alt-coin that retains a fair merged mine and exchangeless tradeability with main bitcoin.) I think another gap is the exchangeless tradeability. Apparently the contract based proposals have race conditions, and ransom issues (refuse to complete agreed commitment phase without being part-paid again). I didnt follow that discussion yet but Greg Maxwell and Sergio Lerner were discussing and that seemed to be their conclusion, and Sergio's proposed solution relied on a non-standard and not-fully-worked-through assumption for the alt-coin (probably non-SPV compatible I think). ps I thought it was quite interesting that seemingly you could make a pure zerocoin alt-coin, it turns out you could direct mine them, and do zc-zc transactions. They are fixed denomination however I think you could extend them with homomorphic amounts. I noticed Matthew Green mentioned this idea in his presentation at microsoft research (saw in the video they have put online). From my perspective (he didnt specify how other than as an attribute) its something like a Brands credential where you can prove in ZK that two attributes sum to a given value without revealing the attributes at all. The missing last part is you have to prove that the attributes are less than some threshold to avoid people cheating and adding q to their balance. (Arithmetic in the exponents is modulo q in the subgroup used in zerocoin). There are several approaches to doing this some of them not that cheap (eg involving k DSA-like signatures to prove vale v 2^k). The idea of proving it is less than k where k is say 128 is that then to add q, you have to spend 2^128 coins which you cant do. You can either make the values uncertain by having v eg have 44 bits of useful precision and a few binary 00s and then 80-bits of randomness, or you can use a second never disclosed random attribute like in a Pederson commitment or Brands credential eg c=g^v h^r mod p where r is random and never disclosed, but the user proves knowledge of discrete log representation of c in terms of powers of g and h. The downside of k signatures is validation CPU cost, and worse transaction size. There are several other approaches which seem to be able to prove v 2^k with less than k, eg even 1 DSA-like signature. I need to gather that info in one place and write something referencing the literature I found so far. A homomorphically verifiable coin balance transfer could be interesting outside of zerocoin - eg for bitcoin, or an alt-coin. Adam On Sun, May 19, 2013 at 03:23:59PM +0200, Adam Back wrote: Is there a way to experiment with new features - eg committed coins - that doesnt involve an altcoin in the conventional sense, and also doesnt impose a big testing burden on bitcoin main which is a security and testing risk? eg lets say some form of merged mine where an alt-coin lets call it bitcoin-staging? where the coins are the same coins as on bitcoin, the mining power goes to bitcoin main, so some aspect of merged mining, but no native mining. and ability to use bitcoins by locking them on bitcoin to move them to bitcoin-staging and vice versa (ie exchange them 1:1 cryptographically, no exchange). Did anyone figure anything like that out? Seems vaguely doable and maybe productive
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
So the idea is that people may want to use proof-of-work unrelated to bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC (and with a published USD exchange rate). And the ways they can do that are to: a) create unspendable addresses (which maybe you cant compact in the UTXO set if the unspendable address choices are not standardized) b) spend to anyone which I take it goes to a random person who happens to see the address first and race the spend to me out on to the network, and hope miners dnt replace it with spend to miner, which is insecure c) doesnt delay by 100 blocks just delay the spend to me race? Also most likely to be one by a big miner once they adapt and join the race. d) some new standardized spend to fees (only miners can claim). e) spend to charity/non-profit of choice could be useful also f) I guess we see something related in zerocoin - locked but unlockable via another type of transaction later. g) why not instead make the beneficiary the address of the service the user is consuming that is being DoS protected by the proof-of-sacrifice? Seems more useful than burning virtual money, then it helps the bitcoin network AND it helps the service provide better service! so if I understand what you proposed d) seems like a useful concept if that is not currently possible. eg alternatively could we not just propose a standard recognized address that clearly no-one knows the EC discrete log of? Adam On Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote: Currently the most compact way (proof-size) to sacrifice Bitcoins that does not involve making them unspendable is to create a anyone-can-spend output as the last txout in the coinbase of a block: scriptPubKey: data OP_TRUE The proof is then the SHA256 midstate, the txout, and the merkle path to the block header. However this mechanism needs miner support, and it is not possible to pay for such a sacrifice securely, or create an assurance contract to create one. A anyone-can-spend in a regular txout is another option, but there is no way to prevent a miner from including a transaction spending that txout in the same block. Once that happens, there is no way to prove the miner didn't create both, thus invalidating the sacrifice. The announce-commit protocol solves that problem, but at the cost of a much larger proof, especially if multiple parties want to get together to pay the cost of the sacrifice. (the proof must include the entire tx used to make the sacrifice) However if we add a rule where txouts ending in OP_TRUE are unspendable for 100 blocks, similar to coinbases, we fix these problems. The rule can be done as a soft-fork with 95% support in the same way the blockheight rule was implemented. Along with that change anyone-can-spend outputs should be make IsStandard() so they will be relayed. The alternative is sacrifices to unspendable outputs, which is very undesirable compared to sending the money to miners to further strengthen the security of the network. We should always make it easy for people to write code that does what is best for Bitcoin. -- 'peter'[:-1]@petertodd.org 00ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
I like this idea a lot. To add: I think it is a bug and security risk if pooled-solo or (current pooled miners) do not add randomness to their extraNonce2 (like 128-bits of it). For privacy and to avoid various hostile-pre-mining attacks it should be done this way. Lack of the self-chosen challenge field is the reason Satoshi's first year mining is marked (plus forgetting to reset the counter). (Bitcoind I believe considered the direct miners key as defense enough as a stand in for self-chosen challenge, which has a few problems). The base counter I think is only 32-bits, the extranonce2 itself being random can be incremented while still looking random. But incrementing extranonce directy while initializing it to 0 is not good (per previous mining extranone marked coins bug - is that even fixed?) (You dont want to reveal the miners power in his pool shares, if the full counter is revealed with no randomness it also reveals how many iterations he can do since the block start). Adam On Fri, May 31, 2013 at 12:57:58PM -0400, Peter Todd wrote: I just posted the following to bitcointalk. https://bitcointalk.org/index.php?topic=221164.0 Right now between two to four running the largest pools control Bitcoin in the short term. That's a lot of hashing power in the hands of very, very few people. In addition pools have little incentive to run secure operations, and many pools have been hacked with their funds stolen. Those hacks could just have easily been used to attack the network itself. This needs to change. Pooled-solo mining is a concept Gregory Maxwell, Luke Dashjr and I were discussing at the conference two weeks ago. (credit goes to Greg and Luke; I was mostly just listening) Basically the idea is that miners with mining equipment run a local Bitcoin node and use that node to construct the blocks they mine - the same as if they were solo mining. The pools job is then to only track shares and organize payouts. If the pool gets hacked the worst that can happen is miners are ripped off, rather than Bitcoin itself being attacked. With pooled-solo mining even a pool with a majority of hashing power wouldn't be able to do much harm to Bitcoin. (depending on the implementation they may be able to blacklist specific transactions - the pool needs to know what transactions are in the share to credit fees properly) Tech-wise Luke created getblocktemplate last year as a means to audit mining pools. I'm sure Greg and Luke can explain the nitty gritty details better than I can, but essentially the plan is to take getblocktemplate and extend it as required for pooled-solo mining. This will include pool and miner software initially, and later improvements to GUIs and what not to make the whole process easier. With the success of my recent video project I also want to make this Keep Bitcoin Free's next project, specifically funding a developer (likely Luke) to make this happen. Additionally once software is written and easily usable a good follow-up would be a video and other media to promote the idea to miners. No guarantees we'll be able to come up with commercially competitive remuneration, but we can at least come up with a Thank you tip. But first lets discuss the technical requirements to get an idea of what the scope is. Finally, for the record, a big part of the reason why myself and other Keep Bitcoin Free supporters are interested in doing this is very much to take power over the direction of the network from big pools and put it into the hands of thousands of individual miners. It's much easier to convince people that changes to Bitcoin, like increasing the blocksize, are directly impacting decentralization when individual miners are seeing that happen to themselves. -- 'peter'[:-1]@petertodd.org 00c14fa7031b2431ab32785efdf1e5aaecc83555ee52a2fc550b -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 07:45:34PM -0700, Gregory Maxwell wrote: [committed coins] depending on how its done, at most conceals the transactions from people who aren't a party to them... though as time goes on eventually everyone becomes a party to a sufficiently old coin, and avoiding publication creates quadratic costs in evaluating a private clique's claims so I believe the coin size and verification cost is linear not quadratic, but maybe it depends on the parameter you're measuing in. The coin size is linear with the number of committed (uncompacted) spends. You can view reveals as committed compaction. For efficiency a recipient of a committed coin may as well compact and spend in one transaction so no new messages are created. Btw I believe if one were concerned about the committed coin size, I can see a small tweak that would keep the size of the committed coins small eg 256-bit regardless of number of spends (no longer grows), and let the block store the encrytped MACed commitment. Then compaction is no longer a concern. However I think that is SPV - SPV client unfriendly. (A full client - SPV client should still be workable as the full client could alternatively send the client the MACed data and key, rather than have him look at it from his block history.) (Crypto sketch below). However I am not sure multi-spend committed coin size is really a concern because to the extent people hold long commitments without revealing to the network for the long term, that is a bandwidth saving to the network. Overall about privacy it would be typically temporary, though the peers have the technical means to react and defend themselves by using longer committed chains if dishonest mining is detected on a significant scale. instead an implementation would make the identities public but only once they're burred a bit. That was the seed idea. The more aggressive spend lots of times in committed form is just a technical threat that will keep dishonest mining in check. By definition the coin is already irrevocably spent before the reveal (without the threat of having the dishonest miners endlessly redoing their own deeply burried work). The only person who could be punished by policy by 50% dishonest miner (retroactively) is the recipient, not the spender, and the punishment is very muted: all he can do is prevent coin compaction. If the committed coins are small, compact doesnt even hurt the committed coin user, just network itself. Therefore a dishonest miner is wasting his time his dishonesty cant enforce his dishonest policy. To store the commitments in the block chain replace: (blind-sender, auth-tag, tx-commit) blind-sender = SHA1( SHA256( 1, pub ) ) auth = HMAC-SHA256-128( K, tx-commit ) tx-commit = SHA-256( tx ) K = SHA-256( pub ) with: (blind-sender, auth-tag, encrypted-tx-commit) blind-sender = SHA1( SHA256( 1, pub ) ) auth = HMAC-SHA256-128( K, encrypted-tx-commit ) encrypted-tx-commit = AES( K, tx-commit ) (*) K = SHA-256( pub ) then a reveal is just to send the recipient the public key (32 bytes) per hop, still linear but ~3x smaller. I suggested fixed size committed coin spends, that also you can do but with public key crypto needed probably, and so dropping to the verification efficiency of standard transactions. Sketch 2: (blind-sender, auth-tag, encrypted-tx-commit) (pub key P = xG, G = base point) blind-sender = cP (public key EC multiplied by constant c) sig = ECDSA( cx, encrypted-tx-commit ) encrypted-tx-commit = AES( K, tx-commit ) K = random as K is random, knowledge of P if stored unencrypted does not allow committed spend-to-junk. To reveal to a recipient just send them P and K at each hop. (Same K each time, anyone on the committed coin spend chain can already chose to reveal at any time so no loss of security.) You dont need to verify a second signature inside the tx-commit because you already signed the encrypted-tx which binds to it (encryption with out MAC is malleable but you cant change it at all without invalidating the encryption). Just need to check the input tx in the tx-commit has P as its recipient. P does not even need to go into tx-commit as its already bound by cP and signature security (cant create a signature with someone elses key). So I think the commited coins of this form are the same size and verification cost for the network. And small and fixed size to spend offline. (32+32=64 bytes fixed). Adam (*) You should not as a principle re-use keys across algorithms, I omitted a second key for simplicity. Really K1 = SHA256( 1||pub ), K2 = SHA256( 2||pub ) encrypted-tx-commit = AES( K1, tx-commit ), auth = HMAC( K2, encrypted-tx-committ ). Or more simply a combined authenticated mode like CCM or GCM and a single key managed by the mode. -- AlienVault Unified Security Management
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
More somewhat improved crypto stuff...
On Thu, May 16, 2013 at 01:32:22PM +0200, Adam Back wrote:
I suggested fixed size committed coin spends [...]
(blind-sender, auth-tag, encrypted-tx-commit)
(pub key P = xG, G = base point)
blind-sender = cP (public key EC multiplied by constant c)
sig = ECDSA( cx, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )
K = random
as K is random, knowledge of P if stored unencrypted does not allow
committed spend-to-junk. To reveal to a recipient just send them P and K at
each hop. (Same K each time, anyone on the committed coin spend chain can
already chose to reveal at any time so no loss of security.)
Actually same K every time is not so hot, as then earlier in the committed
spend chain, can force a reveal for someone later. A clearer requirement is
that each person should only be able to reveal committed coin chains up to
the point of their direct involvement.
So that is easily fixable, just include the K for the input committed coin
in the encrypted-tx-commit, as above but:
encrypted-tx-commit = AES( K_i, K_{i-1} || tx-commit )
K_i = random
(different K for each spend).
And actually for symmetric encrypted variant the coin as specified was
already evaluatable with fixed size committed spend (of the last public key)
- I just didnt realize it in the previous mail: the input public key is
necessarily revealed when processing the decrypted tx-commit, allowing
identification and validation of the txin, and validation recursively back
to the first non-committed coin. With symmetric verification, the
limitation is one-use coin committed addresses (and inability to remove
spend to committed junk with public validation, though there is the tx fee
as a discouragement, it does bloat a recipients verification and so maybe
frustates SPV-SPV consumption of committed coins).
(blind-sender, auth-tag, encrypted-tx-commit)
blind-sender = SHA1( SHA256( 1, pub ) )
auth = HMAC-SHA256-128( K, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )
K = SHA-256( pub )
Adam
ps and it would be better and clearer to read also in terms of purpose of
hashes, to use a KDF like IEEE P1363 KDF2, or PKCS#5 PBKDF2 with 1
iteration, rather than adhoc hashes for key derivation.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
from scratch. Often if simple lower powered intermittent recipient sends the coin will be burried hundreds of blocks back. In addition 6 chain long branches are extremely unlikely with honest payers, so clients can (and maybe already do?) act with suspicion of they see one. Going further, I said for best security, the recipient should never even reveal (to the network) until he is actually about to spend, but futher he does not even have to reveal publicly ever, he can choose to reveal only to the recipient with a direct connection (no p2p flood fill of transaction.) And the direct spend argument composes, ie the 2nd recipient can not do the same thing again. (public key A sends to public key B sends to public key C: B publishes COM( transaction B-C ), sends the reveal of COM( transaction A-B ), and COM transaction B-C ) to C. C waits 6 confirmations and is convinced. So its the approach is composable, and in fact the network doesnt learn the size of the transaction even, though the spend grows each time. Eventually presumably someone will publish will the confirmations to the network to trim the tansaction size, though it is not strictly necessary, and the transaction flow is small and direct (no network scaling issues), so that it wouldnt be a huge problem to have a 1MB payment representing 1000s of hops of network blind transactions. (For the composable network blind respending the commitment has to commit publicly to both the sender and next hop recipient keys, so the network can see how long the chain is). Probably you can cope with multiple inputs and outputs, and maybe given even you can work with a 100% dishonest network mining network (all the dishonest miner can do is selectively DoS transactions if they are all network blind except the mining), maybe the mining can even be decoupled from the voting, as you no longer demand much from the voting process. That admits more interesting things like pool free direct mining, low variance hashcash coins, probably. Many things to think through. I suppose the commitment could be described as a blind symmetric commitment. Adam On Tue, May 14, 2013 at 04:09:02PM +0200, Adam Back wrote: [...] One related concept is commitments. I think its relatively easy to commit to a payment and lock a coin without identifying yourself, until the commitment is released. You might do the commitment, wait 6-blocks for confirmation, then reveal the commitment. Then that is like a self-issued green coin with no need for trust, that can be immediately cleared. The recipient has to be committed to at the same time to prevent double spending. So just commit = H( input-pub ) H( transaction ) and put it in the block chain. Where transaction the is usual ( input signature, output-pub, script). (Fee for the commit would have to come from an unlinked coin or the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction (free because fee was already paid). Validators check input-pub hash against committed coins by hash, check the transaction hash, and the usual ransaction validations = sum inputs, otherwise reject. The user better pay change if any to a different public key, as the inputs public keys are one use - are after the reveal they are DoS lockable by other people reposting H( input-pub ). The input-pub coin is locked as normal transactions have their public key hash validate as not being locked. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] double-spend deletes (or converts to fees) (Re: reward for making probabalistic double-spending via conflicting transactions easy)
On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: no-one seems to think much about how in practice very few vendors have a setup to detect if conflicting transactions were broadcast on the network simultaneously - after all if that is the case which transaction gets mined is up to chance, so much of the time you'll get away with a double spend. We don't yet have a mechanism to propagate double-spend warnings, and funny enough, in the case of a single txin transaction the double-spend warning is also enough information to allow miners to implement replace-by-fee. About double-spends it might be better if the double-spend results in no-one keeping the money ie it gets deleted by definition (except for the fees, or the whole payment gets converted into a 0BTC output so 100% fees). Ideally you'd want a way for known double spends to be circulated at priority in the p2p network, even routed directly to earlier recipients if known. However have to watch out for even the fees being double spent in other transactions. Maybe the fees could be demanded to be self-created (no trusted green-coin issuer) 6-confirmation spend-to-miner green-coins. (Note double spends are not-binary. An attacker can spend a 25BTC coin via 50x 1BTC transactions. Which 25 are valid? Currently it is the first 25 from the network perspective of the miner that succeeds on the current block. (And that view overrides, even if other miners had differing views, unless the block later becomes an orphan). Its surely easy for a double spender to accumulate fast connections to known powerful miners to get the spends that benefit him to them first.) In that way (with double-spend deletes) the would be double-spender can not gain within the bitcoin protocol by double spending. He can gain outside of the protocol eg by persuading merchants to give him non-revocable resellable non-physical goods (or physical but anonymous goods). But that is harder work, and people selling goods with no recourse will be defensive about confirmations. ps I still dont think replace-by-fee is a good idea, at least the way it was implemented with changeable outputs, but I think that discussion seemed closed, so I wont rehash it. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote: If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. Bit-commitments are based on deterministic one-way functions eg like SHA1( SHA256( public key ) ) Obviously it has to be a different one-way function to the coin address calculation which is RIPEMD( SHA256( public key ) ) as that is already public. Alternatively it can be a different serialization using the same hash eg RIPEMD( SHA256( 1 || public key ) ). There is only one commitment possible per public key - so you can only create one commitment that would validate to a receiver, or to the network. The network checks that there are no non-blind double spends of committed coins which it can do as spends require disclosure of the public key, which allows existing commitments to be verified, and it similarly qchecks that there are no blind double-commitments. Each committed coin would be: one-spend-commit = Com( spender pub ), Com( transaction ) where Com is implemented as the above hash. The network just places the commitments in order as with conventional transactions. The committed coins are not linkable to your non-blind coin because you did not reveal your public key in the (largely passive) act of receiving to a coin address. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap ransom is effective. The temporary unlinkability (until commitment reveal) is a necessary side effect, not a cryptographic anonymity feature like zerocoin. The transactions are identical to bitcoins once revealed. How long the committed transaction chains can be between reveals is an implementation choice could be 1 hop, or as long as you like. (Actually it appears to be up to the individual users how long the maximum chain they accept is - the network itself, though ordering the committed spends (if there are multiple spends on the same key) cant even tell how long the commitment payment chains are). Obviously the first coins in the network ordered committed coins on the same key up to the coin value are spends as verified by the recipient, the rest are double-spend and ignored. If someone wants to waste fees by sending more spends than there inputs thats up to them. Probably the typical user doesnt care about long committed chains other than their wallet will bloat if the chains are too long, so probably they would periodically compact it by revealing the long chains. Committed coins are probably a bit less SPV client friendly, though with correct formatting in the merkle trees between blocks, probably a committed coin holder can provide enough proof to an SPV client to verify even multi-spend committed coins directly (without a network feed). About privacy, up to the entire commitment chain can be opened at any time (to other people or to the bitcoin network in general) with the cooperation of any user on the chain (up to the point they saw it), so while the blind commitment protocol is not vulnerable to a 50% power quorum unilaterally imposed policy (without even needing client updates), it is fully dependent on the good will of the recipients for its temporary unlinkability. Thats the point: it puts policy control in the users hands not in the 50% power quorum. If you want cryptographic anonymity its better to look to zerocoin. You may have noticed zero coin talked about optional fraud tracing. Its usually trivial to add tracing to an otherwise privay preserving protocol. The blind commitment if implemented as described (and its not obvious how to get more privacy from it) offers somewhat like community policing. Users on the chain can still themselves do fraud tracing, or any policy they choose, on any blind committed coins that they receive. If they dont like the colour of them they can refund them. The point is to enforce that this is a free uncoerced community choice, by individual end users, not a 50% cpu power quorum choice surreptitiously imposed. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
btw I posted some of this thread on the dev forum: https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994 A related idea is occuring to me that maybe these committed transactions could actually as a side effect make bitcoin scale slightly better by reducing the p2p flood filled transaction size. As I said on the forum: Note committed transactions are more compact than regular transactions - they are just two hashes, so they reduce network bandwidth and make bitcoin more scalable to the extent that transaction reveals stay off network. (As well as more secure against centralization policy risks). Surely its lower bandwidth for nodes to send only committed transactions to the p2p network, and pass committed payment chains direct to recipients. Say committed transaction size is c (20bytes+32bytes+16bytes +header ~ 72 bytes?) And full transaction smallest size is t (txin=20bytes, amount out 4bytes, sender pub key 32bytes, recip address 20bytes, change address 20bytes, formatting 5 bytes, ECDSA signature 64bytes, script 10 byte surely ~ 175bytes)? Thats over twice the size. Probably average more, and it is sent to every node. Its always going to be lower bandwidth to send transactions to the recipients than to send to the network, even if you have to increase the transaction size with each respend. The alternative is for the entire network to see the same transaction. I think the commitment needs to bind the two parts together eg (blind-sender, auth-tag, tx-commit) blind-sender = SHA1( SHA256( 1, pub ) ) auth = HMAC-SHA256-128( K, tx-commit ) tx-commit = SHA-256( tx ) Or some variantion, and you must not reuse the pub key, and must send change if any to a different address, otherwise chain recipients or malicious forwarders could lock your coin, by putting random junk onto the network which would be unverifiable, and non-disclaimable - you cant prove you dont know the preimage of some junk. The MAC prevents it. Maybe there's a more compact way to do it even, but that works efficient demonstration of security feasibility. Other public key variants could be possible, P = xG is the ECDSA public key, x the private key, G base point. Sender could reveal P' = cP, c some fixed constant (computing c from cP is ECDL problem considered oneway hard), and a signature by private key x' = cx over the tx-commit. That is a publicly auditable commitment also, but one tht can make an ECDSA signature over the tx-commit hash, and can be revealed by revealing P later. However that imposes public key computation on the validation (which it already currently does, but faster validation as above is nicer). With that one you dont even have to verify the transaction signature on reveal :) You already did it, just provide the tx that hashes to the signed hash, and P for the recipient to verify the signature was made by cP. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] ecash and revocability
So back in 1999, in an ecash thread on cypherpunks I claimed: http://marc.info/?l=cypherpunksm=95280154629900w=2 I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. This was in the context of a discussion of digigold (e-gold stored the physical gold, digigold offered ecash backed in that physical gold). Digigold ran on Systemics payment server/sox protocol. Because of inferred regulatory concerns and patent licensing issues digigold systemics were not using blind signatures. However with systemics sox server, like bitcoin, you could create multiple accounts on demand and shuffle payments around for a degree of privacy. The bitcoin analogy would be the transaction log lived in the systemics server, so it had a central failure point, but arguably more privacy as the log was not public. Also systemics SOX protocol (Ian Grigg Gary Howland) had some aspect of bitcoins smart contract concepts - ricardian contracts. http://iang.org/papers/ricardian_contract.html (Btw the anonymous reply itself was interesting - http://marc.info/?l=cypherpunksm=95280154629912w=2 that could have been Nakamoto, the only missing thing from the parts on the discussion room floor to bitcoin is mathematical inflation control.) The thread actually started here http://marc.info/?l=cypherpunksm=95280154629912w=2 and then continues here http://marc.info/?l=cypherpunksm=95280154629900w=2 because of a subject line change and then http://marc.info/?l=cypherpunksm=95280154629916w=2 and http://marc.info/?l=cypherpunksm=95280154629948w=2 more subject line change confusion. A related thread a few days later also covers Sander Ta-Shma (which zerocoin is based on): http://marc.info/?l=cypherpunksm=95280154630167w=2 there were many more threads about various ecash technologies. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoin taint unilateral revocability (Re: ecash and revocability)
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote: Adam Back in Sep 1999, cypherpunks list: I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. So I still think that is an important point. Ecash should not be revocable. I think bitcoin currently has a partial problem because of taint. Now blinding based unlinkability, in a distributed cryptographic payer/payee anonymous system like Sander Ta Shma [1] and zerocoin has so far been based on ZKP of set membership. Of course that is somewhat expensive, though zerocoin improved the ZKP with an relatively efficient (but still cut-and-choose) proof. Bitcoins relative lack of privacy creates a problem with tainted coins risking becoming unspendable, or spendable only with some users, or at a discount. So while the policy coded says all coins are equally acceptable, the information exists so people can unilaterally reject them, depending on what the taint is. So far revocability hasnt reared it's head that I heard, nor taint inspection too much? However people have the choice and technical means to check the taint and send the bitcoins back. Another aspect is that bitcoin, like systemics sox/digigold, makes a different privacy tradeoff. Somewhat private, but not very much. But it creates the question: could the taint issue be fixed efficiently (eg even without blinding or ZKP of set membership?) One related concept is commitments. I think its relatively easy to commit to a payment and lock a coin without identifying yourself, until the commitment is released. You might do the commitment, wait 6-blocks for confirmation, then reveal the commitment. Then that is like a self-issued green coin with no need for trust, that can be immediately cleared. The recipient has to be committed to at the same time to prevent double spending. So just commit = H( input-pub ) H( transaction ) and put it in the block chain. Where transaction the is usual ( input signature, output-pub, script). (Fee for the commit would have to come from an unlinked coin or the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction (free because fee was already paid). Validators check input-pub hash against committed coins by hash, check the transaction hash, and the usual ransaction validations = sum inputs, otherwise reject. The user better pay change if any to a different public key, as the inputs public keys are one use - are after the reveal they are DoS lockable by other people reposting H( input-pub ). The input-pub coin is locked as normal transactions have their public key hash validate as not being locked. Adam [1] Sander Ta Shma Auditable, Anonymous Electronic Cash http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote: Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats not so good. [...] [...] Just referring to a standard, fee-bearing, user-created bitcoin transaction, where output_value input_value. The fee is paid to the first miner who includes that transaction in a block, as part of the protocol. Yes but thats inferior in the sense that it is spamming the bitcoin payment protocol slightly, to the small reward of miners, and involves actual money and traceability to real-name (where did you get the coin from to spend). If alternatively you just proof you direct mined on a block with a coinbase that immediately makes payment to future miners its better because: a) you can do that with no new traffic for the bitcoin network (except when you mine a whole block, you'll post it); and b) anyone with a reasonable verification on the blockchain head (even if the spender has to give it to them!) can verify it without any other network traffic; and c) if its micro-mined on the spot it can be bound to the service whereas if you give it to fees as an on network transaction you are limited to values above the min tx fee. So idealy I think you need to be able to simultanously mine and give reward to future block miners. What you could do with out that is d) mine for the reward of bitcoin foundation/software author/or service provider. In the last case (service provider) its an extreme form of Rivests peppercoin probabilistic payment Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides
On Tue, May 14, 2013 at 09:39:46PM +0200, Harald Schilly wrote: If you have your own domain, you can store your key there as a TXT entry. $ dig +short harald._pka.schil.ly. TXT and even use it automatically: $ gpg … --auto-key-locate pka -r email@address.domain Nice. But we all kow about the security of DNS ;) Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
On Mon, May 13, 2013 at 07:31:21AM +, John Dillon wrote: [with] merge-mining [you get] more value from just one unit of work. correct. But Peter's coinbase hashcash protocol carefully ensures [...] the amount of value the miner would have then given away in a anyone-can-spend output. I think there are 3 choices: 1. merged-mine (almost zero incremental cost as the bitcoin mining return is still earned) 2. destroy bitcoin (hash of public key is all 00s so no computible private key) 3. anyone-can-spend (= first to spend gets coin?) Surely in 3 if you mine the bitcoin its no particular assurance a you will do your best to make sure that it is *you* tht spends it, so it devolves to merged-mine. (Eg delay revealing it for 10 seconds while you broadcast your spend widely) Peter talks about value, but the proof only proves cost equal to bitcoin. Those are not the same thing. And they are so-far non-respendable. I still dont understand what he was saying. If you do please speakup. I think potentially a publicly auditable pooled mining protocol would be a place to start thinking about respendble micropayments. I made a post on the bitcointalk forum outlining how that could be done: https://bitcointalk.org/index.php?topic=1976.msg2035637#msg2035637 if you have a publicly auditable pool, where users can prove to each other outside of the bitcoin transaction log that they contributed a number of shares to a block, those could be traded somehow. Possibly eg with the pool keeping a double-spend db. If the payments are low value, people maybe happy trusting a pool. If the pool cheats, everyone stops using the pool. You rely on the pool not to spend the backing bitcoin blocks. But it remains possible for the pool to cashout people who collected enough shares. Probably you could do that with blinding if desired. [probabilistic micro-payments] I think you are misremembering [...] It is not a probabalistic scheme. You are right I was thinking of Rivest's peppercoin. In this way one can merge mine bitcoin hashcash to the benefit of the recipient (or some beneficiary trusted not to be paying the proceeds to the spammer). And in a way that scales to email scale, and does not involve installing a bitcoin client in every client, nor mail server. Blockchain header data may very well be one of the most widely distributed single data sets in the history of mankind, and most of its closest cousins are definitions such as the ASCII table or near definitions like the DNS root servers. Not something with new data every 10 minutes. Well there doesnt need to be a one-true-blockchain DNS, though the power to output a hash at any reasonable rate is a big proportion of the network power. And the outputs are instantly verifiable, so it forms a kind of trapdoor hashchain (where the trap door is not a secret but havng a huge amount of CPU power). And there can and should be many blockchain via DNS. For namesaces in general another approach other than DHT/flood is numerous competing hierarchical, heavily cached, but publicly auditable. Cheaters are shunned. Same effect, more scalable, most people are not cheating most of the time. http://cypherspace.org/p2p/auditable-namespace.html Adam -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)
Some musings about the differences between Peter's proof-of-sacrifice (you did the work but elected to make the small reward chance unclaimable), vs conventional actually doing the work but then destroying the bitcoin! - proof-of-sacrifice seems similiar to hashcash except its difficulty is time stamped and measured against the bitcoins dynamic difficulty, (coordinated inflation control being something posited but never implemented in hashcash). So thats kind of interesting, particularly if you can do it with very low bandwidth, and decentralized; unclear. - with proof-of-sacrifice its more offline because you do not need an on block-chain double spend protection (via flood-fill, validation, and block chain mining) because it is simply unspendable, though you could show the same proof to multiple people. In any case the values are far too low to spam the block chain with. - because proof-of-sacrifice is small you can afford to mine them on the spot and make them payable to the identity of the recipient, like cheques: they identify the recipient, so they are automaticaly non-respendable in the eyes of the recipient (he keeps his own double-spend db, and people wont accept cheques made payabe to other people). This is how hashcash works for email. Also a time-stamp ensures you dont even need a big double-spend db, as you can prune it if you reject expired cheqes. - you could give a proof-of-sacrifice a private key, just like bitcoins; then they could be pre-mined and identity or other info could be signed later. However then you have double spending issues again. You can - I mentioned amortizable hashcash under-contribution feature you can make it so the recipient uncovers the actual value of the coin (if it is merge-mined). (Put recipient public key in coinbase, hash for min share size eg 32-bits leading 0s call that collision; send to recipient, he decrypts the hash with private key, so the decryption is verifiable with public key. Then the full value of the coin is zerobit( collision ) + zerobits( decrypt( collision ) ) if that alternate validation was allowed in bitcoin. - what about if a pool could lock the reward (rather than receive it or destroy it) eg some kind of merkle root instead of a public key hash in the reward recipient address field in the coinbase. Then the miners who created that block have actual share proofs that are claims against something eventually redeemable. Maybe if they collect enough share-proofs to reach a minimum bitcoin transaction size, they can redeem a big strip of shares for a few mBTC, but claims below that are rejected by the network due to tx fee. (btw I think it seems possible to have a publicly auditable pool so it cant skim nor disclaim shares.) I've been thinking about a decentralized way to create an anonymous identity, something I think it key to any number of decentralized, P2P and anonymous markets. There were some systems that charged hashcash for pseudonyms i2p names (i2p is a ToR like system)... see htp://www.i2p2.e/naming.html then there was of course namecoin. There was some remailer/email nymserver integration as well. Getting back on topic, somewhat, one idea I had for creation cost of a SIN was associating the creation cost of a SIN with a bitcoin transaction's miner fee. Anybody in the world could, therefore, create a SIN in a decentralized fashion, simply by following a published protocol for burning a specified amount of bitcoins via miner fee. It can be cryptographically proven with 100% certainty who Yes it seems that having a proof-of-sacrifice that hardens the block chain is the important part. When you said destroy-via-miner-fee: Don't forget: 4. destroy-via-miner-fee, which is useful because it provides funding for a public service (bitcoin transaction verification). Is that directly possible? Because the reward transaction has no source, and no fee? Or can you put a 25BTC fee in the reward transaction in the coinbase? If so that seems like the best option for proof-of-sacrifice rather than proving destroying the possibility of reward. But alternatively the bitcoin foundation as recipient, or EFF etc. 25BTC is a big reward might have some double roll-over lottery effects - everyone piles in for the occasional 25BTC! Adam On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote: On Mon, May 13, 2013 at 6:54 AM, Adam Back a...@cypherspace.org wrote: On Mon, May 13, 2013 at 07:31:21AM +, John Dillon wrote: [with] merge-mining [you get] more value from just one unit of work. correct. But Peter's coinbase hashcash protocol carefully ensures [...] the amount of value the miner would have then given away in a anyone-can-spend output. I think there are 3 choices: 1. merged-mine (almost zero incremental cost as the bitcoin mining return is still earned) 2. destroy bitcoin (hash of public key
Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key
At ZKS other than freedom network (ToR precursor) we had psueudonyms associated with cookie managers. The idea was you create pseudonyms for different purposes to segregate your online linkability. medical casual browsing social media private work true name Seems to me that people are always going to make mistakes with individual keys, even if the feature were there and accidentally link all their coin sources together. I presume people saw the analysis of the slush related 25k BTC theft, even seemingly the thief made possible slips while trying presumably not to: http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html Does the client have any privacy algorithm (to minimise coin source cross linking) to reach a given payment? eg consider say I use social media, with a screen name; I collect reddit tips etc; I pay them out to others, or use them to buy virtual goods associated with the same purpose. It would be rather useful to help people achieve that, there is already the ability to create addresses, label them. But I think just for the GUI to allow you to control which address the payment is from would be enough, it doesnt seem like such a complicated concept. And if people dont care, they only need create one address. Technically ZKS wasnt anonymous networking like ToR but pseudonymous networking. Multiple wallets for different unlinked purposes would be somewhat analogous to ZKS freedom pseudonymous networking cookie-jar. Because of the pseudonymity in ZKS misbehavers could be blocked by exit nodes based on pseudonym. Of course they can always create a new pseudonym but then they lose their accumulated reputation. You can even make people pay for pseudonyms, as I recall users got 5 free pseudonyms but had to pay for more. (Though I have to admit the concensus after some years at ZKS was most end users didnt understand what a pseudonym was! They just wanted to be private and have the computer magically solve it for them.) If you want to simplify maybe you could consider normal (linked to AML trading accounts, orders for physically delivered goods etc), and private analogus to the private browsing mode in various browsers. Maybe beyond 2 is an advanced feature but still available. Adam On Tue, May 07, 2013 at 03:19:50PM +0200, Pieter Wuille wrote: On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or I think the general solution here is providing a feature-reach Python RPC client, which can do things like remember passwords, command history/tab completion, perhaps even batch lookups of compound commands (getblock $(getblockhash X, for example, ...). The naive RPC client built into bitcoind is not a good fit for many features, as they can much more efficiently be developed outside of the core binary, 2. a button to import a private key (and option to transfer it to another key - if you are not the sole controller the private key) I'm quite opposed to any per-key fiddling in the GUI. This will inevitably lead to (even more) people misunderstanding how wallets work and shooting themself in the foot. I don't mind an expert mode (coin control) that enables such features, but in general, we should for entire-wallet export and import rather than individual keys. Import sweep an address is something else, that sounds safe to. 3. a UX way to transfer BTC off a specific adress (eg choose from address), rather than having to spend the entire wallet onto a new address, just to get BTC off a specific address. Doing it that way has problems: creates more network traffic/bigger packets, higher fees (if any transactions are young/low confirmation), and generally damages privacy as all your funds end up linked. This belongs in coin control, IMHO. -- Pieter -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Bitcoin p2p seeding requirements hav some ToR similarities, and we went through the same security considerations with Zero-Knowledge systems freedom network. Though bitcoins attacker profile and motivation is different - so the defense maybe even more demanding. At least you have no shortage of nodes and perhaps merchant interest and general good-will to lean on. At ZKS I proposed we should fix the exit node issue (exit sees where you go often in the clear) with an apache mod so the freedom aip tunnel (ToR tunnel equiv) could terminate right on the web site. (ZKS freedom network is long dead but some of the ideas I think made it into ToR, eg I hope my end2end forward anonymity idea that is implemented in Zach Brown's cebolla.) Anyway I'd have about DNS being of limited value: bitcoins primary vulnerability IMO (so far) is network attacks to induce network splits, local lower difficulty to a point that a local and artificially isolated area of the network can be fooled into accepting an orphan branch as the one-true block chain, maybe even from node first install time. (btw I notice most of the binaries and tar balls are not signed, nor served from SSL - at least for linux). Therefore as it applies to discover, you want to be able to discover peers through as many network routes, and even steganographic protocols as possible. eg if a popular web server (say apache, or an apache module) put a steganographic peer discover relay from its own network area, even for a small bitcoin fee, that would help a lot. (Steganographic in the SSL sense would just mean that the peer seed request to /btcseed.cgi would not be distinguishable to someone highly sophisticated on the inside of the router all the peers traffic is routed through. Eg you could easily do this with a special magic header that overwrites something else or deletes some unnecessary header so that the request at least is a standard size, and pad the response to the same size as the site index.html or whatever). If the user picks a few SSL sites and cross checks (more for high value) a subset of peers available on all and uses them as his seed that seems like a better direction. In that way an attacker cant control the network without denying service to popular SSL sites, which would be a warning sign to users, or having at his disposal a SSL sub-CA cert (like happened with diginotar and gmail). You may be able to pin CAs for popular sites. Obviously to the extent you're using SSL you want to generally use EDH for forward-secrecy. And not RC4 :) Probably anysite that accepts bitcoin payment will be happy to run such a mod-bitcoin. With ToR, it has a similar bootstrap problem to bitcoin. So while that may help it is also passing the buck, not necessarily solving the problem. And as I said I think its possible bitcoin has a higher assurance need in that the attackers motivated my $$ might put more effort in than the odd dictatorship trying to pay lip service to preventing people reading pages on a blacklist. Given the vulnerability of DNS to poisoning I would not trust it too much. I know its just a bootstrap, but ideally you dont want to bootstrap from a known publicly vulnerable protocol - it invites DNS poison net splits against new users. Also to the extent that users local clock is under his control (with unuthentcated NTP?) he should also treat sudden dramatic changes in luck (deviations from 10min interval) as suspicious. Unfortunately at present because of the first past the post nature of the bitcoin lottery, reduced variance hashcash cannot be used, so its hard to infer too much even from quite significant luck changes. Adam On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote: Speaking of, off-topic for this discussion, but in the future node-to-node communicate should be encrypted and signed Yes, I'd like to do this. The threat isn't really ISPs which are mostly trustable (the worst they normally do outside of places like China is dick about with ads), the big threat is people who use untrusted WiFi without realising and end up thinking they received money when actually they were just connected to a hotspot running in the attackers pocket. I'm rather expecting that kind of thing to happen in future. I think we can converge on the best solution with several iterations: Iteration 1) Make it clear in the UI that if the phone is connected to WiFi, payments from untrusted people should not be accepted. Currently the Android app merely says the money won't be spendable for a few minutes. It needs to communicate the may not exist aspect more clearly. If you're connected via a cell tower, the existing wording is fine - it's very unlikely your telco is trying to scam you in a person-to-person transaction, traffic is encrypted and 3G+ connections authenticate the network so you can't be MITMd except by your telco. Assuming you have a good list of IPs, of course. Iteration 2) Give nodes keys that appear in addr
Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote: Hmm: maybe one could use a Brands private credential with offline double spend detection, with the reputation but not coin address of the node disclosed, and the nodes coin address embedded in the proof. Each node could be is own CA, providing a ZKP. If the node ever double spends a coin, it loses its reputation as the coin address is revealed. Be careful not to mix up the concept of a relay node with someone posessing Bitcoins. Node's don't spend coins, people/wallets do. My comment was to say that a good behaviour bond for a relay node could be put on an address that is defined as unspendable until such time as an auditor can prove the node engaged in the undesired behaviour, at which point the audit receives the payment as part of his proof. Or until the node ceases to operate. Its a smart contract. However I added to that, that it is still possible to do that while preseving privacy, to point out that it is technically possible, for people to be aware of in their mental toolbox, if it helps solve an otherwise tricky problem. So that would be a privacy preserving smart contract, the parties are unknown, and unknowable (with unconditional security even), but still the smart contract executes. In some sense a privacy preserving smart-contract is closer to the real point of Szabo's smart-contract idea because you cant try to renege on the contract in a conventional court - because you cant identify your counter-party. Bitcoins privacy feature is fairly weak so that is probably often not true. Of course you'd probably need zerocoin to stand much chance of proving an address private key of an unlinked coin was in the double-spend disclosed attribute in the first place, and as we know zerocoin is not that efficient. Make the node identity expensive to obtain. For instance, construct PoW's including the node pubkey somehow, that could be easily done with the work of creating a vanity address. eg address containing many leading 0s. Adam -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote: On Mon, May 6, 2013 at 11:04 AM, Adam Back a...@cypherspace.org wrote: bitcoins primaryvulnerability IMO (so far) is network attacks to induce network splits, local lower difficulty to a point that a local and artificially isolated area of the network can be fooled into accepting an orphan branch as the one-true block chain, It currently costs about 2016*25*$120 = six million dollars to reduce the difficulty in your isolated fork by a factor of 4. Well I take your point that you have to produce 2016 blocks, but at a lower rate. But that doesnt directly translate into my cost, I am thinking pure network hacking. Maybe I could hack a pool to co-opt it into my netsplit and do the work for me, or segment enough of the network to have some miners in it, and they do the work. I am just thinking $500k/day worth of relatively perfect crime reward is a lot of motivation for hacking networks. Many routers home and even carrier are vulnerable to people armed with cisco source code 0-days. The netsplit doesnt have to be geographical, nor even topological, nor even particularly long-lived. If you control enough people's network routing at a low enough level, you dont even have to stop transactions, nor do any mining work, just stop blocks from the netsplit crossing over, and hold that position for say a day (if your netsplit has 1/24 of network hash rate in it, so the split gets 6 confirmations to reassure the victims) and let the miners do the work. Do enough transactions to do a big cash out (spend differently on the two netsplits). Obviously a big and human inattentive pool, dark-miner etc is the ideal target to put into the netsplit to increase the power while controlling less nodes. Malware could do the same thing for clients, dont forget most are running windows. Malware could also start a miner if none present. maybe even from node first install time. Protecting against that— making sure any such attack has to start from a high difficulty— is, in my opinion, the biggest continued justification for checkpoints. Do you know if there is any downwards limit on difficulty? I know it takes going slow for a long and noticeable time, but I am just curious on the theoretical limit. (btw I notice most of the binaries and tar balls are not signed, nor served from SSL - at least for linux). They are signed. I dont see the signatures. http://bitcoin.org/en/download I see no signatures for linux and none in the tarball. There are some public keys inside the tarball, thats it. Also no SSL. sourceforge support SSL so you can download that. But bitcoin.org doesnt even answer 443, and the source forge link is HTTP. But even if the sourceforge link was SSL one should not serve an SSL download link from an HTTP page, any more than type a password into an HTTPS form action on an HTTP page. The attacker can just redirect and the user doesnt know what is legitimate. Consequently even if there is code signing on the windows exe, the user doesnt know that, nor who they should be signed by, and as they are served via HTTP, its bypassable. I guess by far the easiest way to attack right now (at least linux users) is just to change the binaries to create a user operated netsplit, or just have all their wallets empty to you via a mix once the amount gets interesting. (All attacks hypothetical of course - I'm actually a white-hat type of person). Adam -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
