Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

[Jim Phillips]

#x27;t bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This 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-the-purpose-of-a-maximum-block-size/37303#37303
>
> On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips  wrote:
>
>> 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 create a fee economy for the miners.
>>
>> But these all sound to me like issues that affect some, but not others.
>> So it seems to me like it ought to be a configurable setting. We've already
>> witnessed with last week's stress test that most miners aren't even
>> creating 1MB blocks but are still using the software defaults of 730k. If
>> there are configurable limits, why does there have to be a hard limit?
>> Can't miners just use the configurable limit to decide what size blocks
>> they can afford to and are thus willing to create? They could just as
>> easily use that to create a fee economy. If the miners with the most
>> hashpower are not willing to mine blocks larger than 1 or 2 megs, then they
>> are able to slow down confirmations of transactions. It may take several
>> blocks before a miner willing to include a particular transaction finds a
>> block. This would actually force miners to compete with each other and find
>> a block size naturally instead of having it forced on them by the protocol.
>> Relays would be able to participate in that process by restricting the
>> miners ability to propagate large blocks. You know, like what happens in a
>> FREE MARKET economy, without burdensome regulation which can be manipulated
>> through politics? Isn't that what's really happening right now? Different
>> political factions with different agendas are fighting over how best to
>> regulate the Bitcoin protocol.
>>
>> I know the limit was originally put in place to prevent spamming. But
>> that was when we were mining with CPUs and just beginning to see the
>> occasional GPU which could take control over the network and maliciously
>> spam large blocks. But with ASIC mining now catching up to Moore's Law,
>> that's not really an issue anymore. No one malicious entity can really just
>> take over the network now without spending more money than it's worth --
>> and that's just going to get truer with time as hashpower continues to
>> grow. And it's not like the hard limit really does anything anymore to
>> prevent spamming. If a spammer wants to create thousands or millions of
>> transactions, a hard limit on the block size isn't going to stop him..
>> He'll just fill up the mempool or UTXO database instead of someone's block
>> database.. And block storage media is generally the cheapest storage.. I
>> mean they could be written to tape and be just as valid as if they're
>> stored in DRAM. Combine that with pruning, and block storage costs are
>> almost a non-issue for anyone who isn't running an archival node.
>>
>> And can't relay nodes just configure a limit on the size of blocks they
>> will relay? Sure they'd still need to download a big block occasionally,
>> but that's not really that big a deal, and they're under no obligation to
>> propagate it.. Even if it's a 2GB block, it'll get downloaded eventually.
>> It's only if it gets to the point where the average home connection is too
>> slow to keep up with the transaction & block flow that there's any real
>> issue there, and that would happen regardless of how big the blocks are. I
>> personally would much prefer to see hardware limits act as the bottleneck
>> than to introduce an artificial bottleneck into the protocol that has to be
>> adjusted regularly. The software and protocol are TECHNICALLY capable of
>> scaling to handle the world's entire transaction set. The real issue with
>> scaling to this size is limitations on hardware, which are regulated by
>> Moore's Law. Why do we need arbitrary soft limits? Why can't we allow
>> Bitcoin to grow naturally within the ever increasing limits of our
>> hardware? Is it because nobody will ever nee

[Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?

[Jim Phillips]

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 create a fee economy for the miners.

But these all sound to me like issues that affect some, but not others. So
it seems to me like it ought to be a configurable setting. We've already
witnessed with last week's stress test that most miners aren't even
creating 1MB blocks but are still using the software defaults of 730k. If
there are configurable limits, why does there have to be a hard limit?
Can't miners just use the configurable limit to decide what size blocks
they can afford to and are thus willing to create? They could just as
easily use that to create a fee economy. If the miners with the most
hashpower are not willing to mine blocks larger than 1 or 2 megs, then they
are able to slow down confirmations of transactions. It may take several
blocks before a miner willing to include a particular transaction finds a
block. This would actually force miners to compete with each other and find
a block size naturally instead of having it forced on them by the protocol.
Relays would be able to participate in that process by restricting the
miners ability to propagate large blocks. You know, like what happens in a
FREE MARKET economy, without burdensome regulation which can be manipulated
through politics? Isn't that what's really happening right now? Different
political factions with different agendas are fighting over how best to
regulate the Bitcoin protocol.

I know the limit was originally put in place to prevent spamming. But that
was when we were mining with CPUs and just beginning to see the occasional
GPU which could take control over the network and maliciously spam large
blocks. But with ASIC mining now catching up to Moore's Law, that's not
really an issue anymore. No one malicious entity can really just take over
the network now without spending more money than it's worth -- and that's
just going to get truer with time as hashpower continues to grow. And it's
not like the hard limit really does anything anymore to prevent spamming.
If a spammer wants to create thousands or millions of transactions, a hard
limit on the block size isn't going to stop him.. He'll just fill up the
mempool or UTXO database instead of someone's block database.. And block
storage media is generally the cheapest storage.. I mean they could be
written to tape and be just as valid as if they're stored in DRAM. Combine
that with pruning, and block storage costs are almost a non-issue for
anyone who isn't running an archival node.

And can't relay nodes just configure a limit on the size of blocks they
will relay? Sure they'd still need to download a big block occasionally,
but that's not really that big a deal, and they're under no obligation to
propagate it.. Even if it's a 2GB block, it'll get downloaded eventually.
It's only if it gets to the point where the average home connection is too
slow to keep up with the transaction & block flow that there's any real
issue there, and that would happen regardless of how big the blocks are. I
personally would much prefer to see hardware limits act as the bottleneck
than to introduce an artificial bottleneck into the protocol that has to be
adjusted regularly. The software and protocol are TECHNICALLY capable of
scaling to handle the world's entire transaction set. The real issue with
scaling to this size is limitations on hardware, which are regulated by
Moore's Law. Why do we need arbitrary soft limits? Why can't we allow
Bitcoin to grow naturally within the ever increasing limits of our
hardware? Is it because nobody will ever need more than 640k of RAM?

Am I missing something here? Is there some big reason that I'm overlooking
why there has to be some hard-coded limit on the block size that affects
the entire network and creates ongoing issues in the future?

--

*James G. Phillips IV*


*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] No Bitcoin For You

[Jim Phillips]

I think all the suggestions recommending cutting the block time down also
suggest reducing the rewards to compensate.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*

On Tue, May 26, 2015 at 12:43 AM, gabe appleton 
wrote:

> Sync time wouldn't be longer compared to 20MB, it would (eventually) be
> longer under either setup.
>
> Also, and this is probably a silly concern, but wouldn't changing block
> time change the supply curve? If we cut the rate in half or a power of two,
> that affects nothing, but if we want to keep it in round numbers, we need
> to do it by 10, 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, even once we have the "Internet of Things" brought on by
>> 21, Inc. or whoever beats them to it, I would expect the average home to
>> have only a single full node "hub" receiving the blockchain and
>> broadcasting transactions created by all the minor SPV connected devices
>> running within the house. The in-home full node would be peered with high
>> bandwidth full-node relays running at the ISP or in the cloud. There are
>> more than enough ISPs and cloud compute providers in the world such that
>> there should be no concern at all about centralization of relays. Full
>> nodes could some day become as ubiquitous on the Internet as authoritative
>> DNS servers. And just like DNS servers, if you don't trust the nodes your
>> ISP creates or it's too slow or censors transactions, there's nothing
>> preventing you from peering with nodes hosted by the Googles or OpenDNSs
>> out there, or running your own if you're really paranoid and have a few
>> extra bucks for a VPS.
>>
>> --
>> *James G. Phillips IV*
>> <https://plus.google.com/u/0/113107039501292625391/posts>
>> <http://www.linkedin.com/in/ergophobe>
>>
>> *"Don't bunt. Aim out of the ball 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: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 has any bearing on whether or not the network as a whole
>>> would be negatively impacted by a 20MB block. My inability to rapidly
>>> propagate blocks doesn't really harm the network. It's only if MOST relays
>>> are as slow as mine that it creates an issue. I'm one node in thousands
>>> (potentially tens or hundreds of thousands if/when Bitcoin goes
>>> mainstream). And I'm an individual. There's no reason at all for me to run
>>> a full node from my home, except to have my own trusted and validated copy
>>> of the blockchain on a computer I control directly. I don't need to act as
>>> a relay for that and as long as I can download blocks faster than they are
>>> created I'm fine. Also, I can easily afford a VPS server or several to run
>>> full nodes as relays if I am feeling altruistic. It's actually cheaper for
>>> me to lease a VPS than to keep my own home PC on 24/7, which is why I have
>>> 2 of them.
>>>
>>> And as a business, the cost of a server and bandwidth to run a full node
>>> is a drop in the bucket. I'm involved in several projects where we have
>>> full nodes running on leased servers with multiple 1Gbps connections. It's
>>> an almost zero cost. Those nodes could handle 20MB blocks today without
>>> thinking about it, and I'm sure our nodes are just a few amongst thousands
>>> just like them. I'm not at all concerned about the network being too
>>> centralized.
>>>
>>> What concerns me is the fact that we are using edge cases like my home
>>> PC as a lame excuse to debate expanding the capacity of the network.
>>>
>>> --
>>> *James G. Phillips IV*
>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>> <http://www.linkedin.com/in/ergophobe>
>>>
>>> *&

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

[Jim Phillips]

Do any wallets actually do this yet?
On May 25, 2015 11:37 PM, "Matt Whitlock"  wrote:

> This is very simple to do. Just ping the "all nodes" address (ff02::1) and
> try connecting to TCP port 8333 of each node that responds. Shouldn't take
> but more than a few 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
> > 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 with a home server which in turn relays the transactions
> > they create out to the larger and faster relays on the Internet.
> >
> > In a situation where there are hundreds or thousands of small SPV devices
> > in a single home (if 21, Inc. is successful) monitoring the blockchain,
> > this could result in lower traffic across the slow WAN connection.  And
> > yes, I realize it could potentially take a LOT of these devices before
> the
> > total bandwidth is greater than downloading a full copy of the
> blockchain,
> > but there's other reasons to host your own full node -- trust being one.
> >
> > --
> > *James G. Phillips IV*
> > <https://plus.google.com/u/0/113107039501292625391/posts>
> > <http://www.linkedin.com/in/ergophobe>
> >
> > *"Don't bunt. Aim out of the ball park. Aim for the company of
> immortals."
> > -- David Ogilvy*
> >
> >  *This message was created with 100% recycled electrons. Please think
> twice
> > before printing.*
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Zero-Conf for Full Node Discovery

[Jim Phillips]

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 with a home server which in turn relays the transactions
they create out to the larger and faster relays on the Internet.

In a situation where there are hundreds or thousands of small SPV devices
in a single home (if 21, Inc. is successful) monitoring the blockchain,
this could result in lower traffic across the slow WAN connection.  And
yes, I realize it could potentially take a LOT of these devices before the
total bandwidth is greater than downloading a full copy of the blockchain,
but there's other reasons to host your own full node -- trust being one.

--
*James G. Phillips IV*



*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] No Bitcoin For You

[Jim Phillips]

Incidentally, even once we have the "Internet of Things" brought on by 21,
Inc. or whoever beats them to it, I would expect the average home to have
only a single full node "hub" receiving the blockchain and broadcasting
transactions created by all the minor SPV connected devices running within
the house. The in-home full node would be peered with high bandwidth
full-node relays running at the ISP or in the cloud. There are more than
enough ISPs and cloud compute providers in the world such that there should
be no concern at all about centralization of relays. Full nodes could some
day become as ubiquitous on the Internet as authoritative DNS servers. And
just like DNS servers, if you don't trust the nodes your ISP creates or
it's too slow or censors transactions, there's nothing preventing you from
peering with nodes hosted by the Googles or OpenDNSs out there, or running
your own if you're really paranoid and have a few extra bucks for a VPS.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball 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: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 has any bearing on whether or not the network as a whole
> would be negatively impacted by a 20MB block. My inability to rapidly
> propagate blocks doesn't really harm the network. It's only if MOST relays
> are as slow as mine that it creates an issue. I'm one node in thousands
> (potentially tens or hundreds of thousands if/when Bitcoin goes
> mainstream). And I'm an individual. There's no reason at all for me to run
> a full node from my home, except to have my own trusted and validated copy
> of the blockchain on a computer I control directly. I don't need to act as
> a relay for that and as long as I can download blocks faster than they are
> created I'm fine. Also, I can easily afford a VPS server or several to run
> full nodes as relays if I am feeling altruistic. It's actually cheaper for
> me to lease a VPS than to keep my own home PC on 24/7, which is why I have
> 2 of them.
>
> And as a business, the cost of a server and bandwidth to run a full node
> is a drop in the bucket. I'm involved in several projects where we have
> full nodes running on leased servers with multiple 1Gbps connections. It's
> an almost zero cost. Those nodes could handle 20MB blocks today without
> thinking about it, and I'm sure our nodes are just a few amongst thousands
> just like them. I'm not at all concerned about the network being too
> centralized.
>
> What concerns me is the fact that we are using edge cases like my home PC
> as a lame excuse to debate expanding the capacity of the network.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball 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
>> like 20mb blocks (right now). It would take you well over a minute to
>> download the block before you could even relay it on, so much slow down in
>> propagation! Yes I do see how decreasing the time to create blocks is a bit
>> of a band-aid fix, and to use tge term I've seen mentioned here "kicking
>> the can down the road" I agree that this is doing this, however as you say
>> bandwidth is our biggest enemy right now and so hopefully by the time we
>> exceed the capacity gained by the decrease in block time, we can then look
>> to bump up block size because hopefully 20mbps connections will be baseline
>> by then etc.
>>  --
>> From: Jim Phillips 
>> Sent: ‎26/‎05/‎2015 12:53 PM
>> To: Thy Shizzle 
>> Cc: Mike Hearn ; Bitcoin Dev
>> 
>>
>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>
>>  Frankly I'm good with either way. I'm definitely in favor of faster
>> confirmation times.
>>
>>  The important thing is that we need to increase the amount of
>> transactions that get into blocks over a given time frame to a point that
>> is in line with what current technology can handle. W

Re: [Bitcoin-development] No Bitcoin For You

[Jim Phillips]

I don't see how the fact that my 2Mbps connection causes me to not be a
very good relay has any bearing on whether or not the network as a whole
would be negatively impacted by a 20MB block. My inability to rapidly
propagate blocks doesn't really harm the network. It's only if MOST relays
are as slow as mine that it creates an issue. I'm one node in thousands
(potentially tens or hundreds of thousands if/when Bitcoin goes
mainstream). And I'm an individual. There's no reason at all for me to run
a full node from my home, except to have my own trusted and validated copy
of the blockchain on a computer I control directly. I don't need to act as
a relay for that and as long as I can download blocks faster than they are
created I'm fine. Also, I can easily afford a VPS server or several to run
full nodes as relays if I am feeling altruistic. It's actually cheaper for
me to lease a VPS than to keep my own home PC on 24/7, which is why I have
2 of them.

And as a business, the cost of a server and bandwidth to run a full node is
a drop in the bucket. I'm involved in several projects where we have full
nodes running on leased servers with multiple 1Gbps connections. It's an
almost zero cost. Those nodes could handle 20MB blocks today without
thinking about it, and I'm sure our nodes are just a few amongst thousands
just like them. I'm not at all concerned about the network being too
centralized.

What concerns me is the fact that we are using edge cases like my home PC
as a lame excuse to debate expanding the capacity of the network.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball 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
> like 20mb blocks (right now). It would take you well over a minute to
> download the block before you could even relay it on, so much slow down in
> propagation! Yes I do see how decreasing the time to create blocks is a bit
> of a band-aid fix, and to use tge term I've seen mentioned here "kicking
> the can down the road" I agree that this is doing this, however as you say
> bandwidth is our biggest enemy right now and so hopefully by the time we
> exceed the capacity gained by the decrease in block time, we can then look
> to bump up block size because hopefully 20mbps connections will be baseline
> by then etc.
>  --
> From: Jim Phillips 
> Sent: ‎26/‎05/‎2015 12:53 PM
> To: Thy Shizzle 
> Cc: Mike Hearn ; Bitcoin Dev
> 
>
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>  Frankly I'm good with either way. I'm definitely in favor of faster
> confirmation times.
>
>  The important thing is that we need to increase the amount of
> transactions that get into blocks over a given time frame to a point that
> is in line with what current technology can handle. We can handle WAY more
> than we are doing right now. The Bitcoin network is not currently Disk,
> CPU, or RAM bound.. Not even close. The metric we're closest to being
> restricted by would be Network bandwidth. I live in a developing country.
> 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps
> connections are affordable). That equates to about 17MB per minute, or 170x
> more capacity than what I need to receive a full copy of the blockchain if
> I only talk to one peer. If I relay to say 10 peers, I can still handle 17x
> larger block sizes on a slow 2Mbps connection.
>
>  Also, even if we reduce the difficulty so that we're doing 1MB blocks
> every minute, that's still only 10MB every 10 minutes. Eventually we're
> going to have to increase that, and we can only reduce the confirmation
> period so much. I think someone once said 30 seconds or so is about the
> shortest period you can practically achieve.
>
>  --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball 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 9:30 PM, Thy Shizzle 
> wrote:
>
>  Nah don't make blocks 20mb, then you are slowing down block propagation
> and blowing out conf tikes as a result. Just decrease the time it takes to
> make a 1mb block, then you still see the same propagati

Re: [Bitcoin-development] No Bitcoin For You

[Jim Phillips]

Frankly I'm good with either way. I'm definitely in favor of faster
confirmation times.

The important thing is that we need to increase the amount of transactions
that get into blocks over a given time frame to a point that is in line
with what current technology can handle. We can handle WAY more than we are
doing right now. The Bitcoin network is not currently Disk, CPU, or RAM
bound.. Not even close. The metric we're closest to being restricted by
would be Network bandwidth. I live in a developing country. 2Mbps is a
typical broadband speed here (although 5Mbps and 10Mbps connections are
affordable). That equates to about 17MB per minute, or 170x more capacity
than what I need to receive a full copy of the blockchain if I only talk to
one peer. If I relay to say 10 peers, I can still handle 17x larger block
sizes on a slow 2Mbps connection.

Also, even if we reduce the difficulty so that we're doing 1MB blocks every
minute, that's still only 10MB every 10 minutes. Eventually we're going to
have to increase that, and we can only reduce the confirmation period so
much. I think someone once said 30 seconds or so is about the shortest
period you can practically achieve.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball 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 9:30 PM, Thy Shizzle  wrote:

>  Nah don't make blocks 20mb, then you are slowing down block propagation
> and blowing out conf tikes as a result. Just decrease the time it takes to
> make a 1mb 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 You
>
>
> 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 that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has  and may never have!
>
>
>  ... And will certainly NEVER have if we can't solve the capacity problem
> SOON.
>
>  In a former life, I was a capacity planner for Bank of America's
> mid-range server group. We had one hard and fast rule. When you are
> typically exceeding 75% of capacity on a given metric, it's time to expand
> capacity. Period. You don't do silly things like adjusting the business
> model to disincentivize use. Unless there's some flaw in the system and
> it's leaking resources, if usage has increased to the point where you are
> at or near the limits of capacity, you expand capacity. It's as simple as
> that, and I've found that same rule fits quite well in a number of systems.
>
>  In Bitcoin, we're not leaking resources. There's no flaw. The system is
> performing as intended. Usage is increasing because it works so well, and
> there is huge potential for future growth as we identify more uses and
> attract more users. There might be a few technical things we can do to
> reduce consumption, but the metric we're concerned with right now is how
> many transactions we can fit in a block. We've broken through the 75%
> marker and are regularly bumping up against the 100% limit.
>
>  It is time to stop debating this and take action to expand capacity. The
> only questions that should remain are how much capacity do we add, and how
> soon can we do it. Given that most existing computer systems and networks
> can easily handle 20MB blocks every 10 minutes, and given that that will
> increase capacity 20-fold, I can't think of a single reason why we can't go
> to 20MB as soon as humanly possible. And in a few years, when the average
> block size is over 15MB, we bump it up again to as high as we can go then
> without pushing typical computers or networks beyond their capacity. We can
> worry about ways to slow down growth without affecting the usefulness of
> Bitcoin as we get closer to the hard technical limits on our capacity.
>
>  And you know what else? If miners need higher fees to accommodate the
> costs of bigger blocks, they can configure their nodes to only mine
> transactions with higher fees.. Let the miners decide ho

Re: [Bitcoin-development] No Bitcoin For You

[Jim Phillips]

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 that Bitcoin might actually have to match that level of
> transaction demand with today's hardware. As noted previously, "too many
> users" is simply not a problem Bitcoin has  and may never have!
>
>
... And will certainly NEVER have if we can't solve the capacity problem
SOON.

In a former life, I was a capacity planner for Bank of America's mid-range
server group. We had one hard and fast rule. When you are typically
exceeding 75% of capacity on a given metric, it's time to expand capacity.
Period. You don't do silly things like adjusting the business model to
disincentivize use. Unless there's some flaw in the system and it's leaking
resources, if usage has increased to the point where you are at or near the
limits of capacity, you expand capacity. It's as simple as that, and I've
found that same rule fits quite well in a number of systems.

In Bitcoin, we're not leaking resources. There's no flaw. The system is
performing as intended. Usage is increasing because it works so well, and
there is huge potential for future growth as we identify more uses and
attract more users. There might be a few technical things we can do to
reduce consumption, but the metric we're concerned with right now is how
many transactions we can fit in a block. We've broken through the 75%
marker and are regularly bumping up against the 100% limit.

It is time to stop debating this and take action to expand capacity. The
only questions that should remain are how much capacity do we add, and how
soon can we do it. Given that most existing computer systems and networks
can easily handle 20MB blocks every 10 minutes, and given that that will
increase capacity 20-fold, I can't think of a single reason why we can't go
to 20MB as soon as humanly possible. And in a few years, when the average
block size is over 15MB, we bump it up again to as high as we can go then
without pushing typical computers or networks beyond their capacity. We can
worry about ways to slow down growth without affecting the usefulness of
Bitcoin as we get closer to the hard technical limits on our capacity.

And you know what else? If miners need higher fees to accommodate the costs
of bigger blocks, they can configure their nodes to only mine transactions
with higher fees.. Let the miners decide how to charge enough to pay for
their costs. We don't need to cripple the network just for them.

--
*James G. Phillips IV*


*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

I feel your pain. I've had the same thing happen to me in the past. And I
agree it's more likely to occur with my proposed scheme but I think with HD
wallets there will still be UTXOs left unspent after most transactions
since, for privacy sake it's looking for the smallest set of addresses that
can be linked.
On May 9, 2015 9:11 PM, "Matt Whitlock"  wrote:

> Minimizing the number of UTXOs in a wallet is sometimes not in the best
> interests of the user. In fact, quite often I've wished for a configuration
> option like "Try to maintain _[number]_ UTXOs in the wallet." This is
> because I often want to make multiple spends from my wallet within one
> block, but spends of unconfirmed inputs are less reliable than spends of
> confirmed inputs, and some wallets (e.g., Andreas Schildbach's wallet)
> don't even allow it - you can only spend confirmed UTXOs. I can't tell you
> how aggravating it is to have to tell a friend, "Oh, oops, I can't pay you
> yet. I have to wait for the last transaction I did to confirm first." All
> the more aggravating because I know, if I have multiple UTXOs 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 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 protocol level, we deal
> > with it at the source of the problem -- the wallets. Right now, the
> typical
> > wallet selects only the minimum number of unspent outputs when building a
> > transaction. The goal is to keep the transaction size to a minimum so
> that
> > the fee stays low. Consequently, lots of unspent outputs just don't get
> > used, and are left lying around until some point in the future.
> >
> > What if we started designing wallets to consolidate unspent outputs? When
> > selecting unspent outputs for a transaction, rather than choosing just
> the
> > minimum number from a particular address, why not select them ALL? Take
> all
> > of the UTXOs from a particular address or wallet, send however much needs
> > to be spent to the payee, and send the rest back to the same address or a
> > change address as a single output? Through this method, we should wind up
> > shrinking the UTXO database over time rather than growing it with each
> > transaction. Obviously, as Bitcoin gains wider adoption, the UTXO
> database
> > will grow, simply because there are 7 billion people in the world, and
> > eventually a good percentage of them will have one or more wallets with
> > spendable bitcoin. But this idea could limit the growth at least.
> >
> > The vast majority of users are running one of a handful of different
> wallet
> > apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;
> > Blockchain.info; and maybe a few others. The developers of all these
> > wallets have a vested interest in the continued usefulness of Bitcoin,
> and
> > so should not be opposed to changing their UTXO selection algorithms to
> one
> > that reduces the UTXO database instead of growing it.
> >
> > >From the miners perspective, even though these types of transactions
> would
> > be larger, the fee could stay low. Miners actually benefit from them in
> > that it reduces the amount of storage they need to dedicate to holding
> the
> > UTXO. So miners are incentivized to mine these types of transactions
> with a
> > higher priority despite a low fee.
> >
> > Relays could also get in on the action and enforce this type of behavior
> by
> > refusing to relay or deprioritizing the relay of transactions that don't
> > use all of the available UTXOs from the addresses used as inputs. Relays
> > are not only the ones who benefit the most from a reduction of the UTXO
> > database, they're also in the best position to promote good behavior.
> >
> > --
> > *James G. Phillips IV*
> > <https://plus.google.com/u/0/113107039501292625391/posts>
> >
> > *"Don't bunt. Aim out of the ball park. Aim for the company of
> immortals."
> > -- David Ogilvy*
> >
> >  *This message was created with 100% recycled electrons. Please think
> twice
> > before printing.*
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

Makes sense.. So with that said, I'd propose the following criteria for
selecting UTXOs:

1. Select the smallest possible set of addresses that can be linked in
order to come up with enough BTC to send to the payee.
2. Given multiple possible sets, select the one that has the largest number
of UTXOs.
3. Given multiple possible sets, choose the one that contains the largest
amount of total BTC.
4. Given multiple possible sets, select the one that destroys the most
bitcoin days.
5. If there's still multiple possible sets, just choose one at random.

Once the final set of addresses has been identified, use ALL UTXOs from
that set, sending appropriate outputs to the recipient(s), a new change
address, and a mining fee.

Miners should be cognisant of and reward the fact that the user is making
an effort to consolidate UTXOs. They can easily spot these transactions by
looking at whether all possible UTXOs from each input addresses have been
used. Since most miners use Bitcoin Core, and its defaults, this test can
be built into Bitcoin Core's logic for determining which transactions to
include when mining a block.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*

On Sat, May 9, 2015 at 3:38 PM, Pieter Wuille 
wrote:

> Miners do not care about the age of a UTXO entry, apart for two
> exceptions. It is also economically irrelevant.
> * There is a free transaction policy, which sets a small portion of block
> space aside for transactions which do not pay sufficient fee. This is
> mostly an altruistic way of encouraging Bitcoin adoption. As a DoS
> prevention mechanism, there is a requirement that these free transactions
> are of sufficient priority (computed as BTC-days-destroyed per byte),
> essentially requiring these transactions to consume another scarce
> resource, even if not money.
> * Coinbase transaction outputs can, as a consensus rule, only be spent
> after 100 confirmations. This is to prevent random reorganisations from
> invalidating transactions that spend young coinbase transactions (which
> can't move to the new chain). In addition, wallets also select more
> confirmed outputs first to consume, for the same reason.
> On May 9, 2015 1:20 PM, "Raystonn"  wrote:
>
>> That policy is included in Bitcoin Core.  Miners use it because it is the
>> default.  The policy was likely intended to help real transactions get
>> through in the face of spam.  But it favors those with more bitcoin, as the
>> priority is determined by amount spent multiplied by age of UTXOs.  At the
>> very least the amount spent should be removed as a factor, or fees are
>> unlikely 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 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 use based on the number of UTXOs it contains (more being
>> preferable) and how old those UTXOs are (in order to reduce the fee)?
>>
>> If selecting older UTXOs gives higher priority for a lesser (or at least
>> not greater) fee, that is an incentive for a rational user to use the older
>> UTXOs.  Such policy needs to be defended or removed.  It doesn't support
>> privacy or a reduction in UTXOs.
>>
>> Before starting this thread, I had completely forgotten that age was even
>> a factor in determining which UTXOs to use. Frankly, I can't think of any
>> reason why miners care how old a particular UTXO is when determining what
>> fees to charge. I'm sure there is one, I just don't know what it is. I just
>> tossed it in there as homage to Andreas who pointed out to me that it was
>> still part of the selection criteria.
>>
>>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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 use based on the number of UTXOs it contains (more being
>> preferable) and how old those UTXOs are (in order to reduce the fee)?
>
> If selecting older UTXOs gives higher priority for a lesser (or at least
> not greater) fee, that is an incentive for a rational user to use the older
> UTXOs.  Such policy needs to be defended or removed.  It doesn't support
> privacy or a reduction in UTXOs.
>
Before starting this thread, I had completely forgotten that age was even a
factor in determining which UTXOs to use. Frankly, I can't think of any
reason why miners care how old a particular UTXO is when determining what
fees to charge. I'm sure there is one, I just don't know what it is. I just
tossed it in there as homage to Andreas who pointed out to me that it was
still part of the selection criteria.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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 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 use based on the number of UTXOs it contains (more being
preferable) and how old those UTXOs are (in order to reduce the fee)?
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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 effective as
> combining the UTXOs from multiple addresses, but it would help. The key is
> to do everything that can be done when building a transaction to ensure
> that as many inputs as possible are consolidated into as few outputs as
> possible.
>
>
>  I would agree if you have multiple utxo for a single address then it
> makes sense since there is no privacy loss. However sending the change back
> to the same address would damage privacy (Hive does this) as it is then
> obvious from looking at the transaction which output is change and which
> output is sending funds.
>

I tend to agree with you here. But the change output could just as easily
be sent to a new change address.

>  Also not everyone is concerned with their own privacy, and I'm not aware
> of any HD-wallet implementations that won't already combine inputs from
> multiple addresses within that wallet without user input.
>
>
>  For people who do not care for privacy then it would work fine. But
> adding it into the wallet as default behaviour would deter those who do
> care for privacy - and making it a customisable option just adds complexity
> for the users. Wallets do need to combine utxo at times to spend bitcoins
> which is how people can be tracked today, using the minimum set of utxo
> tries to reduce the risk.
>
> Different wallets are targeted at different demographics. Some are geared
towards more mainstream users (for whom the privacy issue is less a
concern) and some (such as DarkWallet) are geared more towards the privacy
advocates. These wallets may choose to set their defaults at oposite ends
of the spectrum as to how they choose to select and link addresses and
UTXOs, but they can all improve on their current algorithms and promote
some degree of consolidation.

>   Additionally, large wallets that have lots of addresses owned by
> multiple users like exchanges, blockchain.info, and Coinbase can
> consolidate UTXOs very effectively when building transactions
>
>
>  That's true - I'm not sure how they would feel about it though. I
> imagine they probably are already to minimise key management.
>
> That's what these discussions are for. Hopefully this thread will be seen
by developers of these wallets and give them something to consider.

>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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 worth the lower fee. There's no protocol level enforcement of a fee as
far as I understand it. It's enforced by the miners and their willingness
to include a transaction in a block.

> In addition, it results in more linkage between coins/addresses used, so
> lower privacy.
>
Not if you only select all the UTXOs from a single address. A wallet that
is geared more towards privacy minded individuals may want to reduce the
amount of address linkage, but a wallet geared towards the general masses
probably won't have to worry so much about that.

> The only way you can guarantee an economical reason to keep the UTXO set
> small is by actually having a consensus rule that punishes increasing its
> size.
>
There's an economical reason right now to keeping the UTXO set small. The
smaller it is, the easier it is for the individual to run a full node. The
easier it is to run a full node, the faster Bitcoin will spread to the
masses. The faster it spreads to the masses, the more valuable it becomes.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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 always pick *all* UTXOs.
>
> Is it not fair to say though that UTXO database growth is not considered
when selecting the UTXOs to use? And that size of transaction is a priority
if not the top priority?
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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;
> > Blockchain.info; and maybe a few others. The developers of all these
> > wallets have a vested interest in the continued usefulness of Bitcoin,
> and
> > so should not be opposed to changing their UTXO selection algorithms to
> one
> > that reduces the UTXO database instead of growing it.
>
> You can't assume that UTXO growth will be driven by walles at all; the
> UTXO set's global consensus functionality is incredibly useful and will
> certainly be used by all manner of applications, many having nothing to
> do with Bitcoin.
>

You're correct in this point. Future UTXO growth will be coming from all
directions. But I'm a believer in the idea that whatever can be done should
be done.  If we get Bitcoin devs into the mindset now that UTXOs are
expensive to those that have to store them, and that they should be good
netizens and do what they can to limit them, then hopefully that will ideal
will be passed down to future developers. I don't believe consolidating
UTXOs in the wallet is the only solution.. I just think it is a fairly easy
one to implement, and can only help the problem from getting worse in the
future.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jim Phillips]

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 protocol level, we deal
with it at the source of the problem -- the wallets. Right now, the typical
wallet selects only the minimum number of unspent outputs when building a
transaction. The goal is to keep the transaction size to a minimum so that
the fee stays low. Consequently, lots of unspent outputs just don't get
used, and are left lying around until some point in the future.

What if we started designing wallets to consolidate unspent outputs? When
selecting unspent outputs for a transaction, rather than choosing just the
minimum number from a particular address, why not select them ALL? Take all
of the UTXOs from a particular address or wallet, send however much needs
to be spent to the payee, and send the rest back to the same address or a
change address as a single output? Through this method, we should wind up
shrinking the UTXO database over time rather than growing it with each
transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database
will grow, simply because there are 7 billion people in the world, and
eventually a good percentage of them will have one or more wallets with
spendable bitcoin. But this idea could limit the growth at least.

The vast majority of users are running one of a handful of different wallet
apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;
Blockchain.info; and maybe a few others. The developers of all these
wallets have a vested interest in the continued usefulness of Bitcoin, and
so should not be opposed to changing their UTXO selection algorithms to one
that reduces the UTXO database instead of growing it.

>From the miners perspective, even though these types of transactions would
be larger, the fee could stay low. Miners actually benefit from them in
that it reduces the amount of storage they need to dedicate to holding the
UTXO. So miners are incentivized to mine these types of transactions with a
higher priority despite a low fee.

Relays could also get in on the action and enforce this type of behavior by
refusing to relay or deprioritizing the relay of transactions that don't
use all of the available UTXOs from the addresses used as inputs. Relays
are not only the ones who benefit the most from a reduction of the UTXO
database, they're also in the best position to promote good behavior.

--
*James G. Phillips IV*


*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Jim]

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Jim]

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Jim]

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
http://bitcoin-solutions.co.uk

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure

[Jim]

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
http://bitcoin-solutions.co.uk

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Base-32 error correction coding

[Jim Paris]

Mark Friedenbach wrote:
> What follows is a proposed BIP for human-friendly base-32
> serialization with error correction encoding.
...
> 2. Automatic correction of up to 1 transcription error per 31 coded
> digits (130 bits of payload data). For a 256-bit hash or secret key,
> this enables seamless recovery from up to two transcription errors so
> long as they occur in separate halves of the coded representation.

Can we do better than correcting single transcription errors?  I'd
imagine that transposition of two adjacent characters, or insertion or
deletion of a single 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

Jim

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fees UI warning

[Jim]

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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
http://bitcoin-solutions.co.uk

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Safe auto-updating

[Jim]

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@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@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 

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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  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 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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.orgMoney, 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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  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 <
> > > calebdeli...@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

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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 <
> calebdeli...@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.r...@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  > jim...@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 d

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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 
> 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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.orgMoney, 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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  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 
> > 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@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.orgMoney, 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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  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 p

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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  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@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> -- 
> https://multibit.orgMoney, 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.orgMoney, 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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  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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
https://multibit.orgMoney, 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

[Jim]

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

--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

[Jim Nguyen]

Gavin's grandma needs to be able to use bitcoin.  Here is a real world
sampling of the types of people wanting to use bitcoin but are having some
difficulty which I have collected from Facebook.  Should we listen to the
end user? :-P

*"what is the intention of Bitcoin? Is it supposed to be - eventually - for
dummies like myself or is it just for those individuals who are code and
algorithm writers? I downloaded a wallet but how do I know if I need more
software or a massive computer system to solve "the problem" for the next
block? With all the talk of mathematical problem solving on a world wide
network of computers I can't see a small laptop figuring out anything thus
not gaining any bitcoins. Why should I be interested in this if it appears
it's just for computer scientists?"*

*"hi, instaled bitcoin qt, but after it dowladed all the stuff, now i get
DEP protecction from windows, and it tells me bitcoinQT need to run with
DEP on, dont let me make an exception for it, nor work it i turn DEP only
for sys, so hwat i should do?"*

*"hi, i'm new to bitcoin, i got a bunch of free bitcoins from a bunch of
the free sites. how come when i tried to send my bitcoins to myself, it
says the fee exceeds the balance? I thought there was no fees?"*

*"Is there a way to speed up the process of synchronisation with the
network? It has been taken ages on my MAC.*
*Any help would be nice"*
*
*
*and more...*

Sorry if 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 Reiner  wrote:
> > Our divergence is on two points (personal opinions):
> >
> > (1) I don't think there is any real risk to the centralization of the
> > network by promoting a SPV (purely-consuming) node to brand-new users.
> > In my opinion (but I'm not as familiar with the networking as you), as
> > long as all full nodes are full-validation, the bottleneck will be
> > computation and bandwidth, long before a constant 10k nodes would be
> > insufficient to support propagating data through the network.
>
> Not so— a moderately fast multicore desktop machine can keep up with
> the maximum possible validation rate of the Bitcoin network and the
> bandwidth has a long term maximum rate of about 14kbit/sec— though
> you'll want at least ten times that for convergence stability and the
> ability feed multiple peers.
>
> Here are the worst blocks testnet3 (which has some intentionally
> constructed maximum sized blocks),E31230 :
> (with the new parallel validation code)
> - Verify 2166 txins: 250.29ms (0.116ms/txin)
> - Verify 3386 txins: 1454.25ms (0.429ms/txin)
> - Verify 5801 txins: 575.46ms (0.099ms/txin)
> - Verify 6314 txins: 625.05ms (0.099ms/txin)
> Even the slowest one _validates_ at 400x realtime. (these measurements
> are probably a bit noisy— but the point is that its fast).
> (the connecting is fast too, but thats obvious with such a small database)
>
> Although I haven't tested leveldb+ultraprune with a really enormous
> txout set or generally with sustained maximum load— so there may be
> other gaffs in the software that get exposed with sustained load, but
> they'd all be correctable. Sounds like some interesting stuff to test
> with on testnet fork that has the POW test disabled.
>
> While syncing up a behind node can take a while— keep in mind that
> you're expecting to sync up weeks of network work in hours. Even
> 'slow' is quite fast.
>
> > In fact,
> > I was under the impression that "connectedness" was the real metric of
> > concern (and resilience of that connectedness to large percentage of
> > users disappearing suddenly).  If that's true, above a certain number of
> > nodes, the connectedness isn't really going to get any better (I know
> > it's not really that simple, but I feel like it is up to 10x the current
> > network size).
>
> Thats not generally concern for me. There are a number of DOS attack
> risks... But attacker linear DOS attacks aren't generally avoidable
> and they don't persist.
>
> Of the class of connectedness concerns I have is that a sybil attacker
> could spin up enormous numbers of nodes and then use them to partition
> large miners.  So, e.g. find BitTaco's node(s) and the nodes for
> miners covering 25% hashpower and get them into a separate partition
> from the rest of the network. Then they give double spends to that
> partition and use them to purchase an unlimited supply of digitally
> delivered tacos—

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

[Jim]

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-requ...@lists.sourceforge.net wrote:
> Send Bitcoin-development mailing list submissions to
>   bitcoin-development@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-requ...@lists.sourceforge.net
> 
> You can reach the person managing the list at
>   bitcoin-development-ow...@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 
> Subject: Re: [Bitcoin-development] Roadmap to getting users onto SPV
>   clients
> To: Mike Hearn 
> Cc: Bitcoin Dev 
> Message-ID:
>   
> 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  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 go

Re: [Bitcoin-development] Random order for clients page

[Jim]

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.orgMoney, reinvented


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] new bitcoin.org clients page

[Jim]

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 Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development