Re: [Bitcoin-development] BIP32 Index Randomisation
Could you describe what exactly BWS does? Sure. BWS tasks are: * Coordinate Transaction proposals in multisignature wallets: provide an 'always connected' node to distribute pending transaction proposals and receive the signatures from peers. * Coordinate and store BIP32 derivation indexes. (If the BWS disappear, peer can still access the funds by scanning the blockchain, but having the index in a common accessable point in useful). * Access the blockchain and provide functions like: `getBalance` and `getTxHistory` to peers. * Allow agents to notify incoming funds / or transaction proposals to peers. BWS is designed to be extremely easy to setup and run. BitPay will provide a public BWS instance, but companies and individuals can run their own for privacy and security reasons. It sounds like the server doesn't have to actually derive the keys itself for any particular purpose beyond knowing the addresses are a part of the wallet. Could the server work if it didn't even know that, and was just a bucket of arbitrary addresses with the clients themselves deriving the addresses? We have evaluated BWS not having the extended public keys (and it is still an open possibility) but the main drawback we found is that BWS will have no way to verify addresses sent by the peers (*). A peer could send a fake address to BWS and then functions like 'getBalance' or 'txHistory' will be broken. Of course, the peers could verify the addresses on getTxHistory or getBalance (by Address) but we also want to allow thin-clients and agents with lower level of trust (than the server) that can notify the wallet balance and incoming transaction to peers using, for example, mobile push notifications. (*): Gregory Maxwell proposed an schema for doing this with the not extended pubkeys, that we need to evaluate. That could be the best solution. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP32 Index Randomisation
Hello everyone, We are working on bitcore-wallet-server (BWS), a HD multisig wallet 'facilitator'. We have a couple of questions regarding BIP32 path usage, and we would love to have feedback from you before moving forward. Currently the BWS instances hold the set of extended public keys of the wallet's peers to be able to derive addresses. Since this is a problem from the privacy point of view, we thought using pseudo-random BIP32 paths, with a seed only known be the peers, so the server will be able to verify that addresses submitted by peers belong to the wallet, but will not be able to derive future wallet addresses. The workflow would be something like: ``` PeergetCurrentIndex Server [index] Peer: pathSeed = PRNG(seed, index); Peer createAddress(index, pathSeed); Server: derives the address and add it to the wallet. Server new address Peer: Verifies the address and inform it the user. ``` This way, accessing server data won't reveal future wallet addresses. The seed (only known by the peers) could be derived from hashes of their xprivs, so wallet funds can still be recover with: 1) The complete set of xprivs 2) The quorum of xprivs + the complete set of xpubs + the address seed. Thanks a lot in advance for any comment on this schema. matías -- BitPay.com -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
I live in Argentina. Here, 1BTC is around half of a monthly average wage (net), so, as you can imagine, the value of 1 BTC is *very* inconvenient for everyday transactions. Also it presents an important entry barrier for new adopters: It would be easier to accept buying thousands of bits than buying a tiny fraction of a Bitcoin, for the same amount of pesos. Changing to 1e-6 bits will solve both problems. Changing to 1e-6 microbitcoins will solve the first one, but not sure about the second one. Buying (or earning) mili or micro something isn't that sexy either. Finally, against micro and in favor of bits, micro is noted μ, which is also inconvenient (I had to copy and paste it from an other site). Many different notations will be used like: μBTC, uBTC, microBTC and even mBTC. Please prevent that. These arguments also applies to many places in the world (Argentina is 40 out of 72 listed countries in http://en.wikipedia.org/wiki/List_of_countries_by_average_wage). matías On Fri, May 2, 2014 at 10:13 PM, Alan Reiner etothe...@gmail.com wrote: I've been a strong supporter of the 1e-6 unit switch since the beginning and ready to do whatever I can with Armory to help ease that transition. I'm happy to prioritize a release that updates the Armory interface to make bits the default unit, when the time is right. I think it makes sense to get as many apps and services to upgrade nearly simultaneously. My plan is to have a popup on the first load of the new version that briefly introduces the change, and mentions that they can go back to the old way in the settings, but make them work to do it. For the transient period (6 months?) all input boxes will auto-update nearby labels with the converted-to-BTC value as they type, so that they don't have to do any math in their head. Similarly, all displayed BTC values will show both. But the 1e-6 unit will always be default or first unless they explicitly change it in the interface. On 5/2/2014 8:54 PM, Ben Davenport wrote: I fully support this (it's what I suggested over a year ago), but what it comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting together, agreeing what they're going to use, and doing a little joint customer education campaign around it. If there's community momentum around bits, great. My only addition is that I think we should all stop trying to attach SI prefixes to the currency unit. Name me another world currency that uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at least in the US is currency-symbolamountmodifier, i.e. $63k or $3M. That may not be accepted form everywhere, but in any case it's an informal format, not a formal one. The important point is there should be one base unit that is not modified with SI prefixes. And I think the arguments are strong for that unit being = 100 satoshi. Ben On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik jgar...@bitpay.com wrote: vendor hat: on Related: http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Matías Alejo
Re: [Bitcoin-development] Testnet block explorer
Hi Melvin / Mike, Ive been working on Bitcore and Insight next to a BitPay team for the last few weeks. We are happy to receive patches, suggestions and bug reports from you guys at: https://github.com/bitpay/insight Insight also provides some blockchain query capabilities at its REST/Websockets API described on the Readme document. Please note that Insight is meant as a software package that you can download, install and use next to a trusted bitcoind instance. live.bitcore.io / test.bitcore.io are just demo installations. best, matías On Sun, Feb 16, 2014 at 10:45 AM, Melvin Carvalho melvincarva...@gmail.comwrote: On 27 December 2013 19:05, Mike Hearn m...@plan99.net wrote: For a long time the only block explorer for testnet has been the original blockexplorer.com, which is unfortunately often broken / behind / slow and not really maintained any more. There is now a new one, here: https://www.biteasy.com/testnet/blocks There's also a REST/JSON API for it. Please note one curiosity of this block explorer is that the coinbase tx doesn't necessarily come first in the listing (it's sorted by time received, see). Other interesting thing to note: this site is built using bitcoinj. The author can be contacted on IRC sometimes using the nick damethos. Some more information on testnet3 explorers ... Here is a free software testnet explorer based on javascript/node http://test.bitcore.io/ I've been working on a testnet explorer, but I think I will fork this and add semantic web style markup attributes to the HTML. Also a message I got from blockr.io yes testnet will be added. I cannot give you an estimate on when, but it'll probably happen in couple of weeks (hopefully sooner). -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Matías Alejo Garcia CinemaKi.com Skype/Twitter: @ematiu Roads? Where we're going, we don't need roads! -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
