[Bitcoin-development] ASIC-proof mining
Hello, I had a thought after reading Mike Hearn's blog about it being impossible to have an ASIC-proof proof of work algorithm. Perhaps I'm being dim, but I thought I'd mention my thought anyway. It strikes me that he's right that it's impossible for any algorithm to exist that can't be implemented in an ASIC. However, that's only because it's trying to pick an algorithm that is CPU bound. You could protect against ASCI mining (or rather, make it irrelevant that it was being used) by making the algorithm IO-bound rather than CPU-bound. For example, what if the proof-of-work hash for a block were no longer just hash of block, which contains the hash of the parent block, but instead were hash of [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and suffixing the new block, you have to feed every byte of the blockchain through the hashing engine (the prefix prevents you caching the intermediate result). Whatever bus you're using to feed your high speed hashing engine, it will always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and any hashing engine will, effectively, be the same. I'm making the assumption that SHA-256 is not cacheable from the middle outwards, so the whole block-chain _has_ to be transferred for every hash. Apologies in advance if this is a stupid idea. Andy -- Dr Andy Parkins andypark...@gmail.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ASIC-proof mining
On Friday 04 July 2014 06:53:47 Alan Reiner wrote: ROMix works by taking N sequential hashes and storing the results into a single N*32 byte lookup table. So if N is 1,000,000, you are going to compute 1,000,000 and store the results into 32,000,000 sequential bytes of RAM. Then you are going to do 1,000,000 lookup operations on that table, using the hash of the previous lookup result, to determine the location of next lookup (within that 32,000,000 bytes). Assuming a strong hash function, this means its impossible to know in advance what needs to be available in RAM to lookup, and it's easiest if you simply hold all 32,000,000 bytes in RAM. My idea wasn't to make hashing memory hungry; it was to make it IO-hungry. It wouldn't be too hard to make an ASIC with 32MB of RAM. Especially if it gained you a 1000x advantage over the other miners. It seems that sort of solution is exactly the one that Mike Hearn was warning against in his blog. you'll only be using a small fraction of it for each hash. This might achieve what you're describing without actually requiring the full 20 GB of reading on ever hash. But we want that read. Remember the actual hash rate isn't important, what matters is how hard it is to reproduce. If we make it 1000x harder to do one hash for everybody, we're still just as secure. The difficulty adjustment algorithm ensures blocks come at 10 minutes, regardless of hash rate. So we can make it harder by picking a harder algorithm -- SCRYPT or BLOWFISH, or just by upping the size of the data that needs hashing. The advantage of upping the size of the input is that, unlike an algorithm change, you can't build a better ASIC to reduce the size. Andy -- Dr Andy Parkins andypark...@gmail.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ASIC-proof mining
On Friday 04 July 2014 07:22:19 Alan Reiner wrote: I think you misundersood using ROMix-like algorithm, each hash I did. Sorry. requires a different 32 MB of the blockchain. Uniformly distributed throughout the blockchain, and no way to predict which 32 MB until you have actually executed it. If the difficulty is high enough, your miner is likely to end up going through the entire X GB blockchain while searching for a good hash, but other nodes will only need to do 32 MB worth of disk accesses to verify your answer (and it will be unknown which 32 MB until they do the 1,000,000 hash+lookup operations on their X GB blockchain). Excellent. Andy -- Dr Andy Parkins andypark...@gmail.com -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote: There _are_ consequences though: 95% of the time, you end up buying something and paying for it. Yeah, I was imagining a situation in which people who use Bitcoin regularly do buy things they actually want, but wouldn't say no to occasionally getting them for free (think coffees at starbucks etc). So if their double spend fails, no big deal, they're no worse off than if they didn't try. Again true enough; but then we're back to evenly distributed dishonesty, and so you still don't get the potential 5% scam being used at 100% capacity. Andy -- Dr Andy Parkins andypark...@gmail.com -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote: Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure. Just pedantry: 100% of credit card transactions _can_ be fradulantly charged back but arent. In fact, only 2% are ever attempted. If N was 5%, then only 5% of bitcoin transactions _could_ be fraudulantly charged back; so then why wouldn't only 2% of those bitcoin transactions be fraudulant too, just as in the CC case? The comparison would then be 2% chargebacks for credit cards, equivalent to 0.1% (5%*2%) for bitcoin. Not that I think that makes anything else you say invalid. Andy -- Dr Andy Parkins andypark...@gmail.com -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote: OK, sure, let's say most Bitcoin users will be honest (we hope). But unfortunately in a situation where fraud is possible users wouldn't necessarily distribute evenly over transactions. That's true, but even in the worst that that 5% hashing power attack means that 95% of the time, your attack fails. That means you end up paying for what you bought. Also, you're again changing the comparison basis -- your CC figures were for the entire industry, not the most badly affected merchant. You can't say one particular bitcoin merchant suffers 5% fraud, therefore that's worse than the 2% fraud averaged across all CC merchants. If a merchant is selling something of value repeatedly, then a small number of scammers can go back and try their luck over and over. I'm not sure how many trades fall into such an exploitable category, though. Also, there's the philosophical question of how honest people really are when there's no consequences to their actions. For instance, if most There _are_ consequences though: 95% of the time, you end up buying something and paying for it. Viewed another way, if I buy something repeatedly from an at risk merchant (and there won't be many; as you pointed out, mail order is completely unaffected as you can simply wait for your confirmations) that costs, say 0.01 BTC per item, then I have to buy 100 of them to get 5 of them for free. Do I really want 100 of them? Even if I do want them, then I've had to supply capital of 1 BTC to earn 0.05 BTC in kind. If what I'm buying is another form of money (as with exchanges, or perhaps casinos) when that in kind is just as liquid as the BTC, then fair enough, there is a risk, but that just incentivises the merchant in those cases to not allow withdrawal/deposit until 6 confirmations have been received. Those merchants then move from at risk to not at risk. I'm still struggling to see how bitcoin could ever be as bad as CC fraud. Andy -- Dr Andy Parkins andypark...@gmail.com -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Code review
On Friday 04 October 2013 12:30:07 Mike Hearn wrote: Git makes it easy to fork peoples work off and create long series of commits that achieve some useful goal. That's great for many things. Unfortunately, code review is not one of those things. I'd like to make a small request - when submitting large, complex pieces of work for review, please either submit it as one giant squashed change, or Don't do this. It throws away all of the good stuff that git lets you record. There is more to a git branch than just the overall difference. Every single log message and diff is individually valuable. It's easy to make a squashed diff from many little commits; it's impossible to go the other way. Command line for you so you don't have to think about it: git diff $(git merge-base master feature-branch) feature-branch git-merge-base finds the common ancestor between master and feature-branch, and then compares feature-branch against that. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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] Code review
On Friday 04 October 2013 13:32:47 you wrote: There is more to a git branch than just the overall difference. Every single log message and diff is individually valuable. When the log messages don't accurately describe the contents of the diff, it's just misinformation and noise. Everyone starts out by wanting a neat collection of easy to understand and review commits, but in practice it's extremely hard to always get it. Then your request should be for better commits, not for just squashing the lot into some incoherent blob. The alternatives under discussion are: - Coder produces long chain of commits on feature branch. Compresses them, throwing away any individual and accurate messages into one large diff. It's unlikely you'll get a log message that is as descriptive in the large one if you made them throw away the little ones. Large diff is offered for review. Review is of one large diff. - Coder produces long chain on commits on feature branch. Offers them for review. Reviewer only likes to review large diffs, so uses the tools available to produce it. Exactly the same diff is being reviewed, but in one case you're throwing away information. There is no getting that information back ever. You're also discarding the advantages of individual commits. - Merges are considerably harder than rebases. You have to resolve all the conflicts at once with a merge, with a rebase you can resolve them with the log message and original isolated diff to help you. - Bisect doesn't give as fine-grained an answer. I know how to make squashed commits, thanks. I've done LOTS of code review Excellent. Don't take it personally -- I only offered it in case you didn't know. Not everyone is familiar with git plumbing. in my life. I'm making a point here as one of the few people who goes through large pull requests and reviews them line by line. It's hard, That doesn't make you the only person who does code reviews. I do plenty of reviews here; they're just not bitcoin reviews. Obviously we're talking about bitcoin, so you get to decide in the end. partly because github sucks, and partly because reviewing lots of small commits sucks. I'm not suggesting you review lots of small commits anyway. I can't comment on whether github sucks or not -- that's obviously personal preference. However, nothing stops you doing reviews on your own local checkout. There's nothing that makes a single large commit harder to review. It's the same amount of code or strictly less, given the tendency for later commits That's not true. There are often lots of small changes that are manifestly correct -- let's use string changes as an example -- in the large commit, they are just noise. You want to be able to focus on the hard commits. However -- I am not trying to persuade you to review small commits, I'm trying to persuade you not to throw away the small commits, gone forever, merely because your preference is to review large commits. to change earlier ones. You can easily search the entire change whilst reviewing. There are lots of things that make it easier. Since the large commit is always available, no facilities have been lost. Personally I work hard in my repositories to make coherent, small, well described commits. If I had gone to that effort for a bitcoin branch only to be told to collapse them all and throw away that effort, I'd think I'd been wasting my time. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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] HTTP REST API for bitcoind
On Monday 22 July 2013 20:42:45 Jeff Garzik wrote: URL: https://github.com/bitcoin/bitcoin/pull/2844 Adding an HTTP REST API for bitcoind has been occasionally tossed about as a useful thing. Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain. This is excellent. The first two implemented API calls are simple, returning a block or TX given a simple query string based on block hash, e.g. GET /rest/tx/TX-HASH or GET /rest/block/BLOCK-HASH One additional URL makes this pretty much perfect: GET /rest/block-with-tx/TX-HASH Construction of the transaction-hash-to-block database is something the full client's have to do anyway, so this query is no harder than the others for them to supply; but suddenly makes it possible for an SPV client to trace the providence of any transaction without needing to maintain the entire chain. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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] HTTP REST API for bitcoind
On Tuesday 23 July 2013 10:42:05 Pieter Wuille wrote: On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote: One additional URL makes this pretty much perfect: GET /rest/block-with-tx/TX-HASH Construction of the transaction-hash-to-block database is something the full client's have to do anyway, so this query is no harder than the others for them to supply; but suddenly makes it possible for an SPV client to trace the providence of any transaction without needing to maintain the entire chain. There is actually no such index being maintained by default, and doing so is an unnecessary burden IMHO (you need to enable -txindex since 0.8 to get this). Of course, if enabled, it can be exposed. Wow. I'm surprised at that. How does a newly received transaction have its inputs verified then? Multiple linear brute force searches of the block chain for every new transaction? Or is it that transactions are only recorded if they were in a block, and just their presence indicates they're valid? Andy -- Dr Andy Parkins andypark...@gmail.com -- 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] HTTP REST API for bitcoind
On Tuesday 23 July 2013 10:47:03 Peter Todd wrote: On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote: One additional URL makes this pretty much perfect: GET /rest/block-with-tx/TX-HASH Construction of the transaction-hash-to-block database is something the full client's have to do anyway, so this query is no harder than the others for them to supply; but suddenly makes it possible for an SPV client to trace the providence of any transaction without needing to maintain the entire chain. The REST API has nothing to do with SPV clients; it's similar to the RPC interface and won't be exposed to the network as a whole. Yes; I know that. I'm saying that it would make it easier for SPV (and other lightweight clients) for that matter. Increasing the resource usage by SPV clients on full nodes is undesirable; I don't think that's thinking big enough. What I imagine is that making it easier and easier to store a partial blockchain would result in lower demand on full nodes. I might run a client that has only fetched blocks that contain transactions needed to verify my balances, right back to the genesis block. That will be some small subset of the block chain and will take me very little resource to maintain. I join the network and am my client is willing to verify based on information I have, or supply (by REST or bitcoin protocol) blocks. Imagine then that everyone with a wallet were doing this. The blockchain would be distributed massively. Obviously the miners would still be keeping the entire chain, but we'd have a lot more nodes in the network, each contributing a little bit and so reducing the load on the full nodes. In any case UTXO data currently requires you to have full trust in whomever is providing you with it, and that situation will continue until UTXO commitments are implemented - if they are implemented. Almost; because you can go and ask someone else the same question, it's pretty easy to check if you're being lied to. Also, it's far easier to maintain a headers-only block chain. When you fetch your relevant block subset, you can easily see that they are real blocks in your headers-only blockchain; and so it's pretty much impossible to lie to give me the block containing transaction X. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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] HTTP REST API for bitcoind
On Tuesday 23 July 2013 10:56:02 Pieter Wuille wrote: The block chain is not involved at all to verify transactions, it's just a historical record to serve to other nodes, and to do wallet rescans with. It must be involved to some extent. Certainly during a temporary fork, there are two branches growing, and you have to be able, when verifying a new transaction, to say which branch it's one... which branch of the blockchain. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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] HTTP REST API for bitcoind
On Tuesday 23 July 2013 11:17:28 Peter Todd wrote: On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote: Increasing the resource usage by SPV clients on full nodes is undesirable; I don't think that's thinking big enough. What I imagine is that making it easier and easier to store a partial blockchain would result in lower demand on full nodes. Read my proposal for Partial UTXO mode: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02 511.html Very interesting. I love the idea of the UTXO set being tied to a block. I might run a client that has only fetched blocks that contain transactions needed to verify my balances, right back to the genesis block. That will be some small subset of the block chain and will take me very little resource to maintain. I join the network and am my client is willing to verify based on information I have, or supply (by REST or bitcoin protocol) blocks. Imagine then that everyone with a wallet were doing this. The blockchain would be distributed massively. Obviously the miners would still be keeping the entire chain, but we'd have a lot more nodes in the network, each contributing a little bit and so reducing the load on the full nodes. Actually the really scary thing about partial UTXO mode is miners can get away without keeping the entire chain provided they don't (often) try to mine transactions spending UTXO's that they haven't verified themselves. You're right. That is scary. In any case UTXO data currently requires you to have full trust in whomever is providing you with it, and that situation will continue until UTXO commitments are implemented - if they are implemented. Almost; because you can go and ask someone else the same question, it's pretty How do you know they actually are someone else? You don't. You can't invalidate the lie if all you have access to is lies. But if you have access to just one honest node; that will reveal the liars. I'm not claiming that headers-only nodes can ever be made as secure as a full node. Just _more_ secure than they are now; and potentially able to act as one of those honest nodes. easy to check if you're being lied to. Also, it's far easier to maintain a headers-only block chain. When you fetch your relevant block subset, you can easily see that they are real blocks in your headers-only blockchain; and so it's pretty much impossible to lie to give me the block containing transaction X. Do you think you have SPV or full security in that situation? Do you know the difference? There is absolutely no need to get condescendingly shirty. I thought this was a friendly list; and we were having a discussion. If you don't want to respond to posts -- don't. I also didn't realise I had to pass an exam before I was allowed to speak. Yes: I know the difference between SPV and full security. SPV is headers only and so has no way to verify that the transaction outputs references as inputs to any new as-yet-unverified transaction are valid. Instead it relies on having some way of proving it's in the chain; and then looking for the number of blocks built on top of it as verification. Full security (which is itself a very poor name), is obviously just checking that every output referenced in the inputs is unspent; that necessarily requires full blocks. The difference in security being that in SPV there is no way to know if the referenced Unspent TransaXtion Output really is unspent -- it might have been spent elsewhere then referenced again in this new transaction. My suggestion was that we want to be able to fetch a block by transaction; and that simple nodes can all, in aggregate offer contribution to the network rather than just being parasitical on the full nodes. When I ask for a block that contains a transaction, and I do that repeatedly, I have part of the block chain. If lots of simple nodes are doing that, then the whole chain should be available if there are enough of them. They would then gain the ability to do transaction-forwarding in some cases. This is only possible if a few extra facilities are added to the protocol. One of which is the new feature I suggested: block-given-transaction. It's not enough on its own, but if you also add in the ability for a node to tell another about the output transactions (basically, what block spends it), _then_ the simple nodes are able to become much more secure -- not 100% of course, they're still not full nodes, because they have no way of knowing if they are being lied to when they are told (this transaction is unspent), but all it takes is one honest node to point them at the truth, and the lie is then exposed. That facility is just a drain on full nodes for the most part; except if you start encouraging it whole-sale. The simple node would keep cache both the incoming and outgoing transactions (or rather the blocks
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
On Tuesday 30 April 2013 21:11:47 Jeff Garzik wrote: Hardly. The storage format is bitcoin protocol wire format, plus a tiny header. It is supported in multiple applications already, and is the most efficient storage format for bitcoin protocol blocks. Most efficient for what purpose? There is more that one might do than just duplicate bitcoind exactly. I can well imagine storing bitcoin blocks parsed and separated out into database fields. Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP requests? Then any client can supply the same interface, rather than being forced to create blk.dat on the fly? You don't have to create anything on the fly, if you store blocks in their native P2P wire protocol format. If. What if I'm writing a client and don't want to store them the way bitcoind has? This is a whole new client interface. It's fun to dream this up, but it is far outside the scope of an efficient HTTP protocol that downloads blocks. Except the alternative is no schema at all -- essentially it's just give access to a file on disk. Well, that hardly needs discussion at all, and it hardly needs the involvement of bitcoind, apache could do it right now. Your proposal is closer to a full P2P rewrite over HTTP (or a proxy thereof). I don't think it's a rewrite. The wire protocol is only a small part of what bitcoind does. Adding another thread listening for HTTP requests at the same time as on 8333 for stadnard format. Anyway -- I've obviously misunderstood what the idea behind a HTTP protocol was, and it's not like I was volunteering to do any of the work ;-) Andy -- Dr Andy Parkins andypark...@gmail.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
On Wednesday 01 May 2013 15:26:57 Jeff Garzik wrote: A generalized HTTP REST query protocol would be a nice addition... it is just off-topic for this thread. On IRC yesterday, we discussed an HTTP query interface like you suggested. It was agreed that it was a nice interface, and might be a nice addition to bitcoind. That is a separate topic for a separate email thread, though. As an example, see the pull request I wrote for an HTTP REST interface that downloads an encrypted wallet backup: https://github.com/bitcoin/bitcoin/pull/1982 Fair enough. I'm usually behind the state-of-the-art when I suggest things here :-) I should just trust you guys have already planned everything I might think of. Andy -- Dr Andy Parkins andypark...@gmail.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote: The format currently used by bitcoind would be just fine -- blocks/blk.dat for raw data, size-limited well below 1GB. Just need to add a small metadata download, and serve the raw block files. That doesn't seem very generic. It's tied far too much to the current storage format of bitcoind. Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP requests? Then any client can supply the same interface, rather than being forced to create blk.dat on the fly? http://bitcoind.example.com/block/BBB http://bitcoind.example.com/tx/ http://bitcoind.example.com/block/oftx/TTT http://bitcoind.example.com/peers http://bitcoind.example.com/peer/nnn Essentially: block explorer's raw mode but in every bitcoind. The hardest operation for light clients is finding out the block that contains a particular transaction -- something that bitcoind already knows. I'd like to see support for HTTP POST/PUT of signed transactions and block announcements too. Andy -- Dr Andy Parkins andypark...@gmail.com -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.8
On Tuesday 09 April 2013 22:03:35 Mike Hearn wrote: To get bitcoinj 0.8, check out our source from git and then run *git fetch --all; git checkout **cbbb1a2bf4d1*. This will place you on the 0.8 release in a secure manner. This message was written on Tuesday 9th April 2013 and Not quite secure yet, because you didn't sign your email. Andy -- Dr Andy Parkins andypark...@gmail.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
On Monday 03 December 2012 11:19:37 Michael Gronager wrote: The aged coins are simply included in the block mining reward, creating another incentive for miners. Further, if we include all coins in this recycle scheme coins will never be lost forever. Ignoring the cost of storing these never-spent outputs; there is absolutely no reason we need to ensure that coins aren't lost. Nor worry about those that are. The total bitcoins produced is an entirely arbitrary number -- a function of the 210,000 halving rate and the initial block reward. Satoshi could have picked anything for them and bitcoin would work exactly the same. Lost coins never enter the economy ever again, and so supply is slightly lower than it would have been, making all the non-lost coins worth ever so slightly more. Effectively: price adjustments will take care of lost coins. Andy -- Dr Andy Parkins andypark...@gmail.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:
x509chain: one or more DER-encoded X.509 certificates that identifies
the merchant. See the Certificates section below for details.
Personally, I'd like to see fewer implicit ties to X509. With X509 as one
option. For example, I'd much prefer to see a doorway to the future left open
like this:
message Invoice {
repeated bytes issuerIdentityType;
repeated bytes issuerIdentityBytes;
or similar, instead of x509chain.
In particular two additional identification types:
- GnuPG (obviously)
- Hash based
The hash-based system would be there as a method of leveraging an existing
trusted connection, without needing to get into the nitty-gritty of
certificates. For example, I am paying for something on a web site; I
presumably already have a secure connection that I trust to that site. That
site can issue me an invoice (which is to be sent to the bitcoin client) _and_
a hash of the certificate on the same page.
I trust that hash because I received it over a secure connection from a
trusted source. When my bitcoin client pops up with the received invoice, it
shows me the hash of the invoice, and I can be sure that it is from the web
site I thought it was from.
Imagine I'm a (very) small business, I have two or three customers. I want to
email one of my customers an invoice. I don't want to have to get an X509
certificate, and I don't necessarily know how. However, I can ring my
customer up and say I've generated an invoice with my bitcoin client, it is
hashed A7DE-521X-9977. Write that down and confirm it when you get my
invoice. Alternatively, I might attach a file called
invoice-A7DE-521X-9977.bitinv to a signed GnuPG email. The receipient can
easily confirm I sent it because the filename must match the contents and
GnuPG protects against tampering.
Andy
--
Dr Andy Parkins
andypark...@gmail.com
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
On Saturday 16 Jun 2012 07:45:00 Wladimir wrote: As replied on the github issue: Personally I still think it's better to have a clear standardized protocol version, that implies what capabilities are supported, instead of a capability-based system that explicitly lists them. Capability-based systems (just look at OpenGL) tend to become horrendously complex, as you have to take into account all possible combinations of possible interactions, and constantly check for support of specific features instead of just comparing a version number. Sure, it can be necessary to distinguish between different types of nodes, but there is no need to make it this fine-grained. It's less of a problem in a (nearly) stateless protocol like Bitcoin. I like the idea of a capabilities command; as time goes on and the ecosystem of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search- blockchain/memory-pool-query clients becomes more varied, it's going to be more an more important. The particular example that occurs is thin clients connecting to the network are going to want to ensure they are connected to at least one non-thin client. Andy -- Dr Andy Parkins andypark...@gmail.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior
On 2012 April 12 Thursday, Jeff Garzik wrote: One of my From-Day-One complaints about bitcoin is that transactions behavior could be far more deterministic (predictable), from a user standpoint. Transactions in the current system can easily remain in limbo forever. One big step in making transactions behave more predictably would be to remove transactions from the memory pool, if they have not made it into a block for a couple days. i.e. A change I've wished for for a while (but I suspect it is too big a change to ever make it) is that a transaction announcement include the block the user wants to base on. It would only be in the protocol message, not the transaction stored in the blockchain. The advantage is that (1) it protects against double spends without needing a confirmation period; as a merchant I can instantly spend a 1-confirmation transaction by creating my transaction with that 1-confirm as its base. (2) your expiry from memory pool becomes easy -- if the base is more than N blocks below the current head, then that transaction won't be included. Retransmission is possible with the base updated. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP16/17 replacement
On 2012 January 31 Tuesday, Gregory Maxwell wrote: I think you've been deceived by people who have some interest in promoting this as some sort of big controversy, or perhaps just confused by the general level of noise. Well that's good that there is no real problem. It does not, in fact— Yes, it requires a client update to make use of the new functionality, but old nodes will happily continue to validate things. It's hard to express how critical this is distinctly. Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that things were done right, the validate them for themselves. A breaking change of the kind you suggest is not something that would be considered lightly, and this is certainly not justified for this. To be brutally honest; I don't see how the BIP16/17 changes are any less breaking than what I proposed (I'm not trying to push mine; forget it, the last thing bitcoin needs is another proposal if there is no real argument). I will agree the changes are smaller for BIP16, since the transactions are left as they are. If BIP16/BIP17 were being honest they would too increase the version number of the transaction structure. The new transaction type is not supported by the old client... that's a break. My argument would be that once you're going to break the old clients anyway, go the whole hog and fix some other stuff as well. If we ever were to scrap the system, I think we very much would do something like what you describe here... and as much has been documented: https://en.bitcoin.it/wiki/Hardfork_Wishlist (see Elimination of output scripts) I'm glad I wasn't talking rubbish then. But, to be clear, this stuff is pretty much fantasy. I'm doubtful that it will ever happen, doubtful that we can get the kind of development Me too. Which is a shame; as it means we're locked into quite a fair number of earlier decisions that will now never be changed. resources required to pull off a true breaking change in a way that people would actually trust upgrading to— at least not before a time that the system is simply too big to make that kind of change. Again: I don't see how BIP16/17 aren't breaking as well; but perhaps I'm just not familiar enough with the conventions. As far as I understand; no pre-BIP16 miner is going to allow BIP16 into the blockchain because it's not going to pass the IsStandard() test. I'd repeat: the reasonable thing to do is to increase the version number of the transaction structure to indicate that they are being processed differently from old transactions. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP16/17 replacement
On 2012 January 31 Tuesday, Luke-Jr wrote: Both BIP 16 and 17 are backward compatible enough that people can continue to use the old clients with each other. An upgrade is only required to send to (or create/receive on) the new 3...-form addresses. That being Is that true? (I'm happy to be called wrong) It doesn't seem like it to me. The new transaction types will be rejected by old clients won't they? They don't pass IsStandard(). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP16/17 replacement
On 2012 February 01 Wednesday, Pieter Wuille wrote: old clients won't they? They don't pass IsStandard(). IsStandard() is for accepting transactions into the memory pool. Non-standard transactions are verified just fine when they are in the block chain. Ah. My misunderstanding then. If we do a breaking change to the protocol - such as adding a new transaction type - ALL users must upgrade. Those who don't will see a fork of the chain from before the first new-style transaction. That is not the case now. That makes a big difference. Thanks for the correction. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP16/17 replacement
Hello,
Gulp. Am a little nervous about wading into this swamp. However, it seems
to me that the debate has veered into the personal and away from the
technical. Surely if there are objections to both suggestions, that another
solution might be better? The answer doesn't have to be A or B, if the
answer C turns out to be acceptable.
That being said; I am not confident enough to start making BIPs so I offer
this idea up for my traditional mailing-list roasting but with the hope that
I blindly stumble toward something more acceptable to everyone.
If the change is going to be a big one anyway and will require a client
upgrade why not...
- Increase the version number in transactions to make a new transaction
structure
- Dump the scriptPubKey field completely. Everything will be pay-to-
script-hash in version2 transactions
- Replace it with hashOfClaimingScript
- Add an unsignedParameters array.
hashOfClaimingScript is _not_ script. It's just the hash of the script that
is allowed to claim the output. Then before scriptSig is allowed to run, it
is hashed and compared against the hashOfClaimingScript.
unsignedParameters replaces the need for all the crazy messing around that
OP_CHECKSIG currently does because it is specifically a block of the
transaction that it not signed (although I would include the array size bytes
in the signature calculation), therefore no script filtering is necessary.
The claiming script, scriptSig, can then be checked against whatever list of
templates you like. For pay-to-address it will probably look like:
OP_PUSHPARAMETER {0}
OP_PUSH { claimant public key }
OP_CHECKSIGVERIFY
Handling the more complicated transactions (they're the point of all this
after all) is pretty obvious; the unsignedParameters block can hold as many
signatures as you like. It also removes the need for OP_CHECKMULTISIG, since
the script can specify the signature conditions. e.g. a 2-of-3 script:
OP_PUSHPARMETER {0}
OP_PUSH { claimant public key0 }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { claimant public key1 }
OP_CHECKSIG
OP_PUSHPARMETER {1}
OP_PUSH { claimant public key1 }
OP_CHECKSIG
OP_ADD
OP_ADD
OP_PUSH {1}
OP_GREATERTHAN
(I'm sure someone cleverer than I can improve on the above)
-
Let the flaming commence...
Andy
--
Dr Andy Parkins
andypark...@gmail.com
signature.asc
Description: This is a digitally signed message part.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP16/17 replacement
On 2012 January 31 Tuesday, Luke-Jr wrote: I'm not aware of any remaining *tangible* objections to BIP 17 at this point (Gavin seems concerned over a theoretical risk-that-nobody-has-thought-of), but if there's a better solution, I'm perfectly fine Withdrawing BIP 17 to support it. I imagine the BIP16 supporters would say the same? Isn't that the essence of the current impasse? Both BIP 16 and 17 are backward compatible enough that people can continue to use the old clients with each other. An upgrade is only required to send to (or create/receive on) the new 3...-form addresses. That being said, it's quite possible to rewrite the practical implications of both BIP 16 and 17 in the format you seem to be suggesting. Doing so would even get rid of one of the major objections to BIP 16 (its inconsistency). My suggestion is backward compatible. You'd only have to make version2 transactions for version2 addresses; and the join between version1 and version2 is not a problem since the version1 source can be detected, and the handling of the version2 transaction altered as appropriate (it's only a matter of switching from the hash check to running the two scripts as normal). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
On 2011 December 21 Wednesday, Christian Decker wrote: Supernodes will be those nodes that verify all transactions and make them available to miners. Since miners will become more and more specialized these supernodes are likely to be owned by the miners themself. To be a miner either you need to verify all the transactions you include (otherwise others might be able to find an error in your block and thus drop it) or have someone that verifies them for you. In the end I think we'll end up with a hierarchical network, with the miners/supernodes tighly interconnected at the top and the lightweight clients that simply verify transactions (or their inputs to be precise) that are destined for them at the bottom. A thought occurred to me. We already run a decentralised system, but it's done by making everyone duplicate all other work. There is no fundamental reason why all work needs to be duplicated though. What about this: every node randomly chooses whether to verify any particular transaction. If we assume the network is large and the random factor is correctly chosen, then we can still guarantee that every transaction is verified. Then, we simply add a protocol message that is a negative-announce transaction. That is to say, we give nodes a way of telling other nodes that they think a transaction is invalid. The other nodes are then free to verify _that_ assertion and forward the negative-announce. Miners can then listen for negative-announcements and use them to decide were to dedicate their verification efforts. They then don't need to verify all (or perhaps even any) transactions themselves and can dedicate their processing power to mining. (I've actually mentioned this idea before, but that time I was using it as a double-spend prevention method). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On 2011 December 16 Friday, Rick Wesson wrote: On Thu, Dec 15, 2011 at 4:07 PM, slush sl...@centrum.cz wrote: I really like this proposal with standard URLs. All other proposals like DNS mapping or email aliases converted to URLs with some weird logic looks strange to me. wow, really. Maybe you could review some RFCs, there are thousands of examples where some really smart engineers chose the exact opposite path which you propose below. Could you point me at an example? Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
On 2011 December 16 Friday, Rick Wesson wrote: I believe that any URI scheme will still leverage DNS and inherit any base issues you would have with TXT records. I suggest looking at DANE HTTPS takes care of that. and reviewing their work on hardening certificate (x.509) infrastructure as your HTTPS scheme will inherit the issues we currently experience with CAs getting p0wned. This is the only real problem with HTTPS: we would be centralising part of our otherwise decentralised system. CAs are certainly a risk. However, trust is needed somewhere in the communication. There is no way to securely communicate between A and B without the use of some previously trusted secure channel -- in Joe Sixpack's case it's by assuming that the browser he downloaded came with an untainted CA list, and that the CAs are trustworthy. Neither of which is guaranteed. Until and unless we get PGP support in browsers, CAs are all that we have. Worrying about CAs misses the point anyway; if we're being that paranoid -- how did A tell B the appropriate alias to use for a lookup? Was that channel secure too? I could set up a MITM server that simply looks for the alias rickwes...@bitcoinaliases.org and rewrites it to andypark...@bitcoinaliases.org. When the answer to that problem is HTTPS (or some other system that requires a previously authorised secure channel for transfer of trust), then we're back where we started, and HTTPS is acceptable. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On Friday 16 Dec 2011 19:06:52 Gavin Andresen wrote: I think there is also a huge public relations benefit to using a standard like IIBAN instead of inventing our own. Having a Bitcoin Payment Routing Address (or whatever it ends up being called) that looks like the number issues by big financial institutions will give people the warm fuzzies. I can see the PR advantages, but isn't mapping from one massively long, multi-character, human-opaque number (IBAN) to another (bitcoin address) a bit of a waste of time? Surely the point of all this is to provide at least the possibility of a human-readable name for a bitcoin-address? Isn't there a possibility that one day we might want to be able to say send me those bitcoins you owe me to bitcoin.yahoo.co.uk/andyparkins? Or similar? Andy -- Dr Andy Parkins andypark...@gmail.com -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On 2011 December 15 Thursday, Walter Stanish wrote: Andy sounded very convincing when talking in favor of URLs. What's wrong with his proposal? A URI identifies a resource and is in effect an alias itself. Identifying a resource is different from interacting with it. So, while resource-type://resource-type-specific-alias will work sufficiently for the identification, it does not explain the interaction. Quite so; the BIP15 standard shouldn't be setting the format of the URI; it should be setting what the format of the client-server conversation is. Effectively, what headers will a requesting client send? What headers should a server require? What will a server respond? Interaction is a requirement, since there seems to be a widely felt need to preserve anonymity through the use of temporary addresses. I think that's missing the point; any aliasing scheme is definitely reducing your anonymity, neccessarily so -- the alias has to be looked up somewhere, that somewhere reduces anonymity. If anonymity is what you want, stick with just a bitcoin address. The point of an aliasing server is surely to be able to give a single, unchanging, well known label to a transacting party, but still enable that party to generate a new address per transaction. I want my webshop to be able to say please pay 3.20 BTC to https://mywebshop.com/payments/orderid=27282; to enable the automatic connection from orderid to bitcoin address (which my payment system can then monitor for payment receipt). (This is just one example). Generating a temporary address requires some actual processing to achieve, since the issuing of the new address cannot be done without interacting with the entity hosting the wallet (unless I'm missing something?). Well yes; but then the client has no idea what address to send to unless it connects to that URI... interaction/address generation is done when that connection is made. In short: I don't really think that this aliasing system should be concerning itself with preserving anonymity of the receiving party. That is almost certainly already gone (I'm hardly likely to send money to someone I don't know unless I like gifting random cash). The sending party loses a little anonymity because their IP is revealed when they connect to the aliasing system. But there is very little anonymity in a supplier-client relationship anyway (you have to say what goods you want, and where you want them, and you had to interact with a website when you were ordering already). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
On 2011 December 13 Tuesday, Amir Taaki wrote: Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. I don't like the idea of a hard-coded mapping at all. We shouldn't be making choices on behalf of server operators. It's up to them how they arrange their domain names and paths. I also agree that DNS is not the technology to use. DNS is a nightmare. gen...@foo.org Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined. I'll clarify it later. This is the relevant line: string strRequestUrl = strDomain + /bitcoin-alias/?handle= + pszEncodedNick; Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries). Why bother with an encoding scheme at all? If the address gen...@foo.org always maps to https://foo.org/bitcoin-alias/?handle=genjix Then forget the hardcoding of https the hardcoding of bitcoin-alias and ?handle= and the original email-looking gen...@foo.org. Just use the URL. Then the author of the service can use whatever they want. Can I pay you 10 BTC? Sure, send it to 'https://bitcoinalias.foo.org/genjix/' While I might implement my alias server like this: Sure, send it to 'https://google.com/bitcoin/?andyparkins' Sure, send it to 'https://parkins.co.uk/; ... or any other URL they want -- any of which suit might suit me and my webserver better than whatever mapping would otherwise be hard-coded. The world is already very familiar with URLs so this is no more scary than the email address. What's more, the email address form looks _too much_ like an email address, and will only lead to confusion ... send it to gen...@foo.org so I use outlook express for that, right? erm, no, you put it in your bitcoin client. The URL form could easily be made to detect a browser connecting rather than a bitcoin client (and this is an area that would benefit from a standards document -- define the headers and user agent triggers that an alias server expects) and give them better instructions. https can be specified as the default, so https://; can be optional when they're typing. If, in the future, bitcoin gets a distributed peer-to-peer alias system, then a new URL type can be added easily bcalias://andyparkins might automatically find my node in the network and query it for an address (or whatever). All of the above is exactly why OpenID chose to use URLs for ID. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lowering confirmation requirements and preventing double spends
On 2011 December 08 Thursday, Stefan Thomas wrote: Bitcoin already does something which in practice has exactly this effect: If a transaction is reversed, any transactions based on its outputs are rejected. That part is fine; I was aware that Bitcoin did this. How could it not? The transactions form multiple signature chains of their own. It impossible to have a transaction depend on a non-existent input transaction. Hosted wallets can make use of this - but as you correctly point out, depending on the service, it can get tricky. What if I exchange the money to USD and back before withdrawing? You could have an algorithm where MtGox prefers to spend outputs from your own deposits as the inputs for your withdrawals, it's not trivial though and never 100% secure. Quite so; this is essentially the problem my suggestion addresses. What do you do when a transaction is dependent on another transaction financially but not technically? That is to say that your accounting software would show a credit and a debit to a particular entity, but the bitcoin block chain would not. In the old world we might do this as I'll write you a cheque and you give me cash; if that cheque bounces, you've lost your cash. I have trouble thinking of a good example where you need an explicit block dependency as you describe. The only times you'd want to use this dependency of transactions on specific previous transactions is when you can clearly and easily associate the money. But if you can clearly and easily associate the money, you might as well just relate the transactions (use the outputs from the deposit transaction as the inputs of the withdrawal transaction.) The MyBitcoin debacle (if we are to believe their reports) would have been avoided by my suggestion. They were accepting deposits in one chain, and allowing withdrawls from another. That meant that while there was a financial connection, there was not a bitcoin-connection. The withdrawls happened from the pool address, most likely well funded, so were valid on either chain. If MyBitcoin had been able to broadcast the withdrawl transactions as being based on the same chain as the deposit (even though it was not using transactions in that chain) then the attack would have failed. This is btw something that would strongly agree with: Hosted wallets should absolutely keep each account as separate public keys. With that you lose free and instant internal transactions, but you gain instant deposits and much better risk isolation. I'm not sure I agree. There is certainly a case for both types: one-to-one correspondence between address and account has the advantages you list but is highly identifiable and trackable. However the disadvantage is that all funds would have to be kept online. Places like Mt.Gox can (although there is evidence to suggest that they don't, tut tu) move the majority of the funds to five USB sticks, and keep them in five fire-proof safes or deposit boxes or whatever only because deposited funds are pooled. This is just my view. Thanks and keep the thought-provoking stuff coming! Thanks for the encouragement. It's appreciated. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Lowering confirmation requirements and preventing double spends
Hello, Another of my crazy ideas: When a transaction is first broadcast, it should include the hash of the block it wants to appear after, let's call it's basis block. That block can be anything the claimer wants; but it allows the miners to add this condition: the transactions outputs a new transaction claims must be before the new transaction's basis block. Consider this block chain fork: * -- * -- F -- * -- 1 -- 4 -- 5 \ * -- 2 -- 3 Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other pooled-account online wallet). In block 1 I transfer credit from address A to address B. In block 3 I transfer credit from Mt.Gox's pool to address B. The chain at 3 races out first, but eventually the chain at 5 becomes the one. If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is nothing to stop that same withdrawl making it into 4 (since it comes from a pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and must wait for six confirmations of 2 before allowing use of the funds. That is an inconvenience for all the honest users. With my proposed change, the Mt.Gox transaction broadcast at 3 would include block 2 as its basis block. Therefore that transaction could never make it into block 4, as no miner will include a transaction based on block 2 in the block 4 chain. Mt.Gox is probably not a good example, as they have problems with fiat to deal with too. However, for other online wallet accounts it would allow faster acceptance of received funds, since there is no danger of loss should an attacker arrange a reorganisation. This basis block would be optional (implied by the input transactions if it isn't present); and would only need storing for the pending transactions, so no incompatible change is needed to the block format. Andy -- Dr Andy Parkins andypark...@gmail.com -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Jorge Timón wrote: 2011/11/23, Andy Parkins andypark...@gmail.com: Let's abandon the idea of a target difficulty. Instead, every node just generates the most difficulty block it can. Simultaneously, every node is listening for the most difficult block generated before time T; with T being picked to be the block generation rate (10 minutes). A miner could try to obtain more difficulty out of time and cheat its reported datetime (T). Just as with the current system. The defence is that on receipt of a block, its timestamp is checked against the node's own clock and averaged network clock. Blocks out of that band are rejected. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Jorge Timón wrote: With the current system, the timestamp can also be cheated, but miners have no direct incentive to do it. With your system, they increase their probability of mining a block by putting a false timestamp. Also, where's the network clock you're talking about? Isn't it the timestamps in the blockchain? (1) The probability of mining a block is old-think. The probability of mining a block is 100% in my system. Instead, it becomes the probability of your block being the hardest and that requires actual hashing power regardless of the timestamp you write on the block. I could write that my block was generated next year; but I can't fake the hashing power it needs to generate one year's worth of hashes. If chain difficulty were summed correctly (sum(log(difficulty)), I guess), then time makes not the slightest difference anyway. You can issue blocks at any time with any difficulty, and the hardest chain always wins. The block period can be anything, and it is only the block reward that makes it necessary to pick a particular period for block issuing (even that could be worked around I guess with a variable reward, but why bother?). (2) For the network clock; see util.cpp:GetAdjustedTime(). (3) Current clients do have an incentive: more time. The more time they get, the more hashes they can try. The current client already checks the timestamp: main.cpp:CBlock::CheckBlock() // Check timestamp if (GetBlockTime() GetAdjustedTime() + 2 * 60 * 60) return error(CheckBlock() : block timestamp too far in the future); My suggestion only requires that the two hour window be reduced; and a lower limit to be added. Also: while the miners have an incentive to lie about the time, the nodes they broadcast to have an incentive to reject mistimed blocks, so you won't gain much by lying to your peers since your block won't be accepted -- the incentive is therefore removed. Note: my system also prevents an attack that is possible with current bitcoin: recalculating the entire chain. Let's say Visa want to take over bitcoin. They buy enough computing power to significantly beat the current bitcoin network; then they start recalculating the entire block chain; since early blocks were low difficulty, it's not that hard to do. Once they overtake the real chain, they have effectively undone all previous transactions. (I'm not suggesting this is likely; and it's actually mitigated by the hard-coded block hashes). The point is that blocks are only generatable for the time when the rest of the network is willing to add them to the chain. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Christian Decker wrote: The current block generation with a fixed difficulty was chosen because it it clear when to adjust and to what target difficulty it has to be adjusted. If we were to use synchronized time windows and select the hardest block it gets incredibly complicated as synchronization is not possible in distributed systems. Even the smallest drift would allow for forks in the chain all over the place. Furthermore the delay in propagation will also cause forks. If 1/2 of the network see one block as the hardest, and for the rest of the network it came too late then we'll have a fork that stays with us quite a while. The block chain is described as a timestamp server in the paper, but it is more of a proof-of-existence before, as the contained timestamp cannot be trusted anyway. These are reasonable objections. My counter is this: Let's view block difficulty as a measure of time, not time itself. The timestamp is merely a convenience for the block. You cannot fake the computing power needed for a particular difficulty; so the hardest chain always wins (note: hardest chain). If I am a miner, I have two choices: (a) try to replace the top block on the current hardest chain (b) try to append to the current hardest chain Either of these is acceptable; but in case (a) I have to generate a more difficult block to replace it; in case (b), at the start of the window, any difficulty is acceptable (however, I'm competing with other miners, so _any_ difficulty won't beat them). The rule then is that you're trying to win the one block reward that is available every 10 minutes; and your peers will be rejecting blocks with timestamps that are lies. Perhaps an example... - I (a node), download the blockchain - The blockchain has N potential heads. Each of those heads has a time, t and a sum_of_difficulty. - The next block reward is going to go to the highest difficulty with t timestamp (t + T) _and_ verified timestamp (i.e. not received more than, say 5 minutes, from its claimed timestamp). - I can choose any head to start generating from, but given that it's the highest difficulty chain that's going to win the next reward (not the highest difficulty block), I will surely pick the most difficult? - A rogue miner then issues a block with a fake timestamp; it actually generated at (t + T + 5) but claims (t + 5). Should I start using that block as my new head? Obviously not, because my peers might decide that it is a lie and reject it because it was received too late, making my work useless. It is in my interest to pick a head that is honest. Resolving forks is easy: - 50 coins every ten minutes only - most difficult chain wins I'm certainly not saying it's a simple change. There are certainly areas I haven't thought about, and could be game-overs; but I do like the idea of there being no target difficulty, and instead the blocks are issued at a fixed ten minute rate (or rather the rewards are). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Christian Decker wrote: Just brainstorming here, no idea if this would work: - Pick any old block - Create a chain fork by creating simpler blocks on top of your chosen one - The chain will not be accepted by others - At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network - Suddenly all your blocks are valid and you force people to switch to your forked chain If this is possible it would allow you to revoke all transactions and claim all the mined coins since you forked. My point is that the notion of hardest chain is not so simple. The above is a problem in either system (mine or current). If I can make a hardest chain, then I have indeed reverted all the existing transactions. Look at CBlock::AddToBlockIndex(), if (pindexNew-bnChainWork bnBestChainWork) if (!SetBestChain(txdb, pindexNew)) return false; If the received block has higher total chain work than the current best chain work; then the new block becomes the head of the best chain. The chain work being calculated like this (I've abbreviated for the email): pindexNew-bnChainWork = pprev-bnChainWork + pindexNew-GetBlockWork() I'm not entirely convinced that this method of totalling chain work is the best (it's a sum of exponentials I think); but that's a different issue. The difficulty of invalidating a chain is dramatically reduced with your time window approach, by not requiring a given difficulty, and relying on synchronized time windows. I don't see that it is reduced; it is the same. Hashes are hashes. A given difficulty isn't required, but a higher difficulty beats a lower difficulty. So whatever the hashing power of the network at that moment, it's used. That makes the chain more secure, not less. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Jorge Timón wrote: Well, I meant the probability of your block being the hardest. What a miner can do is hash the block (cheating the timestamp) for 2 more minutes than the rest of the people and then send it to the other nodes. Nodes cannot possibly know when did you hashed the block only by looking at their clock when they receive it, because there's also network latency. True enough; but then the same is true for everyone else. If the window is 2 minutes after the stated time, then everyone _can_ wait until the end of that window. However, they risk their block being rejected by their peers, and their efforts are wasted. In fact, it can be guaranteed by making the accept window zero. There is then no reason to carry on computing after the reward window closes, since you know your peers will reject it. (2) For the network clock; see util.cpp:GetAdjustedTime(). 1) This is part of the satoshi client but not the protocol. A miner can rewrite this part of the code and there won't be anything in the chain that contradicts the protocol. Well yes. What does that matter? It's only a way of calculating an average time. The node can use any clock it wants, as long as the block time is verified by the peers. 2) I haven't read the code but I'm pretty sure that's not a perfect decentralized clock. It definitely isn't. NTP is mentioned in the source as an alternative. I will be more specific. Where's the network clock in the chain (in the protocol)? It's nothing to do with the protocol; it's an individual miner choosing whether to accept or reject a block based on the timestamp it claims, and the current time as the miner sees it. For the sake of compatibility, the clients currently choose to use a community clock as current, as established from the time they receive from peers in the version message (it actually holds offsets between them, which is pretty bad, as a long-connected client will drift). They don't have to, but if miners aren't using time that approximates what their peers are using, under my system, their blocks would be rejected: so an incentive to use that community clock exists. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
