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

2015-06-19 Thread 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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread 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 RD 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 is defined by the 

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

2015-06-19 Thread 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 http://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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread 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] Mailman incompatibility with DKIM ...

2015-06-19 Thread 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] Mailman incompatibility with DKIM ...

2015-06-19 Thread 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

2015-06-18 Thread 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

2015-06-18 Thread 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

2015-06-18 Thread 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] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-16 Thread 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

2015-06-16 Thread 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] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread 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] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread 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] Proposal: SPV Fee Discovery mechanism

2015-06-11 Thread 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

2015-06-11 Thread 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] Proposed alternatives to the 20MB step

2015-06-02 Thread 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] DevCore London

2015-06-02 Thread 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 m...@plan99.net 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‏

2015-06-02 Thread 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

2015-06-01 Thread 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

2015-06-01 Thread 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

2015-06-01 Thread 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)

2015-06-01 Thread 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] Proposed alternatives to the 20MB step function

2015-05-29 Thread 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

2015-05-29 Thread 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

2015-05-29 Thread 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

2015-05-29 Thread 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

2015-05-28 Thread 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] Long-term mining incentives

2015-05-28 Thread 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

2015-05-27 Thread 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] Consensus-enforced transaction replacement via sequence numbers

2015-05-27 Thread 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] Long-term mining incentives

2015-05-27 Thread 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] Zero-Conf for Full Node Discovery

2015-05-26 Thread 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 b...@mattwhitlock.name
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] Scaling Bitcoin with Subchains

2015-05-25 Thread 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] Long-term mining incentives

2015-05-25 Thread 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] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread 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

2015-05-25 Thread 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] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread 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] Virtual Notary.

2015-05-25 Thread 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] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread 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] Block Size Increase Requirements

2015-05-08 Thread 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] Block Size Increase

2015-05-08 Thread 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] Proposed alternatives to the 20MB step function

2015-05-08 Thread 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] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-08 Thread 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

2015-05-07 Thread 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

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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] Reusable payment codes

2015-04-27 Thread 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

2015-04-26 Thread 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


[Bitcoin-development] DevCore London

2015-04-09 Thread 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_15utm_medium=emailutm_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

2015-04-09 Thread 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_15utm_medium=emailutm_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

2015-03-28 Thread 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] BIP32 Index Randomisation

2015-03-13 Thread 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] Proof of Payment

2015-03-13 Thread 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

2015-03-13 Thread 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] Criminal complaints against network disruption as a service startups

2015-03-13 Thread 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

2015-03-13 Thread 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

2015-03-13 Thread 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] Criminal complaints against network disruption as a service startups

2015-03-13 Thread 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] Electrum 2.0 has been tagged

2015-03-12 Thread 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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread 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

2015-03-11 Thread 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] Electrum 2.0 has been tagged

2015-03-11 Thread 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

2015-03-11 Thread 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 vois...@gmail.com 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 gmaxw...@gmail.com
 wrote:

 On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
 ricardojdfil...@gmail.com 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] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies

2015-03-04 Thread 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 amil...@cs.umd.edu 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

2015-03-02 Thread 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread 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] Providing Payment Request within URI

2015-02-25 Thread 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 olega...@gmail.com 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://base64url-encoded-payment-request

 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] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-23 Thread Mike Hearn

 This happened to one of the merchants at the Bitcoin 2013 conference in
 San Jose. They sold some T-shirts and accepted zero-confirmation
 transactions. The transactions depended on other unconfirmed transactions,
 which never confirmed, so this merchant never got their money.


Beyond the fact that this risk can be priced in when enough data is
available, I'd be interested to talk to this merchant and dig into what
happened a bit.

For example:

   1. Was the dependent tx non-standard?
   2. Was it double spent?
   3. Could a wallet have co-operated with the P2P network to detect and
   flag whatever the issue was?

My own experience has been that when this happens, it's usually not the
result of outright maliciousness (especially not at a Bitcoin t-shirt
seller at a Bitcoin conference!) but rather something messed up somewhere
and the software in use just didn't detect it well enough.
--
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=190641631iu=/4140/ostg.clktrk___
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

2015-02-23 Thread Mike Hearn

 DHKE will not improve the situation. Either we use a simple method to
 transfer a session key or a complex method.


You're right that just sending the session key is simpler. I originally
suggested doing ECDHE to set up an encrypted channel for the following
reasons:

   1. URIs are put in QR codes more often than NFC tags. QR codes have
   limited space. The more stuff you pack into them, the slower and flakier
   the scanning process becomes.

   For normal wallets, doing ECDH over secp256k1 to derive a session key
   means we can reuse the address that was put in the URI already for
   pre-BIP70 wallets, thus we don't have to expand the URI at all except
   perhaps to flag that crypted Bluetooth connections are supported. Win!

   2. If the wallet is a watching wallet, this won't work and in that case
   you would need to put a separate key into the URI. However, this key is
   ephemeral and does not need to be very strong. So we can generate a regular
   secp256k1 key and then put say 5-8 prefix bytes into the URI as a new
   parameter. The public key can then be provided in full in the clear over
   the Bluetooth connection and the session key derived. If we put the session
   key into the URI in full, then we could not use this trick. Win!

   3. It's quite common in low tech scenarios like little coffee shops to
   just print a QR code and put it in the menu, or sticky tape it to the back
   wall of the shop.

   In these cases, it's possible that the device is actually hanging around
   in the shop somewhere but having the QR code somewhere larger and more
   accessible than the shop devices screen is highly convenient. However it
   means the data is entirely static.

   Putting/reusing an identity key from the URI means the session keys are
   always unique and known only to both devices, even though the bootstrap
   data is public.

   4. Doing ECDHE to derive the keys means we can derive a MAC key as well
   as an AES key. Otherwise you have the issue of exchanging both, which again
   uses up valuable bootstrap space.

So for a small increase in session setup complexity we potentially avoid
troubling problems down the line where people the same functionality from
NFC and QR code based bootstrap, but we can't provide it.

These discussions keep coming up. I think the next step is for someone to
upgrade Andreas' wallet to support encrypted connections and the TBIPs, to
see what happens.

Re: the h= parameter. I only objected to requiring this when the payment
request is also signed. It adds complexity, uses space, and the rationale
was the PKI can't be trusted even though it's been used to protect credit
card payments for 20 years without any issues. In the case of unsigned
payment requests, sure ... but with a proper implementation of an encrypted
Bluetooth channel it'd be unnecessary as the channel establishment process
would guarantee authenticity anyway.

But don't let me hold you guys back! I'd rather see something that works
than an endless debate about the perfect arrangement of hashes and URI
parameters :)
--
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=190641631iu=/4140/ostg.clktrk___
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

2015-02-23 Thread Mike Hearn

 I read from your answer that even if we use ECDHE, we can't use it for
 every situation.


Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in every situation.
--
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=190641631iu=/4140/ostg.clktrk___
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

2015-02-23 Thread Mike Hearn

 At the moment I'm also modifying BitPay's memo field to contain 'ack', as
 Andreas' wallet otherwise reports a failure if I transmit the original via
 Bluetooth. :-)


Huh?
--
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=190641631iu=/4140/ostg.clktrk___
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

2015-02-23 Thread Mike Hearn

 But via Bluetooth it checks for 'ack' directly:


We need a BIP70 conformance suite really. There are so many deviations from
the spec out there already and it's brand new :(
--
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=190641631iu=/4140/ostg.clktrk___
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

2015-02-23 Thread 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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-21 Thread Mike Hearn

 Adam seems to be making sense to me. Only querying a single node when an
 address in my wallet matches the block filter seems to be pretty efficient.


No, I think it's less efficient (for the client).

Quick sums:  blocks with 1500 transactions in them are common today. But
Bitcoin is growing. Let's imagine a system 10x larger than today. Doesn't
seem implausible to reach that in the next 5-10 years, so 15,000
transactions. Each transaction has multiple elements we might want to match
(addresses, keys, etc).

Let's say the average tx contains 5 unique keys/elements. That's the base
case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
for multi-sends then down a bit again for address reuse.

15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:

http://hur.st/bloomfilter?n=75000p=0.001

131.63KB per block extra overhead.

144 blocks in a day, so that's 18mb of data per day's worth of sync to pull
down over the network. If you don't start your wallet for a week that's 126
megabytes of data just to get started.

Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
don't believe that even in five years mobiles will be pulling down and
processing that much data within a few seconds, not even in developed
countries.

But like I said, I don't see why it matters. Anyone who is watching the
wire close to you learns which transactions are yours, still, so it doesn't
stop intelligence agencies. Anyone who is running a node learns which
transactions in the requested block were yours and thus can follow the tx
chain to learn which other transactions might be yours too, no different to
today. If you connect to a single node and say give me the transactions
sending money to key A in block N, it doesn't matter if you then don't
request block N+6 from the same peer - they know you will request it
eventually anyway, just by virtue of the fact that one of the transactions
they gave you was spent in that block.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-21 Thread Mike Hearn

 For downloading transactions unless you frequently receive
 transactions you wont be fetching every block.  Or are you assuming
 bloom filters dialled up to the point of huge false positives?  You
 said otherwise.


Well, what I mean is, bitcoinj already gets criticised for having very low
FP rates, but even with those rates we're applying them to hundreds of
thousands of transactions per sync. So it's still enough FPs to trigger at
least one per block, often several, yet people tell us this isn't enough to
give meaningful privacy.


 Relatedly I think bitcoin could do with a store-and-forward message
 bus with privacy and strong reliability via redundancy (but less
 redundancy maybe than consensus all-nodes must receiving and agree and
 store forever).


Yup, see here:

https://www.bitcoinauthenticator.org/subspace/
https://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI

Subspace looks like it's developing into what we need.


 You seem to be saying at one point that Tor is useless against
 pervasive eavesdropper threat model


No, Tor is effective against in that threat model. What I meant is that
without Tor, someone doing wire intercepts isn't going to be fazed by using
multiple peers together, and with Tor it's not clear that syncing from
multiple peers in parallel gives much an additional win.

Also, getting Tor practical enough to activate by default is tricky. Though
the same people who are doing Subspace are trying it out to see what
happens.

secondly that other types of attackers are disinterested (how do we know
 that?) or maybe that you
 dont care about privacy vs them (maybe some users do!)


Some of my opinions are based on experience of HTTPS deployments, where
many of the same issues apply.


 It would certainly be nice to get real privacy from a wider range of
 attackers but nothing (current situation) is clearly worse; using
 block bloom filters we'd make the pervasive case harder work, and the
 nosy full node learn nothing.


Yes, but what's the best way to fix that?

The calculation goes like this:  we have ~80 hours of hacking time to spend
on privacy this quarter. Do we:

a) Do wire encryption
b) Make Bloom filter clients smarter
c) Optimise Tor
d) Do a new PIR protocol from scratch and possibly run out of time having
failed to launch

Of these (d) is the least appealing to me, especially because I don't feel
like submitting SPV related stuff to Bitcoin Core any more. If I were to
work on the protocol it'd be in the context of Bitcoin XT, which rules out
consensus changes or other things that rely on miners. Wire encryption
would probably raise the bar for our spooky friends quite a lot, with
minimal effort. The ROI looks good, compared to more complex PIR.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin ATM

2015-02-20 Thread Mike Hearn
Hi Fikret,

This is the wrong mailing list for such questions. Most Bitcoin ATM's are
commercial products anyway and don't accept contributors. If you find one
that is different, it's better to contact them directly.



On Fri, Feb 20, 2015 at 5:19 PM, Fikret AKIN i...@fikretakin.com wrote:

 Hello,

 I want to improve the Bitcoin ATM, which way do you think I should
 continue Do you have suggestions?





 Thanks,

 Fikret AKIN




 --
 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=190641631iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Mike Hearn
Ah, I see, I didn't catch that this scheme relies on UTXO commitments
(presumably with Mark's PATRICIA tree system?).

If you're doing a binary search over block contents then does that imply
multiple protocol round trips per synced block? I'm still having trouble
visualising how this works. Perhaps you could write down an example run for
me.

How does it interact with the need to download chains rather than
individual transactions, and do so without round-tripping to the remote
node for each block? Bloom filtering currently pulls down blocks in batches
without much client/server interaction and that is useful for performance.

Like I said, I'd rather just junk the whole notion of chain scanning and
get to a point where clients are only syncing headers. If nodes were
calculating a script-(outpoint, merkle branch) map in LevelDB and allowing
range queries over it, then you could quickly pull down relevant UTXOs
along with the paths that indicated they did at one point exist. Nodes can
still withhold evidence that those outputs were spent, but the same is true
today and in practice this doesn't seem to be an issue.

The primary advantage of that approach is it does not require a change to
the consensus rules. But there are lots of unanswered questions about how
it interacts with HD lookahead and so on.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Mike Hearn

 This is talking about a committed bloom filter. Not a committed UTXO set.


I read the following comment to mean it requires the UTXO commitments.
Otherwise I'm not sure how you prove absence of withholding with just
current block structures+an extra filter included in the block:

but with the bloom commitment (and UTXO trie organised commitment) he
 can verify that the positive hits are correct via the merkle path, and
 that the false positives are not being wrongly withheld by obtaining
 merkle path proof that they are not in the trie
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Mike Hearn

 So now they ask a full node for merkle paths + transactions for the
 addresses from the UTXO set from the block(s) that it was found in.


This is the part where I get lost. How does this improve privacy? If I have
to specify which addresses are mine in this block, to get the tx data, the
node learns which addresses are mine at this point, no?

Also, are you saying each block needs a record of the entire UTXO set at
the time the block was made? I'm not sure how to parse this sentence.

Could you please walk me through precisely what happens and what data is
sent, once I learn that a block has interesting data in it?
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Mike Hearn

 It's a straight forward idea: there is a scriptpubkey bitmap per block
 which is committed. Users can request the map, and be SPV confident
 that they received a faithful one. If there are hits, they can request
 the block and be confident there was no censoring.


OK, I see now, thanks Gregory. You're right, the use of UTXO set in that
context was confusing me.

If I go back to when we first did Bloom filtering and imagine the same
proposal being made, I guess I would have been wondering about the
following issues. Perhaps they have solutions:

1. Miners have to upgrade to generate the per-block filters. Any block that
doesn't have such a filter has to be downloaded in full, still. So it would
have taken quite a while for the bandwidth savings to materialise.

2. If checking the filter isn't a consensus rule, any miner who builds a
wrong filter breaks the entire SPV userbase. With per-node filtering, a
malicious or wrong node breaks an individual sync, but if the wallet user
notices they don't seem to be properly synchronised they can just press
Rescan chain and most likely get fixed. In practice broken nodes have
never been reported, but it's worth considering.

3. Downloading full blocks is still a lot of data. If you have a wallet
that receives tips a couple of times per day, and you open your wallet once
per week, then with 1mb blocks you would be downloading ~14mb of data each
time. Pretty pokey even on a desktop. Much sadness if you're on mobile.

4. Header size is constant, but per-block filters wouldn't be. So even the
null sync would download more data as the network got busier. Of course
Bloom filtering has the same scaling problem, but only between hard disk -
RAM - CPU rather than across the network.

5. Is it really more private? Imagine we see a hit in block 100, so we
download the full block and find our transaction. But now we must also
learn when that transaction is spent, so we can keep the wallet-local UTXO
set up to date. So we scan forward and see another hit in block 105, so now
we download block 105. The remote node can now select all transactions in
block 105 that spend transactions in block 100 and narrow down which txs
are ours. If we are watching a wallet that does multi-sends then it feels
like this problem gets much worse.



I'd really like to find a solution that has O(1) scaling on sync. If we see
nodes just as sources of UTXO data then shovelling the client (tx, existing
merkle path) pairs keyed off script prefixes would (with one additional
index) be O(1) and provide the same security guarantees as Bloom filtering
today. It creates lots of other problems to solve, but at least it would
scale into the forseeable future.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-19 Thread Mike Hearn

 He didn't said a project for all possible language bindings, just
 java bindings. Other languages' bindings would be separate projects.


Yes/no/sorta.

Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as
dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages
like Scala, Kotlin, Ceylon, etc.

It makes more sense to talk about bindings to particular runtimes these
days, rather than particular languages.
--
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=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-13 Thread Mike Hearn

  history. Lots of miners have dropped out due to hardware obsolescence,
 yet
  massive double spending hasn't happened.

 How many thousands of BTC must be stolen by miners before you'd agree
 that it has, in fact, happened?
 (https://bitcointalk.org/index.php?topic=321630.0)


Hmm. I think this is a disagreement over the term massive. I was meaning we
don't see double spending like we see carding fraud in the traditional
online payments world. We can talk about Finney attacks by linking to
specific discussions of specific events, because they are very rare, which
is why merchants generally ignore the possibility. I didn't mean the
numeric value of lost coins added up so far.
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 You can not consider the outcome resulting by replace-by-fee fraudulent,
 as it could be the world as observed by some.


Fraudulent in what sense?

If you mean the legal term, then you'd use the legal beyond reasonable
doubt test. You mined a double spend that ~everyone thinks came 5 minutes
later once? OK, that could be a fluke. Reasonable doubt. You do it 500
times in a row? Probably not a fluke.

If you mean under a technical definition then I think Tom Harding has been
researching this topic, though I've only kept half an eye on it. I guess
it's some statistical approximation of the above, i.e. sufficient to ensure
good incentives with only small false positive losses. Sort of like how the
block chain algorithm already works w.r.t orphans.
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 1. They won't be attacking Bitcoin, they will attack merchants who accept
 payments with 0 confirmations.


Which is basically all of them other than exchanges. Any merchant that uses
BitPay or Coinbase, for instance, or any physical shop.

If you want to play word games and redefine Bitcoin to be something other
than what people are actually using, go right ahead. You will win the
argument under your own definitions which nobody else is using.

In your scenario I won't be able to get hamburgers for free because people
will stop selling them for ordinary bitcoin transactions. Most will say,
you know what, just pay me with Visa instead. And a few might knuckle down
and set up some network of PKI-like trusted third parties that interacts
with the block chain in some way.

Though eventually, if that were to happen, cunning merchants will notice
that having received a transaction counter-signed by a TTP they don't
actually have to broadcast it or pay miner fees at all. They can just keep
it around in their wallet and pass it along to the next guy when they
purchase something with those coins. Eventually whoever ends up not being
able to find a matching TTP gets to be the sucker who pays all the miner
fees at once, because he is the only one who actually needs their services.
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 You can prove a doublespend instantly by showing two conflicting
 transactions both signed by thar party. This pair can be distributed as a
 proof of malice globally in seconds via a push messaging mechanism.

There have been lots of e-cash schemes proposed in the academic literature
that work like this, or variants of it. Schemes where participants are
anonymous until they double spend are popular.

Let's re-write your proposal but substituting the word notary for miner:

To profit, the *miner* would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.


That's the exact argument we're having. The assertion is that a rational
notary would kill his own business to increase his profits in the next few
hours. So you're just arguing that a notary is different to a miner,
without spelling out exactly why.

Does the notary have to make a big up front investment? If so, why is that
different to mining investment?

Is the notary non-anonymous and afraid of being charged with payment fraud?
If so, note that big miners do lots of non-anonymous things too, like
renting warehouses and importing specialised equipment.

Is it because of the big up front collateral they're meant to have lying
around? If so, how do you ensure a fluid market for notaries?
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 But, let's say, 5 years from now, some faction of miners who own
 soon-to-be-obsolete equipment will decide to boost their profits with a
 replace-by-fee pool and a corresponding wallet. They can market it as 1 of
 10 hamburgers are free if they have 10% of the total hashpower.


Yes, like any P2P network Bitcoin cannot work if a sufficiently large
number of miners decide to attack it. This is an ancient argument. It came
up the moment Bitcoin was first invented.

But this argument could have been made at any time in Bitcoin's entire
history. Lots of miners have dropped out due to hardware obsolescence, yet
massive double spending hasn't happened. Perhaps the system is not as
simple as you boil it down to be.

Anyway, what would happen in that event is within a few days some people
would stop selling Bitcoin for hamburgers, others would find workarounds,
and the fees collected from the double spends would be worth very little.
Nobody wins.

So would you take a responsibility for pushing the approach which isn't
 game-theoretically sound?


The approach is how Bitcoin has always worked.

People have been using game theory to predict the imminent demise of
Bitcoin since I first found it. Just one example:   Bitcoin will collapse
when the 50-25 BTC drop happens was promoted as a dead cert thing by game
theorists. Every miner becomes unprofitable and stops at once!

So far game theory based predictions tend to be proven wrong by reality, so
this sort of argument doesn't impress me much.

Anyway, going around this loop again is pointless. I brought up the counter
argument so people who see this thread don't mistakenly think Peter's
position is some kind of de-facto consensus about how Bitcoin should work.
Not because I love rehashing the same arguments every six months ad nauseum.
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 Are you not counting collateralized multisignature notaries? Its an
 extended version of the Greenaddress.it model.

It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.

If unconfirmed payments become flaky enough that people stop using them,
then a portion of the Bitcoin community will find workarounds like trusted
third parties, trusted hardware, whatever and will just struggle one. Other
people will look at the new tradeoffs/complexity, and decide that Bitcoin
is no longer better for them than banks.
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

  So you're just arguing that a notary is different to a miner, without
 spelling out exactly why.

I'm afraid I still don't understand why you think notaries would build long
term businesses but miners wouldn't, in this model.

I think you are saying because notaries have identity, brand awareness and
because they have big up front bonds, that means they will be trustworthy.

Well, sure. It's the same model governments use and is why being a money
transmitter in the USA is so difficult: you need to put up large sums of
money as collateral and have your fingerprints taken 48 times. *Then* you
can start advertising to get customers!

The reason mining is such a nice model is it doesn't have these sorts of
requirements.

 As notaries can be small operations . [snip] .. (almost every
 large organization in the world have some unallocated funds somewhere).

Which is it? Are notaries small operations or large operations?

I think exploring new consensus models with semi-trusted notaries is
interesting, but it's not Bitcoin.

 Depending on that which isn't guaranteed is bd, and breaking other
 people's assumptions is by itself NOT an attack if there never was a
 guarantee or even as little as an implicit understanding it is safe.

Please don't try and apply this logic in the real world :( Rephrased:

*That's a nice house. I noticed it's made of wood. I'm going to start
fires until it burns down, because there is no guarantee your house won't
burn down in future and it's important you understand that wooden houses
aren't safe. Really I'm just doing you a favour*.

Don't get me wrong. I'm all for what *you're* doing - please do continue to
research and explore alternative trust configurations! This is helpful and
useful work. Perhaps we will find something that solves the burger problem
in a way that satisfies everyone.

I'm really not a fan of Peter's approach, which is hey let's try and cause
as many problems as possible to try and prove a point, without having
created any solutions. Replace-by-fee-scorched-earth doesn't work and
isn't a solution. Miners can easily cut payment fraudsters in on the stolen
money, and as they'd need to distribute custom double-spending wallets to
make the scheme work it'd be very easy to do.

 Your also ssume people will expect the Bitcoin network to keep zero-conf
 safe forever and that Bitcoin valuation is tied to that. Given the options
 available and current state of things, I'm assuming that's wrong.

Why? You think ability to make payments in a few seconds is some irrelevant
curiousity?

Let's put it this way. If BitPay's business model evaporates tomorrow,
along with all the merchants they support, do you think that'd have any
effect on Bitcoin's value? If not, why not?
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 So anyway, in my opinion, it is actually great that Bitcoin is still
 relatively small: we have an opportunity to analyze and improve things.
 But you seem to be hostile to people who do that (and who do not share
 your opinion), which is kinda uncool.


To clarify once more, I'm all for people researching and building ways to
make Bitcoin better and safer. And debating that here is cool too.

The replace by fee patches don't do this; as you said yourself the whole
scorched earth thing makes no sense. It's not a solution to anything and
it's important people realise that.

Perhaps it will help if I spell out why this whole approach won't work (but
can easily damage bitcoin a lot along the way).

Normal Bitcoin nodes pick which transaction to put into a block by simply
selecting whichever they saw arrive first, as determined by the arrival
order of network packets. This rule is simple and has multiple advantages
for people using Bitcoin to buy and sell things.

Replace-by-fee changes this so nodes select whichever chain of unconfirmed
transactions pays the highest miner fees. Up until the point that a
transaction appears in a block, anyone can broadcast a double spend (or a
spend of an unconfirmed transaction) which pays higher fees than before,
causing that tx chain to become the candidate for chain inclusion.

Peter argues that this is stable and makes unconfirmed transactions safe
because a fraudster can buy something, walk out of the shop, and broadcast
a double spend with a higher fee. But then the merchant can re-spend the
original payment back to themselves with an *even* higher fee than that.
Then the fraudster can re-spend their double spend with an *even* higher
fee than that, and so on back and forth, until *all* the money has been
spent to miner fees. Thus the merchant loses their goods but the fraudster
has still paid in some sense because they don't get the money either.

This argument makes no sense for two reasons.

The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
double spend this button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.

The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the scorched earth. Even with no miner
collaboration, this means the big company is down the cost of the product
*but* so is the little company who lost everything. Whoever can outspend
the other wins.


We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix anyone can burn the money they
gave you after walking out of the shop.
--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Mike Hearn

 I see no fundamental difference in outcome from miner collusion in
 scorched-fee (which isn't guaranteed to pay the right pool!) and miner
 collusion in knowingly mining a doublespend transaction.

Well, they're the same thing. Replace-by-fee *is* miner collusion in
knowingly mining a double spend, just triggered in a certain way.

Remember that you aren't paying the bad pool, the bad pool is paying you.
Whichever pool benefits from the scorched earth protocol can simply pick an
address out of the transaction it perceived as starting the protocol, and
pay that.

 Zero-conf needs something else for security. A guarantee it can not be
 doublespent in the relevant time frame.

I think this is the core point which many of these debates revolve around.

No payment system provides *guarantees*, though some are stronger than
others. All they do is manage risk.
--
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] Proposal: Requiring a miner's signature in the block header

2015-02-11 Thread Mike Hearn
If you're interested in working on mining decentralisation, chipping away
at getblocktemplate support would be a better path forward. It's possible
to have decentralised pooled mining - I know it sounds like a contradiction
but it's not.

I wrote about some of the things that can be done in this blog post:

https://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hanging-fruit/
--
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] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Mike Hearn
We can certainly imagine many BIP70 extensions, but for things like
auto-filling shipping addresses, is the wallet the best place to do it? My
browser already knows how to fill out this data in credit card forms, it
would make sense to reuse that for Bitcoin.

It sounds like you want a kind of Star-Trek negotiation agent thing, where
your computer knows how to seek out the best deal because all the metadata
is standardised. Such a thing would be an interesting project, but it's
probably not best done in BIP70 given how it's deployed and used today.
Rather, I'd suggest looking at the various HTML5 data standards which would
allow merchants to advertise things like where they ship to in a machine
readable and crawlable form.
--
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


  1   2   3   4   5   6   7   >