Jim [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-05-02 to 2015-03-11
💬 Posted a total of 18 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:31:26

- reply

📅 Original date posted:2015-03-11
📝 Original message:The wallet words system isn't perfect for sure but it does help the user in two main ways:
1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
It can be a simple help page saying:
"If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
That way users have clear instructions on how to recover their bitcoins.
Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
--
http://bitcoin-solutions.co.uk
On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
> Sigh. The wallet words system is turning into kind of a mess.
>
> I thought the word list is in fact not a fixed part of the spec, because
> the entropy is a hash of the words. But perhaps I'm misunderstanding
> something.
>
> The main problem regular SPV wallets have with BIP39 is that there is no
> birth time included in the data. Therefore we must ask users to write down
> a timestamp as well, so we know where to start rescanning the chain. It
> sounds like the Electrum version doesn't fix this, so now we have at least
> FIVE incompatible results from a 12 word list:
>
> - Electrum v2 with a version number but no date
> - myTREZOR with no version and no date and BIP44 key derivation. Some
> seeds I believe are now being generated with 24 words instead of 12.
> - MultiBit HD with no version and a date in a custom form that creates
> non-date-like codes you are expected to write down. I think BIP32 and BIP44
> are both supported (sorta).
> - GreenAddress with no version, no date and BIP32
> - Other bitcoinj based wallets, with no version and a date written down
> in normal human form, BIP32 only.
>
> I really hope we can recover from this somehow because otherwise all
> wallets will have to provide the user with a complicated matrix of
> possibilities and software combinations, and in practice many won't bother
> so these word combinations will actually end up being wallet specific for
> no particularly good reason, just very minor details like the presence or
> absence of single fields.
>
> It feels like we somehow fell flat on our faces just before the finishing
> line. This is deeply unfortunate. Compatibility and UX consistency is
> important!
>
> Currently, I don't have any bright ideas for how to get everyone back onto
> the same page with a fully compatible system that is acceptable to all. If
> anyone else has suggestions, I'm all ears.
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:31:25

- reply

📅 Original date posted:2015-03-02
📝 Original message:Great to see Electrum 2.0 tagged !
It's been a long road I know.
Congratulations to ThomasV and all the other Electrum contributors.
:-)
Jim
--
http://bitcoin-solutions.co.uk
On Mon, Mar 2, 2015, at 03:37 PM, Mike Hearn wrote:
> Congrats Thomas! Glad to see Electrum 2 finally launch.
>
>
> > * New seed derivation method (not compatible with BIP39).
>
>
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:20:05

- reply

📅 Original date posted:2014-04-25
📝 Original message:Oh dear.
For reasons that are perfectly reasonable we are close to losing any chance of intra-client HD compatibility for BIP32 wallets.
In the next 12 months there will probably be collectively millions of users of our new wallets. I don't want them to suffer from vendor lockin.
Can we not agree on a lowest common denominator that we agree to support ?
An "HD Basic" if you like.
For entry level users we can keep things simple and any "HD Basic" bitcoin will be fully interoperable.
Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it.
I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice.
On Fri, Apr 25, 2014, at 11:23 AM, Andreas Schildbach wrote:
> Does anyone use or plan to use the "wallet structure" part of the BIP32
> document?
>
> I suggest removing it from the document and maybe instead point at
> BIP43. That new specification proposal just defines a "purpose" and
> leaves everything else to the inventor of that purpose. The idea it that
> over time a standard will evolve naturally rather than top-down.
>
> https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
>
> I'd volunteer to submit a pull request if I can see some level of
> consent here.
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
http://bitcoin-solutions.co.uk

2023-06-07 17:16:23

- reply

📅 Original date posted:2014-03-27
📝 Original message:Good to hear the bip32 wallet structure is _so_ close to being standardised.
For MultiBit HD, we have put in support for 12/18/24 words but have the UI 'suggest' to use 12.
You can see this on the wallet creation wizard Gary recently blogged about:
https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html
There's a little combo for the seed length, with 12 as the default.
@Thomas. You mention gaps. We are creating new addresses on the UI in a panel marked 'Request' where the user also types in a QR code label and a note to themselves. This gets stored away as a first class 'PaymentRequest'. The UI 'suggests' that each address is used once. There will be some gaps (where the payment request is never paid) but we aren't bulk creating addresses. I am hoping this shouldn't cause Electrum a problem.
We are also storing a timestamp (the number of days since the genesis block) to help wallet restore but that is SPV specific.
On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
>
>
> Le 27/03/2014 13:49, Mike Hearn a écrit :
IP32 allows for a range of entropy sizes and it so happens that
> > they picked 256 bits instead of 128 bits.
> >
> > I'd have thought that there is a right answer for this. 2^128 should not
> > be brute forceable, and longer sizes have a cost in terms of making the
> > seeds harder to write down on paper. So should this be a degree of freedom?
> >
>
>
> Here is what I understand:
>
> 2^128 iterations is not brute forcable today, and will not be for the
> foreseeable future.
>
> An EC pubkey of length n can be forced in approximately 2^(n/2)
> iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> are 256 bits, would require 2^128 iterations. This is why unused
> addresses (160 bits hash) are better protected than already used ones.
>
> However, people tend to believe that a public key of size n requires 2^n
> iterations. This belief might have been spread by this popular image:
> https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
http://bitcoin-solutions.co.uk

2023-06-07 17:10:46

- reply

📅 Original date posted:2013-12-16
📝 Original message:Yes I saw that on reddit too.
I think it applies mainly to custom transactions rather
than where fees are calculated automatically.
Another variant of not understanding change that loses
people's bitcoins I have encountered is:
1) Import a private key of a brainwallet/ paper wallet.
2) Send a small amount of bitcoin from that key.
3) The user then secure deletes all copies of the wallet
'for security'. If they are not careful they can delete
a change address with funds on it.
In MultiBit I have tried to reduce this possibility by:
1) Hiding the ability to delete wallet (in the next version
I am removing it entirely)
2) There is always a single key in a new wallet. When
a user imports a key then that makes two. I always send
the change to the second address, if it is available.
(This is bad for privacy but at least lessens the chances
that the funds become lost).
If users are determined to use a brain wallet and
secure delete every copy of the wallet after they use
them you cannot stop them (it is their machine after all)
But these two options help lessen the chance of bitcoin
loss if they do.
For the HD version of MultiBit we are removing the import
of individual private keys entirely and only supporting HD
addresses, primarily for safety reasons.
Jim
On Mon, Dec 16, 2013, at 10:13 AM, Drak wrote:
> Not sure if this is the right place, but since a few wallet authors
> congregate here I though it might be the best place.
>
> It seems every once in a while you see stories of people accidentally
> paying huge fees. Today I read about a man who paid a 20.14BTC fee for a
> 0.05 BTC transaction[1], oops. There was another recently where someone
> paid a fee of about 200BTC which fortunately the pool operator refunded.
>
> It just occurs to me this kind of sad story could be averted if wallets
> implemented a confirmation box if the fee amount seems crazy - for example,
> if it's >10x what the default fee should be, or if it's greater than x% of
> the sending amount. "the fee seems unusually high, are you really sure you
> want to pay X in fees?"
>
> I realise the exact details of this might need to be fleshed out given we
> want flexible fees, but it should be pretty simple to agree with what looks
> like an unusually large fee according to the going rate.
>
> Drak
>
> [1]
> http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/
> ------------------------------------------------------------------------------
> 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=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
http://bitcoin-solutions.co.uk

2023-06-07 17:05:33

- reply

📅 Original date posted:2013-08-05
📝 Original message:One approach you could use would be to use bitcoin signing on
a list of the build artifacts together with their SHA256 hashes.
If you have a look at the MultiBit release notes you get the
overall idea:
https://multibit.org/releases/multibit-0.5.13/release.txt
Currently these aren't machine readable but you can imagine
having a machine readable statement with:
+ a list of the files in the build
+ their SHA256 hashes
+ the above bitcoin signed by multiple signatures e.g. 2 of 3
The client can then download the file, check the signature,
check the hashes and knows which files to download.
The acceptable Bitcoin addresses for signatures would
be a whitelist in the client code.
On Mon, Aug 5, 2013, at 05:47 PM, Alan Reiner wrote:
> Indeed. You can hardcode a "distributor" public key in the software,
> and client software will only trust signed data from that key. Of
> course, the private key for that data is not kept on the server
> distributing the signed checksums. Ideally it would be kept offline,
> and the couple-times-per-year that you actually execute an upgrade, you
> sign the new checksums offline and upload the signed checksum to the
> distribution server. Then even if the server is compromised, the
> client-side software will not accept a bogus checksum because it won't
> bear the right signature.
>
> If you do this, it would be good to also have some kind of revocation
> process that can be used in the event of the offline key being
> compromised. You won't be able to "switch" keys, as that would defeat
> the purpose (the attacker who compromises the offline key could just
> issue a replacement with his own). Instead, it would be an irreversible
> broadcast that would force clients to start rejecting updates from that
> key. If the key is compromised (and find out), you broadcast the
> revocation and the users will stop auto-updating, and be given a warning
> that they should manually upgrade the software through trusted
> channels. It's not failproof, but it's a decent way to minimize damage
> if you discover compromise early enough.
>
> -Alan
>
>
>
>
>
>
> On 08/05/2013 11:54 AM, Daniel F wrote:
> > If you want package authentication, you should at least throw in some
> > digital signing, not just a checksum. With a compromised host, both the
> > checksum and binaries can be changed undetectably, but if there's a
> > signature made by a key that is not kept on the host, there's no way to
> > fake a valid binary.
> >
> > There may be other issues people would want to bring up, but surely just
> > a checksum is not sufficient.
> >
> > on 08/05/2013 10:39 AM Wendell said the following:
> >> For usability purposes, we at Hive would like to have an
> >> auto-updater
> > in our wallet app.
> >> What is a safe way to do this? I understand that Bitcoin-QT lacks
> >> such
> > an updater for security reasons... Has been thought out in more detail
> > since that decision was made?
> >> We have been toying around with the idea of placing one server
> >> behind
> > a Tor hidden service, whose only function is to output a checksum of the
> > update package. The theory is that if it is well-secured, it will at
> > least be immune to tampering at the physical hosting level.
> >> Any thoughts or advice about any of this?
> >> -wendell
> >>
> >> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
> >>
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Get your SQL database under version control now!
> >> Version control is standard for application code, but databases havent
> >> caught up. So what steps can you take to put your SQL databases under
> >> version control? Why should you start doing it? Read more to find out.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> >>
> >>
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> > ------------------------------------------------------------------------------
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> > caught up. So what steps can you take to put your SQL databases under
> > version control? Why should you start doing it? Read more to find out.
> > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:04:29

- reply

📅 Original date posted:2013-07-09
📝 Original message:For those interested in these things the multibit.org server
is a dedicated server hosted by the German company
http://www.server4you.net.
It is physically located in the delightful city of Strasbourg,
just on the French side of the French German border.
On Tue, Jul 9, 2013, at 03:28 PM, Mike Hearn wrote:
> SourceForge has a horrible UI and blocks some countries. It also exposes
> us
> to a large and potentially hackable mirror network. Whilst we're not
> bandwidth constrained on our own servers, let's try and keep using them.
>
>
> On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> > On Tue, Jul 9, 2013 at 10:00 AM, Daniel F <nanotube at gmail.com> wrote:
> > > on 07/09/2013 06:56 AM Jim said the following:
> > >> + it will bump up the MultiBit download from about 11MB to 30-40MB
> > >> (I think). This drops the maximum copies of MultiBit the multibit.org
> > >> server can deliver per day from around 90,000 to 30,000ish.
> > >> The multibit.org server maxes out at 1 TB of bandwidth per day.
> > >
> > > You could host your downloads on sourceforge and achieve virtually
> > > unlimited capacity.
> >
> > Indeed. There is no reason to worry about download bandwidth these
> > days, for open source software downloads.
> >
> > Move the downloads to a site where such worries do not exist.
> >
> > --
> > Jeff Garzik
> > Senior Software Engineer and open source evangelist
> > BitPay, Inc. https://bitpay.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=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> ------------------------------------------------------------------------------
> 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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:04:26

- reply

📅 Original date posted:2013-07-09
📝 Original message:Currently there are about 2,500 downloads a day for MultiBit.
There are download stats here:
https://multibit.org/awstats/awstats.pl?config=multibit.org
With a mirror from Mike and perhaps another instance at
multibit.org that would get us to 100K per day so probably
nothing to worry about.
I think the highest daily download stats I have seen were in the
April 2013 'boom' where Bitcoin-QT downloads hit 30K per day as
I recall.
The 30-40 MB including a JVM is based on the download sizes for
CharlesProxy.com which does this for their Windows downloads.
The sizes are here:
http://www.charlesproxy.com/download/
This is a Java codebase too.
Yes there must be an auto-update framework (but without
ECDSA signing most likely). I haven't spent much time on this
yet.
On Tue, Jul 9, 2013, at 12:04 PM, Mike Hearn wrote:
> How many downloads/day do we see currently? I think you said it's on the
> order of a few thousand, so nowhere near 30k I'd guess. Anyway I can
> mirror
> it if we need to.
>
> The JavaFX packager is supposed to delete parts of the JVM that aren't
> used. Is the 30-40mb figure based on using that tool or something else?
> Note that you don't need to use the JFX widget toolkit to use the bundler
> tool.
>
> We could also invest in a copy of JET, which does native compilation down
> to self contained Windows binaries. It might create smaller bundles. But,
> it's a proprietary tool and I don't know how reproducible its outputs
> are.
>
> For the auto update, is there an existing auto update framework that we
> can
> modify to support threshold signed updates? I'm sure such a thing must
> exist. The updates would download in the background and then the app can
> just ask the user to restart it once the update is locally available, as
> Chrome does.
>
>
>
> On Tue, Jul 9, 2013 at 12:56 PM, Jim <jim618 at fastmail.co.uk> wrote:
>
> > Yes I would like to bundle a JVM as it would simplify the user
> > experience.
> >
> > There are a few downsides though:
> > + all the build packaging will need redoing and retesting.
> > + it will bump up the MultiBit download from about 11MB to 30-40MB
> > (I think). This drops the maximum copies of MultiBit the multibit.org
> > server can deliver per day from around 90,000 to 30,000ish.
> > The multibit.org server maxes out at 1 TB of bandwidth per day.
> >
> > Currently there is no provision to update anything automatically.
> > I would like to start having Bitcoin signed files that MultiBit can
> > check
> > and update (initially the checkpoints file, I18N files - NOT code
> > at first because of the security implications). I think this needs to be
> > in place before bundling a JVM so that users don't have to
> > keep redownloading it.
> >
> > Having lists of all the artifacts signed and them having SHA256 hashes
> > then makes it practical/ safe to start mirroring the code. I can see
> > each mirror crosschecking the others that the SHA256s are correct
> > for instance. This would increase the maximum number of
> > downloads we could cope with.
> >
> >
> > On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> > > Modern Java versions let you bundle the app with a stripped down JVM. I
> > > don't know if Jim does that, but I think it's an obvious step towards
> > > making MultiBit friendlier and easier to use.
> > >
> > > BTW I believe most secure browsers (Chrome, Firefox) have banned the
> > > applet
> > > plugin or severely restrained it anyway. So even if you install the JVM
> > > and
> > > plugin together there is not an issue.
> > >
> > >
> > > On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle <
> > > calebdelisle at lavabit.com> wrote:
> > >
> > > > Java (Applet) security is indeed abysmal but lets compare apples to
> > apples.
> > > > With an applet some random guy with a website makes up some Java code
> > and
> > > > your browser automatically executes it.
> > > > With Multibit you're only executing highly trusted code (so trusted
> > that it
> > > > handles your money).
> > > > There has almost never been a Java exploit against secure trusted code.
> > > >
> > > > The idea of discouraging use of java apps just because people would be
> > > > tricked into activating the browser plugin when installing the JVM is
> > > > probably valid but Multibit is the only reasonably complete client
> > outside
> > > > of bitcoinqt and I think client diversity is more important than
> > stamping
> > > > out java.
> > > >
> > > > Thanks,
> > > > Caleb
> > > >
> > > >
> > > > On 07/08/2013 08:22 PM, Robert Backhaus wrote:
> > > > > But... Multibit is Java. Java's security problems has made it an
> > instant
> > > > uninstall item on windows PCs for about a year now. Java exploits are a
> > > > dime a dozen.
> > > > >
> > > > > Yes, you can reduce some of the problems by manually disabling the
> > > > browser plugin, but how many users will do that?
> > > > >
> > > > > Recommending a fast SPV client as a first wallet - yes, of course.
> > > > Recommending users open such a huge attack interface on their
> > computers by
> > > > installing Java - No go. Until Multibit is provided as a compiled
> > binary
> > > > without a Java dependency, it is DOA.
> > > > >
> > > > >
> > > > > On 1 July 2013 02:39, Gary Rowe <g.rowe at froot.co.uk <mailto:
> > > > g.rowe at froot.co.uk>> wrote:
> > > > >
> > > > > 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 <jim618 at fastmail.co.uk <mailto:
> > > > jim618 at fastmail.co.uk>> wrote:
> > > > >
> > > > > Yeah "email jim' was never going to work so I have
> > > > > bumped up MultiBit support (a bit) by:
> > > > >
> > > > > + having a dedicated Support page on the website
> > > > > https://multibit.org/support.html
> > > > > It has fixes and support notes for the most common
> > gotchas.
> > > > > + the in-app help also now has a 'Support' section with
> > > > > "Troubleshooting' and the commonest gotchas.
> > > > > I've also written more help to cover as much as possible.
> > > > > + Failing that people are directed first to
> > > > bitcoin.stackchange.com <http://bitcoin.stackchange.com>
> > > > > (I have a notification set up for the 'multibit' keyword.
> > > > > + Then finally users are directed to the github issues to
> > search
> > > > > existing or raise a new issue. Gary and Tim often chip in
> > on
> > > > there to
> > > > > close
> > > > > issues down as well as me.
> > > > >
> > > > >
> > > > >
> > > > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
> > > > > > Sounds like we have consensus, Saivann, shall we do it?
> > > > > >
> > > > > > I'm also going to ask Theymos again to relax the newbie
> > > > restrictions
> > > > > > for the alt client forums. It's probably too hard to get
> > > > support at
> > > > > > the moment and "email jim" doesn't scale at all.
> > > > > >
> > > > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <
> > > > gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>>
> > > > > > wrote:
> > > > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the
> > > > recommended
> > > > > > > desktop wallet app. I think most users will be happier
> > with
> > > > it.
> > > > > > >
> > > > > > > If I'm wrong, it is easy to change back.
> > > > > > >
> > > > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > > > This SF.net email is sponsored by Windows:
> > > > > > >
> > > > > > > Build for Windows Store.
> > > > > > >
> > > > > > > http://p.sf.net/sfu/windows-dev2dev
> > > > > > > _______________________________________________
> > > > > > > Bitcoin-development mailing list
> > > > > > > Bitcoin-development at lists.sourceforge.net <mailto:
> > > > Bitcoin-development at lists.sourceforge.net>
> > > > > > >
> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > > > >
> > > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > > This SF.net email is sponsored by Windows:
> > > > > >
> > > > > > Build for Windows Store.
> > > > > >
> > > > > > http://p.sf.net/sfu/windows-dev2dev
> > > > > > _______________________________________________
> > > > > > Bitcoin-development mailing list
> > > > > > Bitcoin-development at lists.sourceforge.net <mailto:
> > > > Bitcoin-development at lists.sourceforge.net>
> > > > > >
> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > > >
> > > > >
> > > > > --
> > > > > https://multibit.org Money, reinvented
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by Windows:
> > > > >
> > > > > Build for Windows Store.
> > > > >
> > > > > http://p.sf.net/sfu/windows-dev2dev
> > > > > _______________________________________________
> > > > > Bitcoin-development mailing list
> > > > > Bitcoin-development at lists.sourceforge.net <mailto:
> > > > Bitcoin-development at lists.sourceforge.net>
> > > > >
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by Windows:
> > > > >
> > > > > Build for Windows Store.
> > > > >
> > > > > http://p.sf.net/sfu/windows-dev2dev
> > > > > _______________________________________________
> > > > > Bitcoin-development mailing list
> > > > > Bitcoin-development at lists.sourceforge.net <mailto:
> > > > Bitcoin-development at lists.sourceforge.net>
> > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > 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=48808831&iu=/4140/ostg.clktrk
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Bitcoin-development mailing list
> > > > > Bitcoin-development at lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > > >
> > > >
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > 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=48808831&iu=/4140/ostg.clktrk
> > > > _______________________________________________
> > > > Bitcoin-development mailing list
> > > > Bitcoin-development at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > >
> > >
> > ------------------------------------------------------------------------------
> > > 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=48808831&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> > --
> > https://multibit.org Money, reinvented
> >
> >
> > ------------------------------------------------------------------------------
> > 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=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
--
https://multibit.org Money, reinvented

2023-06-07 17:04:23

- reply

📅 Original date posted:2013-07-09
📝 Original message:Yes I would like to bundle a JVM as it would simplify the user
experience.
There are a few downsides though:
+ all the build packaging will need redoing and retesting.
+ it will bump up the MultiBit download from about 11MB to 30-40MB
(I think). This drops the maximum copies of MultiBit the multibit.org
server can deliver per day from around 90,000 to 30,000ish.
The multibit.org server maxes out at 1 TB of bandwidth per day.
Currently there is no provision to update anything automatically.
I would like to start having Bitcoin signed files that MultiBit can
check
and update (initially the checkpoints file, I18N files - NOT code
at first because of the security implications). I think this needs to be
in place before bundling a JVM so that users don't have to
keep redownloading it.
Having lists of all the artifacts signed and them having SHA256 hashes
then makes it practical/ safe to start mirroring the code. I can see
each mirror crosschecking the others that the SHA256s are correct
for instance. This would increase the maximum number of
downloads we could cope with.
On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> Modern Java versions let you bundle the app with a stripped down JVM. I
> don't know if Jim does that, but I think it's an obvious step towards
> making MultiBit friendlier and easier to use.
>
> BTW I believe most secure browsers (Chrome, Firefox) have banned the
> applet
> plugin or severely restrained it anyway. So even if you install the JVM
> and
> plugin together there is not an issue.
>
>
> On Tue, Jul 9, 2013 at 3:20 AM, Caleb James DeLisle <
> calebdelisle at lavabit.com> wrote:
>
> > Java (Applet) security is indeed abysmal but lets compare apples to apples.
> > With an applet some random guy with a website makes up some Java code and
> > your browser automatically executes it.
> > With Multibit you're only executing highly trusted code (so trusted that it
> > handles your money).
> > There has almost never been a Java exploit against secure trusted code.
> >
> > The idea of discouraging use of java apps just because people would be
> > tricked into activating the browser plugin when installing the JVM is
> > probably valid but Multibit is the only reasonably complete client outside
> > of bitcoinqt and I think client diversity is more important than stamping
> > out java.
> >
> > Thanks,
> > Caleb
> >
> >
> > On 07/08/2013 08:22 PM, Robert Backhaus wrote:
> > > But... Multibit is Java. Java's security problems has made it an instant
> > uninstall item on windows PCs for about a year now. Java exploits are a
> > dime a dozen.
> > >
> > > Yes, you can reduce some of the problems by manually disabling the
> > browser plugin, but how many users will do that?
> > >
> > > Recommending a fast SPV client as a first wallet - yes, of course.
> > Recommending users open such a huge attack interface on their computers by
> > installing Java - No go. Until Multibit is provided as a compiled binary
> > without a Java dependency, it is DOA.
> > >
> > >
> > > On 1 July 2013 02:39, Gary Rowe <g.rowe at froot.co.uk <mailto:
> > g.rowe at froot.co.uk>> wrote:
> > >
> > > 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 <jim618 at fastmail.co.uk <mailto:
> > jim618 at fastmail.co.uk>> wrote:
> > >
> > > Yeah "email jim' was never going to work so I have
> > > bumped up MultiBit support (a bit) by:
> > >
> > > + having a dedicated Support page on the website
> > > https://multibit.org/support.html
> > > It has fixes and support notes for the most common gotchas.
> > > + the in-app help also now has a 'Support' section with
> > > "Troubleshooting' and the commonest gotchas.
> > > I've also written more help to cover as much as possible.
> > > + Failing that people are directed first to
> > bitcoin.stackchange.com <http://bitcoin.stackchange.com>
> > > (I have a notification set up for the 'multibit' keyword.
> > > + Then finally users are directed to the github issues to search
> > > existing or raise a new issue. Gary and Tim often chip in on
> > there to
> > > close
> > > issues down as well as me.
> > >
> > >
> > >
> > > On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
> > > > Sounds like we have consensus, Saivann, shall we do it?
> > > >
> > > > I'm also going to ask Theymos again to relax the newbie
> > restrictions
> > > > for the alt client forums. It's probably too hard to get
> > support at
> > > > the moment and "email jim" doesn't scale at all.
> > > >
> > > > On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <
> > gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>>
> > > > wrote:
> > > > > I vote "yes" to have MultiBit replace Bitcoin-Qt as the
> > recommended
> > > > > desktop wallet app. I think most users will be happier with
> > it.
> > > > >
> > > > > If I'm wrong, it is easy to change back.
> > > > >
> > > > >
> > ------------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by Windows:
> > > > >
> > > > > Build for Windows Store.
> > > > >
> > > > > http://p.sf.net/sfu/windows-dev2dev
> > > > > _______________________________________________
> > > > > Bitcoin-development mailing list
> > > > > Bitcoin-development at lists.sourceforge.net <mailto:
> > Bitcoin-development at lists.sourceforge.net>
> > > > >
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > This SF.net email is sponsored by Windows:
> > > >
> > > > Build for Windows Store.
> > > >
> > > > http://p.sf.net/sfu/windows-dev2dev
> > > > _______________________________________________
> > > > Bitcoin-development mailing list
> > > > Bitcoin-development at lists.sourceforge.net <mailto:
> > Bitcoin-development at lists.sourceforge.net>
> > > >
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >
> > >
> > > --
> > > https://multibit.org Money, reinvented
> > >
> > >
> > ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by Windows:
> > >
> > > Build for Windows Store.
> > >
> > > http://p.sf.net/sfu/windows-dev2dev
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net <mailto:
> > Bitcoin-development at lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by Windows:
> > >
> > > Build for Windows Store.
> > >
> > > http://p.sf.net/sfu/windows-dev2dev
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net <mailto:
> > Bitcoin-development at lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > 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=48808831&iu=/4140/ostg.clktrk
> > >
> > >
> > >
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> ------------------------------------------------------------------------------
> 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=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:04:08

- reply

📅 Original date posted:2013-06-28
📝 Original message:There are already descriptions as you describe on:
http://bitcoin.org/en/choose-your-wallet.
If you hover over any of the wallet icons you get a description and a
link.
People being people, we find in practice that the very first wallet link
on the page is what the majority of new users click.
On Fri, Jun 28, 2013, at 09:37 PM, Bill Hees wrote:
> There are good, valid arguments in support of promoting both the
> reference
> client, Bitcoin-QT, and for offering a lighter-weight alternative. Why
> not
> outline these arguments on bitcoin.org and provide links to each; or even
> links to a variety of alternative wallet solutions alongside descriptions
> of their respective benefits and drawbacks? Is there an advantage to
> having
> a singular "recommended" client?
>
>
> On Fri, Jun 28, 2013 at 1:35 PM, Bill Hees <billhees at gmail.com> wrote:
>
> > There are good, valid arguments in support of promoting both the reference
> > client, Bitcoin-QT, and for offering a lighter-weight alternative. Why not
> > outline these arguments on bitcoin.org and provide links to each; or even
> > links to a variety of alternative wallet solutions alongside descriptions
> > of their respective benefits and drawbacks? Is there an advantage to having
> > a singular "recommended" client?
> >
> >
> > On Fri, Jun 28, 2013 at 7:24 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> >
> >> I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended
> >> desktop wallet app. I think most users will be happier with it.
> >>
> >> If I'm wrong, it is easy to change back.
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by Windows:
> >>
> >> Build for Windows Store.
> >>
> >> http://p.sf.net/sfu/windows-dev2dev
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:04:03

- reply

📅 Original date posted:2013-06-30
📝 Original message:Yeah "email jim' was never going to work so I have
bumped up MultiBit support (a bit) by:
+ having a dedicated Support page on the website
https://multibit.org/support.html
It has fixes and support notes for the most common gotchas.
+ the in-app help also now has a 'Support' section with
"Troubleshooting' and the commonest gotchas.
I've also written more help to cover as much as possible.
+ Failing that people are directed first to bitcoin.stackchange.com
(I have a notification set up for the 'multibit' keyword.
+ Then finally users are directed to the github issues to search
existing or raise a new issue. Gary and Tim often chip in on there to
close
issues down as well as me.
On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote:
> Sounds like we have consensus, Saivann, shall we do it?
>
> I'm also going to ask Theymos again to relax the newbie restrictions
> for the alt client forums. It's probably too hard to get support at
> the moment and "email jim" doesn't scale at all.
>
> On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended
> > desktop wallet app. I think most users will be happier with it.
> >
> > If I'm wrong, it is easy to change back.
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:03:59

- reply

📅 Original date posted:2013-06-27
📝 Original message:I missed Greg's point on confirmations.
It is definitely a challenge to explain/ visualize both:
+ has the transaction propagated the network ?
and
+ it it confirmed/ buried in a block ?
when those words probably don't mean much to
the intended audience.
The transaction status icons I *think* do it
(explained here:
https://multibit.org/en/help/v0.5/help_transactions.html).
It basically boils down to:
1) triangle or square : bad.
2) filling circle : good
3) tick mark : great.
On Thu, Jun 27, 2013, at 08:40 PM, Jim wrote:
> RE: 141.101.113.245
>
> http://whois.domaintools.com/141.101.113.245
> gives it as CloudFlare - I suspect it is protecting
> Mt Gox when we make our get for currency ticker info.
>
>
> On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote:
> > A few replies, in order of point raised:
> >
> > Jeff:
> > Arguments against multibit default:
> > * Less testing, field experience on desktop
> >
> > Yes this is true - downloads of multibit have typically been around
> > 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that
> > the bitcoinj networking/ object model is also used by Andreas
> > as you note.
> >
> >
> > Greg:
> > I think Mike has squashed the deadlocking problems with reentrant
> > locks (primarily in the Wallet). I haven't seen one in at least a month.
> >
> > We discussed proxy support on the bitcoinj mailing list a while ago
> > and at the time the stumbling block was the Java library used for
> > the networking (Netty) did not support it. Mike or Miron would
> > know better than I if this is still the case.
> >
> > Change address behaviour will improve significantly when HD
> > wallet support goes into multibit/ bitcoinj (I am hoping to get my
> > bit done over the summer). Matija Mazi has been working on a
> > Java impl of HD wallets so it is coming down the pipe but
> > there is a lot to do yet.
> >
> > Connections out from MultiBit are:
> > + 4 bitcoind nodes on port 8333
> > + multibit.org (188.138.113.201) for help, current version info
> > (and probably more in future)
> > + the currency ticker will make HTTP gets to the source of
> > whichever exchange(s) you have set up e.g MtGox, CampBX.
> > This calls should disappear if you switch the currency conversion
> > and ticker off.
> >
> > I think that is all the connections out I make.
> >
> > Mainly due to the exchanges abruptly changing their APIs and
> > breaking things we are planning to put in intermediate
> > "Exchange Data Provider" servers. Tim Molter is working on this
> > in his XChange project. That will enable us to patch the server
> > when things change and the multibits in the field won't be
> > affected. There will probably be a couple of these initially
> > for redundancy.
> >
> > Alex: Yes I think most users migrate to blockchain.info or,
> > more recently coinbase.com. They are both good wallets
> > but I'd like to keep Bitcoin as P2P as possible.
> >
> > Luke-Jr
> > I think you are right here on the number of full nodes versus
> > SPV nodes.
> > I don't think we even know yet what are the working ratios of
> > full nodes to SPV nodes. I haven't seen anybody do any
> > analysis on this.
> >
> > I doubt multibit will ever participate in the Bitcoin network
> > other than as an SPV client. All the optimisation is to reduce
> > data traffic - it is effectively a mobile wallet that happens to
> > live on a desktop. It is not really intended to be more than
> > "a wallet for regular people to store and spend their bitcoin".
> >
> > In English the nomenclature for direction of the transactions
> > is: "Sent to" and "Received with". To be honest I
> > haven't transliterated the localisation files to check other
> > language packs but the localisers are pretty good in my
> > experience.
> >
> >
> >
> >
> >
> > On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote:
> > > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke at dashjr.org> wrote:
> > > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
> > > >> * Very real possibility of an overall net reduction of full nodes on P2P
> > > >> network
> > > > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
> > > > MultiBit node. :/
> > > > Jim, will MultiBit be adding p2p listening support?
> > >
> > > Without validation listening isn't currently very useful. :( Maybe it
> > > could be somewhat more with some protocol additions.
> > >
> > > ------------------------------------------------------------------------------
> > > This SF.net email is sponsored by Windows:
> > >
> > > Build for Windows Store.
> > >
> > > http://p.sf.net/sfu/windows-dev2dev
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> > --
> > https://multibit.org Money, reinvented
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> https://multibit.org Money, reinvented
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:03:58

- reply

📅 Original date posted:2013-06-27
📝 Original message:RE: 141.101.113.245
http://whois.domaintools.com/141.101.113.245
gives it as CloudFlare - I suspect it is protecting
Mt Gox when we make our get for currency ticker info.
On Thu, Jun 27, 2013, at 08:18 PM, Jim wrote:
> A few replies, in order of point raised:
>
> Jeff:
> Arguments against multibit default:
> * Less testing, field experience on desktop
>
> Yes this is true - downloads of multibit have typically been around
> 1/7th to 1/5th of bitcoin-QT downloads. It helps of course that
> the bitcoinj networking/ object model is also used by Andreas
> as you note.
>
>
> Greg:
> I think Mike has squashed the deadlocking problems with reentrant
> locks (primarily in the Wallet). I haven't seen one in at least a month.
>
> We discussed proxy support on the bitcoinj mailing list a while ago
> and at the time the stumbling block was the Java library used for
> the networking (Netty) did not support it. Mike or Miron would
> know better than I if this is still the case.
>
> Change address behaviour will improve significantly when HD
> wallet support goes into multibit/ bitcoinj (I am hoping to get my
> bit done over the summer). Matija Mazi has been working on a
> Java impl of HD wallets so it is coming down the pipe but
> there is a lot to do yet.
>
> Connections out from MultiBit are:
> + 4 bitcoind nodes on port 8333
> + multibit.org (188.138.113.201) for help, current version info
> (and probably more in future)
> + the currency ticker will make HTTP gets to the source of
> whichever exchange(s) you have set up e.g MtGox, CampBX.
> This calls should disappear if you switch the currency conversion
> and ticker off.
>
> I think that is all the connections out I make.
>
> Mainly due to the exchanges abruptly changing their APIs and
> breaking things we are planning to put in intermediate
> "Exchange Data Provider" servers. Tim Molter is working on this
> in his XChange project. That will enable us to patch the server
> when things change and the multibits in the field won't be
> affected. There will probably be a couple of these initially
> for redundancy.
>
> Alex: Yes I think most users migrate to blockchain.info or,
> more recently coinbase.com. They are both good wallets
> but I'd like to keep Bitcoin as P2P as possible.
>
> Luke-Jr
> I think you are right here on the number of full nodes versus
> SPV nodes.
> I don't think we even know yet what are the working ratios of
> full nodes to SPV nodes. I haven't seen anybody do any
> analysis on this.
>
> I doubt multibit will ever participate in the Bitcoin network
> other than as an SPV client. All the optimisation is to reduce
> data traffic - it is effectively a mobile wallet that happens to
> live on a desktop. It is not really intended to be more than
> "a wallet for regular people to store and spend their bitcoin".
>
> In English the nomenclature for direction of the transactions
> is: "Sent to" and "Received with". To be honest I
> haven't transliterated the localisation files to check other
> language packs but the localisers are pretty good in my
> experience.
>
>
>
>
>
> On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote:
> > On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke at dashjr.org> wrote:
> > > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
> > >> * Very real possibility of an overall net reduction of full nodes on P2P
> > >> network
> > > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
> > > MultiBit node. :/
> > > Jim, will MultiBit be adding p2p listening support?
> >
> > Without validation listening isn't currently very useful. :( Maybe it
> > could be somewhat more with some protocol additions.
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> https://multibit.org Money, reinvented
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:03:58

- reply

📅 Original date posted:2013-06-27
📝 Original message:A few replies, in order of point raised:
Jeff:
Arguments against multibit default:
* Less testing, field experience on desktop
Yes this is true - downloads of multibit have typically been around
1/7th to 1/5th of bitcoin-QT downloads. It helps of course that
the bitcoinj networking/ object model is also used by Andreas
as you note.
Greg:
I think Mike has squashed the deadlocking problems with reentrant
locks (primarily in the Wallet). I haven't seen one in at least a month.
We discussed proxy support on the bitcoinj mailing list a while ago
and at the time the stumbling block was the Java library used for
the networking (Netty) did not support it. Mike or Miron would
know better than I if this is still the case.
Change address behaviour will improve significantly when HD
wallet support goes into multibit/ bitcoinj (I am hoping to get my
bit done over the summer). Matija Mazi has been working on a
Java impl of HD wallets so it is coming down the pipe but
there is a lot to do yet.
Connections out from MultiBit are:
+ 4 bitcoind nodes on port 8333
+ multibit.org (188.138.113.201) for help, current version info
(and probably more in future)
+ the currency ticker will make HTTP gets to the source of
whichever exchange(s) you have set up e.g MtGox, CampBX.
This calls should disappear if you switch the currency conversion
and ticker off.
I think that is all the connections out I make.
Mainly due to the exchanges abruptly changing their APIs and
breaking things we are planning to put in intermediate
"Exchange Data Provider" servers. Tim Molter is working on this
in his XChange project. That will enable us to patch the server
when things change and the multibits in the field won't be
affected. There will probably be a couple of these initially
for redundancy.
Alex: Yes I think most users migrate to blockchain.info or,
more recently coinbase.com. They are both good wallets
but I'd like to keep Bitcoin as P2P as possible.
Luke-Jr
I think you are right here on the number of full nodes versus
SPV nodes.
I don't think we even know yet what are the working ratios of
full nodes to SPV nodes. I haven't seen anybody do any
analysis on this.
I doubt multibit will ever participate in the Bitcoin network
other than as an SPV client. All the optimisation is to reduce
data traffic - it is effectively a mobile wallet that happens to
live on a desktop. It is not really intended to be more than
"a wallet for regular people to store and spend their bitcoin".
In English the nomenclature for direction of the transactions
is: "Sent to" and "Received with". To be honest I
haven't transliterated the localisation files to check other
language packs but the localisers are pretty good in my
experience.
On Thu, Jun 27, 2013, at 07:41 PM, Gregory Maxwell wrote:
> On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr <luke at dashjr.org> wrote:
> > On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
> >> * Very real possibility of an overall net reduction of full nodes on P2P
> >> network
> > Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
> > MultiBit node. :/
> > Jim, will MultiBit be adding p2p listening support?
>
> Without validation listening isn't currently very useful. :( Maybe it
> could be somewhat more with some protocol additions.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
https://multibit.org Money, reinvented

2023-06-07 17:03:57

- reply

📅 Original date posted:2013-06-27
📝 Original message:Hello Everybody,
Over the last few months we have been steadily adding
functionality to MultiBit including:
+ encrypted wallets
+ sign and verify message
+ stability improvements and bug fixes.
As a result of these efforts I think MultiBit is now
suitable for the entry level Bitcoin user. I propose
that we put MultiBit as the default desktop client
on the bitcoin.org "Choose your wallet" page.
I think a typical new user comes to bitcoin.org from a
google search or a Bitcoin news article. We want them to
peruse the bitcoin.org site and try out a wallet. They
should be able to get MultiBit up and running in a tea break.
Then perhaps they get a colleague to send them some bitcoin
from an Android phone by zapping a QR code.
We say: "Welcome to the Bitcoin economy !"
There is plenty MultiBit cannot do of course. However if
in the first ten minutes we get the new user interested
there is a good chance they will go on to explore other
Bitcoin wallets and solutions.
Let me know if you think this is a good idea (or not!)
and if you have any questions.
Jim
https://multibit.org

2023-06-07 12:46:40

- reply

📅 Original date posted:2012-12-04
📝 Original message:I think Alan's list of 'what should an ideal first client look like' is
right here.
>From the first time user's perspective if they can get up and running
relatively quickly but still have the safety of a deterministic wallet
then they should have a good first user experience. MultiBit is not
there yet, but BIP32 support is on the roadmap.
If we have a 'shopping list' of what we want in a first client then that
gives me (and others) a list of what to focus on implementing.
Also, as BIP32 support is added to clients and codebases then the actual
variant of software to use to access your wallet will become relatively
less important. Combined with a standardised seed -> passphrase
algorithm the user can just type in their long passphrase into any BIP32
compliant software and click/ buzz/ whirr : there is their wallet. We
should have a little logo for HD wallet compliance ! :-)
As Bitcoin's users become more varied there will be a spectrum of how
'involved' they want to be computationally so we should have offerings
to reflect this.
On Tue, Dec 4, 2012, at 07:09 PM,
bitcoin-development-request at lists.sourceforge.net wrote:
> Send Bitcoin-development mailing list submissions to
> bitcoin-development at lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> or, via email, send a message with subject or body 'help' to
> bitcoin-development-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> bitcoin-development-owner at lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bitcoin-development digest..."
>
>
> Today's Topics:
>
> 1. Re: Roadmap to getting users onto SPV clients (Alan Reiner)
> 2. Re: Roadmap to getting users onto SPV clients (Gregory Maxwell)
> 3. Re: Roadmap to getting users onto SPV clients (Mark Friedenbach)
> 4. Re: Roadmap to getting users onto SPV clients (Will)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 4 Dec 2012 13:03:11 -0500
> From: Alan Reiner <etotheipi at gmail.com>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> clients
> To: Mike Hearn <mike at plan99.net>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Message-ID:
> <CALf2ePzFZLmQ2+0hmOO0m_=EFy5mOtJ22jy2CYMxmU5U5e3s1w at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> My personal opinion is that the ideal first client has three features:
>
> (1) Starts up and is usable within a couple minutes (even 10 min the
> first
> time would be okay, to sync block headers)
> (2) Supports Windows, Linux and OSX
> (3) Uses deterministic wallets that can produce a permanent backup
> (preferably paper)
>
> Encryption is a major upside, too, but people new enough to Bitcoin that
> they need such a simple client, can survive without encryption (thye're
> not
> going to be holding a ton of coins) -- as long as they are made aware
> that
> they do not currently have encryption, and the associated risks (and
> other
> options).
>
> I think it's extremely important that users have a clear way to backup
> their coins to offline media or paper, in such a way that they don't ever
> need to worry about it again. Not only does it give users protection
> against hard-drive loss, it means that they may find it again in the far
> future when they haven't used Bitcoin in 2 years, and it reminds them
> that
> they still have coins (and they don't have to type in 1000 private keys
> to
> get their coins)
>
> For that reason, I think Multibit is an excellent choice. I haven't
> spent
> much time with it, but I do understand it to satisfy (1) and (2)
> clearly,
> and (3) may be happening in the near future (along with encryption). But
> I
> do wonder if it has enough staffing behind it to be the center of
> attention
> (no offense to jim618, but if this becomes the "de-facto" client for new
> users, we should make sure there's a lot of people available to support
> it
> -- what if a major security bug is found? how long would it take the
> current team to identify, fix and test that bug?)
>
> -Alan
>
>
> On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <mike at plan99.net> wrote:
>
> > At the moment if you visit bitcoin.org then you're recommended to
> > download the full client. I think we all agree that at some point we
> > need to start presenting users with something more like this:
> >
> >
> > To get started, download wallet apps A or B.
> >
> > If you'd like to contribute your computing resources to the Bitcoin
> > network and have a fast computer with an unfiltered internet
> > connection, download:
> >
> > - for desktop machines, Bitcoin-Qt
> > - for servers, bitcoind
> >
> >
> >
> > Obviously not that exact wording.
> >
> > I personally feel it's a bit early for this, but it's true that users
> > are being turned away by the fact that they're pointed to Bitcoin-Qt
> > by default, so having some kind of roadmap or plan for changing that
> > would be good.
> >
> > I think MultiBit is maturing into a client that I'd feel comfortable
> > recommending to end users who take the fast-start path, though it
> > still has a few serious lacks (encrypted wallets aren't released yet,
> > bloom filters will help performance a lot, needs to catch up with some
> > newer features). But there doesn't have to be a one true client.
> >
> > The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> > not convinced this is the best use of time, but if somebody steps up
> > to do it, that could also work. MultiBit has some unique features that
> > are quite useful like integrating charting and exchange rate feeds.
> >
> > What does everyone think on this?
> >
> >
> > ------------------------------------------------------------------------------
> > 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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 4 Dec 2012 13:17:42 -0500
> From: Gregory Maxwell <gmaxwell at gmail.com>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> clients
> To: Mike Hearn <mike at plan99.net>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Message-ID:
> <CAAS2fgQYV7aR86QOwvqMLpFZ+MAwSOSZvV6XuZdXvqjeYziRng at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn <mike at plan99.net> wrote:
> > The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> > not convinced this is the best use of time, but if somebody steps up
> > to do it, that could also work.
>
> I strongly believe that if community leads with client software which
> is not a full _capable_ node (e.g. which can begin life as a SPV node
> but at least eventually become full if the system resources permit)
> then Bitcoin will fail, or at least fail to be anything but the
> world's most inefficient centralized payment system. Obviously SPV
> nodes are excellent tools for getting bitcoin into less capable
> systems, but they aren't a general replacement for the software the
> participants in Bitcoin run.
>
> ? Because the properties promised by the system can not be upheld if
> there is only a fairly small number of self selecting nodes enforcing
> the rules. If we wanted a system where its security against theft,
> denial of service, and non-inflation were governed by the consensus of
> {mtgox,blockchain.info, deepbit, bitpay, slush, btcguild, bitminter}
> we could have something infinitely more scalable by just using
> something OT like with a simple O(N) consensus between these parties.
> No disrespect intended to any of these services? but a system whos
> rules were only enforced at the good graces of a small number of
> interested parties is not what the users of bitcoin signed up for.
>
> People obviously care about supporting the goals and security of a the
> system they use but actions speak louder than words. If a
> non-validating node is promoted then we're telling people that it's
> not important that many people run them. If running a full node
> requires using different software (with a different interface) or a
> much more painful initialization than another promoted option then it
> will be correctly perceived as costly. If people perceive it to be
> both costly and not important then rational participants will not run
> it. The result will be fragile to non-existent security, where
> dishonest or exploitative parties benefit from running all the full
> nodes until they start ripping people off and shift the equilibrium
> just a little towards running costly nodes.
>
> It sounds to me that you're insisting that you're asking people who
> oppose degrading our recommendations to commit to a costly rushed
> development timeline. I think this is a false choice.
>
> There is no set timeline for the adoption of Bitcoin? man has survived
> eons without Bitcoin just fine? and there are many practical reasons
> why slow adoption is beneficial, including reducing the harm users
> experience from growing pains. By allowing things to mature at their
> own pace we can preserve the principles that make the system valuable.
>
> If the new user experience is sufficiently bad (and I agree it's bad,
> esp with the current release versions of Bitcoin-Qt) then that should
> justify more support of work that improves it without compromising the
> system. If it's not bad enough to apply those resources, then it's not
> bad enough to justify compromising it: as this sort of change is hard
> to reverse.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 4 Dec 2012 10:57:40 -0800
> From: Mark Friedenbach <mark at monetize.io>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> clients
> To: Mike Hearn <mike at plan99.net>
> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Message-ID:
> <CACh7GpHUE2CYAMfRdAVPv1WAk102z94KYCWPV87fzzQEaP_hfw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Alan's UTxO meta-chain proposal becomes vastly easier to do now that
> ultraprune is merged. That would allow the Satoshi client to know it's
> wallet balance and operate with a >=SPV level of security during the
> initial block download, and keep them on the path of becoming a full
> node.
> If users can see their balances, send and receive transactions, and
> otherwise go about their business (except for mining) during the initial
> block download, would that not address your concerns?
>
> IMHO the only time bitcoin.org should recommend a SPV-only client is when
> it is dynamically when it is being accessed from a mobile device, but
> that's a separate issue.
>
> Mark
>
>
> On Tue, Dec 4, 2012 at 9:46 AM, Mike Hearn <mike at plan99.net> wrote:
>
> > At the moment if you visit bitcoin.org then you're recommended to
> > download the full client. I think we all agree that at some point we
> > need to start presenting users with something more like this:
> >
> >
> > To get started, download wallet apps A or B.
> >
> > If you'd like to contribute your computing resources to the Bitcoin
> > network and have a fast computer with an unfiltered internet
> > connection, download:
> >
> > - for desktop machines, Bitcoin-Qt
> > - for servers, bitcoind
> >
> >
> >
> > Obviously not that exact wording.
> >
> > I personally feel it's a bit early for this, but it's true that users
> > are being turned away by the fact that they're pointed to Bitcoin-Qt
> > by default, so having some kind of roadmap or plan for changing that
> > would be good.
> >
> > I think MultiBit is maturing into a client that I'd feel comfortable
> > recommending to end users who take the fast-start path, though it
> > still has a few serious lacks (encrypted wallets aren't released yet,
> > bloom filters will help performance a lot, needs to catch up with some
> > newer features). But there doesn't have to be a one true client.
> >
> > The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> > not convinced this is the best use of time, but if somebody steps up
> > to do it, that could also work. MultiBit has some unique features that
> > are quite useful like integrating charting and exchange rate feeds.
> >
> > What does everyone think on this?
> >
> >
> > ------------------------------------------------------------------------------
> > 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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Tue, 4 Dec 2012 18:08:01 +0000
> From: Will <will at phase.net>
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
> clients
> To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
> Message-ID:
> <CAHQs=o72Q3_DXmg80KtJzJgRMVcG+S3HJnseR_yxmWOFVEqnLg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> ...or should we be directing people to a (vetted) list of cloud services
> -
> I think this has a significantly lower entry cost than any client. I know
> the mybitcoin debacle has clouded (pun intended) people's views of these
> providers, but blockchain.info (for example) really does seem quite well
> engineered, and satisfies many of the features in particular a very low
> cost of entry, cross platform support and what appears to be very good
> security (e.g. two factor)
>
> Will
>
> On 4 December 2012 17:46, Mike Hearn <mike at plan99.net> wrote:
>
> > At the moment if you visit bitcoin.org then you're recommended to
> > download the full client. I think we all agree that at some point we
> > need to start presenting users with something more like this:
> >
> >
> > To get started, download wallet apps A or B.
> >
> > If you'd like to contribute your computing resources to the Bitcoin
> > network and have a fast computer with an unfiltered internet
> > connection, download:
> >
> > - for desktop machines, Bitcoin-Qt
> > - for servers, bitcoind
> >
> >
> >
> > Obviously not that exact wording.
> >
> > I personally feel it's a bit early for this, but it's true that users
> > are being turned away by the fact that they're pointed to Bitcoin-Qt
> > by default, so having some kind of roadmap or plan for changing that
> > would be good.
> >
> > I think MultiBit is maturing into a client that I'd feel comfortable
> > recommending to end users who take the fast-start path, though it
> > still has a few serious lacks (encrypted wallets aren't released yet,
> > bloom filters will help performance a lot, needs to catch up with some
> > newer features). But there doesn't have to be a one true client.
> >
> > The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> > not convinced this is the best use of time, but if somebody steps up
> > to do it, that could also work. MultiBit has some unique features that
> > are quite useful like integrating charting and exchange rate feeds.
> >
> > What does everyone think on this?
> >
> >
> > ------------------------------------------------------------------------------
> > 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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> End of Bitcoin-development Digest, Vol 19, Issue 7
> **************************************************
--
http://multibit.org Money, reinvented

2023-06-07 12:22:08

- reply

📅 Original date posted:2012-07-09
📝 Original message:I think we are all so familiar with Bitcoin that we forget how daunting
and confusing it all is to new users. The clients page does a good job
in explaining that there are various pieces of software that they (the
new user) can use with their bitcoins.
It also helps with the question "Who can I trust ?"
By having the clients on a link from the "mothership" of bitcoin.org it
gives credence to all of the alt clients.
This last point is a good reason to only include open source clients
IMHO.
RE: The position randomisation - I have to admit I was secretly pleased
with the original layout, as MultiBit just happened to have the "eye
candy" position of "top and centre". It is only fair to have them
switch around.
--
http://multibit.org Money, reinvented

2023-06-07 12:07:31

- reply

📅 Original date posted:2012-05-02
📝 Original message:Hi Amir,
I am fine with the MultiBit description (+ subsequent suggestions like taking the language text out).
Looking forward to seeing it on the bitcoin.org site.
Jim
jim618 at fastmail.co.uk