Re: [Bitcoin-development] Payment Protocol Hash Comments
SHA-1 support is there for PHP developers. Apparently it can't do SHA-2. On 2 Mar 2014 08:53, Jeremy Spilman jer...@taplink.co wrote: From BIP70: If pki_type is x509+sha256, then the Payment message is hashed using the SHA256 algorithm to produce the message digest that is signed. If pki_type is x509+sha1, then the SHA1 algorithm is used. A couple minor comments; - I think it meant to say the field to be hashed is 'PaymentRequest' not 'Payment' message -- probably got renamed at some point and this is an old reference calling it by its original name. - Could be a bit more explicit about the hashing, e.g. 'copy the PaymentRequest, set the signature field to the empty string, serialize to a byte[] and hash. - SHA1 is retiring, any particular reason to even have it in there at all? - Should there any way for the end-user to see details like the pki_type and the certificate chain, like browser do? Thanks, Jeremy -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Hash Comments
Not true, PHP does support sha2 http://php.net/manual/en/mhash.constants.php http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples On 2 Mar 2014 08:44, Mike Hearn m...@plan99.net wrote: SHA-1 support is there for PHP developers. Apparently it can't do SHA-2. On 2 Mar 2014 08:53, Jeremy Spilman jer...@taplink.co wrote: From BIP70: If pki_type is x509+sha256, then the Payment message is hashed using the SHA256 algorithm to produce the message digest that is signed. If pki_type is x509+sha1, then the SHA1 algorithm is used. A couple minor comments; - I think it meant to say the field to be hashed is 'PaymentRequest' not 'Payment' message -- probably got renamed at some point and this is an old reference calling it by its original name. - Could be a bit more explicit about the hashing, e.g. 'copy the PaymentRequest, set the signature field to the empty string, serialize to a byte[] and hash. - SHA1 is retiring, any particular reason to even have it in there at all? - Should there any way for the end-user to see details like the pki_type and the certificate chain, like browser do? Thanks, Jeremy -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
I've written up a document about all the different methods on how the payment protocol (both the old one and BIP70) is used in Bitcoin Wallet. It only provides an overview -- I plan to go into details with separate (BIP?) documents where needed. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests If you have any questions about compatibility, don't hesitate to contact me. On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. [...] -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn m...@plan99.net wrote:3) Whilst these payment processors currently verify merchants so the security risk is low, in future a lighter-weight model or competing sites that allow open signups would give a weak security situation: a hacker who compromised your computer could sign up for some popular payment processor under a false identity (or no identity), and wait until you use your hacked computer to make a payment to someone else using the same payment processor. They could then do an identity swap of the real payment request for one of their own, and your Trezor would still look the same. Avoiding this is a major motivation for the entire system!Let me restate that, it's a huge problem...Alice's system is compromised,Mallory intercepts a payment request being sent to Alice from payment processor X on behaf of merchant X.Mallory regenerates a spoof payment request which pays to M, from the same payment processorAlice can't tell Mallory's spoofed PR apart from Merchant X's and thinks she's paying Merchant XIt might be a bit challenging for M to generate the new PR on-the-fly without being noticed, but that's not a security guarantee.Perhaps the UI just isn't expressive enough currently to expose this situation in any way, let alone reliably alert the user to the issue, because there's no way for the payment processor to get authenticated fields other than memo into the UI.
Today the only solution is for the payment processor to strictly control the 'memo' field so Mallory wouldn't be able to make his own PR that looked exactly like merchant Y's. But maybe it's too subtle to make payment processors embed that kind of information.So is the main goal is to provide a structured way to embed this information in the PR and expect that user interfaces will display them to end users? If that's the case, I don't think we need an entirely secondary certificate, or cross signing from a secondary ECDSA key.
A poor solution: If the UI included some sort of certificate viewer, even just tied to the OS certificate viewer, and made the cert available for inspection, at least the merchant would have a chance to put some fields in there which a very advanced user might actually find. But this was discussed a while ago and I think the primary problem is the difficulty in getting a CA to let you embed any additional fields in your certificate in the first place, plus you don't want to generate a new cert for each merchant.
A somewhat better option: Some additional fields defined in an extension which are reliably shown in the UI. We could try to define specific fields, like 'DelegateCN' which would possibly override the primary CN... As an aside, I think you can never allow actually overriding the CN displayed in the UI directly, the most you can do is add another field in the UI to show this string. First I need to know it's from Payment Processor X, and then maybe we can let the payment processor make some additional claim, like yes you are paying irs.gov. You can't give the impression that Payment Processor X is not actually man-in-the-middle.Maybe the simplest would be a single field expected to contain a delimited key/value string (of course JSON) which could be shown as additional lines of labeled text in the UI. I don't want to give the "merchant" too much dynamic control over what the user's screen will display, but making it somewhat dynamic might add some future proofing.I think any additional extension fields should be hashed using the hash function specified in pki_type and signed by X509Certificates.certifcate private key. No extended_certs required -- I'm thinking something like;message PaymentRequest { // new fieldoptional bytes extended_properties = 6;optional bytes extended_properties_sig = 7;}Thanks,Jeremy--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors
I'm hoping I can convince Saivann to do a bit of graphics work for this at some point :-) Something like a green stamp that appears (like a watermark) in the background, might be good. On Sat, Mar 1, 2014 at 8:50 AM, Jeremy Spilman jer...@taplink.co wrote: On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir laa...@gmail.com wrote: Such a thing would be interesting for a future BIP standard. I see one problem here: for an unsigned payment request there isn't really an origin. Browser URI handlers don't send the referrer either. Yeah, good point. If you have a cert, we have the CN from the cert, which becomes the string displayed as 'Pay To' and alternatively 'Merchant'. But if there's no cert then all you have is memo. So the best way to differentiate signed requests is by prominently displaying that Merchant string. Really the green part should just be the 'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that would make the lack of certificate highly apparent. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Hash Comments
I'm just repeating the rationale Gavin gave me for adding this to the spec last year when he was implementing it. Perhaps it only applied to some versions of PHP or something like that. Jeremy, good comments. A pull request to fix those would be good. One issue I seem looming on the horizon is that we'll need a version of the payment protocol document that's living. Trying to reverse engineer the current spec by manually reading all the BIPs and layering them in your head is a non starter. On Sun, Mar 2, 2014 at 9:52 AM, Drak d...@zikula.org wrote: Not true, PHP does support sha2 http://php.net/manual/en/mhash.constants.php http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples On 2 Mar 2014 08:44, Mike Hearn m...@plan99.net wrote: SHA-1 support is there for PHP developers. Apparently it can't do SHA-2. On 2 Mar 2014 08:53, Jeremy Spilman jer...@taplink.co wrote: From BIP70: If pki_type is x509+sha256, then the Payment message is hashed using the SHA256 algorithm to produce the message digest that is signed. If pki_type is x509+sha1, then the SHA1 algorithm is used. A couple minor comments; - I think it meant to say the field to be hashed is 'PaymentRequest' not 'Payment' message -- probably got renamed at some point and this is an old reference calling it by its original name. - Could be a bit more explicit about the hashing, e.g. 'copy the PaymentRequest, set the signature field to the empty string, serialize to a byte[] and hash. - SHA1 is retiring, any particular reason to even have it in there at all? - Should there any way for the end-user to see details like the pki_type and the certificate chain, like browser do? Thanks, Jeremy -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
Perhaps the UI just isn't expressive enough currently to expose this situation in any way, let alone reliably alert the user to the issue, because there's no way for the payment processor to get authenticated fields other than memo into the UI. I think for now as long as payment processors include the merchant name in the memo, that's good - as long as hardware devices or second factor wallets display the memo as well! Trezor has a small screen, I don't know how feasible displaying the whole memo is there though - hence an interest in something better. For now we can probably muddle through. A poor solution: If the UI included some sort of certificate viewer, even just tied to the OS certificate viewer, and made the cert available for inspection, at least the merchant would have a chance to put some fields in there which a very advanced user might actually find. Not really interested in solutions that only help very advanced users. Besides, my understanding is that most PKI CA's will not sign certs that include arbitrary data they don't understand for I guess the obvious security reasons (generally signing things you don't understand is a bad idea). But I've never actually tried it. We don't want anyone to have to go back to their CA anyway, especially not with special requests. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
On Sat, Mar 1, 2014 at 9:07 PM, Dev Random c1.devran...@niftybox.netwrote: I'm wondering about the small business case. A small business or an individual might not have the technical expertise to perform the delegation signature. If they take delivery of an SSL cert from the CA themselves, I don't see why it'd be an issue. A simple GUI app can be produced that let's you open the CA cert files and spits out the ExtendedCert file, which you then send to the PP. However, for small businesses like local shops, yes we don't expect them to have a CA cert at the moment. Many of them do have small websites but for those that don't, I don't think any great solutions exist yet. A virgin market waiting to be tapped, perhaps ... Do you think it makes sense to have another scheme where a merchant can be name spaced under the payment processor? This would require just one additional field - the merchant identifier. What is the merchant identifier exactly, and what does it mean? If this question is left unresolved, then it doesn't mean anything and as such it's equivalent to putting the merchant name in the memo field, which is fine and what I expect to happen for now. If it's resolved, then it makes payment processors into certificate authorities themselves. I think such a solution would be spiffy, but it can be done within the same framework we have today by just having wallets add some Bitcoin specific roots to their trust store before PKI verification. For example, BitPay could become their own CA that doesn't issue SSL certs but rather local business certs that contain a verified street address. Indeed X.509 certs include X.520 names, that's one reason they're so damn complicated, and that's already got ways to express organisation names. Actually setting such a scheme up requires real work though. If we want a wallet to display something like: Pay to: Room 77, Graefestraße 77, Berlin then the question is, how is that verified and what does it mean when a payment processor issues a cert containing it? Did someone physically visit them? Did they just check on Google Maps? Does it mean it's a real incorporated business or could it just be the address of a childs lemonade stand? My inclination would be to say that the ID requirements should be low and cheap; for our primary use case of making hardware wallets secure, you don't need robust ID verification, you just need to ensure a MITM can't issue themselves duplicated ID's on the fly. Just posting a postcard with a nonce on it would be sufficient IMO (or making a phone call to a number obtained from a previously verified business listing). Alternatively, a bitcoin payment processor CA could make visiting a business, gathering photo evidence and issuing a cert into a kind of microwork task with the PP/CA acting as a broker. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
On Sun, Mar 2, 2014 at 4:20 PM, Andreas Schildbach andr...@schildbach.dewrote: I somehow think that it is too early for this heavy kind of extension, given that the first version of BIP70 isn't even deployed widely let alone *used*. Definitely agree - like I said, I publish this only because I keep getting asked about it. By reading your proposal I get the idea that the current spec doesn't allow two (or three) different PKIs at once That's right. There's little point in having multiple PKI's simultaneously, that's why it doesn't allow it. This one is a special case because it doesn't replace but rather specialises and extends the existing PKI. Old clients that don't understand it would still show something useful and by upgrading you get better output. Actually you get closer to the output you're supposed to get. That's going to be rare though, I think. Generally you wouldn't want to have multiple PKIs in use simultaneously for the same payment request. I would prefer if your fix would stay local to X.509 (and thus only change X.509 specific structs rather than the top-level PaymentRequest). It can be done but only by sacrificing backwards compatibility, which doesn't seem worth it to me. It's hardly a big deal to have two signature fields. The rest is all localised to the X509 parts. -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
I'm asking for how to DEVELOP THE CODE so I can trade between two block chains, and then I'm going to start trading cats and dogs and bits. Somewhere in trying to figure out the design spec we got caught up in existential concern about 'globally knowable and accurate price history', and I'm telling you it doesn't matter. I'm the customer and the developer, someone give me a clear design document to trade between two chains and I can write it, and then we can debate improvements. On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote: This is not bitcoin-philosophy, it's bitcoin-development. Existential philosophy belongs on IRC or the forums. On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach m...@monetize.io wrote: Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote: You can make the same argument against Bitcoin itself you know... A Bitmessage-like network would be trivial to front-run via a sybil attack. It's the fundemental problem with marketplaces - the data they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about front running those parallel networks. I've seen many street markets without public information and they work just well. The spot price for ammonia fertilizer, refined gasoline at terminals, and price of tea in china are not 'public information', yet these are some of the largest traded commodities in the world, far exceeding the drop in the bucket that all cryptocoin transactions make. I'd further argue that the *actual* price of corn (cash bid price at elevators and ethanol plants) is not public information either. There is a great deal of money traded in collecting and then distributing the 'cleared price' information. Have a look at http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1 I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of archivers could collect and maintain old orders for historic bid and asks, etc. And again, how do you know that record is honest? Fact is without proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. You just made my long-term strategic argument for investing in my own mining hardware so I can be sure to trade reliably. Again, you haven't addressed why the seller cares more about accurate historic market data than just his own fees and sell. You mean a reverse nLockTime that makes a transaction invalid after a certain amount of time - that's dangerous in a reorg unfortunately as it can make transactions permenantly invalid. People who take money from buyers and sellers care most about 'accurate historic market data'. I just want to exchange my corn for e85, fertilizer, and electricity, and audit the code that runs accounting for the exchange. I really don't give a shit if there is 'accurate historic market data' as long as **MY** personal trade data is accurate and I got a good enough price, and I know who I'm dealing with. I know someone smarter than me and with more money, market leverage, and political connections **WILL** game the system and distort the market data history so they can take more money from buyers and sellers without actually doing some usefull market function. As long as use buyers and sellers can see the code, and have a good eye for knowing when someone's pushing the market around, we can just put our orders in and relieve some speculators of their money. Just get me working code for cross-chain trades, and we'll work on the accurate historic data problem later. Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet,
Re: [Bitcoin-development] 0.9.0 release candidate two
Heads up... downloaded the linux tar.gz to my OVH box and got my server terminated. Screenshot from the email: http://cl.ly/image/3q0C2a3Y0T0V They claimed I was attacking 88.198.199.140 over port 443. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig On Sun, Mar 2, 2014 at 8:54 AM, Gavin Andresen gavinandre...@gmail.comwrote: Please download and help test 0.9.0rc2; binaries are available from: https://bitcoin.org/bin/0.9.0/test/ If no serious bugs are found in this release candidate, it will be the final 0.9.0 release. Release notes (please help proofread/improve these, too): --- Bitcoin Core version 0.9.0rc2 is now available from: https://bitcoin.org/bin/0.9.0/test/ This is a release candidate for a new major version. A major version brings both new features and bug fixes. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first, especially if you are switching to the 64-bit version. Windows 64-bit installer - New in 0.9.0 is the Windows 64-bit version of the client. There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Because of this it is recommended to install the 64-bit version if your system supports it. NOTE: Release candidate 2 windows binaries are not code-signed; use pgp and the SHA256SUMS.asc file to make sure your binaries are correct. The final 0.9.0 release Windows setup.exe binaries will be code-signed. OSX 10.5 / 32-bit no longer supported - 0.9.0 drops support for older Macs. The minimum requirements are now a 64-bit-capable CPU running OSX 10.6 or later. Rebranding to Bitcoin Core --- To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we have renamed the reference client to Bitcoin Core. Autotools build system --- For 0.9.0 we switched to an autotools-based build system instead of individual (q)makefiles. Using the standard “./autogen.sh; ./configure; make” to build Bitcoin-Qt and bitcoind makes it easier for experienced open source developers to contribute to the project. Be sure to check doc/build-*.md for your platform before building from source. Bitcoin-cli - Another change in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client. The RPC client functionality (“tell the running bitcoin daemon to do THIS”) was split into a separate executable, 'bitcoin-cli'. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two. `walletpassphrase` RPC --- The behavior of the `walletpassphrase` RPC when the wallet is already unlocked has changed between 0.8 and 0.9. The 0.8 behavior of `walletpassphrase` is to fail when the wallet is already unlocked: walletpassphrase 1000 walletunlocktime = now + 1000 walletpassphrase 10 Error: Wallet is already unlocked (old unlock time stays) The new behavior of `walletpassphrase` is to set a new unlock time overriding the old one: walletpassphrase 1000 walletunlocktime = now + 1000 walletpassphrase 10 walletunlocktime = now + 10 (overriding the old unlock time) Transaction malleability-related fixes -- This release contains a few fixes for transaction id malleability issues: - -nospendzeroconfchange command-line option, to avoid spending zero-confirmation change - IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions - Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they spend the same outputs. - Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions. - New option: -zapwallettxes to rebuild the wallet's transaction information Transaction Fees This release drops the default fee
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Again, the two best ways are here: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains https://bitcointalk.org/index.php?topic=321228 But this is off-topic, Peter wasn't talking about cross-chain trade. On 3/2/14, Troy Benjegerdes ho...@hozed.org wrote: I'm asking for how to DEVELOP THE CODE so I can trade between two block chains, and then I'm going to start trading cats and dogs and bits. Somewhere in trying to figure out the design spec we got caught up in existential concern about 'globally knowable and accurate price history', and I'm telling you it doesn't matter. I'm the customer and the developer, someone give me a clear design document to trade between two chains and I can write it, and then we can debate improvements. On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote: This is not bitcoin-philosophy, it's bitcoin-development. Existential philosophy belongs on IRC or the forums. On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach m...@monetize.io wrote: Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote: You can make the same argument against Bitcoin itself you know... A Bitmessage-like network would be trivial to front-run via a sybil attack. It's the fundemental problem with marketplaces - the data they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about front running those parallel networks. I've seen many street markets without public information and they work just well. The spot price for ammonia fertilizer, refined gasoline at terminals, and price of tea in china are not 'public information', yet these are some of the largest traded commodities in the world, far exceeding the drop in the bucket that all cryptocoin transactions make. I'd further argue that the *actual* price of corn (cash bid price at elevators and ethanol plants) is not public information either. There is a great deal of money traded in collecting and then distributing the 'cleared price' information. Have a look at http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1 I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of archivers could collect and maintain old orders for historic bid and asks, etc. And again, how do you know that record is honest? Fact is without proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. You just made my long-term strategic argument for investing in my own mining hardware so I can be sure to trade reliably. Again, you haven't addressed why the seller cares more about accurate historic market data than just his own fees and sell. You mean a reverse nLockTime that makes a transaction invalid after a certain amount of time - that's dangerous in a reorg unfortunately as it can make transactions permenantly invalid. People who take money from buyers and sellers care most about 'accurate historic market data'. I just want to exchange my corn for e85, fertilizer, and electricity, and audit the code that runs accounting for the exchange. I really don't give a shit if there is 'accurate historic market data' as long as **MY** personal trade data is accurate and I got a good enough price, and I know who I'm dealing with. I know someone smarter than me and with more money, market leverage, and political connections **WILL** game the system and distort the market data history so they can take more money from buyers and sellers without actually doing some usefull market function. As long as use buyers and sellers can see the code, and have a good eye for knowing when someone's pushing the market around, we can just put our orders in and relieve some speculators of their money. Just get me working code for cross-chain trades, and we'll work on the accurate historic data problem later. Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements
Re: [Bitcoin-development] Procedure for non-tech contributions
On Sun, Mar 02, 2014 at 03:10:09PM -0500, Tom Geller wrote: Hey, folks. Sorry if this is documented somewhere -- if so, just point me at it. I couldn't find it, though. I'm a (non-developer) writer with experience in open-source communities, and I'd like to contribute with writing/editing/marketing. What's the procedure? Is there someone in charge of that area? Two examples: 1) Gavin recently asked for proofreading of 0.9.0rc2, but it was unclear how to send the changes. (There are many possibilities, some better than others. Git? Google Docs with revisioning? Microsoft Word with Track Changes? The Bitcoin wiki?) I proof-read rc1 and simply submitted my changes via pull-req: https://github.com/bitcoin/bitcoin/pull/3642 I'd say to encourage that method. If someone doesn't know how to use git, yet still wants to proof-read, just send us a text-file with all your corrections applied. We've got the tools to diff those changes ourselves; no fancy software is required. 2) The page at https://en.bitcoin.it/wiki/BitcoinPayment says that the wiki receiving wallet (for the wiki itself) is also MtGox. Umm, I rather doubt that. :-P But I'm not sure what the current info is, or whom to alert. MtGox does host the bitcoin wiki, so yes, the funds probably do go to a wallet held by MtGox in some fashion. -- 'peter'[:-1]@petertodd.org 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 signature.asc Description: Digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0 release candidate two
On Sun, Mar 2, 2014 at 7:34 PM, James Hartig fastest...@gmail.com wrote: Heads up... downloaded the linux tar.gz to my OVH box and got my server terminated. Screenshot from the email: http://cl.ly/image/3q0C2a3Y0T0V They claimed I was attacking 88.198.199.140 over port 443. Sounds very unlikely that bitcoind would connect to port 443, let alone 'attack' anything. Anything in debug.log regarding that IP? Wladimir -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0 release candidate two
Didn't mean that bitcoind was connecting over port 443. I didn't even get a chance to compile. I was literally just finished downloading the tar.gz file when my server was terminated. Still trying to convince them I wasn't attacking anyone so they can re-enable the server. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig On Sun, Mar 2, 2014 at 3:56 PM, Wladimir laa...@gmail.com wrote: On Sun, Mar 2, 2014 at 7:34 PM, James Hartig fastest...@gmail.com wrote: Heads up... downloaded the linux tar.gz to my OVH box and got my server terminated. Screenshot from the email: http://cl.ly/image/3q0C2a3Y0T0V They claimed I was attacking 88.198.199.140 over port 443. Sounds very unlikely that bitcoind would connect to port 443, let alone 'attack' anything. Anything in debug.log regarding that IP? Wladimir -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.9.0 release candidate two
The domain bitcoin.org resolves to that IP address. Could it be some update check together with a circular redirect? That could at least explain the large number of connection attempts. -- Christian Decker On Sun, Mar 2, 2014 at 9:56 PM, Wladimir laa...@gmail.com wrote: On Sun, Mar 2, 2014 at 7:34 PM, James Hartig fastest...@gmail.com wrote: Heads up... downloaded the linux tar.gz to my OVH box and got my server terminated. Screenshot from the email: http://cl.ly/image/3q0C2a3Y0T0V They claimed I was attacking 88.198.199.140 over port 443. Sounds very unlikely that bitcoind would connect to port 443, let alone 'attack' anything. Anything in debug.log regarding that IP? Wladimir -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Procedure for non-tech contributions
Peter Todd p...@petertodd.org wrote: I proof-read rc1 and simply submitted my changes via pull-req: https://github.com/bitcoin/bitcoin/pull/3642 Drak responded: Actually, this is unnecessary since github allows editing of files directly on the site and the it will submit as a pull request. You can even update by visiting your fork (it creates this automatically and a topic branch) and make more edits and it will add to your PR. There is basically no barrier for non techy people to contribute. Ooo, I like this. I *can* use git, but would love to be able to avoid it -- as would most non-technical contributors. Anyway, this particular solution doesn't appear to be possible in this case, as the file isn't at https://github.com/bitcoin/bitcoin/tree/0.9.0/doc/release-notes , and I don't believe I could copy it to the repository without going the whole git route. Suggestions welcome, here or privately. Peter writes: MtGox does host the bitcoin wiki, so yes, the funds probably do go to a wallet held by MtGox in some fashion. The foolishness of sending a payment to a Mt. Gox-held wallet -- which is required to edit the wiki -- strikes me as a pressing issue. If I understand it correctly, this is a hard blocker that'll stop *all* new contributors. Further, I registered for the wiki and never got my confirmation email. Methinks the whole thing is broken. :( Again, please to redirect me if this is inappropriate for this list. (I'm new here.) Cheers, --- Tom Geller * Oberlin, Ohio * 415-317-1805 Writer/Presenter * http://www.tomgeller.com articles, marketing, videos, user guides, books -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New to this list
Hello. I am a developer and I wish to contribute to bitcoin. Where is the best place to start? -- Kevin -- 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] New to this list
On Mar 2, 2014, at 21:34, Kevin kevinsisco61...@gmail.com wrote: Hello. I am a developer and I wish to contribute to bitcoin. Where is the best place to start? -- Kevin Reading and learning the reference client’s source code, or doing the same for any number of non-reference-client Bitcoin projects. Will signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Procedure for non-tech contributions
On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote: Peter writes: MtGox does host the bitcoin wiki, so yes, the funds probably do go to a wallet held by MtGox in some fashion. The foolishness of sending a payment to a Mt. Gox-held wallet -- which is required to edit the wiki -- strikes me as a pressing issue. If I understand it correctly, this is a hard blocker that'll stop *all* new contributors. Further, I registered for the wiki and never got my confirmation email. Methinks the whole thing is broken. :( We've been working on moving the wiki to new hosting, but it isn't a very high priority (at least for MtGox). PM SomeoneWeird on IRC, as he is currently handling manually approving new accounts for editing. Luke -- 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] New to this list
On Monday, March 03, 2014 3:34:27 AM Kevin wrote: Hello. I am a developer and I wish to contribute to bitcoin. Where is the best place to start? Unit tests. This will be valuable to the projects and also help you learn how things work. -- 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
