his message was created with 100% recycled electrons. Please think twice
before printing.*
On Mon, Jun 1, 2015 at 2:02 PM, Stephen Morse
wrote:
> This exact question came up on the Bitcoin Stack Exchange once. I gave an
> answer here:
> http://bitcoin.stackexchange.com/questions/37292/whats-t
Ok, I understand at least some of the reason that blocks have to be kept to
a certain size. I get that blocks which are too big will be hard to
propagate by relays. Miners will have more trouble uploading the large
blocks to the network once they've found a hash. We need block size
constraints to c
0, 5, or 2. I feel like most people would bank for 10 or 5,
> both of which change the supply curve due to truncation.
>
> Again, it's a trivial concern, but probably one that should be addressed.
> On May 25, 2015 11:52 PM, "Jim Phillips" wrote:
>
>> Incidentally,
w milliseconds on any but the most densely populated LANs.
>
>
> On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> > Is there any work being done on using some kind of zero-conf service
> > discovery protocol so that lightweight clients can find a full node on
> the
Is there any work being done on using some kind of zero-conf service
discovery protocol so that lightweight clients can find a full node on the
same LAN to peer with rather than having to tie up WAN bandwidth?
I envision a future where lightweight devices within a home use SPV over
WiFi to connect
he company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
On Mon, May 25, 2015 at 10:23 PM, Jim Phillips wrote:
> I don't see how the fact that my 2Mbps connection causes me to not be a
> very good relay
l park. Aim for the company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle
wrote:
> Indeed Jim, your internet connection makes a good reason why I don't
>
b block, then you still see the same propagation times today and
> just increase the transaction throughput.
> --
> From: Jim Phillips
> Sent: 26/05/2015 12:27 PM
> To: Mike Hearn
> Cc: Bitcoin Dev
> Subject: Re: [Bitcoin-development] No Bitcoin For Yo
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn wrote:
This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
> right now, but I showed years ago that you could keep up with VISA on a
> single well specced server with today's technology. Only people living in a
> dreamworld think
TXOs in my wallet,
> I can make multiple spends within the same block.
>
>
> On Saturday, 9 May 2015, at 12:09 pm, Jim Phillips wrote:
> > Forgive me if this idea has been suggested before, but I made this
> > suggestion on reddit and I got some feedback recommending I also br
nlikely to ever be paid by those who can afford them. We can reassess the
>> role age plays later. One change at a time is better.
>> On 9 May 2015 12:52 pm, Jim Phillips wrote:
>>
>> On Sat, May 9, 2015 at 2:43 PM, Raystonn wrote:
>>
>> How about th
On Sat, May 9, 2015 at 2:43 PM, Raystonn wrote:
> How about this as a happy medium default policy: Rather than select UTXOs
>> based solely on age and limiting the size of the transaction, we select as
>> many UTXOs as possible from as few addresses as possible, prioritizing
>> which addresses to
On Sat, May 9, 2015 at 2:25 PM, Raystonn wrote:
> Lack of privacy is viral. We shouldn't encourage policy in most wallets
> that discourages privacy. It adversely affects privacy across the entire
> network.
>
How about this as a happy medium default policy: Rather than select UTXOs
based solel
On Sat, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) <
patrick.mcco...@newcastle.ac.uk> wrote:
> Not necessarily. If you want to ensure privacy, you could limit the
> selection of UTXOs to a single address, and even go so far as to send
> change back to that same address. This wouldn't be as ef
On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille
wrote:
> It's a very complex trade-off, which is hard to optimize for all use
> cases. Using more UTXOs requires larger transactions, and thus more fees in
> general.
>
Unless the miner determines that the reduction in UTXO storage requirements
is wor
On Sat, May 9, 2015 at 2:00 PM, Andreas Schildbach
wrote:
> Actually your assumption is wrong. Bitcoin Wallet (and I think most, if
> not all, other bitcoinj based wallets) picks UTXO by age, in order to
> maximize priority. So it keeps the number of UTXOs low, though not as
> low as if it would
On Sat, May 9, 2015 at 1:45 PM, Peter Todd wrote:
> On Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote:
> > The vast majority of users are running one of a handful of different
> wallet
> > apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;
> &
Forgive me if this idea has been suggested before, but I made this
suggestion on reddit and I got some feedback recommending I also bring it
to this list -- so here goes.
I wonder if there isn't perhaps a simpler way of dealing with UTXO growth.
What if, rather than deal with the issue at the prot
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 de
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 finall
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 ag
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-
gle character, would be very common. At the very
least, a transposition could be corrected by interleaving the two
"halves of the coded representation", e.g.:
ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB
insead of
AAABBB
ividual 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 ev
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 read
at 4:06 PM, Jeff Garzik wrote:
>
> > On Tue, Jul 9, 2013 at 10:00 AM, Daniel F 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 c
d 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 wrote:
>
> > Yes I would like to bundle a JVM as it would simplify the user
> > experience.
> >
> > Ther
p 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 an
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 'Suppor
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.
*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://wh
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:
> Argum
k 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 li
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
--
this doesn't belong to the bitcoin-development email list. I just
see this as end-user/customer data gathering to refine the requirements,
since this is software engineering...isn't it?
Jim
On Tue, Dec 4, 2012 at 6:54 PM, Gregory Maxwell wrote:
> On Tue, Dec 4, 2012 at 9:08 PM, Alan
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
ther
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 tr
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
jim...@fastmail.co.uk
--
Live Security Virtual
38 matches
Mail list logo
