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

[Mike Hearn]

Hi Adam,

I am still confused about whether you actually support an increase in the
block size limit to happen right now. As you agree that this "layer 2" you
speak of doesn't exist yet, and won't within the next 10-12 months (do you
agree that actually?), can you please state clearly that you will support
Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but
does/soon will have some code associated with it.

But if we do no R&D on layer2, and insist that clients can never
> change to become layer2 aware, and layer2 is too hard etc
>

I think there's been some confusion here.

I, at least, have never argued that other systems can *never* happen. Never
is a long time, and I myself maintain a payment channels implementation.
These things have their place.

The argument is solely around the need to raise the block size *now* and
not allow the existing layer 1 to gum up and fall over.

If Stroem or Lightning or other block chains or Coinbase or secure hardware
tokens or whatever take off and people start moving bitcoins around that
way - fine. If they're choosing it of their own free will I have no issue
with that, nor does anyone else, I suspect.

However you don't seem fully confident that people actually will choose
whatever is being cooked up as "layer 2", if left to their own devices.
Indeed it's impossible for anyone to know that, as no "layer 2" actually
exists. Any such implementation could have all sorts of flaws that lead to
it not gaining traction.


> No offence but please find a way to gracefully stop and rejoin the
> constructive process. You can disagree on factors and points and be
> collaborative others disagree frequently and have done productive work
> cordially for years  under the BIP process.


As you know from the discussion with myself and Gavin a few days ago on
IRC, neither of us believe any such constructive process exists. There is
another thread to discuss the lack of such a process.


> - Did you accept payment from companies to lobby for 20MB blocks?


Oh please. Conspiracy theories, now, Adam? My position has been consistent
for years. I don't care whether the figure is 20 or something else (looks
like it'll be lucky 8 instead), but I have always been clear that the limit
must rise.

But for the avoidance of doubt: the answer is no.

Gavin is paid by MIT. The MIT deal gives Gavin complete independence.

I am currently self employed and most of income comes from a client that is
actually interested in Lighthouse. Luckily they have given me some leeway
to do general Bitcoin development as well, which this business falls under.
I would *much* rather be working on Lighthouse than this, and so would they.

But seeing as you've gone there - let me flip this around. Blockstream has
a very serious conflict of interest in this situation. I am by no means the
first to observe this. You are building two major products:

   1. Sidechains, a very complex approach to avoid changing the Bitcoin
   consensus rules to add new features.
   2. Lightning, a so-called "layer two" system for transaction routing

No surprise, the position of Blockstream employees is that hard forks must
never happen and that everyone's ordinary transactions should go via some
new network that doesn't yet exist.

The problem is that rather than letting the market decide between ordinary
Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin
protocol because you don't trust people to spontaneously realise that they
should be using your companies products.

I know that many of you guys had these views before joining Blockstream. I
am not saying you are being paid to have views you didn't previously have.
I realise that birds of a feather flock together.

Regardless, that conflict of interest DOES exist, whether you like it or
not, because if you succeed in running Bitcoin out of capacity your own
company stands to benefit from selling consulting and services around your
preferred solutions.

With respect to user rights: all the polling done so far suggests users who
are paying attention strongly support increasing the block size. For
example:

Q: "Should the bitcoin block size be raised in the next two years"
A: 92% yes

http://www.poll-maker.com/results329839xee274Cb0-12#tab-2

Additionally, many Bitcoin users have explicitly delegated handling the
technical details to someone else, like a payment processor or their wallet
developers. Those people are nearly all sure that the block size limit
should rise too.

So please don't engage in idle speculation about "users vs companies". They
aren't some kind of opposing forces. Companies live for their users, and
many of those companies were formed by long time Bitcoin users.

And finally, the Bitcoin social contract is not defined by whatever random
state the code was in at the time Gavin decided to focus on research. Both
Gavin and I have been working on Bitcoin longer than you, Gregory or Peter
Todd. The social contract was and still

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

[Mike Hearn]

>
> Mailman isn't resigning it.  Should it be?  Does other mailing list
> software?
>

Mailman must take responsibility for the mail itself. It doesn't have to
actually sign with DKIM to do so: for backwards compatibility, spam filters
fall back to other heuristics to try and figure out the 'owner' of the mail
if it doesn't use DKIM. Those heuristics can go wrong of course. Ideally
all mail would be DKIM signed. There's no reason not to do it, really.

Yes mailing lists that edit people's emails resign. For example, from a
recent message to the bitcoinj list

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
*d=googlegroups.com *; s=20120806;
h=to:from:subject:date:lines:message-id:references:mime-version
 :content-type:user-agent:in-reply-to:x-original-sender
 :x-original-authentication-results:reply-to:precedence:mailing-list
 :list-id:list-post:list-help:list-archive:sender:list-subscribe
 :list-unsubscribe;



> I suppose it is somewhat acceptable for us to remove subject tags and
> footers if we have no choice...
>

Good email clients can extract the same information from the headers
anyway. I filter all my mail based on them, and the headers also contain
unsubscribe instructions. Gmail is capable of using them programmatically.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

[Mike Hearn]

>
> The new list currently has footers removed during testing.  I am not
> pleased with the need to remove the subject tag and footer to be more
> compatible with DKIM users.
>

Lists can do what are effectively MITM attacks on people's messages in any
way they like, if they resign for the messages themselves. That seems fair
to me!  :)


>  I'm guessing DKIM enforcement is not very common because of issues like
> this?
>

DKIM is used by most mail on the internet. DMARC rules that publish in DNS
statements like "All mail from bitpay.com is signed correctly so trash any
that isn't" are used on some of the worlds most heavily phished domains
like google.com, PayPal, eBay, and indeed BitPay.

These rules are understood and enforced by all major webmail providers
including Gmail. It's actually only rusty geek infrastructure that has
problems with this, I've never heard of DKIM/DMARC users having issues
outside of dealing with mailman. The vast majority of email users who never
post to technical mailing lists benefit from it significantly.

Really everyone should use them. Adding cryptographic integrity to email is
hardly a crazy idea :)


> It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's.
>

It's not SourceForge, it's your spam filter. His mail gets through to me
but it's all in the spam folder.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> Yeah, but increasing block-size is not a longterm solution.


Are you sure? That sort of statement is hard to answer because it doesn't
say what you think long term is, or how much you expect Bitcoin to grow.

Satoshi thought it was a perfectly fine long term solution because he
thought hardware would get cheaper as fast or faster than Bitcoin would
grow. You may disagree with him, but as we're talking about the future are
you 100% certain he was wrong? I did calculations a long time ago that
suggested even with today's hardware (+some software optimisations) it
would be feasible to keep up with Visa.

Hardware improvements can be unintuitive. There's a spreadsheet here that
lets you play with various parameters.

https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128

(note: the spreadsheet says avg txn size is 250 bytes, but if you check the
formula for the middle column, it does actually use 500 bytes as the
multiplier hard coded).


> Necessary higher fees are a logical consequence of lower subsidies.
> Bitcoin was basically free to use at the beginning because miners got paid
> with new coins at  the expense of those who already hold coins.
> Eventually there needs to be a mechanism which matches supply and demand.
>

That's not clear either, I'm afraid.

Remember that there's an upper limit on how high Bitcoin fees can go. When
fees become higher than what the banking system charges, many users won't
use Bitcoin for moving money around anymore. Fees cannot really go much
higher than that even if you assume the currency is still attractive for
other reasons, because people would just sell their coins for fiat, move
the fiat, and buy back the coins the other side.

The way mining will be funded in future is an open question. There are
differing proposals. Still, even with a higher hard block size limit,
miners can always refuse to mine transactions that don't include a
particular fee. So if you're worried about this, miners aren't being forced
into any particular policy.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

[Mike Hearn]

>
> We already removed the footer because it was incompatible with DKIM
> signing.  Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
> with DKIM header signing only if the poster manually prepends it in their
> subject header.
>

I still see footers being added to this list by SourceForge?


> Opinions?
>

I've asked Jeff to not use his @bitpay.com account for now.

The only real fix is to use a mailing list operator that is designed to
operate correctly with DKIM/DMARC, either by not modifying messages in
transit, or by re-sending (and ideally re-signing) under their own identity.

Though I'm sure this won't be an issue for the Linux Foundation, the latter
approach is dangerous because it means the list operator takes full
responsibility for any spamming that occurs from that domain. If the mail
server is ever hacked or spammers start posting to the lists themselves,
all that spam will be seen as originating from the listserv itself and the
reputation will be degraded. It can end with everyone's mail going to the
spam folder.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks
>

It's impossible, Mark. *By definition* if Bitcoin does not have sufficient
capacity for everyone's transactions, some users who were using it will be
kicked out to make way for the others. Whether that happens in some kind of
stable organised way or (as with the current code) a fairly chaotic way
doesn't change the fundamental truth: *some users will find their bitcoin
savings have become uneconomic to spend*.

Here's a recent user complaint that provides a preview of coming
attractions:

https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/

Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
> onto a paper wallet. When I try to send it, a window pops up stating
> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.


These sorts of complaints will get more frequent and more extreme in the
coming months. I realise that nobody at Blockstream is  in the position of
running an end user facing service, but many of us are  and we will be
the ones that face the full anger of ordinary users as Bitcoin hits the
wall.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> So then: make a proposal for a better process, post it to this list.
>

Alright. Here is a first cut of my proposal. It can be inserted into an
amended BIP 1 after "What belongs in a successful BIP?". Let me know what
you think.



The following section applies to BIPs that affect the block chain consensus
rules or the peer to peer protocol and thus require changes to Bitcoin
Core.

Once a draft BIP has been submitted to bitcoin-development for
consideration, the Bitcoin Core maintainer will deliver a preliminary
yes/no verdict within three weeks. This verdict may be informed by the
debate that has taken part in the previous three weeks. If more time is
required, the maintainer is required to request an extension from the BIP
author, who may then elect to force an immediate decision (risking a no),
or choosing to allow more time.

The verdict will meet the following criteria:

   - It will address the latest version of the BIP at the time the verdict
   is rendered.

   - In case of a rejection, it will spell out and describe the technical
   rationale for this decision. Opinions held by other people are not
   considered technical rationales: if the maintainer agrees with a technical
   point made during discussion, he must own that opinion for himself.
   Therefore no BIP will be rejected on grounds of controversy, disagreement,
   lack of consensus or otherwise.

   - In case of rejection, the maintainer will provide a clear, specific
   list of actionable steps the BIP author can take next. For example, a list
   of what changes would address the technical objections raised. In case the
   maintainer believes no change could ever make the BIP acceptable, the list
   must consist of instructions for how to create a patch set and, in the case
   of changes to the consensus rules, how to initiate a hard fork.

A BIP, even once rejected, may live on in the BIPS repository, though its
entry in the index may be sorted below others. The BIP author may update
the BIP with a summary of any resulting discussion. As such a summary may
be inherently contentious in case of a dispute, the authors wording of that
summary is final and may not be subject to meta-debate.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> If you think it's not clear enough, which may explain why you did not even
> attempt to follow it for your block size increase, feel free to make
> improvements.
>

As the outcome of a block size BIP would be a code change to Bitcoin Core,
I cannot make improvements, only ask for them. Which is what I'm doing.

I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany
his patch, because BIPs are best when they describe working code, and BIP 1
*is* at least clear about that. Otherwise it can turn out during
implementation that something was different to what was anticipated. I'm
sure you agree with this.

So a BIP is coming. However, BIP 1 also says this:

Vetting an idea publicly before going as far as writing a BIP is meant to
> save the potential author time


and

BIP authors are responsible for collecting community feedback on a BIP
> before submitting it for review


OK. Gavin has been vetting the idea publicly and collecting community
feedback. Note that the entire Bitcoin community is not on this list, so he
published a series of blog posts to get wider feedback, and then was
criticised for not doing it all here instead.

But anyway - so far, so good.  The procedure is being followed.

What happens once a BIP is written? The process says:

For a BIP to be accepted it must meet certain minimum criteria. It must be
> a clear and complete description of the proposed enhancement. The
> enhancement must represent a net improvement. The proposed implementation,
> if applicable, must be solid and must not complicate the protocol unduly.



>  Once a BIP has been accepted, the reference implementation must be
> completed.


This is where the problem starts.

The BIP process you refer to *does not state how acceptance will happen*.
It merely sets out a few minimum requirements like making some sort of
sense, having code. It's also full of extremely vague descriptions like
"must represent a net improvement". Improvement according to who? That's
left unexplained.

And then it says what happens once a BIP is accepted.

The middle bit is missing. When there is disagreement over a consensus BIP,
how are decisions made?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

Hi Pieter,

I believe Gavin plans to write a blog post about the hard fork process, but
I'd like to debate this with you now, if only to give him material to work
with :)

Your points look to me like the hard/soft fork debate in different clothes.

For example, we all agree that the rules of Bitcoin *can* be changed, and
have been before (e.g. P2SH), with software upgrades.

When such a fork happens, any user who does not upgrade their node isn't
fully verifying the block chain anymore. Their software might *think* it
is, but it's running NOPs that don't mean NOP to other nodes. So there is a
divergence in the consensus, it's merely been done in such a way that the
node won't stop and print "hard fork detected" to the logs. It'll happily
accept a block that violates the new rules, then wait to be corrected by
miners.

So with any fork, hard or soft, there is risk to those who don't upgrade.
They may accept a block, or even two blocks, that they believe are valid
according to their old rule set, but which other miners would reject. The
effect on double spending is much the same.

Now let's talk philosophy.

* Philosophy: Bitcoin is not a democracy.
>

This appears to be a key point of dispute. Bitcoin is a democracy, though
the analogy is not perfect. You can certainly believe whatever you like
about the true state of the ledger, but rubber hits the road the moment you
go and trade with other people.

If 90% of the people you trade with believe a coin exists, and you don't,
you're gonna discover you keep getting paid with that coin and its
descendents. You may hate it, you may feel your rights are being violated,
you may refuse to trade with those people but it will keep happening.

Money is about trade, and trade inherently involves the decisions of other
people. No man is an island.

With Bitcoin we have a great way to quickly find out what other people
believe about the ledger. If the vast majority of people are on ledger A
and you're on ledger B, then you've got a strong incentive to come into
line with the majority in order to keep trading.


> Changing the rules should be possible if there is wide consensus, but
> nobody should feel forced to change their code against their will.
>

Nobody, not even after a hard fork, is *forced* to change their code
against their will. It may be something that *other people require* as part
of trading with them though. Whether one considers this "forced" or not I
guess can be argued either way. Are you "forced" to buy oranges from the
single orange seller in town if the other goes bankrupt, or could you just
avoid oranges? Where does economic freedom begin and end?


> * Governance: being able to push for a controversial change to the system
> sets an incredibly dangerous precedent about who is in charge of the
> system's rules.
>

I think it's surely the opposite - *not* being able to push for
controversial changes sets an incredibly dangerous precedent. Namely,
whoever gets to decide that a change is controversial gets to veto anything
they like!


> I can promise you that I will say anything in mail to this list if someone
> points a gun at me
>

Indeed, me too! But it's worse than that: what if someone sockpuppets a
discussion to make it look like a change does or does not have consensus?

One reason I keep banging on about *process* and how Wladimir needs to be
The Decider is that the current attempt at "process" is so vague, not only
is it unexplainable, but it's wide open to manipulation.

Good thing we have a way to resolve this problem:  the block chain. Now it
doesn't matter if someone points a gun at you or me. We can object to
whatever we like and that wouldn't bring Bitcoin to a halt, thus removing
the incentive to try and pressure individuals.

But if we don't have that ability to vote through choice of software and
rulesets, then us poor developers really are in charge and that's not a
place any of us should want to go. There must be a mechanism for people to
disagree with the consensus, even in major, controversial ways, and that
mechanism must have real force to it.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> And allegations that the project is "run like wikipedia" or "an edit war"
> are verifyably untrue.
> Check the commit history.
>

This was a reference to a post by Gregory on Reddit where he said if Gavin
were to do a pull request for the block size change and then merge it, he
would revert it. And I fully believe he would do so!
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

OK, let's agree to unpack the two things.

The first issue is how are decisions made in Bitcoin Core? I struggle to
explain this to others because I don't understand it myself. Is it a vote
of people with commit access? Is it a 100% agreement of "core developers"
and if so, who are these people? Is it "whoever reverts the change last"?
Could I write down in a document a precise description of how decisions are
made? No, and that's been a fairly frustrating problem for a long time.

But let's leave it to one side for a moment.

Let's focus on the other issue:   what happens if the Bitcoin Core decision
making process goes wrong?

For the sake of argument let's pretend we're discussing a different change,
let's imagine there is a proposal to change the block format to include a
Widget, where a Widget is some potentially desirable thing. And this change
means a hard fork. Let's put the block size to one side for a second to
avoid getting distracted.

Imagine that 90% of people in Bitcoin want their Widgets, but one of your
committers refuses to accept it.  I am not saying the block size debate has
such proportions but pretend Widgets do.

What is the process for resolving this problem?

Gavin and I say - there is a process, and that process is a hard fork of
the block chain.

What you're saying is - there is no process because a contentious hard fork
must never happen. Such a change is simply impossible.

Now which is a better description of this situation? Is the "it must never
happen end of story" really the cuddly warm democracy that you seem to
suggest? Or is it more like a dictatorship where the opinions of one or two
people can override all the others?

The typical answer I'm seeing to this is that Bitcoin Core's own decision
making process is so fantastic that it never goes wrong, even though
"consensus" is not defined and "technical majority" is not defined and we
have serious long time contributors on this mailing list (such as wallet
developers) disagreeing with this consensus yet our feedback is being
ignored.

You guys *must* accept that your preferred process for resolving disputes
is, itself, in dispute. That leaves the block chain itself as the only
remaining method for bringing this saga to a close.

So this is why we keep disagreeing:

   - If Bitcoin Core has reached a formal decision made by the maintainer
   via whatever mechanism he likes to not accept the block size increase, then
   alright, technical disputes will happen. But 

   - You should agree that the next step is a fork of both the software and
   the block chain. And you should welcome such a thing because it is the ONLY
   check on your own power. It's the one thing that allows the community to
   reject the decision making process you are using in case it goes wrong.

I keep reading that Bitcoin cannot survive a hard fork. Well, we've
survived an accidental fork that happened without anyone being prepared,
and even with a planned soft fork "never upgrade" isn't really an option
for either miners or businesses, so ultimately node operators must know
about upgrades and make them. Both myself and Gavin think this process can
work out OK.

Do you at least understand where we're coming from here, even if you
disagree? And if you disagree, is it because you think a hard fork to
resolve a dispute can't work technically, or is it some other reason?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
already said long ago he wouldn't just commit something, even though he has
the ability to do so.

So why did I say it? Because it's consistent with what I've always said:
 you cannot run a codebase like Wikipedia. Maintainers have to take part in
debates, and then make a decision, and anyone else who was delegated commit
access for robustness or convenience must then respect that decision. It's
the only way to keep a project making progress at a reasonable pace.

This is not a radical position. That's how nearly all coding projects work.
I have been involved with open source for 15 years and the 'single
maintainer who makes decisions' model is normal, even if in some large
codebases  subsystems have delegated submaintainers.

This is also how all my own projects are run. Bitcoinj has multiple people
with commit access. Regardless, if there were to be some design dispute or
whatever, I wouldn't tolerate the others with commit access starting some
kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
expect to get my own way in other people's projects by threatening to
revert the maintainers changes.

Core is in the weird position where there's no decision making ability at
all, because anyone who shows up and shouts enough can generate
'controversy', then Wladimir sees there is disagreement and won't touch the
issue in question. So it just runs and runs and *anyone* with commit access
can then block any change.

I realise some people think this anti-process leads to better decision
making. I disagree. It leads to no decision making, which is not the same
thing at all.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mike Hearn]

>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>

How do we plan to deal with security & incident response - exactly the same
way as before. Remember that XT is basically Core plus a few patches.

Gavin and myself are both on the bitcoin-security mailing list and have
been for years. Both of us have experience of responding to very serious
and tight-deadline security incidents, for example, the accidental bdb hard
fork and (in my case) when we discovered that Android phones had so little
entropy in them that different devices were actually generating the same
keys!

That one required co-ordinated crash rollouts of multiple wallets across
the Bitcoin ecosystem because there was a parallel investigation into key
collisions taking place in an open forum and they were not far from
discovering the truth about how badly the Android RNG was broken   (I knew
because at the time I had access to the Google internal Android bug
tracker). I organised the whole thing.

So I think we'll manage. But I don't expect things to exist in a state of
disjointness for very long. XT will rebase on top of Core and follow it's
releases for as long as there seems to be interest in bigger blocks and as
long as I have the time/energy/interest. If the >1mb chain wins then Core
will have to adopt the new ruleset or simply stop being relevant, as it
will have no users. That wouldn't make much sense.

Now, there have been concerns raised that a hard fork is unbelievably
risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I
don't believe it's anywhere near that risky. The patch Gavin is working on
requires both a miner majority *and* also has a date trigger in it. Much
like previous forks, in fact. So nobody should be taken by surprise if/when
bigger blocks appear, because it will have been known for a long time
beforehand that there was sufficiently strong consensus, there will have
been messages printed to the node logs, announcements in various places and
so on.

Does that help clear things up?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mike Hearn]

Hi Bryan,

Specifically, when Adam mentioned your conversations with non-technical
> people, he did not mean "Mike has talked with people who have possibly not
> made pull requests to Bitcoin Core, so therefore Mike is a non-programmer".
>

Yes, my comment was prickly and grumpy. No surprises, I did not sleep well
last night.

I am upset about this constant insistence from Adam, Gregory and others
that the "technical community" or "technical majority" agree with them and
anyone who doesn't is "non technical" or "not a contributor" or not an
expert or not had things properly explained to them.

This is not true and needs to stop. Gavin and I have both been working on
Bitcoin in substantial ways for longer than Gregory and Adam have been in
the community at all. We are extremely technical, as are many of the people
who want us to release XT+larger blocks. We cannot make progress in any
kind of negotiation if one side constantly blows off the other and refuses
to take anything they say seriously, which has been a feature of this
"debate" from the start.

In contrast Gavin and I have written vast amounts of analysis on the
concerns raised by larger blocks. So many hours were spent, we could
probably fill a small book by now. We have carefully read and addressed
*dozens* of points raised by the 1mb camp. We have also done our best to
open this debate to the whole community.

So it would be nice if the people who are so keen on 1mb blocks show the
same respect to us.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mike Hearn]

Hi Adam,

I replied publicly because your questions were sent to the mailing list.
I'd have been happy to reply in private if so asked.

I started to write up a much longer reply, but I'm tired - we've long since
been going in circles. I feel like I've written down answers to almost all
your questions before, including some in the email above.

Still, there are a few new ones. Let me work through them now.


Yes, I am on the bitcoin-security list. I have always been on it. I have
taken part in many threads there and started one or two myself. I guess
you're not though, otherwise you'd know that. You can ask, I'm sure Gavin
will add you if you like.


Re: BIP. Gavin is working on a BIP to go along with his patch. I hope that
will satisfy. I do not expect the resulting discussion to differ much from
the discussion so far, though.


Re: summit. No, I would not attend. I have been to several Bitcoin
conferences over the years where the block size issue was discussed. No
progress was ever made at these events.



Re: if some flaw or bug was found in the patch. Yes, of course if there was
some specific problem with the code then we would fix it. There will be
time to review Gavin's patches for these reasons.



Re: anyone who agrees with noted non-programmers Mike&Gavin must be
non-technical, stupid, uninformed, etc  OK, go ahead and show them the
error of their ways. Anyone can write blogs.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

[Mike Hearn]

>
> It's simple: either you care about validation, and you must validate
> everything, or you don't, and you don't validate anything.
>
Pedantically: you could validate a random subset of all scripts, to give
yourself probabilistic verification rather than full vs SPV. If enough
people do it with a large enough subset the probability of a problem being
detected goes up a lot. You still pay the cost of the database updates.

But your main point is of course completely right, that side chains are not
a way to scale up.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] comments on BIP 100

[Mike Hearn]

>
> The fact that using a centralized service is easier isn't a good reason
> IMHO. It disregards the long-term, and introduces systemic risk.
>

Well sure, that's easy for you to say, but you have a salary :) Other
developers may find the incremental benefits of decentralisation low vs
adding additional features, for instance, and who is to say they are wrong?


> But in cases where using a decentralized approach doesn't *add* anything,
> I cannot reasonably promote it, and that's why I was against getutxos in
> the P2P protocol.
>

It does add something though! It means, amongst other things, I can switch
of all my servers, walk away for good, discard this Mike Hearn pseudonym I
invented for Bitcoin and the app will still work :) Surely that is an
important part of being decentralised?

It also means that as the underlying protocol evolves over time, getutxos
can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
one more additional bit of security. If one day miners commit to UTXO sets,
great, one more additional bit of security. When we start including input
values in the signature hash, great ... one more step up in security.

Anyway, I didn't really want to reopen this debate. I just point out that
third party services are quite happy to provide whatever developers need to
build great apps, even if doing so fails to meet some kind of perfect
cryptographic ideal. And that's why they're winning devs.

Now back to your regularly scheduled block size debates ...
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] comments on BIP 100

[Mike Hearn]

>
> Since you keep bringing this up, I'll try to clarify this once again.
>

I understand the arguments against it. And I think you are agreeing with me
- Adam is bemoaning the way developers outsource stuff to third party
services, and suggesting it is relevant to the block size debate. And we
are saying, no, it's happening because it's easier than doing things in a
decentralised way.


> If you can't do that, and are just aiming for removing central points of
> failure, run a bunch of servers yourself, and let others run their own.
> That sounds remarkably close to what you actually did, actually...
>

Right. There's a deeper issue here. The sort of 'trustless' querying of the
UTXO set that was demanded from me is impossible even with commitments,
because the answer can change the moment you receive it. All it takes is a
new block or new transaction to be broadcast a split second after you
download and use the data, and suddenly what you did is incorrect no matter
how many proofs you verified!

The only way to know this has happened is to be a full node and download
all transactions yourself ... and even then, you are trusting your peers to
actually relay you all transactions and not a subset. So in the end you can
never achieve perfection, only get closer to it.

But that situation is *fine* for many use cases, like showing someone a
snapshot of their crowdfund in a user interface. We just accept that what
we see on the screen may lag behind reality. It happens all the time with
all kinds of non-Bitcoin apps. We accept that there may be cases where the
answer we get is wrong. The software can nevertheless still be useful.

So Lighthouse compromises. It queries multiple peers and cross-references
their answers. If their answers don't match it shows an error on the screen
and won't show the user any status for their crowdfund at all. This error
has never occurred. Maybe one day it will. So the app gets more
decentralisation, more robustness, and accepts that the user interface
might one day show a wrong answer if the P2P network starts lying (or your
internet connection is hacked, but the right fix for that is P2P
encryption).

Unfortunately this sort of balance-of-risks approach is considered a
non-starter in Bitcoin Core. So why would developers even try? The message
sent was clear:  even if you have an approach you think will work, don't
bother.

Much easier to just outsource to a trusted service indeed.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

[Mike Hearn]

Bear in mind the problem that stops Jeff's messages getting through is that
mailman 1.0 doesn't know how to handle DKIM properly. Switching to a
different mailman provider won't fix that.

Does mailman 3.0 even fix this? I found it difficult to tell from their
website. There's a big page on the mailman wiki that suggests they "fixed"
it by simply deleting the signatures entirely, which won't work. DMARC
policies state that mail *must* be signed and unsigned/incorrectly signed
message should be discarded.

The user documentation for mailman 3 doesn't seem to exist? The links on
the website are docs for 2.1, perhaps they released mailman 3 without
refreshing the docs.

Google Groups may be "controversial" but if I recall correctly the main
issue was the question of whether you needed a Google account or not. I'm
pretty sure you can just send an email to
groupname+subscr...@googlegroups.com even if you don't have a Google
account. But of course this is a bizarre standard to hold mailing list
software to: mailman asks users to create an account for each listserv in
order to manage a subscription too!
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mike Hearn]

Hi Adam,

Provisional answers below!

- Are you releasing a BIP for that proposal for review?
>

The work splits like this:

   - Gavin is writing the code and I think a BIP as well

   - I will review both and mostly delegate to Gavin's good taste around
   the details, unless there is some very strong disagreement. But that seems
   unlikely.

   - I have been handling gitian and the patch rebases, the code signing
   and so on, so far. I've also been doing some work to setup the basic
   infrastructure of the project (website etc).


- If the reviewers all say NACK will you take on board their suggestions?
>

Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
aren't scored in any way. The final decision rests with the maintainer as
in ~all open source projects.



> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs.  Can you explain your rationale
> for going ahead anyway?  The risks are well understood and enormous.
>

Yes, I have been working on an article that explains how we got to this
point from my perspective. It is quite long, but only because I want it to
be readable for people who weren't following the debate.

Anyway, I think I've laid out the gist of it over and over again, but to
summarise:

If Bitcoin runs out of capacity *it will break and many of our users will
leave*. That is not an acceptable outcome for myself or the many other
wallet, service and merchant developers who have worked for years to build
an ecosystem around this protocol.



> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
>

The approach is the same for other forks. Voting via block versions and
then when there's been >X% for Y time units the 1mb limit is
lifted/replaced.




> - If you're going it alone as it were, are you proposing that you will
> personally maintain bitcoin-XT?  Or do you have a plan to later hand
> over maintenance to the bitcoin developers?
>

Good question!  I have various thoughts on this, but let's wait and see
what happens first. Perhaps the new chain won't get the majority on it.

In the event that the >1mb chain does eventually win, I would expect Core
to apply the patch and rejoin the consensus rather than lose all its users.
That would take XT back to being a fairly small patchset to improve the
network protocol.



- Do you have contingency plans for what to do if the non-consensus
> hard-fork goes wrong and $3B is lost as a result?
>

Where did you get the $3B figure from? The fork either doesn't happen, or
it happens after quite a long period of people knowing it's going to happen
- for example because their full node is printing "You need to upgrade"
messages due to seeing the larger block version, or because they read the
news, or because they heard about it via some other mechanisms.

Let me flip the question around. Do you have a contingency plan if Bitcoin
runs out of capacity and significant user disruption occurs that results in
exodus, followed by fall in BTC price? The only one I've seen is "we can
perform an emergency hard fork in a few weeks"!



> As you can probably tell I think a unilateral fork without wide-scale
> consensus from the technical and business communities is a deeply
> inadvisable.


Gavin and I have been polling many key players in the ecosystem. The
consensus you seek does exist. All wallet developers (except Lawrence), all
the major exchanges, all the major payment processors and many of the major
mining pools want to see the limit lifted (I haven't been talking to pools,
Gavin has).

This notion that the change has no consensus is based on you polling the
people directly around you and people who like to spend all day on this
mailing list. It's not an accurate reflection of the wider Bitcoin
community and that is one of the leading reasons there is going to be a
fork. A small number of people have been flatly ignoring LOTS of highly
technical and passionate developers who have written vast amounts of code,
built up the Bitcoin user base, designed hardware and software, and yes
built companies.

How do you think that makes Bitcoin Core look to the rest of the Bitcoin
world? How much confidence does that give people?



Of the overall process, I think you can agree we should not be making
> technical decisions with this level of complexity and consensus risk
> with financial implications of this magnitude under duress of haste?
>

This debate will never end until a fork makes it irrelevant. There is no
process for ending it, despite me begging Wladimir to make one.

And there is no haste. We have been debating the block size limit for
*years*. We have known it must be lifted for *years*. I kicked off this
current round of debates after realising that Wladimir's release timeline
wouldn't allow a block size limit to be released before the e

Re: [Bitcoin-development] comments on BIP 100

[Mike Hearn]

>
> That was probably insufficiently specific, let me rephrase: I am
> referring to the trend that much of the industry is built on web2.0
> technology using bitcoin via a library in a web scripting language


OK, good to hear that. I'm not happy about the use of web technologies in
wallets/services either, but the causes of that trend are nothing to do
with block chain sizes. It's more because there's a generation of
developers who see no alternatives.

With projects like Lighthouse, I'm trying to show people that they can
blend the good bits of the web with the good bits of more traditional
client side development, at a cost they can afford.

Unfortunately, as you know, one of the reasons that developers turn to
outsourced services is that those services actually like developers and
give them the features they need. Whereas any attempt to add protocol
features for app/wallet developers to Bitcoin Core becomes controversial
due to some perceived or real lack of perfection.

I persevered for several months to add a very small "API" I needed for my
app to Bitcoin Core, and it was in the end a waste of time. There are no
actionable items left for the getutxo patch, regardless, I had to fork
Bitcoin to get it out there. It would have been *much* easier to just say,
fuck it, I'll use blockchain.info and in fact some in this community told
me to do exactly that. But, the approach I chose has been working fine for
months now.

Compare this experience to companies like chain.com, blockcypher etc - when
developers say jump, they say "how high?"

So It's unreasonable for the Bitcoin Core developer group to constantly
call developers building apps idiots or "non technical" (as I see so often
in this block size debate), and then complain that people don't write apps
in their preferred way! Just accept that decentralised app dev is already
hard, and the way Core is run makes it much harder still.


As I said I dont think we can expect Bitcoin to scale with no further
> algorithmic improvements.


A big part of the debate around this change is showing that this statement
is wrong. "Scaling" is not some kind of binary yes/no thing. It's a
continuous effort. You write a system that scales a certain amount, and
then if you find you need more capacity, you scale it again. Maybe that
 involves rewriting the existing code or maybe it just means improving what
you've got.

Or maybe (painful truth coming up) your product is not that compelling, or
times change and your users leave, and you discover you never actually need
to scale to the giddy heights originally envisioned.

A big part of the reason modern web dev is so messed up is that lots of
developers starting thinking every app they built needed to be "web scale"
from day one. SQL databases? Pah. Doesn't scale. Think big. We gotta no
NoSQL sharded key/value store from the start! Otherwise we're just showing
lack of confidence in our own product.

Then when they used up all their budget solving consistency bugs a
relational database would have avoided, they notice their competitors
sailing past them on a not-fully-scalable but certainly-scalable-enough
architecture that let them focus on features and making users happy.




> I am referring to global bandwidth O(n^2) with n=users


OK. O() notation normally refers to computational complexity, but ... I
still don't get it - the vast majority of users don't run relaying nodes
that take part in gossiping. They run web or SPV wallets. And the nodes
that do take part don't connect to every other node.




> There can be a case for some increase to create some breathing room to
> work on scaling and decentralising tech, I just mean to say that if we
> do it in isolation, we're not focussing on the big picture.


Alright - let's agree that we disagree on a few areas, like the relative
desirability of alternative non-blockchain designs - but we do seem to
agree that there is a case for an increase in the block size limit. That
seems like progress.

As you agree with that, what sort of schedule and time are you thinking of?
(well, by "you" I really mean blockstream because it's taking forever to
try and negotiate with every single person individually).
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] comments on BIP 100

[Mike Hearn]

> StrawPay hasn't published any details of their work publicly; if they
> wanted credit on the mailing list they should have done that.
>

There's a brief discussion here:


https://www.reddit.com/r/Bitcoin/comments/2r3ri7/strawpay_cheap_and_secure_micropayments/

But yes, they are developing it before publishing more details that may be
subject to change post-implementation experience anyway.


> I'm genuinely looking forward to a concrete fork proposal. Any ETA on
> when the blocksize increase code will go in Bitcoin XT?
>

Great!  I am waiting for Gavin to finish writing the patches. Once he has a
patch and there's been some time for review, I guess it will go in,
assuming no other issues.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] User vote in blocksize through fees

[Mike Hearn]

On Sun, Jun 14, 2015 at 4:42 PM, Jeff Garzik  wrote:

> Since you missed it, here is the suggestion again:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>

Reposting as Jeff's mail got eaten by the anti-phishing filters, due to
SourceForge's obsolete mailman setup.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] comments on BIP 100

[Mike Hearn]

>
> One thing that is concerning is that few in industry seem inclined to
> take any development initiatives or even integrate a library.


Um, you mean except all the people who have built more scalable wallets
over the past few years, which is the only reason anyone can even use
Bitcoin from their phone? Or maybe you mean initiatives like Lightning 
except StrawPay already developed something similar to the Lightning
network (complete with a working GUI wallet) and were ignored by
Blockstream as you prefer to write your own from scratch?

Sure, people in the industry take development initiatives. That doesn't
mean their work will be recognised on this mailing list.


> I suppose eventually that problem would self-correct as new startups would
> make a more scalable wallet and services that are layer2 aware and eat the
> lunch of the laggards.


"The laggards" being *everyone* who has already invested in building
Bitcoin software so far. Not a great way to frame things. Many of those
"laggards" have written orders of magnitude more code than you or Gregory
or Jeff, for instance.

I still think you guys don't recognise what you are actually asking for
here - scrapping virtually the entire existing investment in software,
wallets and tools.


> But it will be helpful if we expose companies to the back-pressure
> actually implied by an O(n^2) scaling protocol and don't just immediately
> increase the block-size to levels that are dangerous for decentralisation
> security


Bitcoin does not have n-squared scaling. I really don't get where this idea
comes from. Computational complexity for the entire network is O(nm) where
n=transactions and m=fully validating nodes. There is no fixed
relationships between those two variables.

"Exposing the companies to back-pressure" sounds quite nice and gentle. Let
me rephrase it to be equivalent but perhaps more direct: you mean "breaking
the current software ecosystem to force people into a new, fictional system
that bears little resemblance to the Bitcoin we use today, whether they
want that or not".

As nothing that has been proposed so far (Lightning, merge mined chains,
extension blocks etc) has much chance of actual deployment any time soon,
that leaves raising the block size limit as the only possible path left.
Which is why there will soon be a fork that does it.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

[Mike Hearn]

Sure, and you did indeed say that.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

[Mike Hearn]

>
> are only connected to each other through a slow 2 Mbit/s link.
>

That's very slow indeed. For comparison, plain old 3G connections routinely
cruise around 7-8 Mbit/sec.

So this simulation is assuming a speed dramatically worse than a mobile
phone can get!
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

[Mike Hearn]

>
> > Re: "dropped in an unpredictable way" - transactions would be dropped
> > lowest fee/KB first, a completely predictable way.
>
> Quite agreed.


No, Aaron is correct. It's unpredictable from the perspective of the user
sending the transaction, and as they are the ones picking the fees, that is
what matters.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

[Mike Hearn]

>
> If we assume that transactions are being dropped in an unpredictable way
> when blocks are full, knowing the network congestion *right now* is
> critical, and even then you just have to hope that someone who wants that
> space more than you do doesn't show up after you disconnect.
>

Yeah, my proposal is not intended to function correctly with full blocks,
as Bitcoin cannot work at all in such a state. It assumes that fees only
change slowly and that transactions are being cleared normally.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

[Mike Hearn]

I described an alternative way for SPV wallets to learn about fees some
time ago. It requires a new transaction version that embeds output values
into the signed data. Then an upgrade to the P2P protocol to send UTXO data
along with transactions when they are relayed.

The idea is that the wallet sets a Bloom filter with an FP rate that
ensures it will see some random subset of all transactions being broadcast
on the network, and with the extra data, it can calculate the fee paid.
Once a transaction broadcast is observed the wallet includes that tx hash
in its next Bloom filter, thus it can see which block the tx confirmed in.
By measuring the amount of time that passed between a broadcast and it
appearing in a block, it can calculate its own tables of fee paid:time
taken.

This has the advantage that you don't have to trust miners to publish data
accurately. However it requires some protocol upgrades and of course, a lot
of new code in SPV wallets.

The way Bitcoin Wallet for Android handles fees currently is to just update
a hard coded value every so often.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] DevCore London

[Mike Hearn]

Hi there,

I got some requests to re-record the tutorial talk I gave at DevCore 2015,
"How to build a timestamping smart contracts app in 30 minutes". It's now
available here:

https://bitcoinj.github.io/document-timestamp-app

It covers:

   - How to customise the wallet-template app for this use case
   - How to construct a complex multi-stage SPV proof of block chain
   inclusion
   - How to save and then verify proof files
   - How to bind transaction confidence state to the user interface
   - How to create a Mac DMG bundle with a custom icon

I hope someone finds it enjoyable!



On Thu, Apr 9, 2015 at 10:23 PM, Mike Hearn  wrote:

> Next week on April 15th Gavin, Wladimir, Corey and myself will be at
> DevCore London:
>
>https://everyeventgives.com/event/devcore-london
>
> If you're in town why not come along?
>
> It's often the case that conferences can be just talking shops, without
> much meat for real developers. So in the afternoon I'll be doing two things:
>
>1. Running a hackathon/workshop type event. The theme is contracts,
>but we can hack on whatever you all feel like.
>
>2. My "talk" will actually be a live coding event. Writing contracts
>apps has become a lot easier in the past few years, and to prove it to you
>I will write a decentralised cross-platform Tor supporting document
>timestamping app that uses OP_RETURN outputs and has a nice GUI . in 30
>minutes, on stage.
>
>Don't think it can be done? Turn up and see for yourself.
>
> See you there!
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements‏

[Mike Hearn]

>
> But the majority of the hashrate can now perform double spends on your
> chain! They can send bitcoins to exchanges, sell it, extract the money and
> build a new longer chain to get their bitcoins back.
>
Obviously if the majority of the mining hash rate is doing double spending
attacks on exchanges then the Bitcoin experiment is resolved as a failure
and it will become abandoned. This has been known since day one: it's in
the white paper. The basic assumption behind Bitcoin is that only a
minority of actors are dishonest - if the majority are then Satoshi's
scheme does not work.

So you are not stating anything new here.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

[Mike Hearn]

>
>  1,000 *people* in control vs. 10 is two orders of

magnitude more decentralized.


Yet Bitcoin has got worse by all these metrics: there was a time before
mining pools when there were ~thousands of people mining with their local
CPUs and GPUs. Now the number of full nodes that matter for block selection
number in the dozens, and all the other miners just follow their blocks
blindly.

If you really believe that decentralisation is, itself, the end, then why
not go use an "ASIC resistant" alt coin with no SPV or web wallets which
resembles Bitcoin at the end of 2009? That'd be a whole lot more
decentralised than what you have now.

The *percentage* of the community that mines is totally irrelevant, it's
> the absolute number of (independent) people that matters.
>

So usage does matter, then? You'd rather have a coin that has power
concentrated in a far smaller elite, proportionally, but has overall more
usage? If there are say, 5000 full nodes today, and in ten years there are
6000, and they all run in vast datacenters and are owned by large
companies, you'll feel like Bitcoin is more decentralised than ever?
(n.b. I do not think this situation will ever happen, it's just an example).

That's not the vibe I'm getting from most people on this list. What I'm
seeing is complaints about how in the good old days back when Core was the
only wallet and ASICs hadn't been made,  there were lots of nodes and lots
of people mining solo and since then it's all been downhill and woe is us
... and let's throw on the brakes in case it gets worse.

Not for the first time, these discussions remind me very strongly of the
old desktop Linux/free software debates.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

I don't see this as an issue of sensitivity or not. Miners are businesses
that sell a service to Bitcoin users - the service of ordering transactions
chronologically. They aren't charities.

If some miners can't provide the service Bitcoin users need any more, then
OK, they should not/cannot mine. Lots of miners have come and gone since
Bitcoin started as different technology generations came and went. That's
just business.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Mike Hearn]

>
> (at reduced security if it has software that doesnt understand it)


Well, yes. Isn't that rather key to the issue?  Whereas by simply
increasing the block size, SPV wallets don't care (same security and
protocol as before) and fully validating wallets can be updated with a very
small code change.


> A 1MB client wont even understand the difference between a 1MB and 8MB
> out payment.


Let's say an old client makes a payment that only gets confirmed in an
extension block. The wallet will think the payment is unconfirmed and show
that to the user forever, no?

Can you walk through the UX for each case?


> If I am not misremembering, I think you've sided typically
> with the huge block, big data center only end of the spectrum.


It would be Satoshi, that argued that.

I think there must be a communication issue here somewhere. I'm not sure
how this meme has taken hold amongst you guys, as I am the guy who wrote
the scalability page back in 2011:

https://en.bitcoin.it/wiki/Scalability

It says:

*The core Bitcoin network can scale to much higher transaction rates than
are seen today, assuming that nodes in the network are primarily running on
high end servers rather than desktops. *


By "much higher rates" I meant VISA scale and by "high end server" I meant
high end by today's standards not tomorrows. There's a big difference
between a datacenter and a single server! By definition a single server is
not a datacenter, although it would be conventional to place it in
one. But even
with the most wildly optimistic growth imaginable, I couldn't foresee a
time when you needed more than a single machine to keep up with the
transaction stream.

And we're not going to get to VISA scale any time soon: I don't think I've
ever argued we will. If it does happen it would presumably be decades away.
Again, short of some currently unimagined killer app.

So I don't believe I've ever argued this, and honestly I kinda feel people
are putting words in my mouth.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

[Mike Hearn]

Hi Adam,

I have more experience than Gavin of building consumer wallets, so I'll
make an attempt to answer your questions.

> Then ask the various wallet developer how long it would take them to
> update
> > their software to support something like this,
>
> I don't think thats any particular concern


I am a wallet developer and I am telling you that it is.


> Businesses who are keen to
> have more transactions, would make it their problem to implement in
> their wallet, or ask the wallet vendor/maintainer they're working with
> to do it.  Nothing breaks if they dont use it.


I don't see how this is the case. If an exchange supports extension blocks
and I withdraw from that to a wallet that doesn't, the money will never
arrive from my perspective. Yet the exchange will claim they sent it and
they will wash their hands of the matter. Disaster.

I am not a UX guy
>

But I am. I've designed both consumer and engineering UI's at Google, and
also more recently for Lighthouse.

Attempting to explain to a user why they sent money that didn't show up on
the other end is a non starter. It's bad enough when things take a long
time to confirm or bugs cause propagation failures. Doing it
deliberately is not going to work. Payments *must* be reliable and wallets
*must* be compatible with each other.

This is one reason why a Lightning style approach also isn't going to work
any time soon. For example, it would require people to abandon Bitcoin
addresses. I pushed for that before, around the P2SH time, and Gavin
correctly intuited that the community wasn't ready for it yet. I'm not sure
much has changed.


> Because the more complex one is safer, more flexible, more future
> proof and better for decentralisation


I disagree with all of those points. I find Lightning/Stroem etc to be more
dangerous, less flexible, and worse for decentralisation. I explain why
here:

https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e

You mentioned decentralisation metrics. Gregory's post is ignoring one of
the most important decentralisation metrics, which is number of wallets
made by independent developers. That has got dramatically better over time.
It would get worse if wallets became more complex very suddenly.


> As an aside, a risk with using companies as a sounding board, is that
> you can get a misleading sense of consensus.


>From what I can tell Blockstream employees are just ignoring those
companies entirely, which will give you a radically more distorted view of
the consensus. As companies providing services to our community have
serious economic weight, it stands to reason that their opinions would
matter a great deal. Yet on this mailing list I see zero effort to even
recognise their concerns, let alone care about them.
  
Anyway, let me repeat again to make it clear - as someone who has spent
five years writing SPV wallets, I am not on board with extension blocks or
any other Rube Goldberg contraption that exists purely to work around
theoretical objections by Blockstream employees+Peter Todd, which is what
this feels like to me.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

[Mike Hearn]

>
> It's surprising to see a core dev going to the public to defend a proposal
> most other core devs disagree on, and then lobbying the Bitcoin ecosystem.
>

I agree that it is a waste of time. Many agree. The Bitcoin ecosystem
doesn't really need lobbying - my experience from talking to businesses and
wallet developers months ago is they virtually all see raising capacity as
a no brainer ... and some of them see this "debate" as despair-inducing
insanity.

What's happened here is that a small number of people have come to believe
they have veto power over changes to Bitcoin, and they have also become
*wildly* out of step with what the wider community wants. That cannot last.
So, short of some sudden change of heart that lets us kick the can down the
road a bit longer, a fork is inevitable.

Just be glad it's Gavin driving this and not me ... or a faceless coalition
of startups.


> Decentralization is the core of Bitcoin's security model and thus that's
> what gives Bitcoin its value.
>

No. Usage is what gives Bitcoin value.

It's kind of maddening that I have to point this out. Decentralisation is a
means to an end. I first used Bitcoin in April 2009 and it was perfectly
decentralised back then: every wallet was a full node and every computer
was capable of mining.

So if you believe what you just wrote, I guess Bitcoin's value has gone
down every day since.

On the other hand, if you believe the markets, Bitcoin's value has gone up.

Apparently the question of what gives Bitcoin its value is a bit more
complicated than that.




> : to incentive layer 2 and offchain solutions to scale Bitcoin : there are
> promising designs/solutions out there (LN, ChainDB, OtherCoin protocole,
> ...), but most don't get much attention, because there is right now no need
> for them. And, I am sure new solutions will be invented.
>

I have seen this notion a few times. I would like to dispose of it right
now.

I am one of the wallet developers you would be trying to "incentivise" by
letting Bitcoin break, and I say: get real. Developers are not some
bottomless fountain of work that will spit out whatever you like for free
if you twist their arms badly enough.

The problems that incentivised the creation of Bitcoin existed for decades
before Bitcoin was actually invented. Incentives are not enough. Someone
has to actually do the work, too. All proposals on the table would:

   - Involve enormous amounts of effort from many different people
   - Be technically risky (read: we don't know if they would even work)
   - Not be Bitcoin

The last point is important: people who got interested in Bitcoin and
decided to devote their time to it might not feel the same way about some
network of payment hubs or whatever today's fashion is. Faced with their
work being broken by armchair developers on some mailing list, they might
just say screw it and walk away completely.

After all, as the arguments for these systems are not particularly logical,
they might slave over hot keyboards for a year to support the Lightning
Network or whatever and then discover that it's no longer the fashionable
thing ... and that suddenly an even more convoluted design is being
"incentivised".
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

I'm OK with a smaller size + a formula that ramps it up over time. We are
far from having enough demand to fill 10MB blocks, let alone 20MB today.

To put it in perspective, to be feeling squeezed inside 10MB within two
years, we would need to double usage five times. I wish I knew a way to
make that happen. So the chances of us going to 20MB blocks full of real
transactions any time soon is close to zero short of some amazing killer
app that takes the world by storm (in which case: yay, nice problem to
have). As long as capacity significantly outpaces organic growth, we should
avoid problems.

The reason to pick 20MB then is merely one of expedience: we have to pick a
number, 20 is tested and seems to work, and we don't want to get caught by
surprise if demand does outstrip expectations.

Still, I question the underlying logic. We have no idea what connectivity
into China will look like a few years from now: it's seems to be a function
of politics rather than hardware trends. It might go down rather than up.
So 10 vs 20 feels a bit arbitrary. We can't let the Chinese government
dictate how Bitcoin is used, that would never be accepted by the rest of
the world. But if we optimistically assume things don't get worse, and 10
== more acceptance, then alright - it should make no difference in practice.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn.


Then please enlighten me. You're unable to download block templates from a
trusted node outside of the country because the bandwidth requirements are
too high? Or due to some other problem?

With respect to "now it's your turn". Let's imagine the hard fork goes
ahead. Let us assume that almost all exchanges, payment processors and
other businesses go with larger blocks, but Chinese miners do not.

Then you will mine coins that will not be recognised on trading platforms
and cannot be sold. Your losses will be much larger than from orphans.

This can happen *even* if Chinese miners who can't/won't scale up are >50%
hashrate. SPV clients would need a forced checkpoint, which would be messy
and undesirable, but it's technically feasible. The smaller side of the
chain would cease to exist from the perspective of people actually trading
coins.

If your internet connectivity situation is really so poor that you cannot
handle one or two megabits out of the country then you're hanging on by
your fingernails anyway: your connection to the main internet could become
completely unusable at any time. If that's really the case, it seems to me
that Chinese Bitcoin is unsustainable and what you really need is a
China-specific alt coin that can run entirely within the Chinese internet.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Mike Hearn]

Whilst it would be nice if miners in China can carry on forever regardless
of their internet situation, nobody has any inherent "right" to mine if
they can't do the job - if miners in China can't get the trivial amounts of
bandwidth required through their firewall and end up being outcompeted then
OK, too bad, we'll have to carry on without them.

But I'm not sure why it should be a big deal. They can always run a node on
a server in Taiwan and connect the hardware to it via a VPN or so.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Mike Hearn]

>
> And looking at the version (aka user-agent) strings of publicly reachable
> nodes on the network.
> (e.g. see the count at  https://getaddr.bitnodes.io/nodes/ )
>

Yeah, though FYI Luke informed me last week that I somehow managed to take
out the change to the user-agent string in Bitcoin XT, presumably I made a
mistake during a rebase of the rebranding change. So the actual number of
XT nodes is a bit higher than counting user-agent strings would suggest.

I sort of neglected XT lately. If we go ahead with this then I'll fix
things like this.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Mike Hearn]

>
> The measure is miner consensus.  How do you intend to measure
> exchange/merchant acceptance?
>

Asking them.

In fact, we already have. I have been talking to well known people and CEOs
in the Bitcoin community for some time now. *All* of them support bigger
blocks, this includes:

   - Every wallet developer I have asked (other than Bitcoin Core)
   - So far, every payment processor and every exchange company

I know Gavin has also been talking to people about this.

There's a feeling on this list that there's no consensus, or that Gavin and
myself are on the wrong side of it. I'd put it differently - there's very
strong consensus out in the wider community and this list is something of
an aberration.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Mike Hearn]

>
> If the plan is a fix once and for all, then that should be changed too.
> It could be set so that it is at least some multiple of the max block size
> allowed.
>

Well, but RAM is not infinite :-) Effectively what these caps are doing is
setting the minimum hardware requirements for running a Bitcoin node.

That's OK by me - I don't think we are actually going to exhaust the
hardware abilities of any reasonable computer any time soon, but still,
having the software recognise the finite nature of a computing machine
doesn't seem unwise.


> That system can send a block of any size.  It would require a change to
> the processing of any merkleblocks received.
>

Not "any" size because, again, the remote node must buffer things up and
have the transaction data actually in memory in order to digest it. But a
much larger size, yes.

However, that's a bigger change.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Mike Hearn]

>
> By the time a hard fork can happen, I expect average block size will be
> above 500K.
>

Yes, possibly.


> Would you support a rule that was "larger of 1MB or 2x average size" ?
> That is strictly better than the situation we're in today.
>

It is, but only by a trivial amount - hitting the limit is still very
likely. I don't want to see this issue come up over and over again. Ideally
never. We shouldn't be artificially throttling organic growth of the
network, especially not by accident.

IMO it's not even clear there needs to be a size limit at all. Currently
the 32mb message cap imposes one anyway, but if miners can always just
discourage blocks over some particular size if they want to.

But I can get behind a 20mb limit (or 20mb+N) as it represents a reasonable
compromise: the limit still exists, it's far below VISA capacity etc, but
it should also free up enough space that everyone can get back to what we
*should* be focusing on, which is user growth!
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Mike Hearn]

>
> Twenty is scary.
>

To whom? The only justification for the max size is DoS attacks, right?
Back when Bitcoin had an average block size of 10kb, the max block size was
100x the average. Things worked fine, nobody was scared.

The max block size is really a limit set by hardware capability, which is
something that's difficult to measure in software. I think I preferred your
original formula that guesstimated based on previous trends to one that
just tries to follow some average.

As noted, many miners just accept the defaults. With your proposed change
their target would effectively *drop* from 1mb to 800kb today, which seems
crazy. That's the exact opposite of what is needed right now.

I am very skeptical about this idea.


> I don't think us developers should be deciding things like whether or not
> fees are too high, too low,
>

Miners can already attempt to apply fee pressure by just not mining
transactions that they feel don't pay enough. Some sort of auto-cartel that
attempts to restrict supply based on everyone looking at everyone else
feels overly complex and prone to strange situations: it looks a lot like
some kind of Mexican standoff to me.

Additionally, the justification for the block size limit was DoS by someone
mining "troll blocks". It was never meant to be about fee pressure.
Resource management inside Bitcoin Core is certainly something to be
handled by developers.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Mike Hearn]

>
> Even a 2x rule (implying 800K max blocks) would, today, be squeezing out
> transactions / putting pressure to increase fees .
>
> So my straw-man proposal would be:  max size 2x average size over last 144
> blocks, calculated at every block.
>

Isn't that a step backwards, then? I see no reason for fee pressure to
exist at the moment. All it's doing is turning away users for no purpose:
mining isn't supported by fees, and the tiny fees we use right now seem to
be good enough to stop penny flooding.

Why not set the max size to be 20x the average size? Why 2x, given you just
pointed out that'd result in blocks shrinking rather than growing.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Long-term mining incentives

[Mike Hearn]

>
> The prior (and seemingly this) assurance contract proposals pay the
> miners who mines a chain supportive of your interests and miners whom
> mine against your interests identically.
>

The same is true today - via inflation I pay for blocks regardless of
whether they contain or double spend my transactions or not. So I don't see
why it'd be different in future.


> There is already a mechanism built into Bitcoin for paying for
> security which doesn't have this problem, and which mitigates the
> common action problem of people just sitting around for other people
> to pay for security: transaction fees.


The article states quite clearly that assurance contracts are proposed only
if people setting transaction fees themselves doesn't work. There's some
reasonably good arguments that it probably won't work, but I don't assign
very high weight to game theoretic arguments these days so it wouldn't
surprise me if Satoshi's original plan worked out OK too.

Of course, by the time this matters I plan to be sipping a pina colada on
my private retirement beach :) It's a problem the next generation can
tackle, as far as I am concerned.


> Considering the near-failure in just keeping development funded, I'm not
> sure where the believe this this model will be workable comes from


Patience :)

Right now it's a lot easier to get development money from VC funds and rich
benefactors than raising it directly from the community, so unsurprisingly
that's what most people do.

Despite that, the Hourglass design document project now has sufficient
pre-pledges that it should be possible to crowdfund it successfully once I
get around to actually doing the work. And BitSquare was able to raise
nearly half of their target despite an incredibly aggressive deadline and
the fact that they hadn't shipped a usable prototype. I think as people get
better at crafting their contracts and people get more experience with
funding work this way, we'll see it get more common.

But yes. Paying for things via assurance contracts is a long term and very
experimental plan, for sure.


> one time cost. I note that many existing crowdfunding platforms
> (including your own) do not do ongoing costs with this kind of binary
> contract.
>

Lighthouse wasn't written to do hashing assurance contracts, so no, it
doesn't have such a feature. Perhaps in version 2.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mike Hearn]

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

Re: [Bitcoin-development] Long-term mining incentives

[Mike Hearn]

I wrote an article that explains the hashing assurance contract concept:

https://medium.com/@octskyward/hashing-7d04a887acc8

(it doesn't contain an in depth protocol description)
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mike Hearn]

>
> Mike, this proposal was purposefully constructed to maintain as well as
> possible the semantics of Satoshi's original construction. Higher sequence
> numbers -- chronologically later transactions -- are able to hit the chain
> earlier, and therefore it can be reasonably argued will be selected by
> miners before the later transactions mature. Did I fail in some way to
> capture that original intent?
>

Right, but the original protocol allowed for e.g. millions of revisions of
the transaction, hence for high frequency trading (that's actually how
Satoshi originally explained it to me - as a way to do HFT - back then the
channel concept didn't exist).

As you point out, with a careful construction of channels you should only
need to bump the sequence number when the channel reverses direction. If
your app only needs to do that rarely, it's a fine approach.And your
proposal does sounds better than sequence numbers being useless like at the
moment. I'm just wondering if we can get back to the original somehow or at
least leave a path open to it, as it seems to be a superset of all other
proposals, features-wise.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mike Hearn]

>
> Sequence numbers appear to have been originally intended as a mechanism
> for transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel.
>

Yes indeed they were. Satoshis mechanism was more general than micropayment
channels and could do HFT between any set of parties.


> As it happens, this cannot be made safe in the bitcoin protocol as
> deployed today, as there is no enforcement of the rule that miners include
> the most recent transaction in their blocks.
>

Safe is relative - this is the same logic the original replace-by-fee
argument uses. There's no enforcement that miners use any particular
ordering of transactions.

As I believe out of all proposed protocols Satoshi's is still the most
powerful, I would suggest that any change to the semantics on nSequence be
gated by a high bit or something, so the original meaning remains available
if/when resource scheduling and update flood damping are implemented. That
way people can try it out and if miners are breaking things too frequently
by ignoring the chronological ordering people can abandon protocols that
rely on it, and if they aren't they can proceed and benefit from the
greater flexibility.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

Very interesting Matt.

For what it's worth, in future bitcoinj is very likely to bootstrap from
Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily
working towards Tor by default. So this approach will probably stop working
at some point. As breaking PorcFest would kind of suck, we might want a
ZeroConf/Rendezvous solution in place so local LANs can capture Bitcoin
traffic away from Tor (with some notification to the user, presumably).



On Tue, May 26, 2015 at 7:47 AM, Matt Whitlock 
wrote:

> On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote:
> > On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
> > > On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
> > > > Do any wallets actually do this yet?
> > >
> > > Not that I know of, but they do seed their address database via DNS,
> which you can poison if you control the LAN's DNS resolver. I did this for
> a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well
> over a hundred lightweight wallets, all trying to connect to the Bitcoin
> P2P network over a very bandwidth-constrained Internet link, so I poisoned
> the DNS and rejected all outbound connection attempts on port 8333, to
> force all the wallets to connect to a single local full node, which had
> connectivity to a single remote node over the Internet. Thus, all the
> lightweight wallets at the festival had Bitcoin network connectivity, but
> we only needed to backhaul the Bitcoin network's transaction traffic once.
> >
> > Interesting!
> >
> > What festival was this?
>
> The Porcupine Freedom Festival ("PorcFest") in New Hampshire last summer.
> I strongly suspect that it's the largest gathering of Bitcoin users at any
> event that is not specifically Bitcoin-themed. There's a lot of overlap
> between the Bitcoin and liberty communities. PorcFest draws somewhere
> around 1000-2000 attendees, a solid quarter of whom have Bitcoin wallets on
> their mobile devices.
>
> The backhaul was a 3G cellular Internet connection, and the local Bitcoin
> node and network router were hosted on a Raspberry Pi with some Netfilter
> tricks to restrict connectivity. The net result was that all Bitcoin nodes
> (lightweight and heavyweight) on the local Wi-Fi network were unable to
> connect to any Bitcoin nodes except for the local node, which they
> discovered via DNS. I also had provisions in place to allow outbound
> connectivity to the API servers for Mycelium, Blockchain, and Coinbase
> wallets, by feeding the DNS resolver's results in real-time into a
> whitelisting Netfilter rule utilizing IP Sets.
>
> For your amusement, here's the graphic for the banner that I had made to
> advertise the network at the festival (*chuckle*):
> http://www.mattwhitlock.com/bitcoin_wifi.png
>
>
> --
> 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
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

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

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

[Mike Hearn]

>
> If it matters, I configure the app to connect only to my own trusted
> Bitcoin node, so I only ever have one active connection at most.


Ah, I see, non default configuration. Because the Bitcoin network can and
does change in backwards incompatible ways, the app wants to see that the
transaction it made actually propagated across the network. If you set a
trusted node it won't see that.

Probably the logic should be tweaked so if you set a trusted node you're
just assumed to know what you're doing and we assume the transactions we
make ourselves always work.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

Wallets are incentivised to do a better job with defragmentation already,
as if you have lots of tiny UTXOs then your fees end up being huge when
trying to make a payment.

The reason they largely don't is just one of manpower. Nobody is working on
it.

As a wallet developer myself, one way I'd like to see this issue be fixed
by making free transactions more reliable. Then wallets can submit free
transactions to the network to consolidate UTXOs together, e.g. at night
when the user is sleeping. They would then fit into whatever space is
available in the block during periods of low demand, like on Sunday.

If we don't do this then wallets won't automatically defragment, as we'd be
unable to explain to the user why their money is slowly leaking out of
their wallet without them doing anything. Trying to explain the existing
transaction fees is hard enough already ("I thought bitcoin doesn't have
banks" etc).

There is another way:  as the fee is based on a rounded 1kb calculation, if
you go into the next fee band adding some more outputs and making a bigger
change output becomes "free" for another output or two. But wallets don't
exploit this today.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
> can only spend confirmed UTXOs. I can't tell you how aggravating it is to
> have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for
> the last transaction I did to confirm first." All the more aggravating
> because I know, if I have multiple UTXOs in my wallet, I can make multiple
> spends within the same block.
>

Andreas' wallet hasn't done that for years. Are you repeating this from
some very old memory or do you actually see this issue in reality?

The only time you're forced to wait for confirmations is when you have an
unconfirmed inbound transaction, and thus the sender is unknown.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] No Bitcoin For You

[Mike Hearn]

>
> If capacity grows, fewer individuals would be able to run full nodes.
>

Hardly. Nobody is currently exhausting the CPU capacity of even a normal
computer currently and even if we did a 20x increase in load overnight,
that still wouldn't even warm up most machines good enough to be always on.

The reasons full nodes are unpopular to run seem to be:

1. Uncontrollable bandwidth usage from sending people the chain
2. People don't run them all the time, then don't want to wait for them to
catch up

The first can be fixed with better code (you can already easily opt out of
uploading the chain, it's just not as fine-grained as desirable), and the
second is fundamental to what full nodes do and how people work. For
merchants, who are the most important demographic we want to be using full
nodes, they can just keep it running all the time. No biggie.


> Therefore miners and other full nodes would depend on
> it, which is rather critical as those nodes grow closer to data-center
> proportions.
>

This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
right now, but I showed years ago that you could keep up with VISA on a
single well specced server with today's technology. Only people living in a
dreamworld think that Bitcoin might actually have to match that level of
transaction demand with today's hardware. As noted previously, "too many
users" is simply not a problem Bitcoin has  and may never have!
--
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] Long-term mining incentives

[Mike Hearn]

Hi Thomas,

My problem is that this seems to lacks a vision.
>

Are you aware of my proposal for network assurance contracts?

There is a discussion here:


https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07552.html

But I agree with Gavin that attempting to plan for 20 years from now is
ambitious at best. Bitcoin might not even exist 20 years from now, or might
be an abandoned backwater a la USENET.
--
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] Scaling Bitcoin with Subchains

[Mike Hearn]

Hi Andrew,

Your belief that Bitcoin has to be constrained by the belief that hardware
will never improve is extremist, but regardless, your concerns are easy to
assuage: there is no requirement that the block chain be stored on hard
disks. As you note yourself the block chain is used for building/auditing
the ledger. Random access to it is not required, if all you care about is
running a full node.

Luckily this makes it a great fit for tape backup. Technology that can
store 185 terabytes *per cartridge* has already been developed:

http://www.itworld.com/article/2693369/sony-develops-tape-tech-that-could-lead-to-185-tb-cartridges.html

As you could certainly share costs of a block chain archive with other
people, the cost would not be a major concern even today. And it's
virtually guaranteed that humanity will not hit a storage technology wall
in 2015.

If your computer is compromised then all bets are off. Validating the chain
on a compromised host is meaningless.
--
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] Virtual Notary.

[Mike Hearn]

Very nice Emin! This could be very useful as a building block for oracle
based services. If only there were opcodes for working with X.509 ;)

I'd suggest at least documenting in the FAQ how to extract the data from
the certificate:

openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes -passin
pass:"" | openssl x509 -text|less

That's good enough to get started, but I note two issues:


   1. X.509 is kind of annoying to work with: example code in popular
   languages/frameworks to extract the statement would be useful.

   2. The stock price plugin, at least, embeds the data as text inside the
   X.509 certificate. That's also not terribly developer friendly and risks
   parsing errors undermining security schemes built on it.

   The way I'd solve this is to embed either a protocol buffer or DER
   encoded structure inside the extension, so developers can extract the
   notarised data directly, without needing to do any additional parsing.
--
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] Proposed alternatives to the 20MB step function

[Mike Hearn]

There are certainly arguments to be made for and against all of these
proposals.

The fixed 20mb cap isn't actually my proposal at all, it is from Gavin. I
am supporting it because anything is better than nothing. Gavin originally
proposed the block size be a function of time. That got dropped, I suppose
to make the process of getting consensus easier. It is "the simplest thing
that can possibly work".

I would like to see the process of chain forking becoming less traumatic. I
remember Gavin, Jeff and I once considered (on stage at a conference??)
that maybe there should be a scheduled fork every year, so people know when
to expect them.

If everything goes well, I see no reason why 20mb would be the limit
forever.
--
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 Requirements

[Mike Hearn]

>
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.


With a 20mb cap, miners still have the option of the soft limit.

I would actually be quite surprised if there were no point along the road
from 1mb to 20mb where miners felt a need to throttle their block sizes
artificially, for the exact reason you point out: propagation delays.

But we don't *need* to have fancy protocol upgrades implemented right now.
All we need is to demolish one bottleneck (the hard cap) so we can then
move on and demolish the next one (whatever that is, probably faster
propagation). Scaling is a series of walls we punch through as we encounter
them. One down, onto the next. We don't have to tackle them all
simultaneously.

FWIW I don't think the GFW just triggers packet loss, these days. It's
blocked port 8333 entirely.

 * I'd very much like to see someone working on better scaling
> technology ... I know StrawPay is working on development,
>

So this request is already satisfied, isn't it? As you point out, expecting
more at this stage in development is unreasonable, there's nothing for
anyone to experiment with or commit to.

They have code here, by the way:

   https://github.com/strawpay

You can find their fork of MultiBit HD, their implementation library, etc.
They've contributed patches and improvements to the payment channels code
we wrote.


>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
>

What are your thoughts on using assurance contracts to fund network
security?

I don't *know* if hashing assurance contracts (HACs) will work. But I don't
know they won't work either. And right now I'm pretty sure that plain old
fee pressure won't work. Demand doesn't outstrip supply forever - people
find substitutes.
--
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] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

[Mike Hearn]

Looks like a neat solution, Tier.
--
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

[Mike Hearn]

>
> Alan argues that 7 tps is a couple orders of magnitude too low


By the way, just to clear this up - the real limit at the moment is more
like 3 tps, not 7.

The 7 transactions/second figure comes from calculations I did years ago,
in 2011. I did them a few months before the "sendmany" command was
released, so back then almost all transactions were small. After sendmany
and as people developed custom wallets, etc, the average transaction size
went up.
--
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

[Mike Hearn]

> These statements may even be true, but they're no logical conclusions
> even if they seem obvious to you.
> I don't think those claims are strictly true, specially because they
> involve predictions about what people will do.
> But if they're true they require some proof or at least some explanation.
>

Thank you for your patience, Jorge.

I have written up an explanation of what I think will happen if we run out
of capacity:

   https://medium.com/@octskyward/crash-landing-f5cc19908e32

Now I'm going to go eat some dinner :)
--
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

[Mike Hearn]

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

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.

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.


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


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

[Mike Hearn]

>
> I think you are rubbing against your own presupposition that people must
> find and alternative right now. Quite a lot here do not believe there is
> any urgency, nor that there is an immanent problem that has to be solved
> before the sky falls in.
>

I have explained why I believe there is some urgency, whereby "some
urgency" I mean, assuming it takes months to implement, merge, test,
release and for people to upgrade.

But if it makes you happy, imagine that this discussion happens all over
again next year and I ask the same question.
--
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

[Mike Hearn]

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

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?

And I'll ask again. Do you have a *specific, credible alternative*? Because
so far I'm not seeing one.
--
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

[Mike Hearn]

>
> Dear list,
>
> Apparently my emails are being marked as spam, despite being sent from
> GMail's web interface.  I've pinged our sysadmin.


It's a problem with the mailing list software, not your setup. BitPay could
disable the phishing protections but that seems like a poor solution. The
only real fix is to send from a non @bitpay.com email address. Gmail or
Hotmail will work, I think. Yahoo won't: they enforce the same strict
policies than bitpay does.
--
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

[Mike Hearn]

>
> It is an argument against my admittedly vague definition of
> "non-controversial change".
>

If it's an argument against something you said, it's not a straw man, right
;)

Consensus has to be defined as agreement between a group of people. Who are
those people? If you don't know, it's impossible to decide when there is
consensus or not.

Right now there is this nice warm fuzzy notion that decisions in Bitcoin
Core are made by consensus. "Controversial" changes are avoided. I am
trying to show you that this is just marketing. Nobody can define what
these terms even mean. It would be more accurate to say decisions are
vetoed by whoever shows up and complains enough, regardless of technical
merit. After all, my own getutxo change was merged after a lot of technical
debate (and trolling) . then unmerged a day later because "it's a
shitstorm".

So if Gavin showed up and complained a lot about side chains or whatever,
what you're saying is, oh that's different. We'd ignore him. But when
someone else complains about a change they don't like, that's OK.

Heck, I could easily come up with a dozen reasons to object to almost any
change, if I felt like it. Would I then be considered not a part of the
consensus because that'd be convenient?


> I'm sure that's not what the proponents of the size increase want, and
> I'm not defending 1 MB as a sacred limit  or anything, but my question
> is "where is the limit for them?"
>

20mb is an arbitrary number, just like 1mb. It's good enough to keep the
Bitcoin ecosystem operating as it presently does: gentle growth in usage
with the technology that exists and is implemented. Gavin has discussed in
his blog why he chose 20mb, I think. It's the result of some estimates
based on average network/hardware capabilities.

Perhaps one day 20mb will not be enough. Perhaps then the limit will be
raised again, if there is sufficient demand.

You are correct that "no limit at all" is a possible answer. More
precisely, in that case miners would choose. Gavin's original proposal was
20mb+X where X is decided by some incrementing formula over time, chosen to
approximate expected improvements in hardware and software. That was cool
too. The 20mb figure and the formula were an attempt to address the
concerns of people who are worried about the block size increase:  a
meet-in-the-middle compromise.

Unfortunately it's hard to know what other kinds of meet-in-the-middle
compromise could be made here. I'm sure Gavin would consider them if he
knew. But the concerns provided are too vague to address. There are no
numbers in them, for example:

   - We need more research -> how much more?
   - I'm not against changing the size, just not now -> then when?
   - I'm not wedded to 1mb, but not sure 20mb is right -> then what?
   - Full node count is going down -> then what size do you think would fix
   that? 100kb?
   - It will make mining more centralised -> how do you measure that and
   how much centralisation would you accept?

and so on.
--
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

[Mike Hearn]

>
> It is a trivial *code* change.  It is not a trivial change to the
> economics of a $3.2B system.
>

Hmm - again I'd argue the opposite.

Up until now Bitcoin has been unconstrained by the hard block size limit.

If we raise it, Bitcoin will continue to be unconstrained by it. That's the
default "continue as we are" position.

If it's not raised, then ... well, then we're in new territory
entirely. Businesses built on the assumption that Bitcoin could become
popular will suddenly have their basic assumptions invalidated. Users will
leave. The technical code change would be zero, but the economic change
would be significant.
--
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

[Mike Hearn]

>
> What gives Bitcoin value aren't its technical merits but the fact that
> people believe in it.
>

Much of the belief in Bitcoin is that it has a bright future. Certainly the
huge price spikes we've seen were not triggered by equally large spikes in
usage - it's speculation on that future.

I quite agree that if people stop believing in Bitcoin, that will be bad. A
fast way to bring that about will be to deliberately cripple the technology
in order to force people onto something quite different (which probably
won't be payment channel networks).


> I'd argue that if we didn't force through a 20MB fork now, and we ran into
> major network difficulties a year from now and had no other technical
> solutions, that maybe we would get nearly universal agreement
>

I doubt it. The disagreement seems more philosophical than technical. If
Bitcoin fell off a cliff then that'd just be taken as more evidence that
block chains don't work and we should all use some network of payment hubs,
or whatever the fashion of the day is. Or anyone who doesn't want to pay
high fees is unimportant. See all the other justifications Gavin is working
his way through on his blog.

That's why I conclude the opposite - if there is no fork, then people's
confidence in Bitcoin will be seriously damaged. If it's impossible to do
something as trivial as removing a temporary hack Satoshi put in place,
then what about bigger challenges? If the community is really willing to
drive itself off a cliff due to political deadlock, then why bother
building things that use Bitcoin at all?
--
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

[Mike Hearn]

>
> If his explanation was "I will change my mind after we increase block
>
size", I guess the community should say "then we will just ignore your
> nack because it makes no sense".
>

Oh good! We can just kick anyone out of the consensus process if we think
they make no sense.

I guess that means me and Gavin can remove everyone else from the developer
consensus, because we think trying to stop Bitcoin growing makes no sense.

Do you see the problem with this whole notion? It cannot possibly work.
Whenever you try and make the idea of developer consensus work, what you
end up with is "I believe in consensus as long as it goes my way". Which is
worthless.


> One thing is the Bitcoin core project where you could argue that the 5
> committers decide (I don't know why Wladimir would have any more
> authority than the others).
>

Because he is formally the maintainer.

Maybe you dislike that idea. It's so  centralised. So let's say Gavin
commits his patch, because his authority is equal to all other committers.
Someone else rolls it back. Gavin sets up a cron job to keep committing the
patch. Game over.

You cannot have committers fighting over what goes in and what doesn't.
That's madness. There must be a single decision maker for any given
codebase.


> Ok, so in simple terms, you expect people to have to pay enormous fees
> and/or wait thousands of blocks for their transactions to get included
> in the chain. Is that correct?
>

No. I'll write an article like the others, it's better than email for more
complicated discourse.

As others have said, if the answer is "forever, adoption is always the most
> important thing" then we will end up with an improved version of Visa.
>

This appears to be another one of those fundamental areas of disagreement.
I believe there is no chance of Bitcoin ending up like Visa, even if it is
wildly successful. I did the calculations years ago that show that won't
happen:

https://en.bitcoin.it/wiki/Scalability

Decentralisation is a spectrum and Bitcoin will move around on that
spectrum over time. But claiming we have to pick between 1mb blocks and
"Bitcoin = VISA" is silly.



Peter:   your hypocrisy really is bottomless, isn't it? You constantly
claim to be a Righteous Defender of Privacy, but don't even hesitate before
publishing hacked private emails when it suits you.

Satoshi's hacker had no illusions about your horrible personality, which is
why he forwarded that email to you specifically. He knew you'd use it. You
should reflect on that fact. It says nothing good about you at all.
--
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

[Mike Hearn]

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

https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d

It's a fairly simple estimate based on previous growth patterns.

Because I love wild guesses and mine is that full 1 MB blocks will not
> happen until June 2017.
>

OK, it could be. But do you think this debate will play out significantly
differently if you are right, I am wrong, and we have this discussion next
summer instead? Because in several years of watching these debates, I
haven't seen much change in them.


> We've successfully reached consensus for several softfork proposals
> already.
>

Are you sure about that?

What if Gavin popped up right now and said he disagreed with every current
proposal, he disagreed with side chains too, and there would be no
consensus on any of them until the block size limit was raised.

Would you say, oh, OK, guess that's it then. There's no consensus so might
as well scrap all those proposals, as they'll never happen anyway. Bye bye
side chains whitepaper.



> I just hope that by  "What we need to see right now is leadership" you
> don't mean something like "when Gaving and Mike agree it's enough to
> deploy a hardfork" when you go from vague to concrete.
>

No. What I meant is that someone (theoretically Wladimir) needs to make a
clear decision. If that decision is "Bitcoin Core will wait and watch the
fireworks when blocks get full", that would be showing leadership .
albeit I believe in the wrong direction. It would, however, let people know
what's what and let them start to make longer term plans.

This dillydallying around is an issue - people just make vague points that
can't really be disagreed with (more nodes would be nice, smaller pools
would also be nice etc), and nothing gets done.


> "no bitcoin long term it's broken long term but that's far away in the
> future so let's just worry about the present".
>

I never said Bitcoin is broken in the long term. Far from it - I laid out
my ideas for what will happen when the block subsidy dwindles years ago.

But yes, it's hard for me to care overly much about what happens 30 years
from now, for the same reason you probably care more about what happens
tomorrow than what happens after you are dead. The further into the future
you try and plan, the less likely your plans are to survive unscathed.


> What you want to avoid at all cost (the block size actually being
> used), I see as the best opportunity we have to look into the future.
>

I think I see one of the causes of disagreement now.

I will write more on the topic of what will happen if we hit the block size
limit soon, maybe this evening. I have some other tasks to do first.

Regardless, I don't believe we will get any useful data out of such an
event. I've seen distributed systems run out of capacity before. What will
happen instead is technological failure followed by rapid user abandonment
that pushes traffic back below the pressure threshold  and those users
will most likely not come back any time soon.


> Ok, this is my plan: we wait 12 months, hope that your estimations are
> correct (in case that my guess was better than yours, we keep waiting
> until June 2017) and start having full blocks and people having to
> wait 2 blocks for their transactions to be confirmed some times.
>

I disagree that'd be the outcome, but good, this is progress. Now we need
to hear something like that from Wladimir, or whoever has the final say
around here.

With respect to the fee market: I think it's fairer to say Gavin wants a
market to exist, and he also wants supply to be plentiful. 20mb limit
doesn't actually mean every block will be 20mb the day after, no more than
they're all 1mb today. Miners may discover that if they go beyond 5mb they
have too many orphans and then propagation speed will have to be optimised
to break through the next bottleneck. Scaling is always about finding the
next bottleneck and removing it, ideally, before you hit it.
--
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

[Mike Hearn]

Hey Matt,

OK, let's get started 

However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>

Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).

If you're wondering "why now", that's probably my fault. A few days ago
Wladimir posted a release timeline. I observed to Wladimir and Gavin in
private that this timeline meant a change to the block size was unlikely to
get into 0.11, leaving only 0.12, which would give everyone only a few
months to upgrade in order to fork the chain by the end of the winter
growth season. That seemed tight.

Wladimir did not reply to this email, unfortunately. Perhaps he would like
the issue to go away. It won't - if Bitcoin continues on its current growth
trends it *will* run out of capacity, almost certainly by some time next
year.

What we need to see right now is leadership and a plan, that fits in the
available time window.


> Certainly a consensus in this kind of technical community should be a
> basic requirement for any serious commitment to blocksize increase.
>

I'm afraid I have come to disagree. I no longer believe this community can
reach consensus on anything protocol related. Some of these arguments have
dragged on for years. Consensus isn't even well defined - consensus of who?
Anyone who shows up? And what happens when, inevitably, no consensus is
reached? Stasis forever?


> Long-term incentive compatibility requires that there be some fee
> pressure, and that blocks be relatively consistently full or very nearly
> full.


I disagree. When the money supply eventually dwindles I doubt it will be
fee pressure that funds mining, but as that's a long time in the future,
it's very hard to predict what might happen.


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

Many do because free transactions are broken - the relay limiter means
whether a free transaction actually makes it across the network or not is
basically pot luck and there's no way for a wallet to know, short of either
trying it or actually receiving every single transaction and repeating the
calculations. If free transactions weren't broken for all non-full nodes
they'd probably be used a lot more.


> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale.


I have two huge problems with this line of thinking.

Firstly, no, the "Bitcoin ecosystem" is not well funded. Blockstream might
be, but significant numbers of users are running programs developed by tiny
startups, or volunteers who don't have millions in venture capital to play
with.

Arm-twisting "the ecosystem" into developing complicated Rube Goldberg
machines in double quick time, just to keep the Bitcoin show on the road,
is in fact the opposite of decentralisation - it will effectively exclude
anyone who isn't able to raise large amounts of corporate funding from
writing code that uses the Bitcoin network. Decentralisation benefits from
simplicity, and bigger blocks are (in Gavin's words) "the simplest thing
that will work".

My second problem is the claim that everyone is playing pretend about
Bitcoin, except you guys. I would put it another way - I would say those
people are building products and getting users, by making reasonable
engineering tradeoffs and using systems that work. Yes, one day those
systems might have to change. That's the nature of scaling. It's the nature
of progress. But not today. Probably not tomorrow either.

What I would like to see from Blockstream is a counter-proposal. So far you
have made lots of vague comments that we all agree with - yes,
decentralisation is good, yes some block size limit must exist, if only
because computers are finite machines.

What I don't see from you yet is a *specific and credible plan* that fits
within the next 12 months and which allows Bitcoin to keep growing. Not
some vague handwave like "let's all use the Lightning network" (which does
not exist), or "let's do more research" (Gavin has done plenty of
research), or "but what about the risks" (Bitcoin is full of risks). A
plan, with dates attached, and a strong chance of actually being deployed
in time.
--
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.sourc

Re: [Bitcoin-development] Reusable payment codes

[Mike Hearn]

>
> 1. There will be a 1:1 relationship between a payment code owner and their
> identity.
>

Bear in mind, the spec defines "identity" to mean:

 *Identity is a particular extended public/private key pair. *

So that's not quite what is meant normally by identity. It's not a
government / real name identity or an email address or phone number kind of
identity.
--
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] Fwd: Reusable payment codes

[Mike Hearn]

Could you maybe write a short bit of text comparing this approach to
extending BIP70 and combining it with a simple Subspace style
store-and-forward 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] Where do I start?

[Mike Hearn]

Hey Gabe,

That's diving into the deep end for sure! :)

> What are some current things that are lacking in Bitcoin core? Or am I
> better off making something else for the ecosystem?
>
That depends on your interests.

Many of the highest priority tasks in Bitcoin Core are rather complicated,
unfortunately, even for people with experience. You can consult the issue
tracker to get a feel for it.

Alternatively, there are lots of wallet apps out there and plenty of more
straightforward projects on them. However they may have less of a research
flavour.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] DevCore London

[Mike Hearn]

Next week on April 15th Gavin, Wladimir, Corey and myself will be at
DevCore London:

   https://everyeventgives.com/event/devcore-london

If you're in town why not come along?

It's often the case that conferences can be just talking shops, without
much meat for real developers. So in the afternoon I'll be doing two things:

   1. Running a hackathon/workshop type event. The theme is contracts, but
   we can hack on whatever you all feel like.

   2. My "talk" will actually be a live coding event. Writing contracts
   apps has become a lot easier in the past few years, and to prove it to you
   I will write a decentralised cross-platform Tor supporting document
   timestamping app that uses OP_RETURN outputs and has a nice GUI . in 30
   minutes, on stage.

   Don't think it can be done? Turn up and see for yourself.

See you there!
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Build your own nHashType

[Mike Hearn]

>
> I don't think it's quite a blank check, but it would enable replay attacks
> in the form of sending the money to the same place it was sent before if an
> address ever receives coins again.
>

Right, good point. I wonder if this sort of auto forwarding could even be a
useful feature. I can't think of one right now.


> It's hard, though, because there is different data needs to be signed for
> each input.
>

Yes but is that fundamental or is there a way to avoid it? That's what I'm
getting at.


> Another possibility would be to put the previous scriptPubKey and previous
> output value at the END of the serialized transaction, so that you could
> make use of some sort of a signature hash midstate.
>

Interesting idea! I don't agree it's messy. If anything it should be
simpler than what we have today - the need to edit a transaction *in the
middle* means that sighash computation involves constantly reserializing a
transaction before it even gets to be hashed.


> Is hashing transaction data once for each input really a huge bottleneck,
> though? Do mobile devices have an issue with this?
>

Consider what happens with very large transactions, like a big assurance
contract that might have thousands of inputs and be multiple megabytes in
size. Obviously such large transactions cannot happen today, but there is
user demand for giant contracts (or at least, users tell me there is,
whether they'd actually do it for real is a bit unclear).
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Build your own nHashType

[Mike Hearn]

Hi Stephen,

It's an interesting idea. I'm not sure that all the combinations make
sense. Excluding the connected output script or value but still signing the
prev tx hash appears pointless: the script cannot change anyway, and you
still need to know what it is to actually calculate the inputs to it, so
what is the point of this?

I also worry that quite a few of these combinations could be unexpectedly
dangerous. If you don't sign the prevout hash or value and combine it with
a regular pay-to-address output then you've effectively written a blank
cheque that can be used by anyone, to claim any money ever sent to that
address ... no? And then any p2p node or miner could do so, making the
transaction pretty useless.

That isn't inherently a problem as long as people understand which
combinations have what effects or cannot be used for various reasons. But
it would need good documentation and careful thought to explore each
possibility people might use.

I'll leave the soft fork business to one side for now. I think any change
in CHECKSIG or new version of it would likely be ready around the same time
as the hard fork we need for changing the block size limit anyway, and it's
much cleaner to do it that way.

The most important change that we need in sighash calculation, IMO, is
ensuring that you don't have to hash data over and over again without a
good reason. The current sighash definition is unfortunate because it's
possible to make small transactions that involve hashing huge amounts of
data. It's not clear to me that your proposal fixes that: ideally there
would be one exactly one sighash for one transaction no matter how many
checksigs are involved in verifying it.

thanks,
-mike
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Double spending and replace by fee

[Mike Hearn]

I've written a couple of blog posts on replace by fee and double spending
mitigations. They sum up the last few years (!) worth of discussions on
this list and elsewhere, from my own perspective.

I make no claim to be comprehensive or unbiased but I keep being asked
about these topics so figured I'd just write up my thoughts once so I can
send links instead of answers :) And then so can anyone who happens to
agree.

(1) Replace by fee scorched earth, a counter argument:

https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

This article lays out the case against RBF-SE and argues it is harmful to
Bitcoin.

(2) Double spending and how to make it harder:

https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008

This article summarises a couple of double spending incidents against
merchants and then discusses the following techniques:

   1. Risk analysis of transactions
   2. Payment channels
   3. Countersigning by a trusted third party
   4. Remote attestation
   5. ID verification
   6. Waiting for confirmations
   7. Punishment of double spending blocks

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

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Mike Hearn]

>
> Don't SPV clients announce their intentions by the act of uploading a
> filter?
>

Well they don't set NODE_NETWORK, so they don't claim to be providing
network services. But then I guess the Chainalysis nodes could easily just
clear that bit flag too.


> What I'd actually like to see is for network users to pay for the node
> resources that they consume


It's not quite pay-as-you-go, but I just posted a scheme for funding of
network resources using crowdfunding contracts here:

https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064

That comment doesn't have any kind of provision for access control, but
group signatures could be extended in both directions: the server proves it
was a part of the group that was funded by the contract, and the client
proves it was in group that funded the contract, but it's done in a
(relatively) anonymous way. Then any client can use any node it funded, or
at least, buy priority access.

But it's rather complicated. I'd hope that nodes can be like email
accounts: yes they have a cost but in practice people everyone gets one for
free because of random commercial cross-subsidisation, self hosting and
other things.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Mike Hearn]

>
> I'm not talking about keeping logs, I mean purporting to be a network
> peer in order to gain a connection slot and then not behaving as one
> (not relaying transactions)


That definition would include all SPV clients?

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

Re: [Bitcoin-development] Proof of Payment

[Mike Hearn]

>
> As soon as that PaymentRequest leaves the wallet on its way to the hotel
> server, it is up for grabs
>

Is it? I'm assuming TLS is being used here. And the hotel server also has a
copy of the PaymentRequest, as the hotel actually issued it and that's how
they're deciding the receipt is valid. So I don't know how it could be
stolen unless the attacker can break TLS.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Mike Hearn]

That would be rather new and tricky legal territory.

But even putting the legal issues to one side, there are definitional
issues.

For instance if the Chainalysis nodes started following the protocol specs
better and became just regular nodes that happen to keep logs, would that
still be a violation? If so, what about blockchain.info? It'd be shooting
ourselves in the foot to try and forbid block explorers given how useful
they are.

If someone non-maliciously runs some nodes with debug logging turned on,
and makes full system backups every night, and keeps those backups for
years, are they in violation of whatever pseudo-law is involved?

I think it's a bit early to think about these things right now. Michael
Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
interested to know their thoughts on all of this.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 Index Randomisation

[Mike Hearn]

>
> You are killing us Mike! :) We really don't like to think that BWS is
> a webwallet. Note
> that private keys are not stored (not even encrypted) at the server.


Sure, sorry, by web wallet I meant a blockchain.info/CoPay type setup where
the client has the private keys and signs txns, but otherwise relies on the
server for learning about the wallet contents. I tend to call wallets where
the server has the private key BitBanks but I don't know if anyone else
uses this terminology. It might just be a personal quirk of my own ;)


> we think having some visibility of the wallet by the multisig
> facilitator will make the user experience much better (e.g: mobile
> notifications).
>

Fair enough. Yes, push notifications to mobiles in a decentralised way is
rather a hard problem.

I think what Gregory suggested is then the best approach for you to do what
you want. Whether it's worth the additional complexity is something I don't
have any feedback on, only you can judge that.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proof of Payment

[Mike Hearn]

Hi Kalle,

I think you're thinking along the right lines, but I am skeptical that this
protocol adds much. A saved payment request is meant to be unique per
transaction e.g. because the destination address is unique for that payment
(for privacy reasons). Where would you store the signed payment request?
Probably in the wallet. You could just extract the metadata that's useful
for UI rendering into a separate structure and then encrypt the original
full payment request under the wallet key. At least this is how I imagine
it would work.

So then, if someone can steal a payment request they can probably steal the
wallet signing keys too, and thus signing a challenge with the wallet keys
doesn't add much. It means the wallet doesn't have to store the
PaymentRequest encrypted. But AFAICT that's about all it does.

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

Re: [Bitcoin-development] BIP32 Index Randomisation

[Mike Hearn]

It sounds like the main issue is this is a web wallet server of some kind.
If the clients were SPV then they'd be checking their own balances and
downloading their own tx history, which would mean the coordination tasks
could be done by storing encrypted blobs on the server rather than the
server itself having insight into what's going on (see: Subspace).

So whilst you might be able to use some scheme to avoid the server knowing
the xpubkey, if the server still knows all addresses and all transactions
because the clients are web wallets . is there any point? It seems like
maybe going from server knows everything to server knows 95% of everything:
maybe not worth the engineering cost.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 Index Randomisation

[Mike Hearn]

Hey Matias,

We are working on bitcore-wallet-server (BWS), a HD multisig wallet
> 'facilitator'.
> Currently the BWS instances hold the set of extended public keys of the
> wallet's peers to be able to derive  addresses.
>

Could you describe what exactly BWS does? It sounds like the server doesn't
have to actually derive the keys itself for any particular purpose beyond
knowing the addresses are a part of the wallet. Could the server work if it
didn't even know that, and was just a bucket of arbitrary addresses with
the clients themselves deriving the addresses?
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> b) "Creation date" is just a short-term hack.
>

I agree, but we need things to be easy in the short term as well as the
long term :)

The long term solution is clearly to have the 12 word seed be an encryption
key for a wallet backup with all associated metadata. We're heading in that
direction one step at a time. Unfortunately it will take time for wallets
to start working this way, and all the pieces to fall into place. Restoring
from the block chain will be a semi regular operation for users until then.

WRT version number I have no real strong feelings about this. But
representing short pieces of binary data as words is so convenient, it
seems likely that it could be similar to addresses: people find other uses
for this mechanism beyond just storing a raw private key. Bitcoin addresses
have versions and that's proven to be useful several times, even though in
theory an address is "just" a hash of a pubkey.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

>
> I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.


Sure. But in practice people will want to have a pool of spending money
that they can spend when they are out and about, and also with one click
from their web browser on their primary computer, and maybe also on their
games console, etc etc.

I don't think we can realistically tell people to *always* use clever
multi-device wallets - there will always be a desire to have a convenient
hot wallet that's synchronised between different devices.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

Users will want to have wallets shared between devices, it's as simple as
that, especially for mobile/desktop wallets. Trying to stop them from doing
that by making things gratuitously incompatible isn't the right approach:
 they'll just find workarounds or wallet apps will learn how to import
seeds from other apps. Better to just explain the risks and help people
mitigate them.

On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine  wrote:

> I'm not convinced that wallet seed interoperability is such a great thing.
> There is a wide variability in the quality and security level of wallet
> implementations and platforms. Each new device and wallet software a user
> types their seed into increases their attack surface and exposure to flaws.
> Their security level is reduced to the lowest common denominator. I see the
> need for a "fire exit", certainly, but we must also remember that fire
> exits are potential entrances for intruders.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell 
> wrote:
>
>> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>>  wrote:
>> > i guess you look at the glass half full :)
>> > even though what you say is true, we should aim for wallets not to
>> > require those instructions, by standardizing these things in BIPs.
>> > let's hope bitcoin doesn't fail in standards as our industries have in
>> > the past...
>>
>> There are genuine principled disagreements on how some things should
>> be done. There are genuine differences in functionality.
>>
>> We cannot expect and should not expect complete compatibility. If you
>> must have complete compatibility: use the same software (or maybe not
>> even then, considering how poor the forward compatibility of some
>> things has been..).
>>
>> What we can hope to do, and I think the best we can hope to do, is to
>> minimize the amount of gratuitous incompatibility and reduce the
>> amount of outright flawed constructions (so if there are choices which
>> must be made, they're at least choices among relatively good options).
>>
>>
>> --
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

[Mike Hearn]

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

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

[Mike Hearn]

Sigh. The wallet words system is turning into kind of a mess.

I thought the word list is in fact not a fixed part of the spec, because
the entropy is a hash of the words. But perhaps I'm misunderstanding
something.

The main problem regular SPV wallets have with BIP39 is that there is no
birth time included in the data. Therefore we must ask users to write down
a timestamp as well, so we know where to start rescanning the chain. It
sounds like the Electrum version doesn't fix this, so now we have at least
FIVE incompatible results from a 12 word list:

   - Electrum v2 with a version number but no date
   - myTREZOR with no version and no date and BIP44 key derivation. Some
   seeds I believe are now being generated with 24 words instead of 12.
   - MultiBit HD with no version and a date in a custom form that creates
   non-date-like codes you are expected to write down. I think BIP32 and BIP44
   are both supported (sorta).
   - GreenAddress with no version, no date and BIP32
   - Other bitcoinj based wallets, with no version and a date written down
   in normal human form, BIP32 only.

I really hope we can recover from this somehow because otherwise all
wallets will have to provide the user with a complicated matrix of
possibilities and software combinations, and in practice many won't bother
so these word combinations will actually end up being wallet specific for
no particularly good reason, just very minor details like the presence or
absence of single fields.

It feels like we somehow fell flat on our faces just before the finishing
line. This is deeply unfortunate. Compatibility and UX consistency is
important!

Currently, I don't have any bright ideas for how to get everyone back onto
the same page with a fully compatible system that is acceptable to all. If
anyone else has suggestions, I'm all ears.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies

[Mike Hearn]

Nice, Andrew.

Just one minor point. SPV clients do not need to maintain an ever growing
list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and
thus has O(1) disk usage. Re-orgs past the event horizon cannot be
processed but are assumed to be sufficiently rare that manual intervention
would be acceptable.

On Mon, Mar 2, 2015 at 8:48 AM, Andrew Miller  wrote:

> We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten,
> Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have
> written a “systemization” paper about Bitcoin-related research. It’s
> going to appear in the Oakland security conference later this year
> (IEEE Security and Privacy) but we wanted to announce a draft to this
> community ahead of time.
>
> http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf
>
> One of the main goals of our work is to build a bridge between the
> computer science research community and the cryptocurrency community.
> Many of the most interesting ideas and proposals for Bitcoin come from
> this mailing list and forums/wikis/irc channels, where many academic
> researchers simply don’t know to look! In fact, we started out by
> scraping all the interesting posts/articles we could find and trying
> to figure out how we could organize them. We hope our paper helps some
> of the best ideas and research questions from the Bitcoin community
> bubble up and inspires researchers to build on them.
>
> We didn’t limit our scope to Bitcoin, but we also decided not to
> provide a complete survey of altcoins and other next-generation
> cryptocurrency designs. Instead, we tried to explain all the
> dimensions along which these designs differ from Bitcoin.
>
> This effort has roughly been in progress over two years, though it
> stopped and restarted several times along the way.
>
> If anyone has comments or suggestions, we still have a week before the
> final version is due, and regardless we plan to continue updating our
> online version for the forseeable future.
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mike Hearn]

Congrats Thomas! Glad to see Electrum 2 finally launch.


> * New seed derivation method (not compatible with BIP39).


Does this mean a "12 words" wallet created by Electrum won't work if
imported into some other wallet that supports BIP39? Vice versa? This seems
unfortunate. I guess if seeds are being represented with 12 words
consistently, people will expect them to work everywhere.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Providing Payment Request within URI

[Mike Hearn]

Andreas' wallet supports this, but don't do it. Payment requests can get
larger in future even without signing. Exploding the capacity of a QR code
is very easy.

Instead, take a look at the Bluetooth/NFC discussion happening in a
different thread.

On Tue, Feb 24, 2015 at 4:58 PM, Oleg Andreev  wrote:

> Hi,
>
> I wonder if there is a standard way to put Payment Request data into
> bitcoin: URI or directly into QR code. The goal is to allow device to
> generate a multi-output payment request on its own, without relying on the
> server and x509 certificates. When scanned via QR code from, say, POS, it's
> pretty secure, so no additional authentication needed.
>
> I'd like something like this:
>
> bitcoin:?r=data://
>
> If there's no standard for that, would it be a good idea to extend BIP72
> this way?
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin

[Mike Hearn]

Hi Chris,

Just FYI you may not have received much feedback on this because Gmail put
it into the spam folder for some reason. So I'm guessing a lot of people
didn't see it.

My main feedback is - I do not really see how this is different from actual
mining. Mining also incentives the running of full nodes, miners are
rewarded via coinbases, etc. I'm missing a crisp description of why your
scheme is better than this, in particular, taking into account the
difficulty of distinguishing full node sybils of each other.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

>
> Does this not also require the BT publication of the script for a P2SH
> address?


You mean if the URI you're serving is like this?

   bitcoin:3aBcD?bt=

Yes it would. I guess then, the server would indicate both the script, and
the key within that script that it wanted to use. A bit more complex but
would still work to save URI space.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Mike Hearn]

>
> I don't see how you propose to treat the bitcoin address as a secp256k1
> public key, or do you mean something else?
>

Sorry, I skipped a step. I shouldn't make assumptions about what's obvious.
The server would provide the public key and the client would convert it to
address form then match against the URI it has scanned. If it didn't match,
stop at that point.
--
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=190641631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development