When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:
* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language varian
When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:
* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language varian
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, spaces
.
On 12 March 2014 19:35, Jean-Paul Kogelman wrote:
>
>
> On Mar 12, 2014, at 09:49 AM, Gary Rowe wrote:
>
> 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 se
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
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 wrote:
> One variation of this, "recycled address", might avert misconceptions that
> the "re-use" is e
Happy New Year to all the good people out there working hard to make
Bitcoin better than ever before.
Thank you!
On 1 January 2014 19:25, Melvin Carvalho wrote:
>
>
>
> On 1 January 2014 19:33, Mike Hearn wrote:
>
>> Bitcoin had an incredible year in 2013, and I very much enjoyed working
>> w
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 wrote:
> This entire discussion is recycled. Please review the previous
> discussion, before asking the same questions over agai
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 wrote:
> Yeah "email jim' was never go
Many people that I have introduced Bitcoin to have balked at the massive
blockchain download. When I showed them MultiBit (and Bitcoin Wallet) they
breathed a sigh of relief and got on with it.
A currency lives or dies by network effects. If we can provide the average
low-tech user with a great cl
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 wrote:
> Can we please drop the binary vs text issue? We have been around it
> millions of times already. There are no compelling arguments to
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 loo
build the Bitcoin economy.
More info:
https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction
http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/
On 10 October 2012 12:19, Mike Hearn wrote:
> +gary
>
> > Electrum also has a daemon for merchants.
>
> Well,
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 wrote:
> on 09/25/2012 02:32 PM steve sai
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 th
that
introducing a false hierarchy is breaking the specification since it
presumes the existence of a relative URI.
On 16 July 2012 10:02, Wladimir wrote:
> But is he the only one using the broken URLs? It was my impression that
> they were widespread already.
>
> Wladimir
>
>
&g
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 wrote:
> > I asked Ben to fix this (social networks don't parse QRcodes after
> > all), but after
Although I can only speak for my involvement with MultiBit, the idea of a
randomised client page seems wrong to me, for the reasons given by Alan
earlier.
Equally, in order to further the idea that Bitcoin is more than the
reference client, it is appropriate that other clients are acknowledged and
Now that I've seen and read through the forum thread on this, I think I'll
step back and let others get on with it. As Amir notes, we could be "Bike
Shedding" this for years.
On 2 May 2012 21:25, Luke-Jr wrote:
> On Wednesday, May 02, 2012 3:34:35 PM Gary Row
uilt.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
>
> From: Gary Rowe
> To: "bitcoin-development@lists.sourceforge.net" <
> bitcoin-development@lists.sou
Regards,
> Raphael
>
>
> On 05/02/2012 09:34 PM, Gary Rowe wrote:
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with install
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
* Design
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 wit
Seems reasonable to me.
On 4 Feb 2012 14:03, wrote:
> Just another question concerning BIP21:
>
> On the wiki, the description of the "message" parameter reads:
> "message that shown to the user after scanning the QR code"
>
> I believe that the purpose of this parameter is to contain a descripti
OK - I've added a comment to the pull request.
On 2 February 2012 17:39, Matt Corallo wrote:
> Not yet, its up to genjix (Amir) to do that. See
> https://github.com/genjix/bips/pull/2
>
> Matt
>
> On Thu, 2012-02-02 at 17:07 +, Gary Rowe wrote:
> > BlueMatt, d
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
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 that
Shudder.
:-)
On 31 January 2012 15:02, Gregory Maxwell wrote:
> On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe wrote:
> > One never uses doubles or floats for money.
>
> Lots and lots of people do. Go place a sell ord
Regarding the decimal vs satoshi notation I see a few problems with satoshi:
* readability - humans reading the URI would expect it to accurately
reflect what is being displayed (subject to internationalisation issues)
For example, amount=1.234 is more human readable than amount=12340 (ish)
*
I think that the "send to private address" field will require more effort
to implement than the simpler "expires" and "message" fields and should be
deferred to a later BIP. There is a pressing need for expires and the only
point of contention I see is the inclusion of a dual representation (block
the use of a
single representation in decimal notation.
In my view, BIP 21 still wins since it reduces complexity for the end
client both at the human and machine level.
On 30 January 2012 18:56, Luke-Jr wrote:
> On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:
> > Speaking on behal
the BIP 21 proposal
is "expires" which would contain 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
perio
34 matches
Mail list logo
