Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Matt Corallo]

>For example, I think some of the resistance for bigger blocks is coming
>from contributors who are worried they, personally, won't be able to
>keep
>up with a bigger blockchain. They might not be able to run full nodes
>from
>their home network connections (or might not be able to run a full node
>AND
>stream Game of Thrones), on their old raspberry pi machines.

Ive been trying to stay out of these increasingly useless shit-throwing 
contests, but I wanted to take objection to this... I highly, highly doubt any 
seriously technical person is making any kind of decision on block size issues 
based on their own personal network. If you're assuming this is a serious 
motivating factor for anyone, then I'm not sure you've even been reading your 
email or listening to the conversations you've had with people over the last 
year or more.

On June 18, 2015 11:23:33 AM PDT, Gavin Andresen  
wrote:
>On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos  wrote:
>
>> Let me take a pass at explaining how I see this.
>>
>> 1) Code changes to Bitcoin Core that don't change consensus: 
>Wladimir is
>> the decider but he works under a process that is well understood by
>> developers on the project in which he takes under reasonable
>consideration
>> other technical opinions and prefers to have clear agreement among
>them.
>>
>
>Yes.
>
>2) Changes to the consensus rules: As others have said, this isn't
>anyone's
>> decision for anyone else.
>>
>
>Yes.
>
>
>> It's up to each individual user as to what code they run and what
>rules
>> they enforce.  So then why is everyone so up in arms about what Mike
>and
>> Gavin are proposing if everyone is free to decide for themselves?  I
>> believe that each individual user should adhere to the principle that
>there
>> should be no changes to the consensus rules unless there is near
>complete
>> agreement among the entire community, users, developers, businesses
>miners
>> etc. It is not necessary to define complete agreement exactly because
>every
>> individual person decides for themselves.  I believe that this is
>what
>> gives Bitcoin, or really any money, its value and what makes it work,
>that
>> we all agree on exactly what it is.  So I believe that it is
>misleading and
>> bad for Bitcoin to tell users and business that you can just choose
>without
>> concern for everyone else which code you'll run and we'll see which
>one
>> wins out.  No.  You should run the old consensus rules (on any
>codebase you
>> want) until you believe that pretty much everyone has consented to a
>change
>> in the rules.  It is your choice, but I think a lot of people that
>have
>> spent time thinking about the philosophy of consensus systems believe
>that
>> when the users of the system have this principle in mind, it's what
>will
>> make the system work best.
>>
>
>I don't think I agree with "pretty much everybody", because status-quo
>bias
>is a very powerful thing. Any change that disrupts the way they've been
>doing things will generate significant resistance -- there will be 10
>or
>20% of any population that will take a position of "too busy to think
>about
>this, everything seems to be working great, I don't like change, NO to
>any
>change."
>
>For example, I think some of the resistance for bigger blocks is coming
>from contributors who are worried they, personally, won't be able to
>keep
>up with a bigger blockchain. They might not be able to run full nodes
>from
>their home network connections (or might not be able to run a full node
>AND
>stream Game of Thrones), on their old raspberry pi machines.
>
>The criteria for me is "clear super-majority of the people and
>businesses
>who are using Bitcoin the most," and I think that criteria is met.
>
>
>
>> 3) Code changes to Core that do change consensus: I think that
>Wladimir,
>> all the other committers besides Gavin, and almost all of the other
>> developers on Core would defer to #2 above and wait for its outcome
>to be
>> clear before considering such a code change.
>>
>
>Yes, that's the way it has mostly been working. But even before
>stepping
>down as Lead I was starting to wonder if there are ANY successful open
>source projects that didn't have either a Benevolent Dictator or some
>clear
>voting process to resolve disputes that cannot be settled with "rough
>consensus."


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

Re: [Bitcoin-development] Block Size Increase Requirements

[Matt Corallo]

On 05/29/15 23:48, Gavin Andresen wrote:
> On Fri, May 29, 2015 at 7:25 PM, Matt Corallo  <mailto:bitcoin-l...@bluematt.me>> wrote:
> 
> Sadly, this is very far from the whole story. The issue of miners
> optimizing for returns has been discussed several times during this
> discussion, and, sadly, miners who are geographically colocated who are
> optimizing for returns with a free-floating blocksize will optimize away
> 50% of the network!
> 
> 
> I must have missed that analysis-- link please?  Or summary of HOW they
> will optimize away 50% of the network?
> 
> Or are you assuming that 50% of the network is colocated... (which is a
> potential problem independent of blocksize)

If, for example, the majority of miners are in China (they are), and
there is really poor connectivity in and out of China (there is) and a
miner naively optimizes for profit, they will create blocks which are
large and take a while to relay out of China. By simple trial-and-error
an individual large miner might notice that when they create larger
blocks which fork off miners in other parts of the world, they get more
income. Obviously forking off 50% of the network would be a rather
extreme situation and assumes all kinds of simplified models, but it
shows that the incentives here are very far from aligned, and your
simplified good-behavior models are very far from convincing.

> 
> >
> > In addition, I'd expect to
> > see analysis of how these systems perform in the worst-case, not 
> just
> > packet-loss-wise, but in the face of miners attempting to break the
> > system.
> >
> >
> > See 
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> > analysis of "but that means bigger miners can get an advantage" 
> argument.
> >
> > Executive summary: if little miners are stupid and produce huge blocks,
> > then yes, big miners have an advantage.
> 
> I'll talk about transaction fees in a second, but there are several
> problems with this already. As pointed out in the original mail, gfw has
> already been known to interfere with Bitcoin P2P traffic. So now by
> "little" miners, you mean any miner who is not located in mainland
> China? Whats worse, the disadvantage is symmetric - little miners are at
> a disadvantage when *anyone* mines a bigger block, and miners dont even
> have to be "evil" for this to happen - just optimize for profits.
> 
> 
> But the disadvantage is tiny. And essentially zero if they connect to
> your fast relay network (or anything like it).
> 

The disadvantage is small with 1MB blocks, but already non-zero. 20MB
blocks are much, much worse (lots of things here dont scale linearly,
even just transfer over a high-packet-loss-link). I mentioned this in my
original email as something which doesnt make me comfortable with 20MB
blocks, but something which needs simulation and study, and might
actually be just fine!

> 
> > But they're not, so they won't.
> 
> I dont know what you're referring to with this. Are you claiming little
> miners today optimize for relay times and have good visibility into the
> Bitcoin network and calculate an optimal block size based on this (or
> would with a 20MB block size)?
> 
> 
> Do you have another explanation for why miners choose to leave
> fee-paying transactions in their mempool and create small blocks?

Defaults? Dumb designs? Most miners just use the default 750K blocks, as
far as I can tell, other miners probably didnt see transactions relayed
across several hops or so, and a select few miners are doing crazy
things like making their blocks fit in a single packet to cross the gfw,
but that is probably overkill and not well-researched.

> > Until the block reward goes away, and assuming transaction fees become
> > an important source of revenue for miners.
> > I think it is too early to worry about that; see:
> >
> >http://gavinandresen.ninja/when-the-block-reward-goes-away
> 
> You dont make any points here with which I can argue, but let me respond
> with the reason /I/ think it is a problem worth thinking a little bit
> about...If we increase the blocksize sufficiently such that transaction
> fees are not the way in which miners make their money
> 
> 
> I'm not suggesting that we increase the blocksize sufficiently such that
> transaction fees are not the way in which miners make their money.
> 
> I'm suggesting the blocksize be increased to 20MB (and then doubled
> every couple of years).

Do you have convincing evidence that at 20MB miner

Re: [Bitcoin-development] Block Size Increase Requirements

[Matt Corallo]

On 05/29/15 22:36, Gavin Andresen wrote:
> Matt brought this up on Twitter, I have no idea why I didn't respond
> weeks ago (busy writing blog posts, probably):
> 
> On Thu, May 7, 2015 at 6:02 PM, Matt Corallo  <mailto:bitcoin-l...@bluematt.me>> wrote:
> 
> 
> 
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
> 
> 
> If block propagation isn't fixed, then mines have a strong incentive to
> create smaller blocks.
> 
> So the max block size is irrelevant, it won't get hit.

Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during this
discussion, and, sadly, miners who are geographically colocated who are
optimizing for returns with a free-floating blocksize will optimize away
50% of the network!

> 
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the
> system.
> 
> 
> See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> analysis of "but that means bigger miners can get an advantage" argument.
> 
> Executive summary: if little miners are stupid and produce huge blocks,
> then yes, big miners have an advantage.

I'll talk about transaction fees in a second, but there are several
problems with this already. As pointed out in the original mail, gfw has
already been known to interfere with Bitcoin P2P traffic. So now by
"little" miners, you mean any miner who is not located in mainland
China? Whats worse, the disadvantage is symmetric - little miners are at
a disadvantage when *anyone* mines a bigger block, and miners dont even
have to be "evil" for this to happen - just optimize for profits.

> But they're not, so they won't.

I dont know what you're referring to with this. Are you claiming little
miners today optimize for relay times and have good visibility into the
Bitcoin network and calculate an optimal block size based on this (or
would with a 20MB block size)?

> Until the block reward goes away, and assuming transaction fees become
> an important source of revenue for miners.
> I think it is too early to worry about that; see:
> 
>http://gavinandresen.ninja/when-the-block-reward-goes-away

You dont make any points here with which I can argue, but let me respond
with the reason /I/ think it is a problem worth thinking a little bit
about...If we increase the blocksize sufficiently such that transaction
fees are not the way in which miners make their money, then either
miners are not being funded (ie hashpower has to drop to very little),
or the only people mining/funding miners are large orgs who are
"running" Bitcoin (ie the web wallets, payment processors, big
merchants, and exchanges of the world). Sadly, this is no longer a
decentralized Bitcoin and is, in fact, pretty much how the banking world
works today.

I'm not sure who, if anyone, claims Bitcoin is novel or interesting for
any reason other than its decentralization properties, and, in a world
which you are apparently proposing, the "natural" course of things is to
very strongly centralize.

>  * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. 
> 
> 
> Ok. What does this have to do with the max block size?
> 
> Are you arguing that work won't happen if the max block size increases?

Yes, I am arguing that by increasing the blocksize the incentives to
actually make Bitcoin scale go away. Even if amazing technologies get
built, no one will have any reason to use them.

>   * I'd like to see some better conclusions to the discussion around
> 
> long-term incentives within the system.
> 
> 
> Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away
> for what I think about that.

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

[Bitcoin-development] Block Size Increase Requirements

[Matt Corallo]

OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
with committing to this right now, but think we should eventually", but
not much "I'd be comfortable with committing to this when I see X". In
the interest of ignoring debate and pushing people towards a consensus
at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
second.

Personally, there are several things that worry me significantly about
committing to a blocksize increase, which I'd like to see resolved
before I'd consider supporting a blocksize increase commitment.

 * Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today. I'd expect to see these not only implemented but
being used in production (though I dont particularly care about them
being all that stable). I'd want to see measurements of how they perform
both in production and in the face of high packet loss (eg across the
GFW or in the case of small/moderate DoS). In addition, I'd expect to
see analysis of how these systems perform in the worst-case, not just
packet-loss-wise, but in the face of miners attempting to break the system.

 * I'd very much like to see someone working on better scaling
technology, both in terms of development and in terms of getting
traction in the marketplace. I know StrawPay is working on development,
though its not obvious to me how far they are from their website, but I
dont know of any commitments by large players (either SPV wallets,
centralized wallet services, payment processors, or any others) to
support such a system (to be fair, its probably too early for such
players to commit to anything, since anything doesnt exist in public).

 * I'd like to see some better conclusions to the discussion around
long-term incentives within the system. If we're just building Bitcoin
to work in five years, great, but if we want it all to keep working as
subsidy drops significantly, I'd like a better answer than "we'll deal
with it when we get there" or "it will happen, all the predictions based
on people's behavior today say so" (which are hopefully invalid thanks
to the previous point). Ideally, I'd love to see some real free pressure
already on the network starting to develop when we commit to hardforking
in a year. Not just full blocks with some fees because wallets are
including far greater fees than they really need to, but software which
properly handles fees across the ecosystem, smart fee increases when
transactions arent confirming (eg replace-by-fee, which could be limited
to increase-in-fees-only for those worried about double-spends).

I probably forgot one or two and certainly dont want to back myself into
a corner on committing to something here, but those are a few things I
see today as big blockers on larger blocks.

Luckily, people have been making progress on building the software
needed in all of the above for a while now, but I think they're all
very, very immature today.

On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
Matt Corallo  <mailto:bitcoin-l...@bluematt.me>> wrote:
-snip-
>> If, instead, there had been an intro on the list as "I think we should
>> do the blocksize increase soon, what do people think?", the response
>> could likely have focused much more around creating a specific list of
>> things we should do before we (the technical community) think we are
>> prepared for a blocksize increase.
>
> Agreed, but that is water under the bridge at this point.  You - rightly
> - opened the topic here and now we're discussing it.
>
> Mike and Gavin are due the benefit of doubt because making a change to a
> leaderless automaton powered by leaderless open source software is
> breaking new ground.  I don't focus so much on how we got to this point,
> but rather, where we go from here.

--
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] Block Size Increase

[Matt Corallo]

On 05/07/15 19:34, Mike Hearn wrote:
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public
> 
> 
> So your concern is just about the ordering and process of things, and
> not about the change itself?

No, I'm very concerned about both.

> I have witnessed many arguments in IRC about block sizes over the years.
> There was another one just a few weeks ago. Pieter left the channel for
> his own sanity. IRC is not a good medium for arriving at decisions on
> things - many people can't afford to sit on IRC all day and
> conversations can be hard to follow. Additionally, they tend to go circular.

I agree, thats why this mailing list was created in the first place
(well, also because bitcointalk is too full of spam, but close enought :))

> That said, I don't know if you can draw a line between the "ins" and
> "outs" like that. The general public is watching, commenting and
> deciding no matter what. Might as well deal with that and debate in a
> format more accessible to all.

Its true, just like its true the general public can opt to run any
version of software they want. That said, the greater software
development community has to update /all/ the software across the entire
ecosystem, and thus provide what amounts to a strong recommendation of
which course to take. Additionally, though there are issues (eg if there
was a push to remove the total coin limit) which are purely political,
and thus which should be up to the greater public to decide, the
blocksize increase is not that. It is intricately tied to Bitcoin's
delicate incentive structure, which many of the development community
are far more farmiliar with than the general Bitcoin public. If there
were a listserv that was comprised primarily of people on
#bitcoin-wizards, I might have suggested a discussion there, first, but
there isnt (as far as I know?).

> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?"
> 
> 
> There have been many such discussions over time. On bitcointalk. On
> reddit. On IRC. At developer conferences. Gavin already knew what many
> of the objections would be, which is why he started answering them.
> 
> But alright. Let's say he should have started a thread. Thanks for
> starting it for him.
> 
> Now, can we get this specific list of things we should do before we're
> prepared?

YesI'm gonna split the topic since this is already far off course
for that :).

> A specific credible alternative to what? Committing to blocksize
> increases tomorrow? Yes, doing more research into this and developing
> software around supporting larger block sizes so people feel comfortable
> doing it in six months. 
> 
> 
> Do you have a specific research suggestion? Gavin has run simulations
> across the internet with modified full nodes that use 20mb blocks, using
> real data from the block chain. They seem to suggest it works OK.
> 
> What software do you have in mind?

Let me answer that in a new thread :).

--
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] Block Size Increase

[Matt Corallo]

On 05/07/15 11:29, Mike Hearn wrote:
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
> 
> 
> I was referring to winter next year. 0.12 isn't scheduled until the end
> of the year, according to Wladimir. I explained where this figure comes
> from in this article:

On a related note, I'd like to agree strongly with Peter Todd that we
should get away from doing forks-only-in-releases. We can add code to do
a fork and then enable it in 0.11.1 or 0.11.11 if Gavin prefers more 11s.

--
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] Block Size Increase

[Matt Corallo]

Replies inline.

On 05/07/15 17:43, Mike Hearn wrote:
> The only answer to this that anyone with a clue should give is "it
> will very, very likely be able to support at least 1MB blocks
> roughly every 10 minutes on average for the next eleven years, and
> it seems likely that a block size increase of some form will happen
> at some point in the next eleven years", anything else is dishonest.
> 
> 
> Matt, you know better than that. Gavin neither lacks clue nor is he
> dishonest. 

No, I dont think Gavin is being deliberately dishonest, and I'm rather
confident he phrased everything in a way that is technically true (ie
the quote in his response). However, others have definitely not taken
away the correct interpretation of what he said, and this is a serious
problem. Setting expectations correctly as this is a very contentious
issue and one that does not appear to be reaching consensus quickly in
the technical community is important.
More generally, consider the situation we're in now. Gavin is going off
pitching this idea to the general public (which, I agree, is an
important step in pulling off a hardfork) while people who actually
study the issues are left wondering why they're being ignored (ie why is
there no consensus-building happening on this list?).


> He has been working on the assumption that other developers are
> reasonable, and some kind of compromise solution can be found that
> everyone can live with. Hence trying to find a middle ground, hence
> considering and writing articles in response to every single objection
> raised. Hence asking for suggestions on what to change about the plan,
> to make it more acceptable. What more do you want, exactly?

The appropriate method of doing any fork, that we seem to have been
following for a long time, is to get consensus here and on IRC and on
github and *then* go pitch to the general public (either directly or by
releasing software) that they should upgrade. I admit that hardforks are
a bit different in that the level of software upgrade required means
additional lead time, but I'm not sure that means starting the
public-pitching phase before there is any kind of consensus forming
(actually, I'd point out that to me there seems to be rahter clear
consensus outside of you and Gavin that we should delay increasing block
size).
As far as I can tell, there has been no discussion of block sizes on
this list since 2013, and while I know Gavin has had many private
conversations with people in this community about the block size, very
little if any of it has happened in public.
If, instead, there had been an intro on the list as "I think we should
do the blocksize increase soon, what do people think?", the response
could likely have focused much more around creating a specific list of
things we should do before we (the technical community) think we are
prepared for a blocksize increase.

> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.

A specific credible alternative to what? Committing to blocksize
increases tomorrow? Yes, doing more research into this and developing
software around supporting larger block sizes so people feel comfortable
doing it in six months. I acknowledge that Gavin has been putting a lot
of effort into this front, but, judging by this thread, I am far from
the only one who thinks much more needs done.

--
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] Block Size Increase

[Matt Corallo]

On 05/07/15 14:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
>   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> 
> In it, I asked people to email me objections I might have missed. I
> would still appreciate it if people do that; it is impossible to keep up
> with this mailing list, /r/bitcoin posts and comments, and
> #bitcoin-wizards and also have time to respond thoughtfully to the
> objections raised.

People have been sharing the same objections as on this list for months,
I'm not sure what is new here.

> I would very much like to find some concrete course of action that we
> can come to consensus on. Some compromise so we can tell entrepreneurs
> "THIS is how much transaction volume the main Bitcoin blockchain will be
> able to support over the next eleven years."

I think this is a huge issue. You've been wandering around telling
people that the blocksize will increase soon for months, when there is
very clearly no consensus that it should in the short-term future. The
only answer to this that anyone with a clue should give is "it will
very, very likely be able to support at least 1MB blocks roughly every
10 minutes on average for the next eleven years, and it seems likely
that a block size increase of some form will happen at some point in the
next eleven years", anything else is dishonest.

--
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] Block Size Increase

[Matt Corallo]

On 05/06/15 23:33, Tier Nolan wrote:
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo  <mailto:bitcoin-l...@bluematt.me>> wrote:
> 
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
> 
> 
> Miners can always reduce the block size (if they coordinate). 
> Increasing the maximum block size doesn't necessarily cause an
> increase.  A majority of miners can soft-fork to set the limit lower
> than the hard limit.

Sure, of course.

> Setting the hard-fork limit higher means that a soft fork can be used to
> adjust the limit in the future. 
> 
> The reference client would accept blocks above the soft limit for wallet
> purposes, but not build on them.  Blocks above the hard limit would be
> rejected completely.

Yes, but this does NOT make an actual policy. Note that the vast
majority of miners already apply their own patches to Bitcoin Core, so
applying one more is not all that hard. When blocks start to become
limited (ie there is any fee left on the table by transactions not
included in a block) there becomes incentive for miners to change that
behavior pretty quick. Not just that, the vast majority of the hashpower
is behind very large miners, who have little to no decentralization
pressure. This results in very incompatible incentives, mainly that the
incentive would be for the large miners to interconnect in a private
network and generate only maximum-size blocks, creating a strong
centralization pressure in the network.

--
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] Block Size Increase

[Matt Corallo]

For now, lets leave the discussion to JUST the block size increase. If
it helps - everyone should assume that their pet feature is included in
a hard fork or, if you prefer, that no other features are included in a
hard fork.

On 05/06/15 23:11, Matt Whitlock wrote:
> I'm not so much opposed to a block size increase as I am opposed to a hard 
> fork. My problem with a hard fork is that everyone and their brother wants to 
> seize the opportunity of a hard fork to insert their own pet feature, and 
> such a mad rush of lightly considered, obscure feature additions would be 
> extremely risky for Bitcoin. If it could be guaranteed that raising the block 
> size limit would be the only incompatible change introduced in the hard fork, 
> then I would support it, but I strongly fear that the hard fork itself will 
> become an excuse to change other aspects of the system in ways that will have 
> unintended and possibly disastrous consequences.
> 

--
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] Block Size Increase

[Matt Corallo]

Replies inline.

On 05/06/15 22:44, Tier Nolan wrote:
> On Wed, May 6, 2015 at 11:12 PM, Matt Corallo  <mailto:bitcoin-l...@bluematt.me>> wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.
-snip-
> The question being discussed is what is the maximum block size merchants
> and users will accept.  This puts a reasonable limit on the maximum size
> miners can increase the block size to.
> 
> In effect, the block size is set by the minimum of the miner's and the
> merchants/user's size.min(miner, merchants/users).

Indeed, "the bitcoin community of users and miners can decide to do
whatever they want", but this is univeral - "they" could decide whatever
they want if "they" want to hardfork. That said, "we" should be having a
rigorous technical discussion about whether it is sane to recommend a
given course of action by releasing software which makes it happen.

> 
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
> 
> 
> Would you accept a rule that the maximum size is 20MB (doubling every 2
> years), but that miners have an efficient method for choosing a lower size?
> 
> If miners could specify the maximum block size in their block headers,
> then they could coordinate to adjust the block size.  If 75% vote to
> lower the size, then it is lowered and vice versa for raiding.
> 
> Every 2016 blocks, the votes are counter.  If the 504th lowest of the
> 2016 blocks is higher than the previous size, then the size is set to
> that size.  Similarly, if the 504th highest is lower than the previous
> size, it becomes the new size.
> 
> There could be 2 default trajectories.  The reference client might
> always vote to double the size every 4 years.
> 
> To handle large blocks (>32MB) requires a change to the p2p protocol
> message size limits, or a way to split blocks over multiple messages.
> 
> It would be nice to add new features to any hard-fork.
> 
> I favour adding an auxiliary header.  The Merkle root in the header
> could be replaced with hash(merkle_root | hash(aux_header)).  This is a
> fairly simple change, but helps with things like commitments.  One of
> the fields in the auxiliary header could be an extra nonce field.  This
> would mean fast regeneration of the merkle root for ASIC miners.  This
> is a pretty simple change.

The point of the hard block size limit is exactly because giving miners
free rule to do anything they like with their blocks would allow them to
do any number of crazy attacks. The incentives for miners to pick block
sizes are no where near compatible with what allows the network to
continue to run in a decentralized manner.

--
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] Block Size Increase

[Matt Corallo]

Recently there has been a flurry of posts by Gavin at
http://gavinandresen.svbtle.com/ which advocate strongly for increasing
the maximum block size. However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.

Block size is a question to which there is no answer, but which
certainly has a LOT of technical tradeoffs to consider. I know a lot of
people here have varying levels of strong or very strong opinions about
this, and the fact that it is not being discussed in a technical
community publicly anywhere is rather disappointing.

So, at the risk of starting a flamewar, I'll provide a little bait to
get some responses and hope the discussion opens up into an honest
comparison of the tradeoffs here. Certainly a consensus in this kind of
technical community should be a basic requirement for any serious
commitment to blocksize increase.

Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).

This allows the well-funded Bitcoin ecosystem to continue building
systems which rely on transactions moving quickly into blocks while
pretending these systems scale. Thus, instead of working on technologies
which bring Bitcoin's trustlessness to systems which scale beyond a
blockchain's necessarily slow and (compared to updating numbers in a
database) expensive settlement, the ecosystem as a whole continues to
focus on building centralized platforms and advocate for changes to
Bitcoin which allow them to maintain the status quo[1].

Matt

[1] https://twitter.com/coinbase/status/595741967759335426

--
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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Matt Corallo]

On 04/21/15 07:59, Peter Todd wrote:
> On Mon, Mar 16, 2015 at 10:22:13PM +0000, Matt Corallo wrote:
>> In building some CLTV-based contracts, it is often also useful to have a
>> method of requiring, instead of locktime-is-at-least-N,
>> locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
>> an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
>> stack element, adds the height of the output being spent and then has
>> identical semantics to CLTV.
> 
> Depending on what you mean by "identical" this isn't actually reorg
> safe. For instance consider this implementation:
> 
> nLockTime = stack[-1] + prevout.nHeight
> if (nLockTime > txTo.nLockTime):
> return False
> 
> Used with this scriptPubKey:
> 
> 10 RCLTV DROP  CHECKSIG
> 
> If I create that output in tx1 which is mined at height 42 I can spend
> it in a tx2 at height > 42+10 by setting tx2's nLockTime to >42+10, for
> instance 53. However if a reorg happens and tx1 ends up at height 43
> after the reorg I'm stuck - tx2's nLockTime is set at 42.
> 
> Thus RCTLV is only reorg safe if the height is compared against the
> actual block height of the block containing the spending transaction,
> not the spending transaction's nLockTime.

Yes, as discussed on IRC months ago when the first email was sent, the
assumption is that you would require N be at least 100. That way you are
reorg safe up to the same limit as coinbase transactions, which are also
only reorg safe in the case of no 100-block reorgs. Its not ideal in
some contracts, but keeping the no-second-nLockTime-equivalent property
is worth it IMO, and its still incredibly useful in many contracts.

>> A slightly different API (and different name) was described by maaku at
>> http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
>> which does a better job of saving softfork-available opcode space.
>>
>> There are two major drawbacks to adding such an operation, however.
>>
>> 1) More transaction information is exposed inside the script (prior to
>> CLTV we only had the sigchecking operation exposed, with a CLTV and
>> RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).
>>
>> 2) Bitcoin Core's mempool invariant of "all transactions in the mempool
>> could be thrown into one overside block and aside from block size, it
>> would be valid" becomes harder to enforce. Currently, during reorgs,
>> coinbase spends need checked (specifically, anything spending THE
>> coinbase 100 blocks ago needs checked) and locktime transactions need
>> checked. With such a new operation, any script which used this new
>> opcode during its execution would need to be re-evaluated during reorgs.
> 
> Yup, definitely kinda ugly.
> 
> If the above style of RCTLV was used, one possibility might be to make
> the relative locktime difference be required to be at least 100 blocks,
> same as the coinbase maturity, and just accept that it's probably not
> going to cause any problems, but could in an extremely big reorg. But
> re-orgs that big might be big enough that we're screwed anyway...
> 
> With the 100 block rule, during a sufficiently large reorg that
> coinbases become unavailble, simply disconnect entire blocks - all
> txouts created by them.
> 
>> I think both of these requirements are reasonable and not particularly
>> cumbersome, and the value of such an operation is quite nice for some
>> protocols (including settings setting up a contest interval in a
>> sidechain data validation operation).
> 
> So to be clear, right now the minimal interface to script execution is
> simply:
> 
> int bitcoinconsensus_verify_script(const unsigned char *scriptPubKey, 
> unsigned int scriptPubKeyLen,
>const unsigned char *txTo, 
> unsigned int txToLen,
>unsigned int nIn, unsigned int flags, 
> bitcoinconsensus_error* err);
> 
> Where scriptPubKey is derived from the unspent coin in the UTXO set and
> txTo is the transaction containing the script that is being executed.
> The UTXO set itself currently contains CCoins entries, one for each
> transaction with unspent outputs, which basically contain:
> 
> nVersion - tx nVersion
> nHeight  - Height of the block the transaction is contained in.
> vout - Unspent CTxOut's of the transaction.
> 
> The block nTime isn't directly available through the UTXO set, although
> it can be found in the block headers. This does require nodes to have
> the block headers, but at 4

[Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Matt Corallo]

In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the height of the output being spent and then has
identical semantics to CLTV.
A slightly different API (and different name) was described by maaku at
http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
which does a better job of saving softfork-available opcode space.

There are two major drawbacks to adding such an operation, however.

1) More transaction information is exposed inside the script (prior to
CLTV we only had the sigchecking operation exposed, with a CLTV and
RCLTV/OP_CHECK_MATURITY_VERIFY we expose two more functions).

2) Bitcoin Core's mempool invariant of "all transactions in the mempool
could be thrown into one overside block and aside from block size, it
would be valid" becomes harder to enforce. Currently, during reorgs,
coinbase spends need checked (specifically, anything spending THE
coinbase 100 blocks ago needs checked) and locktime transactions need
checked. With such a new operation, any script which used this new
opcode during its execution would need to be re-evaluated during reorgs.

I think both of these requirements are reasonable and not particularly
cumbersome, and the value of such an operation is quite nice for some
protocols (including settings setting up a contest interval in a
sidechain data validation operation).

Thoughts?

Matt

On 10/01/14 13:08, Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY. The BIP, reproduced below, can be found at:
> 
> 
> https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki
> 
> The reference implementation, including a full-set of unittests for the
> opcode semantics can be found at:
> 
> https://github.com/petertodd/bitcoin/compare/checklocktimeverify
> 
> 
>   BIP:
>   Title: OP_CHECKLOCKTIMEVERIFY
>   Author: Peter Todd 
>   Status: Draft
>   Type: Standards Track
>   Created: 2014-10-01
> 
> 
> ==Abstract==
> 
> This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin
> scripting system that allows a transaction output to be made unspendable until
> some point in the future.
> 
> 
> ==Summary==
> 
> CHECKLOCKTIMEVERIFY re-defines the existing NOP2 opcode. When executed it
> compares the top item on the stack to the nLockTime field of the transaction
> containing the scriptSig. If that top stack item is greater than the 
> transation
> nLockTime the script fails immediately, otherwise script evaluation continues
> as though a NOP was executed.
> 
> The nLockTime field in a transaction prevents the transaction from being mined
> until either a certain block height, or block time, has been reached. By
> comparing the argument to CHECKLOCKTIMEVERIFY against the nLockTime field, we
> indirectly verify that the desired block height or block time has been 
> reached;
> until that block height or block time has been reached the transaction output
> remains unspendable.
> 
> 
> ==Motivation==
> 
> The nLockTime field in transactions makes it possible to prove that a
> transaction output can be spent in the future: a valid signature for a
> transaction with the desired nLockTime can be constructed, proving that it is
> possible to spend the output with that signature when the nLockTime is 
> reached.
> An example where this technique is used is in micro-payment channels, where 
> the
> nLockTime field proves that should the receiver vanish the sender is 
> guaranteed
> to get all their escrowed funds back when the nLockTime is reached.
> 
> However the nLockTime field is insufficient if you wish to prove that
> transaction output ''can-not'' be spent until some time in the future, as 
> there
> is no way to prove that the secret keys corresponding to the pubkeys 
> controling
> the funds have not been used to create a valid signature.
> 
> 
> ===Escrow===
> 
> If Alice and Bob jointly operate a business they may want to
> ensure that all funds are kept in 2-of-2 multisig transaction outputs that
> require the co-operation of both parties to spend. However, they recognise 
> that
> in exceptional circumstances such as either party getting "hit by a bus" they
> need a backup plan to retrieve the funds. So they appoint their lawyer, Lenny,
> to act as a third-party.
> 
> With a standard 2-of-3 CHECKMULTISIG at any time Lenny could conspire with
> either Alice or Bob to steal the funds illegitimately. Equally Lenny may 
> prefer
> not to have immediate access to the funds to discourage bad actors from
> attempting to get the secret keys from him by force.
> 
> However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
> the form:
> 
> IF
>  CHECKLOCKTIMEV

Re: [Bitcoin-development] Area of Focus

[Matt Corallo]

Well, some ISPs, when they see an IP address serving malware, will
(apparently) simply replace DNS results for anything returning that IP
with a warning page.

One solutions is to just blindly block everything with HTTP(S), as
Christian has done, but this is a rather ugly solution, since many
perfectly good nodes will get caught in the crossfire. Hiding what
actual IPs we're returning in the results seems much cleaner, despite
being an ugly hack.

On 12/20/14 11:14, Jeremy Spilman wrote:
> On Sat, Dec 20, 2014 at 08:57:53AM +0000, Matt Corallo wrote:
>>> There was recently some discussion around dnsseeds. Currently some
>>> dnsseeds are getting blocked by ISPs because the hosts they pick up
>>> (which run bitcoin core nodes) often run rather web servers alongside
>>> which serve malware or whatever else and thus end up on IP-based malware
>>> blacklists.
> 
> On Sat, 20 Dec 2014 02:08:17 -0800, Roy Badami  wrote:
>> Why would we want to have anything to do with people who are hosting
>> malware?  Or do I misunderstand?
> 
> It sounds like Matt is saying the nodes the dnsseed is pointing to as  
> valid full nodes, that those IPs are hosting the malware. Since the  
> dnsseed picks up any stable nodes it can find without auditing, it's  
> perhaps not surprising some servers in the world are running a full node  
> and a malware server together.
> 
> I guess what confused me about this though, how are ISPs reading the  
> dnsseed's node list, scanning *those* IPs for malware, and then ending up  
> blocking the dnsseed? Seems like a pretty winding path to end up blocking  
> a DNS server?
> 
> Since when do ISPs null-route a DNS server for happening to resolve some  
> domains to IPs which happen to also be hosting some malware? Null-route  
> those endpoint IPs sure, but the DNS server too? I guess there was that  
> incident of Microsoft taking over No-IP.com -- are dnsseeds being blocked  
> ostensibly because they are acting as dyanamic DNS infrastructure for  
> malware sites?
> 
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Area of Focus

[Matt Corallo]

There was recently some discussion around dnsseeds. Currently some
dnsseeds are getting blocked by ISPs because the hosts they pick up
(which run bitcoin core nodes) often run rather web servers alongside
which serve malware or whatever else and thus end up on IP-based malware
blacklists.

Of course we really dont want to move off of DNS because it has this big
built-in anonymity network where the DNS seed servers only get
information about your ISP, not you, and its cached so you dont get as
much information about how many users are making those requests.

A potential solution might be supporting some subdomain which has
results XORed with some constant mask to tweak the real IP.

Additionally, it might be cool to stuff a TXT//whatever record with
a signature of the results provided by the DNSseed operator.

Matt

On 12/20/14 07:42, Will Bickford wrote:
> Hi all, I'm looking to help with Bitcoin core development in my spare
> time (a few hours per week).
> 
> A little bit about me:
> * I use C++ and Qt daily
> * I love to automate and enhance software systems
> * I enjoy root causing and fixing issues
> 
> I saw Gavin say we needed help with testing in a Reddit AMA a while ago.
> I'm curious where I can make the best impact. Any feedback would be
> appreciated. Thanks!
> 
> Will Bickford
> "In Google We Trust"
> 
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] ACK NACK utACK "Concept ACK"

[Matt Corallo]

Also utACK ("untested ack") and "tested ack" when people are being explicit.

On 12/09/14 21:14, Sergio Lerner wrote:
> Is that the full terminology or are there more acronyms?
> Is this documented somewhere?
> 
> Best regards,
>  Sergio.
> 
> 
> 
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

[Matt Corallo]

Depends, without BIP62 a /lot/ of the even basic contracts that people
want to use today (or wanted to use 18 months ago) are unusable, in
fact, without BIP62, the atomic swaps suggested as important for
sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
its a very long-term thing, so I'm not sure about making people wait for
a large hardfork just to use payment channels.

Also, I echo the difficulty of writing consensus-compatible code and
highly suggest anyone with money behind an implementation that is doing
script verification in code that isnt Bitcoin Core rethink that decision.

Matt

On 11/06/14 21:58, Tamas Blummer wrote:
> Thanks Peter,
> 
> Having tried to write a bug-for-bug compatible code with Satoshi, I can only 
> second that it is rather close to impossible. 
> 
> The aim of BIP62 is noble, still it does not feel right for me to increase 
> the complexity of the code with e.g. soft-fork-ready versioning.
> Freezing the consensus code, studying its bugs appears more appropriate to 
> me. What we learn could define a hard fork or a better
> chain we migrate to as discussed by blockstream.
> 
> Tamas Blummer

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

Re: [Bitcoin-development] DS Deprecation Window

[Matt Corallo]

It is a very bad idea to delay relaying/accepting blocks based on
information which is only local to your node (ie would create the
ability for people to split the network by sending out lots of
double-spends to different parts of the network at the same time). Thus,
miners are incentivized to go connect to everyone on the network and
look for double-spends, not including them in their blocks to avoid
being delayed (which is OK, except having to connect to everyone is bad).
There is a related concept of "discouraging" blocks which generally only
refers to mining on a previous block, but you have to be careful doing
that so you dont break consensus.

On 10/27/14 19:58, Tom Harding wrote:
> Greetings Bitcoin Dev,
> 
> This is a proposal to improve the ability of bitcoin users to rely on 
> unconfirmed transactions.  It can be adopted incrementally, with no hard 
> or soft fork required.
> 
> https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
> 
> Your thoughtful feedback would be very much appreciated.
> 
> It is not yet implemented anywhere.
> 
> Cheers,
> Tom Harding
> CA, USA
> 
> 
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

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

Re: [Bitcoin-development] Proposed BIP status changes

[Matt Corallo]

On 10/15/14 08:47, Wladimir wrote:
> These BIPs should go to Final state - they are implemented all over
> the place, and are thus entirely fixed in place now. Any changes would
> require a new BIP as amandment:
> 
> - BIP 14 (BIP Protocol Version and User Agent)
> 
> - BIP 21 (URI Scheme)

ACK.

> - BIP 22 (getblocktemplate - Fundamentals)
> 
> - BIP 31 (Pong Message)
> 
> - BIP 34 (Block v2, Height in coinbase)
> 
> - BIP 35 (mempool message)
> 
> - BIP 37 (Bloom filtering)
> 
> Let me know if you (don't) agree.
> 
> Wladimir
> 
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

[Matt Corallo]

See-also: this related bug on Curve25519 and some MS Research curves
that generated far more discussion.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

Matt

On 10/13/14 10:01, Melvin Carvalho wrote:
> FYI:
> 
> This is an issue I filed related to adding secp256k1 into Web Crypto API
> which will be implemented natively in (some) web browsers.
> 
> If there is any feedback from crypto implementers, please feel free to
> add comments to this thread:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=2
> 
> -- Forwarded message --
> From: ** mailto:bugzi...@jessica.w3.org>>
> Date: 13 October 2014 09:18
> Subject: [Bug 2] Named Curve Registry (adding secp256k1)
> To: melvincarva...@gmail.com 
> 
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=2
> 
> Myron Davis mailto:myr...@gmail.com>> changed:
> 
>What|Removed |Added
> 
>  Status|RESOLVED|REOPENED
>  CC||myr...@gmail.com
> 
>  Resolution|NEEDSINFO   |---
> 
> --- Comment #2 from Myron Davis  > ---
> Could this be looked at again?
> 
> Last response was waiting for feedback from crypto implementors.
> 
> Currently secp256k1 is supported in the following SSL/TLS libraries now
> Botan
> NSS
> openssl
> LibreSSL
> PolarSSL
> JSSE
> 
> The three other curves are all all have parameters which do not define
> how they
> were generated.  secp256k1 curve has some great advantages in faster
> signature
> verification and how the values were determined for the curve.  (i.e. not
> random).
> 
> http://www.ietf.org/rfc/rfc4492
> 
> The curve has had a lot of eyes on it with lots of hardware and software
> supporting this curve.
> 
> With discovery of backdoor's in NIST's random number generator
> (https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I
> would
> like to see a determined parameter curve instead of a "random" curve option.
> 
> Thanks
> 
> --
> You are receiving this mail because:
> You reported the bug.
> 
> 
> 
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Decreasing block propagation time

[Matt Corallo]

It already is https://bitcointalk.org/index.php?topic=766190.0;all.
Well, ok, a variation on the idea is.

Matt

On 10/02/14 04:39, Rebroad (sourceforge) wrote:
> https://bitcointalk.org/index.php?topic=145066.0
> 
> The idea proposed in the above article seemed like an excellent idea.
> What is holding this up from being implemented? Does someone need to
> code it, or write a BIP first?
> 
> 
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] RIP Hal Finney

[Matt Corallo]

I'm sure many of you have already seen this, but Hal Finney passed away
on Tuesday. While his body is being cryogenically preserved, we should
all take a moment to thank Hal for everything he did for the cypherpunk
community, specifically helping hugely in the early days of Bitcoin as
well as PGP.

Matt

http://lists.extropy.org/pipermail/extropy-chat/2014-August/082585.html

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Matt Corallo]

For those who have been using this to get faster relays to/from the
network, you may have noticed some instability recently. This is because
the nodes were all being upgraded to use some new relaying code which
should cut down on duplicate transaction relaying in blocks, improving
relay speed within the network and to nodes which run new clients which
use the same relaying technique. Essentially instead of relaying entire
blocks, nodes keep a rolling window of recently-seen transactions and
skip those when relaying blocks.

You can find a simple client which connects to a local bitcoind and a
relay node at http://bitcoin.ninja/RelayNodeClient.jar and the source
for the whole thing at https://github.com/TheBlueMatt/RelayNode.

Matt

On 11/06/13 05:50, Matt Corallo wrote:
> Recently, there has been a reasonable amount of discussion about the
> continued fragility of the public Bitcoin network on IRC and elsewhere
> (1). To this extent, I'm organizing a system of peering between nodes in
> the network by creating a system of high-speed relay nodes for miners
> and merchants/exchanges. This system will a) act as a fallback in the
> case that the public Bitcoin network encounters issues and b) decrease
> block propagation times between miners.
> It is NOT designed to in any way replace or decrease the need for the
> public Bitcoin P2P network. It is NOT any kind of attempt at
> centralization, and I still encourage interested parties to establish
> their own private peering agreements with large miners as needed.
> 
> Currently the network consists of one specially-designed relay node, but
> I hope to bring more online in the coming days.
> 
> This network is open to everyone via a few public relay nodes, but also
> will have nodes which are made available only to large miners and
> merchants/exchanges to mitigate the ability of malicious parties to DoS
> the network.
> 
> To peer with the public relay nodes, simply select the closest region
> out of us-west (West Coast US), us-east (East Coast US), eu (Western
> Europe), au (Australia), or jpy (Japan) and add
> public.REGION.relay.mattcorallo.com to your addnode list. Note that
> since all of the relay nodes will relay between each other, you gain no
> latency advantage by peering with more than the closest node to you (and
> currently all the regions map to one node, so there they're redundant
> anyway).
> 
> For each relay node, you can connect to either port 8334 or 8335.
> Connecting on port 8334 will relay only blocks, and port 8335 will relay
> both blocks and transactions. The relay nodes will request any
> transactions which appear in your invs no matter which port you connect to.
> 
> Relay node details:
>  * The relay nodes do some data verification to prevent DoS, but in
> order to keep relay fast, they do not fully verify the data they are
> relaying, thus YOU SHOULD NEVER mine a block building on top of a
> relayed block without fully checking it with your own bitcoin validator
> (as you would any other block relayed from the P2P network).
>  * The relay nodes do not follow the standard inv-getdata-tx/block flow,
> but instead relay transactions/blocks immediately after they have done
> their cursory verification. They do keep some track of whether or not
> your nodes claim to have seen the transactions/blocks before relaying,
> but you may see transactions/blocks being sent which you already have
> and have not requested, if this is a problem for you due to bandwith
> issues, you should reconsider your bandwith constraints and/or are
> peering with too many nodes.
>  * The relay nodes will all relay among themselves very quickly, so
> there is no advantage to peering with as many relay nodes as you can
> find, in fact, the increased incoming bandwidth during block relay
> spikes may result in higher latency for your nodes.
>  * The relay nodes are NOT designed to ensure that you never miss data,
> and may fail to relay some transactions. Additionally, because the relay
> nodes do not respond to standard getdata requests, if you miss a relay
> and then reconnect, that data will not be sent again by the relay nodes.
> The relay nodes are NOT a replacement for having peers on the standard
> P2P network, they are only there to augment the existing P2P network.
> 
> If you are a merchant/exchange/large miner/other important node operator
> and wish to gain access to additional domain names which map to relay
> nodes with fewer peers, please fill out the form at
> https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform
> 
> You can find the source for the relay nodes at
> https://github.com/TheBlueMatt/RelayNode
> 
> If you have any comments/concerns/suggestions, please do not hesitate to
> email bitcoin-peer

Re: [Bitcoin-development] Policy for DNS seeds

[Matt Corallo]

Absolutely not. Time and time again we've seen "anonymized" data sets
that dont work out so well. I'm sure its possible to do but there are
too many factors and we dont want to succumb to this.

Also, these generally look good (and essentially the same as what had
been a gentleman's agreement for those who read IRC actively, the
purpose of codifying this is essentially that we ended up adding a lot
of DNS Seeds run by people who dont follow development closely and/or
are not aware of the issues involved).

Thanks for writing this up,
Matt

On 07/21/14 13:53, Christian Decker wrote:
> How about research projects into node distribution? Specifically I
> wonder whether the collection and analysis of DNS query origin is
> allowed when queries are anonymized and aggregated. This would prevent
> the identification of a single user, which I assume is the rationale
> for point 4.
> 
> Other than that I'm perfectly fine with accepting the rules for
> seed.bitcoinstats.com
> 
> Regards,
> Christian
> --
> Christian Decker
> 
> 
> On Mon, Jul 21, 2014 at 2:43 PM, Wladimir  wrote:
>> We've established a few basic rules for the DNS seeds as used in the
>> Bitcoin Core software. See below.
>>
>> If you run one of the DNS seeds please reply to this and let us know
>> whether you agree to these terms. if you think some requirements are
>> unreasonable let us know too. If we haven't heard from you by
>> 2014-08-04 we will remove your DNS seed from the list of defaults.
>>
>> Expectations for DNSSeed operators
>> 
>>
>> Bitcoin Core attempts to minimize the level of trust in DNS seeds,
>> but DNS seeds still pose a small amount of risk for the network.
>> Other implementations of Bitcoin software may also use the same
>> seeds and may be more exposed. In light of this exposure this
>> document establishes some basic expectations for the expectations
>> for the operation of dnsseeds.
>>
>> 0. A DNSseed operating organization or person is expected
>> to follow good host security practices and maintain control of
>> their serving infrastructure and not sell or transfer control of their
>> infrastructure. Any hosting services contracted by the operator are
>> equally expected to uphold these expectations.
>>
>> 1. The DNSseed results must consist exclusively of fairly selected and
>> functioning Bitcoin nodes from the public network to the best of the
>> operators understanding and capability.
>>
>> 2. For the avoidance of doubt, the results may be randomized but must not
>> single-out any group of hosts to receive different results unless due to an
>> urgent technical necessity and disclosed.
>>
>> 3. The results may not be served with a DNS TTL of less than one minute.
>>
>> 4. Any logging of DNS queries should be only that which is necessary
>> for the operation of the service or urgent health of the Bitcoin
>> network and must not be retained longer than necessary or disclosed
>> to any third party.
>>
>> 5. Information gathered as a result of the operators node-spidering
>> (not from DNS queries) may be freely published or retained, but only
>> if this data was not made more complete by biasing node connectivity
>> (a violation of expectation (1)).
>>
>> 6. Operators are encouraged, but not required, to publicly document
>> the details of their operating practices.
>>
>> 7. A reachable email contact address must be published for inquiries
>> related to the DNSseed operation.
>>
>> If these expectations cannot be satisfied the operator should
>> discontinue providing services and contact the active Bitcoin
>> Core development team as well as posting on bitcoin-development.
>>
>> Behavior outside of these expectations may be reasonable in some
>> situations but should be discussed in public in advance.
>>
>> 
>>
>> See
>> https://github.com/bitcoin/bitcoin/pull/4566
>>
>> Wladimir
> 
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-devel

Re: [Bitcoin-development] DNS seeds unstable

[Matt Corallo]

Oops, missed the lost

On May 16, 2014 3:04:40 PM EDT, Matt Corallo  wrote:
>Oh, I missed that this was the testnet seed. Yea, that one never got
>set
>up properly and was just pointing to a static seed node (that is now
>down...). The mainnet seed actually works.
>
>On 05/16/14 19:01, Laszlo Hanyecz wrote:
>> Matt,
>> 
>> I get the same:
>> 
>> $ host testnet-seed.bluematt.me
>> testnet-seed.bluematt.me is an alias for
>bitcoin-seednode.bluematt.me.
>> bitcoin-seednode.bluematt.me is an alias for desktopv2.bluematt.me.
>> desktopv2.bluematt.me has address 152.23.202.18
>> 
>> 
>> $ dig +trace desktopv2.bluematt.me. any
>> 
>> ; <<>> DiG 9.8.5-P1 <<>> +trace desktopv2.bluematt.me. any
>> ;; global options: +cmd
>> .451792  IN  NS  l.root-servers.net.
>> .451792  IN  NS  d.root-servers.net.
>> .451792  IN  NS  e.root-servers.net.
>> .451792  IN  NS  c.root-servers.net.
>> .451792  IN  NS  j.root-servers.net.
>> .451792  IN  NS  b.root-servers.net.
>> .451792  IN  NS  h.root-servers.net.
>> .451792  IN  NS  f.root-servers.net.
>> .451792  IN  NS  g.root-servers.net.
>> .451792  IN  NS  a.root-servers.net.
>> .451792  IN  NS  i.root-servers.net.
>> .451792  IN  NS  m.root-servers.net.
>> .451792  IN  NS  k.root-servers.net.
>> ;; Received 512 bytes from 2a00:5540:5014::1#53(2a00:5540:5014::1) in
>2 ms
>> 
>> me.  172800  IN  NS  b2.me.afilias-nst.org.
>> me.  172800  IN  NS  ns2.nic.me.
>> me.  172800  IN  NS  a0.cctld.afilias-nst.info.
>> me.  172800  IN  NS  b0.cctld.afilias-nst.org.
>> me.  172800  IN  NS  c0.cctld.afilias-nst.info.
>> me.  172800  IN  NS  d0.cctld.afilias-nst.org.
>> me.  172800  IN  NS  a2.me.afilias-nst.info.
>> me.  172800  IN  NS  ns.nic.me.
>> ;; Received 509 bytes from 2001:7fe::53#53(i.root-servers.net) in
>1807 ms
>> 
>> bluematt.me. 86400   IN  NS  ns.bluematt.me.
>> bluematt.me. 86400   IN  NS  ns3.he.net.
>> bluematt.me. 86400   IN  NS  ns4.he.net.
>> bluematt.me. 86400   IN  NS  ns1.rollernet.us.
>> bluematt.me. 86400   IN  NS  ns2.rollernet.us.
>> ;; Received 162 bytes from
>2001:500:26::1#53(b0.cctld.afilias-nst.org) in 118 ms
>> 
>> desktopv2.bluematt.me.   3600IN  A   152.23.202.18
>> bluematt.me. 86400   IN  NS  ns4.he.net.
>> bluematt.me. 86400   IN  NS  ns3.he.net.
>> bluematt.me. 86400   IN  NS  ns2.rollernet.us.
>> bluematt.me. 86400   IN  NS  ns1.rollernet.us.
>> bluematt.me. 86400   IN  NS  ns.bluematt.me.
>> ;; Received 178 bytes from 2607:fe70:0:4::b#53(ns2.rollernet.us) in
>126 ms
>> 
>> 
>> 
>> 
>> Thanks,
>> Laszlo
>> 
>> 
>> On May 16, 2014, at 6:53 PM, Matt Corallo 
>wrote:
>> 
>>> This is very strange...when did you run this test and can anyone
>else
>>> reproduce this?
>>>
>>> Matt
>>>
>>> On 05/15/14 11:50, Andreas Schildbach wrote:
>>>> testnet-seed.bluematt.me   OK (but only returns one node)
>>>
>>>
>--
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For
>FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>> Get unparalleled scalability from the best Selenium testing platform
>available
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> ___
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 


--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] DNS seeds unstable

[Matt Corallo]

This is very strange...when did you run this test and can anyone else
reproduce this?

Matt

On 05/15/14 11:50, Andreas Schildbach wrote:
> testnet-seed.bluematt.me  OK (but only returns one node)

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Ubuntu LTS Packaging?

[Matt Corallo]

Hmm? It's up to date... 0.9.1 doesn't change anything for 
dynamically-linked-to-openssl builds.

Matt

On April 12, 2014 10:26:07 AM EDT, Oliver Egginger  wrote:
>Hello,
>
>so far, nothing yet?
>
>See: https://launchpad.net/~bitcoin/
>
>I'm developing currently a LiveCD for hot/cold wallet management on
>Ubuntu LTS basis. For critical vulnerabilities I have to provide timely
>updates. I have now decided to maintain my own repository for this
>project. If there are better alternatives, let me know.
>
>regards
>Oliver
>
>--
>Put Bad Developers to Shame
>Dominate Development with Jenkins Continuous Integration
>Continuously Automate Build, Test & Deployment 
>Start a new project now. Try Jenkins in the cloud.
>http://p.sf.net/sfu/13600_Cloudbees
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

[Matt Corallo]

I move to reclaim bip 42 as reserved for a bip containing either a reference to 
musical dolphins or towels in the name.

Matt

On April 1, 2014 5:47:34 PM EDT, Gregory Maxwell  wrote:
>On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille 
>wrote:
>> In case there are no further objections (excluding from people who
>> disagree with me), I'd like to request a BIP number for this. Any
>> number is fine, I guess, as long as it's finite.
>
>With ten people commenting on this proposal there are quite a few ways
>in which you could partition their views. Only one possible integer
>partitioning has everyone in the same partition, so consensus seems
>unlikely.
>
>But owing to a rather large bribe (or at least not less large than any
>other offered by competing parties) I hereby assign BIP 42 for this
>proposal.
>
>--
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

[Matt Corallo]

I disagree with this proposal both in spirit and in practice.

We all know satoshi was the best programmer like no one ever was. Clearly he 
intended this monetary supply from the beginning, who are we but mere mortals 
to go against satoshi's will?

Also, should we really do this with a soft fork when we can take this 
opportunity to redesign the whole system with a hard fork? This is out chance 
to switch to a whole new script engine!

Matt

On April 1, 2014 3:00:07 PM EDT, Pieter Wuille  wrote:
>Hi all,
>
>I understand this is a controversial proposal, but bear with me please.
>
>I believe we cannot accept the current subsidy schedule anymore, so I
>wrote a small draft BIP with a proposal to turn Bitcoin into a
>limited-supply currency. Dogecoin has already shown how easy such
>changes are, so I consider this a worthwhile idea to be explored.
>
>The text can be found here: https://gist.github.com/sipa/9920696
>
>Please comment!
>
>Thanks,
>
>-- 
>Pieter
>
>--
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Matt Corallo]

We already have a wonderful system for secure updating - gitian-downloader. We 
just neither use it not bother making actual gitian releases so anyone can use 
it to verify signatures of downloads.

Jeremy Spilman  wrote:
>I didn't know about the dedicated server meltdown, it wasn't any of my 
>
>infra. Anyway, my previous offer still stands.
>
>One less 'security theater' approach would be if we could provide  
>forward-validation of updates using the blockchain. It's always going
>to  
>be up to the user the first time they install the wallet to verify the 
>
>provenance of the binaries/source. From that point forward, we could
>make  
>it easier if the wallet could detect updates and prove they were valid.
>
>This could be as simple as hard-coding a public key into the client and
> 
>checking a signature on the new binaries. But it could also be more  
>interesting...
>
>For example, a well known address on the blockchain corresponds to  
>multi-sig with keys controlled by developers (or whatever key policy
>the  
>release team wants to impose). A spend from that address announces a
>new  
>release, and includes the expected hash of the file.
>
>You would probably need some way to handle the different release
>targets.  
>A more rigorous approach could identify all the various releases in
>terms  
>of a BIP32 xpubkey whose branches would correspond to the different  
>release trains and platform builds. Spends from a node announce the  
>release and the expected hash.
>
>This provides zero benefit if the wallet software is already
>compromised,  
>but I think this would allow trusted automatic update notification, and
>a  
>trusted way to deliver the expected hashes. It also might resolve some
>of  
>the consternation around when a release is truly "released", if that's 
>
>really a problem.
>
>I'm not sure how far along the slope you would want to go; 1)
>announcing  
>updates in the UI, 2) providing a button the user could click to verify
>a  
>binary matches its expected hash, 3) click to download and verify the  
>upgrade matches the expected hash, 4) click to upgrade
>
>Formalizing the release process around a set of privkeys (or split
>shares  
>of keys) may raise its own set of questions.
>
>For the download itself, I've heard the advocates of announcing  
>availability on the blockchain leading to a BitTorrent magnet link, but
>I  
>also understand objections to adding an entire BitTorrent stack into a 
>
>wallet.
>
>On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn  wrote:
>
>>> The site was actually moved onto a dedicated server temporarily and
>it
>>> melted down under the load. I wouldn't call that no progress.
>>
>> Oh, it did? When was that? I must have missed this excitement :)
>>Any idea how much load it had?
>>
>>> Perhaps I wasn't clear on the point I was making Drak's threat model
>>> is not improved in the slightest by SSL. It would be improved by
>>> increasing the use of signature checking, e.g. by making it easier.
>>
>> Well, that depends. If you watch Applebaums talk he is pushing TLS  
>> pretty hard, and saying that based on the access to the source docs
>some  
>> of >their MITM attacks can't beat TLS. It appears that they have the 
>
>> capability to do bulk MITM and rewrite of downloads as Drak says but 
>
>> *not* when >TLS is present, that would force more targeted attacks.
>So  
>> to me that implies that TLS does raise the bar and is worth doing.
>>
>> However if we can't find a server that won't melt under the load,
>then  
>> that'd be an issue. We could consider hosting downloads on AppEngine
>or  
>> >something else that can handle both high load and TLS.
>
>
>
>--
>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
--
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 ma

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Matt Corallo]

I'm not sure where you got the idea that Bitcoin-development was ideal for 
hiring scamcoin developers, but it's not. Most of the people on this list are 
smart enough to realize posts like this are dumb ideas backed by greedy 
"entrepreneurs" who don't understand the system they're trying to improve 99.9% 
of the time.


Evan Duffield  wrote:
>Hello,
>
>We’re a startup looking for 1 or 2 really good C++ programmer that is
>familiar with the bitcoin internals to help with a for-profit startup.
>
>We will be able to provide more information about the project after
>signing
>a non-compete/non-disclosure agreement. Our coin will be one of the
>truly
>unique coins that are not just a clone of the original Bitcoin code. In
>short the project will be a merge-mined altcoin that will provide a
>very
>useful service to the whole crypto-coin ecosystem.
>
>If you have added any features to Bitcoin or related technologies this
>is a
>definite bonus. Please include information about the work you’re done
>in
>the space.
>
>We have detailed plans on how to implement it and the roles we are
>looking
>to fill. If interested please email eduffiel...@gmail.com with a
>description of your work experience and we’ll vett the applications and
>share our plans to see if you’re interested.
>
>Thanks,
>
>Evan & Kyle
>Hawk Financial Group, LLC
>
>
>
>
>--
>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
--
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] Bitcoin difficulty sanity check suggestion

[Matt Corallo]

An attacker with some small hashpower isolates you (as an individual)
from the network by MITMing your network. You just switch the the
attackers chain as if nothing happened because of the network rule
that defines it as OK. Today, you will see that you're behind and warn
the user.

Was it really so hard to write a three-sentence paragraph to clarify
the attack instead of insulting people? Still, posting ideas here
without spending time to ensure you understand the Bitcoin network
well is frowned upon.

Matt

On 12/23/13 17:51, Ryan Carboni wrote:
> I think you misunderstood my statement. If time > 3 days, and after
> 4 blocks have been mined, then difficulty would be reset.
> 
> In theory, one would have to isolate roughly one percent of the
> Bitcoin network's hashing power to do so. Which would indicate an
> attack by a state actor as opposed to anything else. Arguably, the
> safest way to run Bitcoin is through a proprietary dial-up
> network.
> 
> 
> On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach
> mailto:m...@monetize.io>> wrote:
> 
> Ryan, these sort of adjustments introduce security risks. If you
> were isolated from the main chain by a low-hashpower attacker, how
> would you know? They'd need just three days without you noticing
> that network block generation has stalled - maybe they wait for a
> long weekend - then after that the block rate is normal but
> completely controlled by the attacker (and isolated from mainnet).
> 
> There are fast acting alternative difficulty adjustment algorithms 
> being explored by some alts, such as the 9-block interval,
> 144-block window, Parks-McClellan FIR filter used by Freicoin to
> recover from just such a mining bubble. If it were to happen to
> bitcoin, there would be sophisticated alternative to turn to, and
> enough time to make the change.
> 
> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
>> I think Bitcoin should have a sanity check: after three days if 
>> only four blocks have been mined, difficulty should be adjusted 
>> downwards.
> 
>> This might become important in the near future. I project a 
>> Bitcoin mining bubble.
> 
> 
> 
> 
> 
> --
>
> 
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
> 

--
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] Who or what is /Satoshi:0.8.99/Gangnam Style:2.1/ ?

[Matt Corallo]

No, mine identifies as BitcoinJ, RelayNode, version string

On 11/21/2013 10:27 AM, Jeff Garzik wrote:
> Is that Matt's relay, which has reduced validity checking?
> 
> 
> On Thu, Nov 21, 2013 at 8:48 AM, Mike Hearn  wrote:
>> I added some additional logging to my node and ran it for a few days.
>> There's a pull req open for my extra logging, it is quite trivial. Here's
>> what it looks like:
>>
>> 2013-11-21 13:41:04 AcceptToMemoryPool: 5.9.24.81:7834
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> 2d1bbcc2bf64dfcb57a2f0180b2607a48a34de4422c446929b26b190083bbfe7 (poolsz
>> 2087)
>> 2013-11-21 13:41:05 AcceptToMemoryPool: 198.12.127.2:29057
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> 28bb94978bdaa224faeafa95d03a0c4f5743396d6f592469c5ac2b64184ac716 (poolsz
>> 2088)
>> 2013-11-21 13:41:06 ERROR: AcceptToMemoryPool : nonstandard transaction:
>> dust
>> 2013-11-21 13:41:06
>> 42323d9553e4c592d27765dc3ef9152c186cb7d67b08d783d72974a56085032d from
>> 82.68.68.254:39232 /Satoshi:0.8.1/ was not accepted into the memory pool:
>> dust
>> 2013-11-21 13:41:06 AcceptToMemoryPool: 198.12.127.2:29057
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> 2fdb19e5e87d518b7b6bb7371d547a5f60c2bb056ba4522190460f0bc41b51fb (poolsz
>> 2089)
>> 2013-11-21 13:41:08 AcceptToMemoryPool: 5.9.24.81:7834
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> 52c8ed6a48f89d48b1152b67ac0b718a7aadb5f9a0c70c18b9b2fed058ca3323 (poolsz
>> 2090)
>> 2013-11-21 13:41:08 AcceptToMemoryPool: 198.12.127.2:29057
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> 980bbdbd4a6b365fa6f13fb5247eb6cb1e54847e490c3b7c3026d1548fb9efc6 (poolsz
>> 2091)
>> 2013-11-21 13:41:08 AcceptToMemoryPool: 64.120.253.194:60896
>> /Satoshi:0.8.99/Gangnam Style:2.0/ : accepted
>> 03f79c611bbdc1afa7afa67eb0bbd4d8bc86a730a7066622e2709ae506e61e0f (poolsz
>> 2092)
>> 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> af8096ad637af1ca022a5146e07cf1fc6bfbec877935f9e114b279fcfe26c06d (poolsz
>> 2093)
>> 2013-11-21 13:41:10 AcceptToMemoryPool: 5.9.24.81:7834
>> /Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
>> 751c2415d058d45ca602fdf1b6490edb6e57fc718e914d628c11b17e25aac834 (poolsz
>> 2094)
>>
>>
>>
>> Despite that I have 87 connections from regular nodes, virtually all
>> transactions seen by my node are being announced by this modified software,
>> which appears to run on several different machines.
>>
>> I am wondering if anyone out there knows/owns these nodes and if they are
>> relaying transactions without checking their validity. That seems the most
>> likely reason for how they are always able to win the race to be the first
>> to announce to my node.
>>
>> --
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> 
> 
> 

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Matt Corallo]

In the short-term, maybe. Keep in mind that the code for tx relay is
fairly different and the bandwidth for transaction relay on these
nodes is already lower than it is for blocks (by design). That said,
I'd like to look into doing tx-less block relays for transactions that
peers already have to limit block relay times even for large blocks,
in which case tx relay is very much required.

Matt

On 11/13/13 15:13, John Dillon wrote:
> You should split the block-only and block+tx not only by port
> number, but also by DNS address. DoS attack by flooding blocks is
> fundamentally more difficult than DoS attack by flooding
> transctions, so doing the split by IP address ensures that in the
> event of an attack the more important block relaying functionality
> is less likely to be damaged. In the meantime point both DNS 
> addresses to the same IP until it becomes an issue.
> 
> 

--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Matt Corallo]

On 11/08/13 06:46, Mike Hearn wrote:
> I took a brief look at the code - it's looking very reasonable. You can
> replace any construct like
> 
> try {
>   Thread.sleep(1000);
> } catch (InterruptedException e) {
>   throw new RuntimeException(e);
> }
> 
> which is quite verbose, just with
> Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS); (and
> of course static imports help too)

Thanks, fixed.


> 
> I think for this concept to take off, you'd need a website and to
> recruit someone to help you market it. Pool operators won't reach out to
> you.

Yes, I've done some initial outreach and plan on doing another major
round now that the initial network is up and Im working on running some
relay time benchmarks. Finding someone to help push peering would be
nice, if you have any suggestions, Im all ears.

> 
> I still find it perhaps more elegant to just boost the connectivity of
> the existing network with bitcoind changes, but this can help for now.

Agreed, improving relay times across the regular P2P network would be
nice, however I really dont see this as a part of the P2P network. Its
more of a backup relay network that just happens to follow the P2P
protocol (mostly, it doesnt do full block verification, so technically
it breaks spec). In this model, this is really a nice augment to the P2P
network no matter what improvements are made. Having more protocols/ways
blocks are relayed is always nice (anyone wanna launch a satellite?)

Matt

--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Matt Corallo]

No, the transactions relayed are piped through a bitcoind first (ie
fully verified by a bitcoind). For blocks, for which the timing needs to
be tighter, bitcoinj does SPV-validation. Though it is possible to
create a block which passes SPV validation but causes a DoS score, doing
so would cost a miner a full block's worth of profits, which they are
fairly unlikely to do. In any case, if it every becomes a problem, its
not hard to adapt addnode to allow higher DoS scores for individual nodes.

Matt

On 11/06/13 07:25, Tier Nolan wrote:
> 
> 
> 
> On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo  <mailto:bitcoin-l...@bluematt.me>> wrote:
> 
> Relay node details:
>  * The relay nodes do some data verification to prevent DoS, but in
> order to keep relay fast, they do not fully verify the data they are
> relaying, thus YOU SHOULD NEVER mine a block building on top of a
> relayed block without fully checking it with your own bitcoin validator
> (as you would any other block relayed from the P2P network).
> 
> 
> Wouldn't this cause disconnects due to misbehavior? 
> 
> A standard node connecting to a relay node would receive
> blocks/transactions that are not valid in some way and then disconnect.
> 
> Have you looked though the official client to find what things are
> considered signs that a peer is hostile?  I assume things like double
> spending checks count as misbehavior and can't be quickly checked by a
> relay node.
> 
> Maybe another bit could be assigned in the services field as "relay". 
> This means that the node doesn't do any checking. 
> 
> Connects to relay nodes could be command line/config file only.  Peers
> wouldn't connect to them.

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Matt Corallo]

Recently, there has been a reasonable amount of discussion about the
continued fragility of the public Bitcoin network on IRC and elsewhere
(1). To this extent, I'm organizing a system of peering between nodes in
the network by creating a system of high-speed relay nodes for miners
and merchants/exchanges. This system will a) act as a fallback in the
case that the public Bitcoin network encounters issues and b) decrease
block propagation times between miners.
It is NOT designed to in any way replace or decrease the need for the
public Bitcoin P2P network. It is NOT any kind of attempt at
centralization, and I still encourage interested parties to establish
their own private peering agreements with large miners as needed.

Currently the network consists of one specially-designed relay node, but
I hope to bring more online in the coming days.

This network is open to everyone via a few public relay nodes, but also
will have nodes which are made available only to large miners and
merchants/exchanges to mitigate the ability of malicious parties to DoS
the network.

To peer with the public relay nodes, simply select the closest region
out of us-west (West Coast US), us-east (East Coast US), eu (Western
Europe), au (Australia), or jpy (Japan) and add
public.REGION.relay.mattcorallo.com to your addnode list. Note that
since all of the relay nodes will relay between each other, you gain no
latency advantage by peering with more than the closest node to you (and
currently all the regions map to one node, so there they're redundant
anyway).

For each relay node, you can connect to either port 8334 or 8335.
Connecting on port 8334 will relay only blocks, and port 8335 will relay
both blocks and transactions. The relay nodes will request any
transactions which appear in your invs no matter which port you connect to.

Relay node details:
 * The relay nodes do some data verification to prevent DoS, but in
order to keep relay fast, they do not fully verify the data they are
relaying, thus YOU SHOULD NEVER mine a block building on top of a
relayed block without fully checking it with your own bitcoin validator
(as you would any other block relayed from the P2P network).
 * The relay nodes do not follow the standard inv-getdata-tx/block flow,
but instead relay transactions/blocks immediately after they have done
their cursory verification. They do keep some track of whether or not
your nodes claim to have seen the transactions/blocks before relaying,
but you may see transactions/blocks being sent which you already have
and have not requested, if this is a problem for you due to bandwith
issues, you should reconsider your bandwith constraints and/or are
peering with too many nodes.
 * The relay nodes will all relay among themselves very quickly, so
there is no advantage to peering with as many relay nodes as you can
find, in fact, the increased incoming bandwidth during block relay
spikes may result in higher latency for your nodes.
 * The relay nodes are NOT designed to ensure that you never miss data,
and may fail to relay some transactions. Additionally, because the relay
nodes do not respond to standard getdata requests, if you miss a relay
and then reconnect, that data will not be sent again by the relay nodes.
The relay nodes are NOT a replacement for having peers on the standard
P2P network, they are only there to augment the existing P2P network.

If you are a merchant/exchange/large miner/other important node operator
and wish to gain access to additional domain names which map to relay
nodes with fewer peers, please fill out the form at
https://docs.google.com/forms/d/1UL82QdcXXEhZwSHJAK04Sk_cWg4zLOu8a216nO7Mt8c/viewform

You can find the source for the relay nodes at
https://github.com/TheBlueMatt/RelayNode

If you have any comments/concerns/suggestions, please do not hesitate to
email bitcoin-peer...@mattcorallo.com

Thanks,
Matt


(1) There has been extended discussion on #bitcoin-wizards as well as
#bitcoin-dev of the very small number of active, listening nodes.
Additionally, because many of those nodes are versions prior to 0.8.4,
it seems very likely that maliciously creating network splits or at
least drastically reducing the number of peers for most nodes would not
be particularly challenging in the current network. Also,
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
noted that they were able to single-handledly decrease the network-wide
orphan rate by around 50% by improving network peering. Finally, you've
all seen the recent discussion on malicious mining algorithms. Though
those are not entirely prevented by reducing block propagation times,
they can be significantly limited compared to the current, rather
disjoint, network.

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking,

Re: [Bitcoin-development] More appropriate XDG menu category for bitcoin-qt

[Matt Corallo]

(Finally) got around to this, sorry for the delay. 0.8.5 has the new
category and pull request is at
https://github.com/bitcoin/bitcoin/pull/2999

Matt

On Fri, 2013-08-02 at 12:08 -0700, Kip Warner wrote:
> Hey list,
> 
> Currently the bitcoin-qt application's XDG desktop integration on some
> desktop environments requests that it be placed under the "Office" menu
> category.[1] This is a rather broad category and I would like to suggest
> that this be refined further into "Finance", given that XDG's menu
> specification allows for this.[2]
> 
> I believe the line in question in bitcoin-qt.desktop should be as
> follows:
> 
> Categories=Office;Finance;
> 
> I would have provided this trivial patch myself, but my knowledge of Git
> is rather weak and I apologize.
> 
> Respectfully,
> 
> [1] 
> 
> [2] 
> 
> --
> 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



--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871&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: remove "getwork" RPC from bitcoind

[Matt Corallo]

ACK, I see no reason to leave broken things in that a) arent necessary
and b) no one has the developer resources to fix.

Matt

On Mon, 2013-08-19 at 12:27 -0400, Jeff Garzik wrote:
> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
> remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork
> 
> On mainnet, almost everybody uses a pool (and therefore, not "getwork"
> directly to bitcoind).  Those few who solo mine use a pool server to
> talk to bitcoind via "getblocktemplate" or other means.  Tests show
> that attempts to solo mine on mainnet via "getwork" lead to delays and
> problems.
> 
> On testnet, getwork has a better chance of continuing to work.
> Nevertheless, the same tools (open source pool servers or p2pool) are
> available for testnet, obviating the continued need to support
> getwork.
> 
> However, at one time, getwork to bitcoind was widely used.  I wanted
> to poke the audience, to gauge response to removing "getwork."  If a
> driving use case remains of which we're unaware, speak up, please.  We
> don't want to break anybody needlessly.
> 



--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

[Matt Corallo]

I really beg to differ on this one.  If you're an Ubuntu user who is
behind only one distro (quantal) you're stuck on version 0.6.2 with no
updates since 2012 (yes, that means on May 15th you'll be lost). 
 
For those still on Debian Squeeze (ie barely out of date), you get
0.3.24! Yes, 0.3.24 including every issue we've fixed since
(https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures) and
bitcoin is not available in wheezy.

Those are just the two I bothered to look up, but, additionally, nearly
every distro I know of links bitcoin against libdb5.1 (latest Ubuntu,
Arch, etc) which means wallets run once with those packages will never
be usable an "official" Bitcoin build ever again.  I can't necessarily
fault them for this since 4.8 is quite old, but its certainly not "doing
mostly a pretty good job"

Matt

On Mon, 2013-05-06 at 23:48 -0500, Petr Praus wrote:
> I think it's worth noting that quite a large portion of Linux users
> probably get the mainline Bitcoin client from the packages. I think
> Bitcoin package maintainers are doing mostly a pretty good job :)



--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] [RFC] Fees/Minimum Priorities based on Mempool and Memory-Limited Mempool

[Matt Corallo]

I hacked together a new min fee/prio calculator and memory-limited
mempool a while back and figured Id post the code here to get some
comments.  Its more of a discussion-starter than a strict proposal and
has a few obvious holes (hence posting here instead of pull-requesting).

It works as such (note that all constants are really place-holders, so
please recommend reasonable constants):

1) Watches when transactions enter mempool and calculates minimum
fee/priority based on a fairly dumb algorithm... It finds the highest
FEE_POLICY_TOP_N_TX (10) fee/prio transactions in mempool that have been
in mempool at least FEE_POLICY_DETERMINATION_BLOCKS (6) blocks and
averages together their fee/prio then multiplies by FEE_POLICY_FACTOR
(1.1).

2) It limits mempool size to a default of 10*MAX_BLOCK_SIZE (bringing it
down to 9*MAX_BLOCK_SIZE each time it has to throw out transaction).
When transactions are throw out, it keeps 2/9 of the mempool size in
highest-prio transactions and 7/9 of the mempool in highest-fee
transactions.  

3) Any transactions which have a fee lower than the lowest-fee
transaction thrown out of the mempool and a priority lower than the
lowest-priority transaction thrown out of the mempool will not be
accepted into the mempool at all.  

Obvious bugs:
1) It doesnt yet do anything for minimum fee/prio when it hasnt seen at
least FEE_POLICY_TOP_N_TX (10) transactions sitting in mempool for at
least FEE_POLICY_DETERMINATION_BLOCKS (6) blocks (ie hasnt been running
for 6 blocks or blocks are being filled completely).  The likely way to
address this is to look at previous blocks and find the lowest fee/prio
transactions included in them.

2) It will relay all transactions until the mempool has filled up (or if
the mempool never fills).  Something should be done initially to limit
DoS potential.

Code is at
https://github.com/TheBlueMatt/bitcoin/commits/fees

Matt


--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Integration testing for BitCoin

[Matt Corallo]

These tests are run on each pull requests and on each new commit to
master.  They arent very complete, but they do test a lot of block
acceptance rules.

https://github.com/TheBlueMatt/test-scripts

Matt

On Fri, 2013-04-05 at 12:24 -0500, Adam Ritter wrote:
> Hey guys,
> 
> I just bought some BitCoins after being lazy to do it for the last few
> years, but also looked at the client code and the messages that are
> going on this mailing list.
> I saw that there are quite some unit tests, but I didn't find
> integration test for BitCoin, and I believe that it's quite important
> for the future of BitCoin (making the current code more stable,
> testing attack scenarios, refactoring and extending code).
> 
> I have wrote some integration tests before at other projects, and they
> usually turned out useful, but I have 0 experience with the BitCoin
> development and codebase.
> I wrote a short document of what I think would be the safest way to do
> the testing (but not yet the tests themselves, as I don't have enough
> experience..I'd like to have something like testing that the wallets
> are empty, and after somebody mines she'll have more money..after she
> sends money to the other person, the other person will see it...things
> like this, just to get to know the code base).
> 
> What do you guys think?
> The plan is here:
> https://github.com/xiphias/bitcoin/blob/master/src/test/integration/README.md
> Please feel free to comment/fork, I'll try to write all your replies
> in the document as well.
> 
> Also here's the text to make it easier to comment:
> 
> Integration testing for bitcoin
> 
> 
> Tests that simulate multiple bitcoin users and can verify that the
> whole network of bitcoin clients work together
> to achieve the goals of Bitcoin. Also maybe [System
> testing](http://en.wikipedia.org/wiki/System_testing)
> would be a better name for the tests, but I'm not sure.
> 
> Goals
> -
> - Make the bitcoin code easier to refactor while increasing the guarantee
>  that it doesn't break the overall behaviour of the client.
> - Make it easier to have multiple experimental coins (for example
> LightCoin or PPCoin) in the codebase, while guaranteeing that the
> original BitCoin protocol doesn't break
> - Make it easy to test attack scenarios (like DOS,
>  releasing an incompatible BitCoin client), monitoring
> - Have tests without (or at least minimal number of) unreadable
> constants and unreadable fake data to make them easier to verify.
> 
> Proposed implementation
> 
> The first implementation should use the JSON-RPC interface and build
> up as much verification
> of BitCoin network as possible. It should be in C++, which makes it
> easier to move to the second implementation.
> The JSON-RPC calls should be hidden by a C++ interface.
> 
> The second implementation should use the same interface that was used
> for JSON-RPC,
> but using the BitCoin code directly (while not breaking the JSON-RPC tests).
> For this the BitCoin client has to be refactored as a library,
> getting rid of all global variables (and having them in a data structure),
> so that multiple BitCoin clients can be run in the same process.
> 
> The improvement of the second implementation should have dependency injection
> for the time and for finding/verifying a mined block,
> so that the tests don't need to use real CPU power for mining,
> and they can run faster and test more complex scenarios.
> 
> --
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire 
> the most talented Cisco Certified professionals. Visit the 
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Draft BIP for Bloom filtering

[Matt Corallo]

Actually, there is one more minor algorithmic change I would like to
make to the way the hash function is computed really quick before it
gets merged, I'll have that finished up by the end of today.

Matt

On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:
> Matts latest code has been tested by Andreas and seems to work
> correctly. He had to extend the client a bit to refresh the filter
> every 25k blocks because even with the extra flag, eventually the
> filter degrades into uselessness, but it did still improve the
> situation quite a bit.
> 
> Because it's unit tested, been reviewed by me several times, has an
> interoperable implementation that has also been tested by Andreas in a
> build of his smartphone app,  I'm going to ACK the current code and
> request that it be merged in to 0.8. What do you say Gavin?
> 
> The next step after that would be profiling. It's a big performance
> improvement for SPV clients already, but not as much as I anticipated.
> I suspect there's a simple bottleneck or missed optimization
> somewhere. But that can obviously come post-0.8



--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Draft BIP for Bloom filtering

[Matt Corallo]

On Thu, 2013-01-10 at 16:21 +0100, Mike Hearn wrote:
> Here's a quick update on where we're up to.
> 
> Thanks to Matts excellent work, I was able to test his bitcoinj and
> bitcoin-qt work together today. There are a few minor tweaks needed,
> but I feel like we're maybe a week away from having all the code in a
> mergeable state. Here is the remaining work:
> 
> - There are a couple of bugfixes needed on the bitcoinj side: the
> fallback to downloading full blocks is problematic and needs to be
> deleted, there's an API change we want
First of the two is done.
> 
> - Adjust the default FP rate requested by BCJ to be 0.0001, this is
> appropriate for the latest blocks in the chain and yields 0-5 false
> positives per block
Is a part of the larger API changes mentioned above.
> 
> - Introduce a new part to the filter protocol that allows clients to
> control auto-expansion. This turned out to be very volatile, we saw
> jumps from 0-3 FPs per block to 500 in the space of 1 block, perhaps
> if a SatoshiDice transaction got into the filter. A simple yes/no flag
> can suffice for now, but a better solution would be for the client to
> submit templates for output scripts that would trigger auto-adding the
> matched outpoint - autoexpansion is only needed in the case where the
> input script doesn't contain any predictable data. For pay-to-address
> and P2SH it does, so expansion doesn't help. Matt said he'd hopefully
> try to look at this soon.
The flags mentioned have been implemented, both to disable
autoexpansion, enable it for all outputs, enable for only pay to pubkey
outputs (the most likely use-case), or use a set of templates.  The
matched templates part isn't properly tested and I would like comments
on that part (see the last few commits at
https://github.com/bitcoin/bitcoin/pull/1795).
> 
> With auto-expansion disabled, the FP rate adjusted and a bugfix on the
> bcj side I was able to sync a wallet using a bloom filtered chain.
> 
> Although it's tight, I think this work should go into 0.8 - it'll be
> much more compelling to advertise it this way, we can say "Upgrade to
> 0.8 and help network performance for everyone". And in the case that
> we discover a showstopper problem, we just don't deploy the code that
> uses the new messages into clients.
Ive been missing lately, when is 0.8 targeted for freeze?

Matt


--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Draft BIP for Bloom filtering

[Matt Corallo]

On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote:
> On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote:
> > I've written a draft BIP describing the bloom filtering protocol
> > extension developed by myself and Matt.
> > 
> > https://en.bitcoin.it/wiki/BIP_0037
> 
> Two comments I made on the pullreq page, which are probably better discussed 
> here:
> * The 0x/(n-1)*i seed value seems intended to result in large bit
>   differences between the different hash function's seeds. Together with the 
> tweak,
>   however, the first and the last now get seeds tweak and tweak-1. I think
>   something simpler like k1*i+k2*n+tweak is better (with k1 and k2 arbitrary 
> large
>   odd 32-bit integers).
Meh, sure, whatever...I dont really think the seed values matter
significantly (Murmur3 isnt that bad of a hash function...) (and the
original algorithm wont result in a significant bit difference between
the seeds in many cases).
> * I feel uneasy about the arbitrary filter parameters used for the implicitly
>   created filter when sending filteradd without filterload. The server cannot 
> be
>   expected to make a reasonable guess how the client is going to use the 
> filter,
>   and the client still has to track how large the server-side filter grows 
> anyway.
>   I'd prefer to make this simply illegal (DoS 100): filteradd always requires 
> an
>   active filter.
I think there is some consensus here, and I have no problem doing it
this way (in large part, filteradd should not be used at all).
> Maybe the actual filter data in filterload can be made optional:
>   if it is omitted, it's assumed to be all zeroes (though that would mean the 
> size
>   has to be specified).
> 
I'm not sure here, if you are sending a filter just to use filteradd to
add things to it manually, you are doing something very, very, very
wrong... Though we could certainly do some kind of compressed bloom
filter encoding to allow for small filter loads (loading the few things
you need to filteradd right away) where you anticipate adding
significantly more filter elements down the road (can anyone even come
up with a case where you anticipate doing this?), the filter is small
enough (max 36kB) that I see little benefit for the large increase in
complexity (or is this another repeat of the merkle branch discussion?)

Matt


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Draft BIP for Bloom filtering

[Matt Corallo]

On Wed, 2012-10-24 at 14:54 -0400, Gavin Andresen wrote:
> RE: sharing parts of the merkle branches when returning a 'merkleblock' :
> 
> I think I agree that complicating the BIP for what should be a very
> rare case (more than a handful of transactions in a block match the
> transactions in your wallet) is the right decision.
I believe you meant NOT complicating?
> 
> I want to make sure I'm understanding this bit correctly:
> 
> "In addition, because a merkleblock message contains only a list of
> transaction hashes, any transactions that the requesting node hasn't
> either received or announced with an inv will be automatically sent as
> well. This avoids a slow roundtrip that would otherwise be required
> (receive hashes, didn't see some of these transactions yet, ask for
> them)."
> 
> Requiring serving/relaying nodes to keep track of which transactions
> they have or have not sent to their peers makes me nervous. I think
> requiring an extra 'inv' round-trip would be simpler to implement and
> less likely to lead to some kind of DoS attack.
> 
Sadly that requires (potentially) more DoS potential because you require
nodes to store each transaction that could be requested instead of just
going ahead and forwarding them.  I agree the BIP should not specify
that the sending node is required to keep track of which transactions
have been announced/sent to clients, however since the reference client
does so currently, that implementation is significantly simpler (note
that it is a bounded set in the reference client, so even the reference
client doesn't really fully comply with the BIP as stated here).  

Matt


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Testing Project

[Matt Corallo]

On Wed, 2012-09-26 at 13:28 +0100, steve wrote:
> Hi Matt,
> 
> Glad to have another ninja onboard :)
> 
> On 25/09/2012 21:41, Matt Corallo wrote:
> > Although Jenkins may not be the best system, we already have
> > jenkins and pull-tester (which is a dumb python script I wrote to
> > test all incoming pull requests from github).
> 
> I have never heard of jenkins before.  I need to do some more digging.
> is this the right thing?
> 
> https://wiki.jenkins-ci.org/display/JENKINS/Mantis+Plugin
For a mantis plugin, sure, I guess...
> 
> Mantis on the other hand, I know exceptionally well.  I hate
> duplication of work/data unless absolutely necessary.  I will check
> jenkins out (just out of interest what is it actually meant to do? the
> website implies framework, but not what its for)
Jenkins currently just runs the test script after each new commit to
bitcoin (and provides binaries to anyone who wants them), so its pretty
basic (though jenkins has way more features than we use).  The bitcoin
one lives at http://jenkins.bluematt.me/
> 
> > 
> > They both run the same set of scripts, namely those at 
> > https://github.com/TheBlueMatt/test-scripts (its pretty basic right
> > now, but since it is on github, I was hoping someone would find
> > the inspiration to add to it).
> 
> I will check it out. I wrote a very basic script that wikified the
> changelog,
We currently keep a changelog at https://en.bitcoin.it/wiki/Changelog (I
went back and added tons of logs a while back and it got updated, though
0.7 seems to be missing...) anyway, automating that would be nice...
> and linked to the changes and created wiki pages for the
> testcases.  
Having more info on that changelog page would be nice.
> have you seen the stuff I put on bettermeans? bits keep
> vanishing then re appearing.
I have been meaning to catch up with the various attempts at better
bitcoin testing that have started up a few times, but I keep never
getting around to it...
> 
> This is the outline of the testing that I setup for 0.7
> 
> https://secure.bettermeans.com/projects/4256/wiki
> 
> > 
> > I dont really care if we keep using jenkins, but I figure we might
> > as well keep all the tests in one place?
> 
> Yes, I would love to unify all build testing and testcases into one
> place.  I am still on the fence as to including unit tests into this.
> However I do see 3 distinct type of testcases
Even if unit tests are considered separate, having it all run in one
huge test script makes it quite easy to implement new things (like
pull-tester) which test some arbitrary bitcoind commit in the same way
as every other tester.  
> 1 - requirements based testcases (requirements based off the current
> block chain rules - these are edge cases and known interoperability
> issues)
The BitcoinjBitcoindComparisonTool.jar file which is run as a part of
the test scripts tries to hit as many block acceptance edge cases as
possible (I'm sure I missed a ton, but it hits a lot too).  I've also
been pushing alternate implementation implementors to use it to test
their own implementations.
> 
> 2 - Acceptance based testcases - these are testcases that should be
> run for every build.  Check out the General Acceptance Tests in the
> wiki link for examples and testcases
> 
> 3 - Testcases for reference implementations of things (like multisig -
> i see these working like the /test folder when you install a new perl
> module)
> 
> These three things alone are a massive task. and they still wont cover
> everything.  I would like to get the workflow so that people can
> sponsor or donate to a specific campaign (eg a new feature is
> implemented, people want it tested so can donate just for that
> campaign [developing testcases, structure, requirements, etc])
> 
> Once this is done, I will get to do some exciting stuff (like writing
> fuzzers, automation, etc) unfortunately I do not know python, only perl.
As far as I'm concerned more test cases are more test cases, it may get
unwieldy to maintain, but at least we'd have more test cases :)

In terms of general testing strategies, I really prefer to script it
all, jenkins is quite nice in that it can have slave workers using a
different OS which run their own tests and then report back to the main
jenkins instance.  Getting a real Windows slave to run the installer and
test that thoroughly as well as basic Mac things (I know OSX uses a very
different build system...) would be nice (though I dont really have time
to write all those tests...)

re: GUI testing is hard: I've heard Qt's unit test framework is really
powerful and can even include things like click scripting and analysis
of the current views (though, I agree, its still no doubt hard).  

Matt

Re: [Bitcoin-development] Bitcoin Testing Project

[Matt Corallo]

Although Jenkins may not be the best system, we already have jenkins and
pull-tester (which is a dumb python script I wrote to test all incoming
pull requests from github).  

They both run the same set of scripts, namely those at
https://github.com/TheBlueMatt/test-scripts (its pretty basic right now,
but since it is on github, I was hoping someone would find the
inspiration to add to it).

I dont really care if we keep using jenkins, but I figure we might as
well keep all the tests in one place?

Anyway, I'm all for more testing (I'm always complaining about how we
need more tests for stuff...).

Matt

On Tue, 2012-09-25 at 19:32 +0100, steve wrote:
> Hi All,
> 
> After the failure to get any real testing done for the 0.7 release (all
> of which is my fault) I have decided to rejig things.
> 
> I am heavily into test driven development, and I have a strong
> background in requirements management, and automation.
> 
> I want to leave bettermeans behind, maybe we might be able to keep the
> voting aspect of it, and link it into mantis.
> 
> So, what I have been doing over the past few weeks is developing a
> rudimentary requirements set, basic requirement tracking, tests to
> prove/stress the requirements.
> 
> The next most important thing is to get release/acceptance tests done -
> these primarily focus on new stuff doesnt break old (ie lose a wallet,
> etc) and needs no special requirements.
> 
> To this end I have installed various opensource applications (mantis,
> salomeTMF, bugzilla, etc) and am currently evaluating the best workflow
> process.
> 
> This was a much longer post, but decided against it. :)
> 
> So, what I want to know is who wants to be a part helping me out with
> all this? I am finalising the workflow flow diagrams and they should be
> ready for inspection soon.
> 
> Anyone interested in helping out/reviewing processes? even if it is just
> some encouragement, it is all greatly appreciated.
> 
> Drop me an email if you want access to the current setup and help me
> review the different software for the bitcoin workflow process.
> 
> cheers,
> 
> steve


--
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] Segmented Block Relaying BIP draft.

[Matt Corallo]

It seems to me the whole idea of segmenting blocks would add very little
(to nothing) with any sane block size.  Sure, if a block were to be
10GB, it may make sense.  However, even in that case, it would be easier
to relay a list of tx hashes (which may be a bit expensive) and txes
separately instead of using a notion of block segments.  That said, I
don't see blocks ever being that large and if they do become that large,
as only a few full nodes will remain, upgrading their protocol would be
(relatively) easy.  I would instead encourage focus on decreasing block
relay times for the current network and as blocks approach 10MB (so that
they can approach 10MB).

Matt

On Mon, 2012-09-10 at 20:34 +0100, Matthew Mitchell wrote:
> Do you mean getdata? Here is the reason for the 6 new messages:
> 
> 
> getseginv,seginv - These are for learning about what segments of a
> block a node has. Else you could remove these messages and simply have
> nodes advertise blocks via inventory messages. In this case nodes
> would have to wait until they had fully received a block before
> relaying anything. No longer is there a benefit with nodes being able
> to relay segments of blocks before they have received the entire
> block.
> 
> 
> gettreelevel,treelevel - These are to received a level of
> the merle tree. Instead you might use get data but gettreelevel is
> more compact than get data and is clearly differentiates itself as
> part of the new protocol. Perhaps these messages could include the
> block headers alongside the hashes and you could request many at once
> like with the getheaders message? If you skip these messages, then you
> could verify the transactions at the end but there would be problems
> when peers give bad segments where data would need to be downloaded
> again.
> 
> 
> getsegment,segment - These are clearly important to request and
> receive segments for the blocks. These allows for nodes
> to download arbitrary segments of blocks. The optimum number of
> segments could be calculated by node software using measurements of
> download speeds and latency times, the number of connections and how
> likely redundancy is to occur. If a node is up-to-date and likely has
> many of the transactions in blocks, it can start asking for the
> deepest merle level (tx hashes) and ask nodes for segments, avoiding
> transactions it already has.
> 
> 
> I'll get around to doing measurements myself sometime to estimate the
> benefit of this proposal. It will certainly be beneficial when block
> sizes reach some size but not much is really known except what can be
> assumed/guessed.
> 
> 
> I should also mention the bitcointalk topic
> here: https://bitcointalk.org/index.php?topic=103295.0
> 
> On 10 Sep 2012, at 19:59, "Luke-Jr"  wrote:
> > 
> > Most of the problem with block propagation lies in implementation,
> > not 
> > protocol... Distributing missing transaction on an as-needed basis
> > is a 
> > possible improvement at the protocol level, but there hasn't (AFAIK)
> > been any 
> > research into whether the little benefit outweighs the cost yet. In
> > any case, 
> > I don't see why 6 new messages are needed instead of simply adding a
> > single 
> > new type to getinv?



--
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] Segmented Block Relaying BIP draft.

[Matt Corallo]

I actually implemented parts of the header+ v stuff in a branch with
my bloom filter stuff, you can see it here:
https://github.com/TheBlueMatt/bitcoin/commits/bloom%2Brelayblock
Its pretty stupid and would be pretty easy to DoS/get it stuck/etc, but
in theory it works.  I don't see much reason why we'd need anything
significantly more complicated, but maybe there is a use-case I'm
missing?

Matt

On Mon, 2012-09-10 at 11:14 -0400, Gregory Maxwell wrote:
> On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell
>  wrote:
> > Here is a BIP draft for improving the block relaying and validation so that
> > it can be done in parallel and so that redundancy can be removed. This
> > becomes more beneficial the larger the block sizes are.
> >
> > https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal
> 
> Why does this focus on actually sending the hash tree?  The block
> header + transaction list + transactions a node doesn't already know
> (often just the coinbase) is enough.


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

[Bitcoin-development] Warning to rawtx creators: bug in SIGHASH_SINGLE

[Matt Corallo]

If you are playing around with the current rawtx API, be careful using
SIGHASH_SINGLE:

When parsing a transaction input, which uses a SIGHASH_SINGLE signature,
and the given input's index is >= the total number of outputs in the
current transaction, bitcoind doesn't sign anything useful, it signs the
constant 1.

Thus, if anyone were to create such an invalid transaction, any future
outputs to the public key which created the signature would be
immediately steal-able by anyone.

The conclusion on how to fix the issue was to fix the rawtx API to block
such transactions instead of creating a hardfork-risk or further
complicating transaction verification.

Code (in script.cpp:SignatureHash, under SIGHASH_SINGLE):
if (nOut >= txTmp.vout.size())
{
printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
return 1;
}

Matt


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

[Bitcoin-development] Bloom Filter Implementation

[Matt Corallo]

I spend some time implementing some of the changes discussed in the
previous thread "New P2P commands for diagnostics, SPV clients", and
wanted to field comments before I write up a BIP.

I have implemented a simple bloom filter that works on transactions as
well as a new block relay type which relays blocks as header+coinbase tx
+vector which allows for faster relay for clients which already
have transactions in memory pool.

In order to request that all future MSG_TX inv messages and blocks (only
those relayed in the new format) are filtered, SPV clients will send a
filterload message with a serialized bloom filter.  Nodes can also send
filteradd messages which add particular data blocks to the filter (not
recommended for anonymity) and call filterclear which disables filtering
on a node's connection until re-enabled.

The filter will match any tx which:
 1. Has a script data element in either a scriptPubKey or scriptSig
which matches the filter.
 2. Spends an input who's COutPoint is in the filter.
 3. Has a hash in the filter (see #4 for why this matters).
 4. Has a script data element in a prevout's scriptPubKey.  This
allows for matching pay-to-pubkey transactions without sending a
new filter after each transaction which matched (which would
cause some nasty timing issues where you may miss transactions
if you get transactions back-to-back before you can send a new
filter).  Matching of prevouts only occurs on free txes, not
those in blocks.  Thus, before requesting a block, SPV clients
should update the remote node's filter, if required, to be sure
it includes the hash of any transaction which would not
otherwise match the filter so that the node knows when its
transactions are included in blocks.

I can't say I'm a big fan of requiring SPV nodes constantly update the
filter when they learn about new transactions (could get nasty during
IDB, if the node has a lot of transactions, as you could end up
re-requesting blocks many times), but I really don't think its worth
loading all prevouts when a node is in IBD to fix it.

The branch can be found at
https://github.com/TheBlueMatt/bitcoin/compare/master...bloom

Matt


--
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] script tests - invalid script in script_valid.json?

[Matt Corallo]

On Sun, 2012-07-29 at 20:52 -0400, Gavin Andresen wrote:
> > Is there interest to port more tests (P2SH, checksig, checkmultisig,
> > block verification, maybe even DoS rules) into data-driven format? It
> > might be something that I'd like to help with if pull requests in that
> > direction are welcome.
> 
> Yes, more tests are definitely welcome.
> 
> check*sig tests are tricky, because they have to refer to previous
> unspent transactions and private keys (so require a particular block
> chain to test against). Brilliant ideas on a simple data-driven format
> welcome.
> 
> block verification tests would be great; a collection of good/bad
> block chains, starting from a common chain (maybe the testnet3
> tesnet-in-a-box chain) would be very useful for regression testing.
> 

I wrote a simple block chain tester (that is capable of forking,
checking invalid blocks, etc) as a part of the bitcoinj test suite.  Its
more targeted at testing bitcoinj directly and keeping the bitcoinj test
suite light weight, so if it were to be more generic some tweaks could
be done (not requiring tweaking the minimum difficulty/genesis block
hash/etc would be first).  It doesn't have that many test cases yet, but
it is capable of sanity-testing reorgs/etc.  Its mostly the first two
commits listed at
http://code.google.com/r/bluemattme-bitcoinj/source/list?name=fullverif

Matt


--
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 P2P commands for diagnostics, SPV clients

[Matt Corallo]

On Mon, 2012-07-23 at 09:54 +0200, Andreas Petersson wrote:
> Some concerns regarding Bloom Filters. I talked with Stefan Thomas on 
> the Hackathon Berlin about this.
> I tried to follow the discussion closely but i have not taken a look at 
> the code yet (is there already an implementation?) so please correct me 
> if i got something wrong.
AFAIK there was no implementation.  I pushed one for bitcoinj+bitcoind
today that compiles, but I haven't tested it much further (though its
really quite a simple implementation):
https://github.com/TheBlueMatt/bitcoin/commits/bloom
http://code.google.com/r/bluemattme-bitcoinj/source/list?name=bloomfilter

> The way the Bloom filters are planned now this requires a complicated 
> setup. basically the client will ask the server to replay the whole 
> blockchain, but filtered.
> This is not optimal for the following reasons:
> This will require the server to do a full scan of his data and only 
> filter out non-matching entries.
My implementation has yet to implement block filtering, for now its only
tx inv filtering.  However, its really not that complicated and doing a
scan of any individual transaction is very fast.  So during the download
phase, it really isn't much of any extra load on block chain providers
(aside from having to load inputs in the current implementation, but
that could be optimized some).

> Really lightweight clients (like Bitcoincard), clients with shared 
> private keys (electrum-style), or brainwallets - will ask the following 
> question quite often to "supernodes": Given my public keys/addresses, 
> what is the list of unspent outputs. i think it would make sense to 
> include such a command, instead or in addition to the filterload/filterinit.

> And perhaps more severe: as far as i understand classic bloom filters, 
> the server has no method of indexing his data for the expected requests. 
> There is simply no data structure (or maybe it has to be invented) which 
> allows the use of an index for queries by bloom filters of *varying 
> length* and a generic hashing method.

> im not sure what a really efficient data structure for these kinds of 
> query is. but i think it should be possible to find a good compromise 
> between query flexibility, server load, client privacy.

> one possible scheme, looks like this:

> the client takes his list of addesses he is interested in. he hashes all 
> of them to a fixed-length bit array (bloom filter) of length 64KiB (for 
> example), and combines them with | to add more 1's with each address.
> the server maintains a binary tree data structure of unspent outputs 
> arranged by the Bloom filter bits.
> to build the tree, the server would need to calculate the 64KiB bits for 
> each address and arrange them in a binary tree. that way he can easily 
> traverse the tree for a given bloom query.
> if a client whishes to query more broadly he can calculate the bloom 
> filter to 64KiB and after that fill up the last 50% of the Bits with 1. 
> or 95%. the trailing 1 bits even don't need to be transmitted to the 
> server when a client is querying. of course, if the client is more 
> privacy-concerned he could also fill up random bits with 1, which would 
> not change much actually.
> 
> the value of 64KiB is just out of thin air.
> according to my experimentation using BloomFilter from Guava - 
> currently, also 8KiB would be sufficient to hava a 3% false positive 
> rate for the 4 active addresses we have right now.
> 
> someone more familiar with hashing should please give his opinion if 
> cutting a bloom filter in half has any bad consequences.
> 
> Andreas
Though I like the idea of having a "give me all unspent outputs for my
pubkeys" command, I see quite a future for clients somewhere between "I
store nothing but pubkeys and don't know about the chain" and "I store a
full chain" and the bloom filters as described are pretty useful for
many clients in that in between.  Also, for clients that are "Really
lightweight clients" (given that they don't know about the chain) should
probably just stick with an electrum-style server-client system with
specialized servers (IMHO) instead of relying on P2P nodes to provide
them with a list of unspent outputs/etc.

In response to Mike's what-the-filter-should-match:
The way it is now, it just checks each input+output to see if the
hash160 of the dest addr, hash160 of the pubkey or hash160 of the p2sh
sh matches the filter as-is.
>From the list provided, I think adding a check to allow adding a
specific outpoint to a filter would be nice.
However, in terms of data elements in txes, Im not so sure.
Its by no means a bad idea, and it wouldnt be too much overhead, but
making filters match a very broad set of criteria seems like a bit much
to me, but maybe others disagree?

Matt


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat

Re: [Bitcoin-development] Coinbase script parse failures

[Matt Corallo]

I mentioned this on IRC a week or so ago, noticing that though they are
not executed and required to be well-formed, we still count any sigops
that appear in them (which I guessed may be an interesting attack if you
could get a miner to put a byte in there that is the equivalent of
OP_CHECKSIG because we dont count the sigops in the coinbase scriptSig
during mining, however luke pointed out that we always push the content
of coinbase scriptSigs properly by default, and those modifying the code
should spend time researching this stuff anyway, so if they break it,
its their fault (and now they can find this email)).

Matt

On Mon, 2012-07-23 at 02:07 -0400, Jeff Garzik wrote:
> While writing the script engine for pynode, I ran a test to validate
> my script tokenizer -- a python script which does nothing more than
> split up scriptPubKey and scriptSig into component opcodes and data
> elements.  No execution, just tokenization of the script's data
> stream.
> 
> Scanning the entire blockchain, my script found over 8,000
> tokenization failures, and 100% of those were in coinbase
> transactions' scriptSig.  The scripts used to generate this can be
> found at https://github.com/jgarzik/pynode
> 
> The following data dump are just the first few, and most recent few,
> of the invalid scripts I found in the blockchain:
> 
> Scanning block #142312 
> 046acff93b0e76cd10490551bf871ce9ac9fad62e67a0
> 7ff1d1e (1 tx)
>TX 50cfd3361f7162b3c0c00dacd3d0e4ddf61e8ec0c51bfa54c4ca0e61876810a9
>   txin 0 parse failed
> Scanning block #142357 
> 0743c432f84ad688b7b60d1474ccd7baa3d762df0b3f5
> 1205712 (1 tx)
>TX 587da4d4870515e57efc27623aa92fae0b7aef5908162de57fef0bbe6382be73
>   txin 0 parse failed
> Scanning block #143014 
> 07fe6ecd20a8c454cd43c78d912b499c46a1179e30f7c
> ff002b3 (1 tx)
>TX 4c8f43c5115c5f29f3761176fa59cde2de2ad976efcbc5faae8ee79fa5dd6264
>   txin 0 parse failed
> ...
> Scanning block #190315 
> 06a0bc3be527033c02d3bcfa72af2f4213c4b0feec923
> 9573342 (336 tx)
>TX f0ba80ce080eb49148b69c47d744bbb85e4e07e4e4d0273b402c0989d79c359c
>   txin 0 parse failed
> Scanning block #190321 
> 01c3bacc869917cacdafb6e00c552ac294835107b574a
> 44a0362 (38 tx)
>TX 4c91f5ad0616df92165819902d0b117d9e68345f5fe964de6146f89838b9295e
>   txin 0 parse failed
> Scanning block #190331 
> 00e3d3eaf93600684b085df7d58f84ef952c91e84eb4a
> 251d5d8 (128 tx)
>TX 5ee371d65e323934570566b1d92dceb8456e887814da8ef2a53971683bd11da4
>   txin 0 parse failed
> 



--
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 P2P commands for diagnostics, SPV clients

[Matt Corallo]

On Sat, 2012-06-16 at 10:27 +0200, Mike Hearn wrote:
> > I'd much rather have an overloaded node respond with 50% fp rate filters
> > as an option if there aren't many full nodes available than simply
> > disconnect SPV clients.
> 
> I don't think the bloom filter settings have any impact on server-side
> load ... a node still has to check every transaction against the
> filter regardless of how that filter is configured, which means the
> same amount of disk io and processing.
> 
> How can you reduce load on a peer by negotiating different filter settings?
Agreed, I was largely giving a reason why one may want to negotiate the
filter settings in response to your question as to why it was done.  As
long as there are sane limits (you cant make a 1GB filter by specifying
0% fp and some crazy number of entires), filter negotiation largely isnt
worth it (also prevents any floats from appearing in the p2p protocol,
though in either case it shouldn't be able to cause issues).

Matt


--
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 P2P commands for diagnostics, SPV clients

[Matt Corallo]

On Fri, 2012-06-15 at 11:32 -0400, Jeff Garzik wrote:
>  As for full nodes... I like the organic growth and random nature of
> the mempools.  On the fence, WRT full node mempool sync at startup.
> 
I dont particularly care either way, but I have a feeling miners will
really want that so that they can get fee-paying transactions right
away.

Matt


--
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] Near-term scalability

[Matt Corallo]

On Fri, 2012-06-15 at 15:34 +0200, Mike Hearn wrote:
> > The idea can be more generalized in that there are many cases where the
> > generator of a transaction doesn't care about confirmation times, and
> > would really be willing to make their transaction lower priority than
> > other 0-fee transactions.
> 
> Just to be clear, I think this solution is a hack and don't support it
> because it's yet another change of network rules. Some random people
> will get whacked because of a heuristic "rule of thumb".
Its arguably not a change to network rules as its something that users
can already do today by patching their clients.  Obviously any
implementation would have sane defaults which allowed for a significant
number of transactions to/from a given address at a time, avoiding
whacking random people unless they are large enough that they should
really already be fully aware of how bitcoin works.
> 
> If it's implemented, SD could/would switch to fresh addresses and
> nothing would have been achieved except making an already complex
> system more complex.
I would think SD would switch to using fresh addresses for each bet.
But even that is a good thing, at least where user privacy is concerned.
However, I would hope that SD would see the rule tweak and, in order to
avoid having to generate a number of new addresses per second (or, if
they went the pool route, having a huge pool of many thousands of
addresses), they would consider implementing sendmulti support.
> 
> I disagree with the notion that you need "less important than free".
> If you care about the confirmation time of a transaction that was sent
> to you and you need space in a limited resource, you can pay for it.
> It's an auction like any other. Besides, the idea that transactions
> are free today is just a psychological trick befitting governments but
> not us - transactions are funded by aggressive hyperinflation. I would
> never describe Bitcoin as a free system and I suggest nobody else does
> either.
I agree, free transactions isnt something we should aggressively push as
a feature of Bitcoin, its simply not.  However, in the current system
free transactions are usually confirmed within a small number of blocks,
and for a number of users, that is an important feature that draws them
to get through the initial hurdles of converting money to Bitcoin and
understanding enough of the system to trust it.  I believe that if we
can incentive large transaction creators to avoid delaying free
transactions, we should and giving them the option to delay their own
transactions seems like a perfectly reasonable way to do so.  Even if
you drop all the per-address limit stuff, allowing transaction creators
to add a simple flag to transactions seems reasonable when they want to
encourage Bitcoin to continue to grow as it does today.  Obviously
keeping free transactions confirming won't be possible forever, but
hopefully that will be as a result of natural growth which can encourage
further growth without the need for free transactions and not as a
result of a few actors in the community creating a transaction volume
significantly greater than their user-base.
> 
> If grouped fee calculations are implemented, we can keep the nice
> property that the person who cares about double spending risk pays the
> fees, and if you assume most transactions are hub-and-spoke from
> buyers to merchants, rather than a pure p2p graph, in practice it'll
> work out to seeming free most of the time even if seen globally it
> doesn't make much difference.
ACK, thats an important thing to implement IMO, but I really dont see it
as something that replaces the option to deprioritize your own
transactions to below 0-fee transactions.  It could even allow users who
receive payouts which are below 0-fee transactions to place a fee on the
subsequent transactions to allow the payouts to confirm quicker (if done
right).
> 
> > My point was that the easiest way to do it would be to ship a pruned
> > snapshot with Bitcoin, and such a system, while verifiable, would
> > increase Bitocin's centralization.
> 
> I'm not sure why. If you want to audit everything from scratch, after
> checking the code you could just blow away the included files and then
> "-connect=archive.bitcoin.org" or something like that. After
> rebuilding the chain from scratch, check the databases for consistency
> with the included data.
I would be surprised if more than a handful of devs audit such a thing.
And I would say that does define an increase in centralization.
> 
> It reduces the number of nodes with full copies of the block chain,
> yes, but as long as there's at least one copy of the old data in an
> accessible location new nodes can still bootstrap just fine.
Sadly, old nodes do not know where to look for such data, and I'm fairly
certain people running old nodes don't read the forums enough to catch
when it is announced that old nodes should make sure to
-connect=archive.bitcoin.org in order to avoid init

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

[Matt Corallo]

On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:
> > Yes, the format is something that must be hashed out (no pun
> > intended).  Need input from potential users about what information
> > they might need.
> 
> Matts point that a branch-per-transaction may duplicate data is well
> made, that said, I suspect a format that tries to fix this would be
> much more complicated.
> 
> How about see this project as a three part change?
> 
> First step - add the mempool command and make nodes sync up their
> mempools on startup.
ACK
> 
> Second step - if protocol version >= X, the "block" message consists
> of a header + num transactions + vector  instead of the full
> transactions themselves.
If vector is sorted in the order of the merkle tree, you dont need
to forward the merkle tree to non-filtered nodes, further saving some
small amount of bandwidth.  For filtered nodes, you would still need to
forward merkle branches anyway.
> 
> On receiving such a block, we go look to see which transactions we're
> missing from the mempool and request them with getdata. Each time we
> receive a tx message we check to see if it was one we were missing
> from a block. Once all transactions in the block message are in
> memory, we go ahead and assemble the block, then verify as per normal.
> This should speed up block propagation. Miners have an incentive to
> upgrade because it should reduce wasted work.
ACK
> 
> Third step - new message, getmerkletx takes a vector and returns
> a merkletx message: "merkle branch missing the root + transaction data
> itself" for each requested transaction. The filtering commands are
> added, so the block message now only lists transaction hashes that
> match the filter which can then be requested with getmerkletx.
I really dont think it would be /that/ difficult to make it getmerkletxs
vector. And then respond with a partial merkle tree to those
transactions.

Matt


--
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 P2P commands for diagnostics, SPV clients

[Matt Corallo]

On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote:
> > > Why not combine these two?
> >
> > I believe its because it allows the node which will have to use the
> > bloom filter to scan transactions to chose how much effort it wants to
> > put into each transaction on behalf of the SPV client.
> 
> If that's the case then the negotiation protocol needs to be specified
> too. It seems heavy though. If a node is getting overloaded it could
> just disconnect intensive peers or refuse new connections.
IMHO it already is.  A node requests a filter using filterinit by
specifying the false positive rate it wants and a guessed number of
items.  The node which will have to hold that filter then responds with
the closest filter to what the SPV node requested that it is willing to
provide.  If the SPV node responds with a filterload command, it has
accepted the offer, otherwise it will simply disconnect and find a
better full node.  
I'd much rather have an overloaded node respond with 50% fp rate filters
as an option if there aren't many full nodes available than simply
disconnect SPV clients.
At least thats my thinking, but you may be right that it is too heavy
for too little gain.


--
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] Near-term scalability

[Matt Corallo]

On Fri, 2012-06-15 at 13:29 +0200, Mike Hearn wrote:
> I had to hit the sack last night as it was 2am CET, but I'd like to
> sum up the discussion we had on IRC about scalability and SatoshiDice
> in particular.
> 
> I think we all agreed on the following:
> 
> - Having senders/buyers pay no fees is psychologically desirable even
> though we all understand that eventually, somebody, somewhere will be
> paying fees to use Bitcoin
> 
> - In the ideal world Bitcoin would scale perfectly and there would be
> no need for there to be some "winners" and some "losers" when it comes
> to confirmation time.
> 
> There was discussion of some one-off changes to address the current
> situation, namely de-ranking transactions that re-use addresses. Gavin
> and myself were not keen on this idea, primarily because it just
> avoids the real problem and Bitcoin already has a good way to
> prioritize transactions via the fees mechanism itself. The real issue
> is that SatoshiDice does indeed pay fees and generates a lot of
> transactions, pushing more traditional traffic out due to artificial
> throttles.
The idea can be more generalized in that there are many cases where the
generator of a transaction doesn't care about confirmation times, and
would really be willing to make their transaction lower priority than
other 0-fee transactions.  This enables the first point with lower
confirmation times for a while longer.
As it turns out, we already have an indication that someone is willing
to wait longer for confirmations - rapid reuse of an address.  
1) Green Addresses: The whole point of a green address is that you are
trusted based on your address, not necessarily based on confirmations of
your transactions.  In this case, you are generally willing to wait a
bit longer for confirmations than the average user depositing coins into
their Mt. Gox account.  
2) Donation Addresses: If you are using a publicized donation address,
you probably aren't depending on getting your coins *now* to turn around
and ship a product and, again, you are a bit more willing to tolerate
longer confirmation times.
3) Lazy (or overworked) coders: If, for whatever reason, someone
designing a bitcoin site decides that it is simply easier to make users
pay to a single address for everything, such actions should generally be
discouraged.  Such a setup is worse for end-user privacy.  Also, such
laziness (or likely just overworked and not having time to fix the
issue) is likely also laziness across the board including ignoring
multisend for payouts.  If you discourage such address use forcing site
designers to implement more sane policies, hopefully they will do enough
research to also do multisend.  Note that though this is where one
addresses sites like SatoshiDice, its also the one where we are likely
to have the least impact...

One of the ways to implement such deprioritization of rapidly-reused
addresses is to limit the count of address re-uses by default in memory
pool.  By limiting relaying of such transactions, you a) give nodes
across the network some small say in the transactions which they have to
deal with relaying outside of blocks, instead of relying on miners to
make decisions which are good for the total network load, but which are
worse for them.  b) You allow sites which wish to re-use addresses to do
so initially to keep the time-to-launch the same as it is today, but
force them to re-think their design decisions as they grow to
(hopefully) decrease their impact on the average Bitcoin full-node
operator.  Sites which begin to see their transactions rate-limited have
several options:
1) Make a deal with a miner to feed them their list of now-non-relayed
transactions outside of the regular p2p network and have them manually
added to blocks.  Id argue that such setups are going to become more
common in the future and such out-of-band transaction relaying should be
encouraged.  This also shifts the delay for other transactions from a
constant delay getting into blocks until there is room for additional
0-fee transactions to a spike on each block from the given miner.  I
highly prefer this, as you would see usually only one or two block delay
getting your transaction confirmed at the worst case, instead of a very
fuzzy unknown delay that could stretch on for some time.
2) Use rotating addresses.  This is likely the simplest to implement,
and I would absolutely think this is what most sites would end up doing.
Though it doesn't result in a decreased load on the transaction-relaying
nodes, it does at least allow for a minor improvement in user privacy.  

In the end, it boils down to an optional transaction deprioritization.
> 
> The following set of proposals were discussed:
> 
> (1) Change the mining code to group transactions together with their
> mempool dependencies and then calculate all fees as a group. A tx with
> a fee of 1 BTC that depends on 5 txns with zero fees would result in
> all 6 transactions being considered to have a fee 

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

[Matt Corallo]

On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote:
> > filterinit(false positive rate, number of elements): initialize
> > filterload(data): input a serialized bloom filter table metadata and data.
> 
> Why not combine these two?
I believe its because it allows the node which will have to use the
bloom filter to scan transactions to chose how much effort it wants to
put into each transaction on behalf of the SPV client.  Though its
generally a small amount of CPU time/memory, if we end up with a drastic
split between SPV nodes and only a few large network nodes, those nodes
may wish to limit the CPU/memory usage each node is allowed to use,
which may be important if you are serving 1000 SPV peers.  It offers a
sort of negotiation between SPV client and full node instead of letting
the client specify it outright.
> 
> > 'filterload' and 'filteradd' enable special behavior changes for
> > 'mempool' and existing P2P commands, whereby only transactions
> > matching the bloom filter will be announced to the connection, and
> > only matching transactions will be sent inside serialized blocks.
> 
> Need to specify the format of how these arrive. It means that when a
> new block is found instead of inv<->getdata<->block we'd see something
> like  inv<->getdata<->merkleblock where a "merkleblock" structure is a
> header + list of transactions + list of merkle branches linking them
> to the root. I think CMerkleTx already knows how to serialize this,
> but it redundantly includes the block hash which would not be
> necessary for a merkleblock message.
A series of CMerkleTx's might also end up redundantly encoding branches
of the merkle tree, so, yes as a part of the BIP/implementation, I would
say we probably want a CFilteredBlock or similar


--
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] Adding callback hooks to the satoshi client

[Matt Corallo]

I spent some time changing the internal bitcoin code to use callback
hooks, but its far from complete (or even really usable from anything
other than the code in the satoshi client itself, it doesnt even have
any deregister methods!).  As it sits now, it is likely to get more
eyeballs and merged for 0.7.  If you need additional specific callbacks,
adding them would be cool, though I wouldn't recommend relying on the
blockstore API to remain even remotely stable for the foreseeable
future.

https://github.com/bitcoin/bitcoin/pull/771

Matt

On Wed, 2012-03-21 at 22:13 -0700, Eric Lombrozo wrote:
> Hey, guys.
> 
> I've been writing a number of apps that require realtime event
> notifications, where the JSON-RPC API clearly doesn't suffice.
> 
> There are two approaches I've been taking to this end:
> 
> 1) Writing my own library for dealing with raw bitcoin structures and
> connecting to bitcoin nodes via the bitcoin protocol.
> 2) Making custom builds of the satoshi client putting callback hooks
> in key points.
> 
> Neither of these two approaches is ideal. (1) involves a lot of code
> duplication, (2) involves patching the satoshi client source
> each time I grab a later version, with the everpresent risk of
> something breaking and the need to continue maintaining these patches.
> Moreover, unfortunately many of these key points happen to be in files
> like main.cpp which see frequent changes.
> 
> I would like to propose adding these callback hooks to the main
> branch. I am willing to help locate these key points, reorganize the
> code
> to place these methods in separate source files, define a callback
> mechanism, and contribute source code.
> 
> -Eric Lombrozo


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Adding a pong message

[Matt Corallo]

On Tue, 2012-03-13 at 14:45 -0400, Luke-Jr wrote:
> On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote:
> > https://github.com/bitcoin/bitcoin/pull/932 adds a "pong" message that
> > echoes back a 64 bit nonce contained in the ping, if the protocol
> > version is new enough.
> > 
> > The goal of this is to make it easier for clients, especially mobile
> > clients, to quickly check if a connection is stale, and also to see if
> > a remote node is overloaded so we can avoid talking to it. A common
> > case where this happens is if the remote node is itself downloading
> > the block chain or doing something equally intensive.
> > 
> > Any objections?
> 
> Not really an objection per se, but what's wrong with TCP keepalives?
> 
It wont tell you if the node itself is overloaded (not just the OS'
network stack).

Looks good to me.

Matt


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Duplicate transactions vulnerability

[Matt Corallo]

In other words when we roll out the update, we have to make sure we have
>>50% not just 50%.  Something like 60%-75% should do fine (IMHO).  In
other words we just have to be very, very vocal about the change when it
happens and make sure miners are all on board.

Matt

On Wed, 2012-02-29 at 22:05 +, Ben Reeves wrote:
> Assuming 50% of hashing power adopts BIP30 but the actual client
> install base is relatively low the patch will likely result in a
> "hard" blockchain split if someone takes advantage.
> 
> A malicious miner can produce a duplicate coinbase which the majority
> of clients will accept but the majority of hashing power won't.
> Spending the coinbase output after disconnection will cause the
> blockchain to fork. All none BIP30 clients on the short blockchain
> will be vulnerable to transaction reversal of 6 confirmations or more.
> 
> It is a relatively inexpensive attack to perform (costing the attacker
> only one valid block ~$240) and could be quite disruptive. I think
> this should be patched in DisconnectBlock() (if it hasn't already?)
> before any protocol change - maybe a new mapByCoinbase multimap is
> needed.
> 
> Thank You,
> Ben Reeves
> www.blockchain.info
> 
> On Tue, Feb 28, 2012 at 4:48 PM, Pieter Wuille  
> wrote:
> > Hello all,
> >
> > as some of you may know, a vulnerability has been found in how the
> > Bitcoin reference client deals with duplicate transactions. Exploiting
> > it is rather complex, requires some hash power, and has no financial
> > benefit for the attacker. Still, it's a security hole, and we'd like
> > to fix this as soon as possible.
> >
> > A simple way to fix this, is adding an extra protocol rule[1]:
> >
> >  Do not allow blocks to contain a transaction whose hash is equal to
> > that of a former transaction which has not yet been completely spent.
> >
> > I've written about it in BIP30[2]. There is a patch for the reference
> > client, which has been tested and verified to make the attack
> > impossible. The change is backward compatible in the same way BIP16
> > is: if a supermajority of mining power implements it, old clients can
> > continue to function without risk.
> >
> > The purpose of this mail is asking for support for adding this rule to
> > the protocol rules. If there is consensus this rule is the solution, I
> > hope pools and miners can agree to update their nodes without lengthy
> > coinbase-flagging procedure that would only delay a solution. So, who
> > is in favor?
> >
> >  [1] https://en.bitcoin.it/wiki/Protocol_rules
> >  [2] https://en.bitcoin.it/wiki/BIP_0030
> >
> > --
> > Pieter




--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

I changed the description of the message parameter to be a bit more
descriptive, however, I dont want to change the name of the parameter
because some clients have already implemented that and I really prefer
to make as minor of changes as possible to this BIP even if it is
officially only a Draft.  

Matt

On Sat, 2012-02-04 at 16:03 +, Gary Rowe wrote:
> Seems reasonable to me.
> 
> On 4 Feb 2012 14:03,  wrote:
> Just another question concerning BIP21:
> 
> On the wiki, the description of the "message" parameter reads:
> "message that shown to the user after scanning the QR code"
> 
> I believe that the purpose of this parameter is to contain a
> description of the  transaction. This has use cases that go
> beyond QR codes.
> 
> If I am right, then I would say that naming it "message" is
> misleading. In fact, "message" suggests that a message will be
> sent to someone (the recipient of the funds? a third party?),
> which is not the case here. That parameter should probably be
> called "description".



--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

Not yet, its up to genjix (Amir) to do that.  See
https://github.com/genjix/bips/pull/2

Matt

On Thu, 2012-02-02 at 17:07 +, Gary Rowe wrote:
> BlueMatt, did the BIP0021 Wiki entry for "req:" to "req-" get updated?
> I'm looking there now and it seems to be still at "req:"
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___ Bitcoin-development mailing 
> list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

Odd, here I was thinking I checked that.  Just goes to show how useful
sources other than the rfc itself are... Anyway, Ill change it to a
hyphen.

Matt

On Tue, 2012-01-31 at 22:37 +, Gary Rowe wrote:
> Andreas has a good point. See RFC 3986 on URI
> schemes: http://tools.ietf.org/html/rfc3986#page-12
> 
> 
> The colon is a reserved general delimiter (similar in use to the / in
> a typical URL, but applies to URNs etc). As suggested, we get
> req:something being changed to one of the unreserved characters that
> do not have to be URL encoded. Again, from the RFC these are
> 
> 
> * Option A: req_something (underscore)
> * Option B: req-something (hyphen)
> * Option C: req~something (tilde)
> * Option D: req.something (period)
> 
> 
> Personally, my eye likes Option B, the hyphen. 
> 
> On 31 January 2012 22:14, Andreas Schildbach 
> wrote:
> On 01/31/2012 07:22 PM, Matt Corallo wrote:
> 
> > that "It is recommended that additional variables prefixed
> with
> > mustimplement: not be used in a mission-critical way until a
> grace
> 
> 
> Is the ':' sign actually allowed in URL parameter names
> (unescaped/unencoded)? If not, I'd propose an unrestricted
> char instead,
> maybe '_'.




--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

OK, I went ahead and changed mustimplement out for req (required).  Its
not quite as expressive, but its much shorter and still makes sense
(IMHO).  I also explicitly stated that numbers shouldnt contain commas
and should use period to separate whole numbers and fractional decimal
fractions (to avoid any localization concerns).

Matt

On Tue, 2012-01-31 at 20:02 +0100, Wladimir wrote:
> 
> On Tue, Jan 31, 2012 at 7:22 PM, Matt Corallo
>  wrote:
> 
> All that said, I dont think its an ideal solution, depending
> on the
> names of variables to provide information is ugly.  If anyone
> has a
> better idea on how to do backward compatibility, please
> suggest it.
> 
> I like the mustimplement: idea, though I'd recommend a shorter
> (abbreviated) prefix, to keep URL sizes small for QR codes and such,
> 
> Wladimir
> 
> 



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

OK, so I just did some heavy changes to the methods for forward
compatibility in BIP 21.  Instead of a version number, now new variables
will be added either as-is or with a mustimplement: prefix.  If a
clients does not know what the variable is that is after mustimplement:,
it should consider the entire URI invalid and either notify the user or
just drop it silently.  That way things like expiretime can be added
without worrying about old clients ignoring the field.  

All that said, I dont think its an ideal solution, depending on the
names of variables to provide information is ugly.  If anyone has a
better idea on how to do backward compatibility, please suggest it.

In terms of the expiretime field being implemented now, I dont think its
appropriate.  Because some clients already have an old implementation,
the possibility of it getting ignored is too large.  The BIP now states
that "It is recommended that additional variables prefixed with
mustimplement: not be used in a mission-critical way until a grace
period of 6 months from the finalization of this BIP has passed in order
to allow client developers to release new versions, and users of old
clients to upgrade."  Mostly, however, I want to keep the list of
changes from the Bitcoin-Qt implementation to this BIP very, very
minimal this late the 0.6 release cycle (I want to get this BIP
finalized and implemented for 0.6, so that at least Bitcoin-Qt will have
no version which support OS URI opening with a broken implementation).

Matt

On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote:
> On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote:
> > BIP 20 really has no support among implementations such as Bitcoin-Qt, 
> > Electrum, MultiBit or Bitcoin-JS. As the most active and visible user 
> > facing GUI projects (all with some form of URI Scheme), their opinion 
> > carries the most weight. To a lesser degree Bitcoin-Qt has the large 
> > majority of users too (although that's a line of reasoning I'd discourage).
> > 
> > Normally we should probably Reject BIP 21 and re-submit a new standard (for 
> > history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans 
> > some sections b) it is still a draft, probably the best thing here is if 
> > you all agree on something to run it by BlueMatt and then we'll make it the 
> > new BIP 21.
> > 
> > I can see a consensus forming on most parts. Just the send private key is 
> > contentious, and there's the topic of adding a time to expire field for 
> > merchants (this is a very good idea IMO).
> > 
> > Also BIP 20 is problematic because it is incompatible with about every 
> > standard on the web. All the HTML, URI and everything uses decimal numbers 
> > alone. I see no reason for breaking with tradition. Note that everytime I 
> > have to write Color or Vectorize (as a British speaker) in my code, I die a 
> > little inside. But it's convention and American English = International 
> > English. Also it would be cool if all code used a *real* international 
> > language (like Esperanto) but the world ain't perfect! We live in a 
> > decimal-counting English-speaking Windows-using God-worshipping world!
> > 
> > (no offense to decimal-counting English-speaking Windows-using 
> > God-worshipping world- I do half those things too :)
> 
> The send crap was not in the original spec, is not implemented anywhere,
> and should have been removed as part of the BIP 21 copy/paste.  It is
> now gone.
> 
> As for the expire time, well thats a bit problematic IMHO.  Technically
> BIP 21 is still a draft, but it is implemented in all versions of
> Bitcoin-Qt for drag and drop and adding a field which restricts the
> validity of a URI for new clients, but which old clients will gladly
> accept could result in some ugly situations IMO.
> 
> Matt


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote:
> BIP 20 really has no support among implementations such as Bitcoin-Qt, 
> Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing 
> GUI projects (all with some form of URI Scheme), their opinion carries the 
> most weight. To a lesser degree Bitcoin-Qt has the large majority of users 
> too (although that's a line of reasoning I'd discourage).
> 
> Normally we should probably Reject BIP 21 and re-submit a new standard (for 
> history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some 
> sections b) it is still a draft, probably the best thing here is if you all 
> agree on something to run it by BlueMatt and then we'll make it the new BIP 
> 21.
> 
> I can see a consensus forming on most parts. Just the send private key is 
> contentious, and there's the topic of adding a time to expire field for 
> merchants (this is a very good idea IMO).
> 
> Also BIP 20 is problematic because it is incompatible with about every 
> standard on the web. All the HTML, URI and everything uses decimal numbers 
> alone. I see no reason for breaking with tradition. Note that everytime I 
> have to write Color or Vectorize (as a British speaker) in my code, I die a 
> little inside. But it's convention and American English = International 
> English. Also it would be cool if all code used a *real* international 
> language (like Esperanto) but the world ain't perfect! We live in a 
> decimal-counting English-speaking Windows-using God-worshipping world!
> 
> (no offense to decimal-counting English-speaking Windows-using 
> God-worshipping world- I do half those things too :)

The send crap was not in the original spec, is not implemented anywhere,
and should have been removed as part of the BIP 21 copy/paste.  It is
now gone.

As for the expire time, well thats a bit problematic IMHO.  Technically
BIP 21 is still a draft, but it is implemented in all versions of
Bitcoin-Qt for drag and drop and adding a field which restricts the
validity of a URI for new clients, but which old clients will gladly
accept could result in some ugly situations IMO.

Matt


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] All pre-BIP BIPs are not valid

[Matt Corallo]

I have to say, I agree with Luke here, this was Finalized a long time
ago.  The version that was agreed on can be seen at
https://en.bitcoin.it/wiki/BIP_0021

Also see https://bitcointalk.org/index.php?topic=6205.0 and Luke's three
biased polls at 
https://bitcointalk.org/index.php?topic=6206.0
https://bitcointalk.org/index.php?topic=6207.0
https://bitcointalk.org/index.php?topic=6208.0

Matt

On Sun, 2012-01-29 at 14:40 -0800, Amir Taaki wrote:
> Hi all,
> 
> Luke Dashjr is telling me that BIP 20 was accepted as Final a year ago 
> (before the BIP process existed).
> 
> https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
> 
> 
> I respectfully disagree. I find it nonsensical to have a BIP to have been 
> accepted before the BIP process existed. My feeling is that a BIP needs to go 
> through the proper formalised motions in public before becoming accepted.
> 
> The URI Scheme did not go through these motions. I did not know it was even 
> accepted, and at least 2 implementations have objected to the standard as is. 
> This is problematic because a standard is meant to be consensus building not 
> enforcement from above.
> 
> Ergo I am going to say:
> 
> NO BIP EXISTED BEFORE THE BIP PROCESS.
> 
> NEW BIPS ARE ALWAYS DRAFT STATUS.
> 
> BIPS CHANGE STATUS AS SPECIFIED IN BIP 0001
> 
> Luke claims I do not have the ability to specify those conditions above.
> 
> If there are any objections then please tell me. I did not get to observe the 
> process for BIP 20, therefore I am not accepting it. Anybody is welcome to 
> submit a competing BIP to Luke's BIP 20 (as has happened with BIP 16 and 17).



--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC

[Matt Corallo]

Because many made the mistake and it isnt specified in this email, this
meeting is tomorrow (not 30 minutes ago).

On Mon, 2012-01-02 at 08:04 -0800, Amir Taaki wrote:
> This meeting is to discuss the new OP_EVAL changes coming to bitcoin.
> 
> A good summary of the past discussion so far by justmoon can be found:
> http://privatepaste.com/4088b049af
> 
> Hopefully this can become a weekly thing. For now this is to discuss and 
> inform about the coming changes to bitcoin.
> 
> --
> 
> Where: Freenode IRC #bitcoin-dev
> When:  21:00 UTC (16:00 New York time) until 22:00*
> What:  OP_EVAL
> 
> Bitcoin is starting decentralising as any healthy free thinking community
> should. Projects are thiving and the economy is growing. New ideas are
> being realised and will edge out old models disruptively.
> 
> My hope is that we don't all become fractured. By having weekly regular
> meetings, projects can harmonise in lock step. Concepts and algorithms can
> be proposed and debated. You'd be surprised what having a scheduled regular
> platform can achieve. A soap-box on an island in central waters.
> 
> For me, I don't have time to wade through IRC discussions, forum posts and
> mailing lists. At least if the important things are discussed in one place
> it makes bitcoin development and the system more accessible.
> 
> Before meeting:
> 
> - A wiki page is created for in advance of a weekly meeting.
> - Announced on forums/mailing lists.
> - Throughout the week talking points are added to the meeting page.
> 
> After:
> 
> - Log of discussion is posted online.
> - I will type an accessible summary for the community at large on
> http://bitcoinmedia.com/
> - Next weekly meeting is scheduled.
> 
> Amir Taaki
> 
> *We can go over this hour, but this is to stop meetings dwindling off topic
> into banal banter and stay focused.
> 
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] upnp isnt working

[Matt Corallo]

On Fri, 2011-12-30 at 00:57 -0800, Amir Taaki wrote:
> hey,
> 
> so sipa/gmaxwell proposed on irc that maybe upnp is not working anymore but 
> there isnt any way to test.
> 
> well i made an alternate chain, and ran the daemon on my vps.
> 
> sometimes it accepts connections, sometimes not. It's all very patchy.
> 
> anyway just putting this out there

I believe the issue isn't lack of working, but lack of re announcing to
the router that the port needs to remain open.

Matt


--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Pubkey addresses

[Matt Corallo]

On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
> Don't know much about QR codes, but I thought they have a length limitation.
> Why jav wants to use not just addresses but firstbits then?
Under no circumstances should the use of firstbits ever be supported.
It doesn't scale, not even close, especially as we (hopefully) move
towards SPV clients.  Also, it provides incentives for people to spam
the chain to get a firstbits address.  Never should that be supported.

Matt


--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP 15] Aliases

[Matt Corallo]

On Thu, 2011-12-15 at 13:59 -0600, theymos wrote:
> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete u...@server.com handling:
I'm not against this, but I think its way overcomplicated when compared
to the DNS or HTTPS methods.
> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.
OK, not too debatable, but considering how terrible bitcoind's account
handling is, the second might not be easy to get right...
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.
This is where I think this method becomes way overcomplicated.  Not only
do you have to update the IP-Transaction code, but now you have to
implement the full DNS System that is the other option as well.  Note
that to make this secure, we have to have a full DNSSEC-capable resolver
built-into bitcoind (there are libs, but it has to happen).  Yes you can
ask the user "does this fingerprint look right to you? Y/N" but that
always opens you up to a ton of users getting screwed out of coins and I
don't think it should be enabled, except in bitcoind, and since the main
target of this whole alias system is bitcoin-qt users, well...

Matt


--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP 15] Aliases

[Matt Corallo]

On Tue, 2011-12-13 at 00:37 +0100, Jorge Timón wrote:
> I don't think Amir wants to put it into the protocol, but I still
> don't like much the proposal if it has to rely on servers.
> As an aside, even if firstbits it's not useful enough for the human
> memory, it is still useful for QR-codes like in the case of green
> addresses's POS instant payments.
Firstbits isn't acceptable for anything.  As Amir originally pointed
out, it doesn't scale well and worst of all it fills the blockchain with
a ton of crap to get 1 satoshi at an address so that it is
"registered".  
> 
> Would it be too strange to use namecoin?
> Some devices may need to rely on block exploring servers, but it is
> the easiest decentralized solution that comes to mind.
Firstbits is unacceptable because it causes unnecessary harm to each
Bitcoin node.  However, if one were to use a chain specifically crafted
for such a purpose isn't terrible.  That said, it still doesn't scale
well and if it becomes popular virtually every implementation would have
to rely on trusted servers at which point you are better off going back
to an HTTPS/DNSSEC-based implementation

Matt


--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mac libboost_thread or thread-mt?

[Matt Corallo]

On Tue, 2011-10-04 at 16:40 -0700, Brian McQueen wrote:
> I installed boost via the mac ports.  Its got lobboost_thread-mt, but
> it doesn't have libboost_thread.a. Should I modify the makefile or get
> a different version of boost?
> 

(from
http://stackoverflow.com/questions/2293962/boost-libraries-in-multithreading-aware-mode)

The -mt suffix means built in multithreading aware mode (what this means
for a threading library I have no idea), however that suffix was removed
from Linux and Mac builds in 1.42.  If you are linking against 1.42+ on
Linux/Mac, adding/removing the -mt suffix means nothing AFAICT.

Matt


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Pull request for translation - who reviews it?

[Matt Corallo]

On Tue, 2011-09-27 at 20:28 +0200, da...@bitcoin.se wrote:
> Hi all,
> 
> I posted this question on the forums but got no answers.
Most developers treat the forums as write-only or just ignore them all
together, they are way too full of junk to bother reading.
> 
> I'd like to make some improvements to the Swedish translation of the
> client. I understand the technical side of making a pull request etc.,
> but will my request be accepted? There aren't many people in the
> project who can judge if the Swedish translation is good or not, so
> will it simply be accepted if noone opposes it?
Translation updates are pretty much just blindly pulled unless someone
opposes. 
> 
> Previous Swedish translations seem to have been commited by codler, is
> this person "responsible" for the Swedish translation? 
No one is responsible for translations in Bitcoin, though it would be
nice to have people agree to keep their translations up-to-date when
they submit new ones...
> Related to
> this, is there anywhere I can see a list of people who have
> permissions to make a pull?
Anyone can make a pull request, people who can push to the bitcoin repo
(ie can pull a pull request) are Gavin, tcatm, sipa, jgarzik, and
alexwaters.

Matt


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin 0.4 Release

[Matt Corallo]

Gavin tagged 0.4 release today, so here are my gitian builds.
These zips are in gitian-download format which means they can be
automatically downloaded and pgp-verified using the gitian-updater
script (see
https://github.com/devrandom/gitian-builder/blob/master/share/gitian-updater). 
Currently they only contain my sig, but if other devs have time to gitian build 
and re-roll the same zip with other sigs added as well it would make updating 
via gitian scripts easy and secure :).

http://dl.dropbox.com/u/29653426/bitcoin-0.4.0-linux-gitian.zip
http://dl.dropbox.com/u/29653426/bitcoin-0.4.0-win32-gitian.zip

SHA1:
3794ec0ce8a3ea96200b3970937c5f224313267d  bitcoin-0.4.0-linux-gitian.zip
a4857b2238a102d8f4ba9a2bdfed74ddd985ad3d  bitcoin-0.4.0-win32-gitian.zip

Email PGP signed as always.

Matt


signature.asc
Description: This is a digitally signed message part
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 0.4 Release Candidate 2

[Matt Corallo]

On Fri, 2011-09-09 at 10:02 -0400, Gavin Andresen wrote:
> I just tagged the git tree:  v0.4.00rc2
> 
> Fixes from release candidate 1:
> 
> + Optimize database writes for transactions with lots of inputs
> + Fix a deadlock that could occur when adding addresses from 'addr'
> messages and irc
> + Fix a potential problem with duplicate, un-spendable coinbase
> transactions if you were generating bitcoins, with a locked wallet,
> and ran out of keypool keys.
> 
> 
I'm too lazy to make nice tars so here is the raw gitian output (I plan
on working out gitian-downloader stuff sometime in the next couple
days).
Also, setup exe still not deterministic so theres that...

Anyway:
http://dl.dropbox.com/u/29653426/bitcoin-ubuntu-v0.4.00rc2.zip
http://dl.dropbox.com/u/29653426/bitcoin-win32-v0.4.00rc2.zip

SHA1s:
fd886d79bf48ba0d90f2f99fdd19d96946662bf5  bitcoin-ubuntu-v0.4.00rc2.zip
703712859ecdce423020116ebf65d087b179997d  bitcoin-win32-v0.4.00rc2.zip

Matt


signature.asc
Description: This is a digitally signed message part
--
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Alert System

[Matt Corallo]

On Thu, 2011-09-08 at 09:09 -0700, David Perry wrote:
> @Steve re "Who knows, it might be the only way we'll ever hear from
> Satoshi again."
> 
> 
> That brings up a good point... Does anyone aside from Satoshi actually
> have the ability to send such an alert?
Gavin does
> Should we at the very least change the alert system to give such
> privileges to current devs and ensure that that if the missing Mr.
> Satoshi has had his key compromised we don't see an
> authoritative-looking alert come up from a malicious source?
Meh, why make the key-holder send out two alerts for old clients and new
clients.  I also highly doubt satoshi would let his key get compromised.
That said, keep in mind they are literally just messages, they make no
functional difference.


--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Alert System

[Matt Corallo]

On Thu, 2011-09-08 at 07:42 -0700, David Perry wrote:
> There has been some discussion on the new Bitcoin StackExchange site
> lately about the alert protocol. A few have suggested that it might
> carry the potential for abuse (spam/DoS) and others have argued that
> it's merely deprecated. In any case, enough have voiced concerns that
> I've forked bitcoin/bitcoin, removed the snippet of code from main.cpp
> that makes the questionable call and submitted a pull request. On that
> pull request it was noted by Gavin Andresen that it merited discussion
> here and some kind of consensus should be reached before acting on
> that pull request. It was also mentioned that he thought the feature
> was still more useful than dangerous and that he would argue against.
> 
> 
> So I pose the question to you fine fellows: Is the alert system
> valuable, an unnecessary risk or merely a snippet of deprecated code?
> Should it be removed?

The alert system requires a signature verification when it receives an
alert, but so do blocks and transactions so it really isn't a DoS target
(remember that the alert system requires alerts to be signed by a key
that only gavin and satoshi have).

The alert system could prove very, very valuable.  In much software it
carries the risk for abuse or simply seems wrong that the developers can
send a message to everyone's computer to notify them of something, but
keep in mind that Bitcoin is financial software.  If there is an urgent
problem (like the overflow bug) there must be a way to notify people to
upgrade immediately, which is exactly what alerts provide.  Since alerts
no longer carry the ability to put Bitcoin into RPC safe-mode, they are
literally just a message and I see no reason why they should be removed.


--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Testing commits

[Matt Corallo]

On Tue, 2011-09-06 at 20:32 -0400, Alex Waters wrote:
> I am working on the following to create a stable build environment for
> testers:
> 
> 
> - Build bitcoin 4.0 source in Windows 7
When did it switch from 0.4 to 4.0?
I feel like the user-facing quality of the software should not be
over-emphasized when it really is very beta in quality.
> - Create a package of the build dependencies, and upload to SF
https://bitcointalk.org/index.php?topic=4750.0 (a bit outdated, but it
should still work fine)
> - Write up instructions for the build process
https://bitcointalk.org/index.php?topic=5851.msg86700#msg86700
If the instructions were updated with fresh links/versions/etc, they
should work 100%.
> 
> 
> x Build bitcoin 4.0 source in Ubuntu 11
> - Create a package of the build dependencies, and upload to SF
No package needed, just apt-get the relevant packages?
> - Write up instructions for the build process
doc/build-unix.txt is (though in some cases somewhat ubuntu-specific)
quite good IMHO.
> 
> 
> I am also compiling a list of commits that need to be tested in both
> environments. If you can think of any priority commits that need
> testing, and/or have a test case for them - please link the pull
> request in a response
>  to https://github.com/alexwaters/bitcoin/issues/2
If you are feeling lazy, I can convince jenkins.bluematt.me to churn out
windows and ubuntu builds almost identical to those that will come out
of gitian (ie the same build as the official release builds) if you
want.
Something like the current jenkins scripts could also be easily hacked
up to automatically sanity-test pull requests as they come in and catch
common errors (or just sanity failures).
> 
> 
> This is not a requirement for pull requests, but will help process the
> important/easy ones a lot faster. I would love to discuss other ways
> of prioritizing pull requests, but this seems like it can get the job
> done for the time-being.
> 
> 
> -Alex Waters 


--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage 
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 0.4rc1 known bugs

[Matt Corallo]

On Sat, 2011-09-03 at 20:13 -0400, Gavin Andresen wrote:
> Quick status update on 0.4; I probably won't have time to tackle these
> properly before Tuesday:
> 
> + sipa found what looks like a deadlock between the addr-handling and
> IRC-join-handling code.
> + UukGoblin reports a deadlock problem on a bitcoind handling getwork 
> requests.
> 
> If you want to get more familiar with the bitcoin code and you have a
> lot of patience, tracking down deadlocks a great way to do it.
> 
> + ArtForz found a performance bug with transactions that have
> thousands of inputs and outputs on the solidcoin test network.
>  (not as big an issue for bitcoin due to fees being based on
> transaction size, but still worrying)
> 
+ (my fault) Gitian doesnt build properly.


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin-qt ready for merging

[Matt Corallo]

On Wed, 2011-08-31 at 14:20 +, John Smith wrote:
> Hi,
> 
> Bitcoin-qt is now feature complete (including wallet encryption), and
> has been tested for a while by various people without any major
> problems.
> 
> It is now in status of feature freeze.
> 
> The project builds on Windows, MacOSX and Linux using qmake.
> 
> Impact to the core bitcoin functions is still minimal, and it can
> co-exist with Wx in the source tree. The only thing it lacks compared
> to the Wx GUI is translations, currently we only have English, Dutch
> and Russian.
Would it be possible to port some of the existing translations?
Something is better than nothing so some text that is close to the wx
version can just be copied.
Though IMHO its not a huge deal if qt is merged without all the
translations as IMHO it should be merged soon and then not the default
release GUI until its in tree for a bit (like one release) and some
translations can be built up.
> 
> So IMO, it is ready to be merged.
IMHO it should be merged right after 0.4 is pushed.


signature.asc
Description: This is a digitally signed message part
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Project status

[Matt Corallo]

On Mon, 2011-08-29 at 16:10 -0400, Gavin Andresen wrote:
> Quick brain dump on a bunch of stuff:
> 
> I'd like to get a 0.4 release out, but am still working on a fix for
> the deadlock bugs that the new wallet encryption and/or the CWallet
> refactoring caused. My short-term plan is to reduce the number of
> locks and make sure they're always acquired in a consistent order.
> Longer term, I think reworking the design to be based on
> boost::asio and use fewer threads is probably the right thing to do.
Hopefully working on something that would help do this now.
> 
> Other things on the 0.4 TODO list:  block chain checkpoint (got a PULL
> for that, thanks).  Updated list of hard-coded seed nodes (nanotube
> did that last time). Pieter's dump/import privkey patch.
Also my build update pull would be much appreciated.
> 
> After my talk at the conference, Alex Waters approached me about being
> the core bitcoin Q/A lead; he'll be working on creating test plans,
> keeping on top of the issues list, testing new features, and
> suggesting improvements to the code/test/release process.  And
> whatever else he thinks needs to be done to improve core bitcoin.
NICE


--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development