The MultiBit HD view is that this is a locale-sensitive presentation issue.
As a result we offer a simple configuration panel giving pretty much every
possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
mXBT, μXBT, sat along
with settings for leading/trailing symbol, commas,
Jean-Paul, it may be worth noting that the BIP39 word list is integrated
into Bitcoinj so will likely become the de facto standard for Android,
Trezor web and several desktop wallets. Anyone deviating from that word
list would likely find themselves in an isolated pocket.
Regarding the timestamp,
Speaking from the MultiBit perspective, all future protocol development
(with the exception of critical security and network compatibility fixes)
will be put into a HD wallet. Over time we want to see MultiBit Classic
gracefully retire and be fully superseded.
Right now, HD is not out there but
MultiBit here.
At least Trezor and bitcoinj (Multibit) seems to be going in this way,
which is 100% of clients which expressed interest in bip39 :-).
slush
We'll be using the BIP39 implementation present in Bitcoinj as slush says.
Proper Unicode handling is a serious issue however. You don't
I like reusable address.
It is very clear what the intended purpose is and gives a subtle hint that
other types of address should not be re-used.
On 16 January 2014 00:44, Eric Martindale e...@ericmartindale.com wrote:
One variation of this, recycled address, might avert misconceptions that
Personally, I would be more inclined to submit and work on a BIP if it was
in GitHub. It's a regular home from home for me now.
On 5 December 2013 14:43, Jeff Garzik jgar...@bitpay.com wrote:
This entire discussion is recycled. Please review the previous
discussion, before asking the same
I've beefed up the supporting documentation for the website to make it more
accessible for developers who wish to contribute. It's a Java application
serving HTML.
It can be found here: https://github.com/jim618/multibit-website
On 30 June 2013 16:19, Jim jim...@fastmail.co.uk wrote:
Yeah
I've been following this thread closely, and Mike is correct here -
protocol buffers is definitely the way to go.
On 17 December 2012 09:19, Mike Hearn m...@plan99.net wrote:
Can we please drop the binary vs text issue? We have been around it
millions of times already. There are no compelling
I would like to chime on on the user experience of the SPV client (in
particular MultiBit).
Without exception, everyone that I have introduced Bitcoin (which is a lot
of people) have expected an instant-on experience. It has to clobber
PayPal and credit cards or people won't give it a second
This is definitely worth doing and I wish you every encouragement.
For my part I'm working on a different area of the Bitcoin ecosystem and
that is taking up all my time so I can only cheer you on from the sidelines.
On 25 September 2012 21:49, Daniel F nanot...@gmail.com wrote:
on 09/25/2012
Hi Steve,
This looks like a good idea to me. The test suites could act similarly to
the 100% Pure Java approach that successfully fended off a lot of
corrupting influences to Java over the years.
Maybe it's worth putting together a small starter suite of tests and
showing them to the community
Is it worth having a few more people email Ben to ask him politely to fall
into line with the BIP? No point encouraging broken windows by not speaking
out.
On 16 July 2012 09:16, Andreas Schildbach andr...@schildbach.de wrote:
I asked Ben to fix this (social networks don't parse QRcodes after
AM, Gary Rowe g.r...@froot.co.uk wrote:
Is it worth having a few more people email Ben to ask him politely to
fall into line with the BIP? No point encouraging broken windows by not
speaking out.
On 16 July 2012 09:16, Andreas Schildbach andr...@schildbach.de wrote:
I asked Ben to fix
How about keeping it simple?
Bitcoin-Qt
* Requires the entire blockchain
* Standalone client
* Designed for continuous operation
* Available for Windows, Mac, Linux with installer
* Developed in C
* Website: https://bitcoin.org
MultiBit
* Requires a reduced blockchain
* Standalone client
*
with that description? I will check with
ThomasV about Electrum.
From: Gary Rowe g.r...@froot.co.uk
To: bitcoin-development@lists.sourceforge.net
bitcoin-development@lists.sourceforge.net
Sent: Wednesday, May 2, 2012 8:34 PM
Subject: Re: [Bitcoin-development] new
Hi Walter,
This could be of interest to the XChange project. See GitHub:
https://github.com/timmolter/XChange
The aim of this project is to provide a unifed API for applications to
access financial exchanges. At present it supports Bitcoin exchanges (MtGox
and Intersango are the primary focus
BlueMatt, did the BIP0021 Wiki entry for req: to req- get updated? I'm
looking there now and it seems to be still at req:
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning
Shudder.
:-)
On 31 January 2012 15:02, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe g.r...@froot.co.uk wrote:
One never uses doubles or floats for money.
Lots and lots of people do. Go place a sell order on mtgox
Andreas has a good point. See RFC 3986 on URI schemes:
http://tools.ietf.org/html/rfc3986#page-12
The colon is a reserved general delimiter (similar in use to the / in a
typical URL, but applies to URNs etc). As suggested, we get req:something
being changed to one of the unreserved characters
an ISO8601 formatted date/time in UTC
(e.g. 2000-01-01T23:59:59Z). This would allow merchants to issue Bitcoin
URIs that would expose them to a currency/inventory risk for a defined
period of time.
Kind regards,
Gary Rowe
PS First post to this list
20 matches
Mail list logo
