<unnamed>

Public Key

npub1jkdfcglr59lwnhek94l393g0hhhaj0v5yzz3n5s3p0r9u0576sgs7373ck

Profile Code

nprofile1qqsftx5uy036zlhfmumz6lcjc58mmm7e8k2zppge6ggsh3j7860dgygpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsvv7y6h

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:32:29 UTC

- reply

📅 Original date posted:2015-08-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 4 August 2015 11:12:36 PM AEST, Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The
>mining
>> landscape is very centralized, with apparently a majority depending
>on
>> agreements to trust each other's announced blocks without validation.
>>
>And that is a problem... why?
With all due respect Gavin, large-block advocates appear to hold the position that:
* pushing individual economic actors away from running full nodes is a natural and unproblematic consequence of block size increase, as they're expected to rely on SPV
You now also appear to hold the position that:
* pushing miners to SPV mining is unproblematic
Have I misunderstood? Is one of these not an expected outcome of large blocks? I can understand the validity of either argument alone -- the assertion that we can trust miners to validate and just trust most-POW ourselves, /or/ the assertion that lack of miner validation is safe under certain circumstances. But together?
Who do you expect to actually validate large blocks if not miners, and what do you expect their incentive to do so to be?
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFABAEBCgAqBQJVwcYAIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEEWQH/Aty47q71H/ZcMMX/6qcTpOumI9h/buUfsvYA2H+
J6Al5S8JvCy3/0yMFCLmqolHoxOdWu5jwtUf/w2fepgA1RJyZItFo1EG9cJB0Cpz
JgM+2s4L/F3l4+Gea2ddjhvE5JqGS0Qh3EWaR/xy1bouq0FZjtDendmK7vFRj/oS
Gowm+g5EFBiT1XwCQQXJc9k0RxzDpPQ0ouSOXWdPUuxfQAjPyX89eQBeQzgVDtEf
zVfROZVHQuBu85rKTd32TdCNLQ0oEhAYmwgdtmJyLLgieeqHmNbaikBaVDEOvixn
S+fmnfD8CVeeXo5zKdlLZXazc5geRx97H4NMBMjTyjPzR5k=
=WG0I
-----END PGP SIGNATURE-----

2023-06-07 15:44:48 UTC

- reply

2023-06-07 15:43:10 UTC

- reply

📅 Original date posted:2015-07-23
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I've seen a lot of talk on this list debating the role of Bitcoin Core and its maintainers WRT consensus, typically focused around whether they can technically force anyone to run their code (of course, they can't.)
I've yet to see the discussion framed in terms of influence and leadership. Which is why I want to highlight:
>I believe it is the responsibility of the maintainers/developers of
>Bitcoin
>Core to create software which helps guarantee the security and
>operation of
>the Bitcoin network
Perhaps s/helps guarantee/promotes/ , but this stands out as an excellent description of Bitcoin Core's relationship to the Bitcoin network.
Defaults are powerful. Users technically /can/ compile and run any code they like, but very few even bother to change configurable settings. They just want a trusted brand ("Bitcoin Core") that does the right thing out of the box. Bitcoin Core and its maintainers play a valuable /leadership/ role for the network. Whether they can force people to run their code is uninteresting -- people trust them.
That trust is well earned, precisely because they have always promoted the operation and security of the network.
In light of this responsibility it seems unreasonable for anyone to expect Core maintainers to promote patches that endanger network consensus (e.g. user configurable consensus parameters.)
Consensus is order of business #1. If we can't all agree to use the same money then the grand experiment is resolved as a failure. Everyone has consensus parameters they'd (strongly) prefer. Somebody needs to heard us all toward using the same ones, sometimes even in the face of very high costs.
- -Gareth
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFABAEBCgAqBQJVsKPgIxxHYXJldGggV2lsbGlhbXMgPGdhY3J1eEBnbWFpbC5j
b20+AAoJEEY5w2E3jkVEZuEIAIKC9jTO33y4YC/cl1mO/+ux9YUqBlFUpuElKjNe
NLUIqPANrMV3nTjUm666Hk3tVHk8IpYLUU1pRuYBAT17d1t/2bFC4CpfpWssF9Nw
YhoYOKKVMvLUR4DRlkyhMD4YxorJ/TGiuEaFD4K/1s5uKf1+7Vj/BTi+SP+AIAIW
gTbn2CA3T4n8WjDYADE0dqcYSqzt2M1fjXB+Ld95JGLun8m+6lDPhFy/o5aGhBk6
5j86SITT9UtyyA6oaV5NNNgumcNBievnVwjTxjaWm8CBJlJ5jNpW65PQGkoSnCgz
TpYt/wZHcdSqBeNHyno9XaEBSm99Ylk3i2Z1dGQwrSsZU0Q=
=0pac
-----END PGP SIGNATURE-----

2023-06-07 15:40:12 UTC

- reply

📅 Original date posted:2015-06-25
📝 Original message:On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly at bitcoins.info>
wrote:
<snip>
> Also, the incentive for new
> developers to come in is that they will be paid by companies who want to
> influence the code and this should be considered
<snip>
> Now you are left with a broken, unwritten/unspoken process.
Your former statement is a great example of why "rough consensus and
running code" is superior to design by committee.
An argument should be assessed on its technical merit alone, not on
the number of people advancing it -- a process that would be open to
exactly the type of external manipulation you say you are concerned
about.

2023-06-07 15:39:51 UTC

- reply

📅 Original date posted:2015-06-25
📝 Original message:On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik at gmail.com> wrote:
>Miners can collude today to lower the block size limit.
Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?
You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.
Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.
* but with a safer "supermajority" than 75% please :)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2023-06-07 15:19:42 UTC

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 00:13, Mike Hearn wrote:
> I do think we need to move beyond this idea of Bitcoin being some kind
> of elegant embodiment of natural mathematical law. It just ain't so.
I haven't seen anybody arguing that it is.
Bitcoin is the elegant embodiment of /artificially contrived/
mathematical rules, which just so happen to be very useful in their
current configuration :-P
Nobody is saying those rules are immutable. Just that it isn't sensible
to undermine them by introducing imprecise and unpredictable elements
like human politics.
> Every time miners and nodes ignore a block that creates >formula() coins
> that's a majority vote on a controversial political matter
No it isn't. That's the node enforcing the protocol. It isn't a matter
of opinion, and it isn't a vote. The protocol is clearly defined: you
either follow it or you're not running a Bitcoin node. If 51% don't
follow it tomorrow /they're/ not running Bitcoin.
Contrast with your "vote to reinterpret the meaning of arbitrary blocks"
mechaism - you're free to vote either way while remaining within the
protocol. That's a /real/ vote - majority decides what the Bitcoin
protocol /and every node that follows it/ will recognise as valid.
Nothing like that currently exists. Thank $deity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140430/3e39d0ea/attachment.sig>

2023-06-07 15:19:42 UTC

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 00:13, Mike Hearn wrote:
> Every time miners and nodes ignore a block that creates >formula() coins
> that's a majority vote on a controversial political matter
Actually, there's one more thing I'd like to add. Apologies to the list,
but it bears repeating:
* rejecting a block at validation
Is /very different/ from:
* reinterpreting a block that has already passed validation
Nodes ignoring a block that creates >formula() coins is rejection at
block *validation*. That's the protocol working as it is supposed to.
It's deliberately an all-or-nothing mechanism; you can't pick and choose
which blocks you like. If 51% of the network say your block is invalid,
they're now on a different fork. The consequences are this drastic on
purpose, for stability.
Nodes reinterpreting a block that has already passed validation is
almost the polar opposite of this. They're /ignoring the protocol/ and
making up their own meaning for stuff. Sidestepping the mechanism in the
paragraph above. I would hope it'd be self evident that this is dangerous.
Adam Back is arguing practicality in this thread. I'm arguing
fundamental principle. (And, er, someone else is randomly throwing
around ad hominems, which we'll politely ignore; Mike could work for
Lucifer himself and his good ideas would still be good, and his bad
ideas would still be bad, so let's just stick to the ideas eh.)
So, fundamental principle: don't reinterpret history!
We have validation for a very good reason. Undermine it and you might as
well have an unvalidated system like Counterparty, which I wouldn't
ever trust with more than the value of a small hamburger.
If the economic majority starts reinterpreting history (through whatever
voting mechanism / side-channel you like) that completely undermines
Bitcoin's validation, and its PoW. It's worse than 51% of miners
deciding to rewrite history.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140501/cba8ecc6/attachment.sig>

2023-06-07 15:19:41 UTC

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 23:55, Mike Hearn wrote:
> If Bitcoin works correctly nobody should have to care if they consider
> themselves attackers, defenders, or little green men from Mars.
>
>
> One last time, I request that people read the white paper from 2008
> before making statements like this. If the notion of attacker was
> irrelevant to Bitcoin, it would not be mentioned in the abstract, would it?
I've read it :) The notion of an attacker is obviously relevant to
someone designing the system. It should not be relevant to someone
running a node.
I'll retire from posting on this too, I've posted way too much.
Our fundamental disagreement is simply that you think Bitcoin is, or
should be, a /democratic/ system. I think Bitcoin is, and should be, a
/trustless/ system. If we're going to resort to appeal to authority,
I'll point to the words "Electronic Cash System" in the title of
Satoshi's whitepaper :-P He intended to create ecash; that's widely
understood to mean trustless.
If there was this magic computer up in the sky somewhere, free from
human influence, that would run Satoshi's code for him in perpetuity
(let's overlook the initial upload please, bear with me), then I believe
Satoshi would've built his perfectly trustless ecash to run on that.
For lack of such a magic masterless computer he had to approximate one,
ingeniously using distributed consensus to achieve it. That's his real
invention - the "magic masterless computer" simulator, and the incentive
scheme to get the world to run it for him. (We'll see more of what it
can do if Ethereum ever gets off the ground.)
But for Pete's sake, Bitcoin is trustless. Just because the
infrastructure it sits atop is "democratic" (because there was no other
way to implement it,) doesn't mean you suddenly have to start voting on
everything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140501/afb10d09/attachment.sig>

2023-06-07 15:19:41 UTC

- reply

📅 Original date posted:2014-04-30
📝 Original message:On 30/04/14 00:26, Mike Hearn wrote:
> These parties wouldn't generally consider themselves attackers
>
>
> Of course not, attackers rarely do :)
If Bitcoin works correctly nobody should have to care if they consider
themselves attackers, defenders, or little green men from Mars. There
are simply nodes that follow the protocol, and nodes that do not.
The fact that you even need to think about who should and should not be
considered an attacker, in the context of your proposed change, should
be ringing alarm bells :)
> What do you think miners exist for?
Ordering transactions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140430/e5d8bcd3/attachment.sig>

2023-06-07 15:19:39 UTC

- reply

📅 Original date posted:2014-04-27
📝 Original message:Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.) Useful and non-controversial hard forks don't keep me awake at night :) I support your general position on zero-conf payments (that they're useful and we should make them as reliable as practical.)
But the very essence of Bitcoin, to me, is trustlessness. Satoshi's great invention isn't just another payment network - it's /ecash/. Bearer-negotiable, whoever-controls-the-private-keys-owns-it, **ecash**.
If not that, what do you think it is? :-)
I like trustless systems for purely pragmatic, cost-benefit reasons. They allow us to avoid all the costs associated with imperfect humans, while reaping the benefits of reliability and predictability :P
On 28 April 2014 12:31:05 AM AEST, Mike Hearn <mike at plan99.net> wrote:
>>
>> That moves us away from a pure trustless system built upon a small
>> democratic foundation (as something of a necessary evil in an
>imperfect
>> world where humans run our computers and use our system) and toward a
>> "democratic system".
>>
>> You don't have to agree, but I hope you can understand the point I'm
>> making :-)
>
>
>Yep, your point is well made.
>
>I don't have much more to say about this proposal specifically, but I
>think
>this whole question of what changes are OK and what would be a
>violation of
>the social contract will get discussed endlessly over the coming years.
>Put
>another way, what do Bitcoin's users expect and want - a system that
>evolves or a system that remains exactly as they found it? There will
>be
>good arguments on both sides, and the answer will probably be different
>on
>a case by case basis. But personally I'm skeptical of any argument that
>argues against change for its own sake. It has to be an argument rooted
>in
>a careful analysis of costs and benefits.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2023-06-07 15:19:39 UTC

- reply

📅 Original date posted:2014-04-27
📝 Original message:On 27/04/14 11:42, Christophe Biocca wrote:> This seems like splitting
hairs, no? A block isn't a guarantee (it can
> get orphaned). And as a user of bitcoin (as opposed to a miner), this
> change cannot affect any payment you ever receive.
Disagree. Maybe we just have a fundamental disagreement about what
Bitcoin is? :)
Bitcoin is this perfect /trustless/ mathematical machine, built - most
unfortunately - upon a foundation of mushy humans.
We depend specifically upon these three assumptions:
1. >50% of hashpower will not cooperate to rewrite history
2. the economic majority will not cooperate to reinterpret history
3. enough people believe in the illusion of artificial scarcity to give
it real value
Given that the above hold, from there up the system operates completely
trustlessly, with predictable security parameters. (Of course a block
isn't a guarantee of anything, but I know the probability that you can
cause a re-org from depth N with X% hashpower, which allows me to reason
about security.)
Now, some people on this thread might point to the above 3 points and
say "that isn't really a trustless system, it's a democratic system."
And then advocate that we can do without assumption 2, replacing it with:
2. the economic majority will not cooperate to reinterpret history
against any good guys, only against bad guys; "please trust their good
judgement."
That moves us away from a pure trustless system built upon a small
democratic foundation (as something of a necessary evil in an imperfect
world where humans run our computers and use our system) and toward a
"democratic system".
You don't have to agree, but I hope you can understand the point I'm
making :-) It's a fundamental shift in the nature of the system, and to
some people a violation of the social contract. Definitely not splitting
hairs.
I feel I've now consumed rather more bytes of everyone's inboxes than I
ought to have with this topic. I appreciate you and Mike taking the time
to reply to a newbie/lurker.
-Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140427/421557d1/attachment.sig>

2023-06-07 15:19:38 UTC

- reply

📅 Original date posted:2014-04-26
📝 Original message:On 26/04/14 01:28, Mike Hearn wrote:
> When you have a *bitcoin* TXn buried under 100 blocks you can be damn
>
> sure that money is yours - but only because the rules for interpreting
> data in the blockchain are publicly documented and (hopefully)
> immutable. If they're mutable then the PoW alone gives me no confidence
> that the money is really mine, and we're left with a much less useful
> system. This should be more sacred than the 21m limit.
>
>
> Well, I think we should avoid the term "sacred" - nothing is sacred
> because we're not building a religion here, we're engineering a tool.
Are you sure there isn't room for just a touch of "religion"? :) As you
state below, all that protects my money from confiscation is strong
group consensus that it's mine - "a social rule, not a mathematical one."
Everything ultimately balances on that. People being a little bit
"religious" about following the protocol faithfully are the linchpin of
Bitcoin security, not PoW.
> Consider a world in which 1 satoshi is too valuable to represent some
> kinds of transactions, so those transactions stop happening even though
> we all agree they're useful. The obvious solution is to change the rules
> so there can be 210 million coins and 10x everyones UTXOs at some
> pre-agreed flag day. We probably wouldn't phrase it like that, it's
> easier for people to imagine what's happening if it's phrased as "adding
> more places after the decimal point" or something, but at the protocol
> level coins are represented using integers, so it'd have to be
> implemented as a multiply.
Agree.
> Would this be a violation of the social contract? A violation of all
> that is sacred? I don't think so, it'd just be sensible engineering and
> there'd be strong consensus for that exactly because 21 million /is/ so
> arbitrary. If all balances and prices multiply 100-fold overnight, no
> wealth is reallocated which would be the /actual/ violation of the
> social contract: we just get more resolution for setting prices.
Wholeheartedly agree. "21 million" is just shorthand for the
preservation of artificial scarcity. No rational person could argue that
what you described violates the social contract.
I do see what you're driving at - that there exists a situation where it
would be justified to change the interpretation of data in existing blocks.
But, please consider: if I controlled a single UTXO worth 1% of the
total money supply before your change, the network would still recognise
that I control a single UTXO worth 1% of the total money supply after
your change. So you haven't really changed the interpretation of
existing blocks at all there. It's just semantics :)
Contrast this with invalidating a coinbase before maturity, which
clearly has a very real impact. At the point the vote passes, you're ***
sidestepping the PoW mechanism and rewriting the meaning of an existing,
validated block ***.
> So. The thing that protects your money from confiscation is not proof of
> work. PoW is just a database synchronisation mechanism. The thing that
> protects your money from confiscation is a strong group consensus that
> theft is bad. But that's a social rule, not a mathematical rule.
Agree. That's my whole point :)
I recognise my security is in the hands of the users (the economic
majority.) Tomorrow they could all decide to patch their nodes to
reallocate my UTXOs, and there's not a damn thing I could do about it,
PoW and private keys notwithstanding. I must simply trust that they will
not do this.
So we can have:
1. "Neutral Bitcoin", where everyone is committed to prevention of theft
by following a simple set of mathematical rules which treat all
validated blocks as equal.
Or:
2. "Political Bitcoin", where everyone is committed to prevention of
theft based on human judgements, and the contents of some validated
blocks are more equal than others.
I recognise that the latter allows for a lot of flexibility in combating
fraud, but with (substantial) due respect, it isn't Bitcoin.
-Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140426/c5fcc01b/attachment.sig>

2023-06-07 15:19:37 UTC

- reply

📅 Original date posted:2014-04-25
📝 Original message:On 25/04/14 00:28, Mike Hearn wrote:
> Why are we here? We are here because we were brought together by shared
> goals.
>
> What are those goals? They were defined at the start of the project by
> the creator of the project.
>
> Why do we issue 21 million coins and not 42? Because 21 million is the
> goal everyone signed up for.
Mike: the blockchain is a public document, with a very public and well
defined interpretation, which we've all signed up for too.
What's the point of piling PoW on top of some data to make it difficult
to modify if the interpretation itself is open to modification?
There is an important distinction to draw between a hard fork via a
change in block validation rules, and a hard fork via a change in the
/interpretation of the blockchain itself/.
Bitcoin validates data /before/ it makes it into a block; we can all be
confident that, short of a reorg, /if it's in a block, it's the law/. As
much as the 21m cap is the law anyway.
Proving that you can convince the economic majority that the
interpretation of existing blocks is in any way up for grabs would set a
dangerous precedent, and shake some people's faith in Bitcoin's overall
robustness and security (well, mine anyway.)
My 2 bits.
-Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/864fe1bb/attachment.sig>

2023-06-07 15:19:37 UTC

- reply

📅 Original date posted:2014-04-25
📝 Original message:On 25/04/14 20:17, Mike Hearn wrote:
> Proving that you can convince the economic majority that the
>
> interpretation of existing blocks is in any way up for grabs would set a
> dangerous precedent, and shake some people's faith in Bitcoin's overall
> robustness and security (well, mine anyway.)
>
>
> Hmm, then I think your faith needs to be shaken. Bitcoin is money, and
> money is a purely artificial social construct. The interpretation of
> what a bitcoin means, or what a dollar means, has always been and always
> will be a human decision taken in order to achieve some socially useful
> goal.
My argument does not concern what a bitcoin means, just what data in the
blockchain means. People are free to value an individual bitcoin however
they like. But it's useful if we all agree on a standard that defines
who owns them - ie. the protocol as described in Satoshi's whitepaper. I
recognise that your ability to provide a valid scriptSig for /any
existing UTXO in the blockchain/ as proof of your ownership of the
corresponding bitcoin. You want to pick and choose which UTXO (well,
coinbase; same diff) you consider valid and spendable /after they've
become part of the blockchain/, regardless of the fact they're buried
under PoW.
As an illustration, consider Counterparty - an altcoin whose TXns are
embedded as unvalidated data in the bitcoin blockchain. A lot of people
imagine that an XCP transaction buried under 100 blocks and a BTC
transaction buried under the same 100 blocks are equally secure. You
tell me: are they? It's the same PoW chain after all.
Hell no they're not! The way Counterparty interprets that data in the
blockchain is anything but stable or well documented. On more than one
occasion they've gone "whoops, found a bug that caused some transactions
to occur that we don't consider valid - we'll just fix that." A suddenly
the reference client doesn't consider the XCP in your wallet valid
anymore - they just magically disappear - because the parent of the TXn
that paid you was actually invalid. Nobody rewrote history via PoW; they
simply tweaked their interpretation of the existing history.
When you have a *bitcoin* TXn buried under 100 blocks you can be damn
sure that money is yours - but only because the rules for interpreting
data in the blockchain are publicly documented and (hopefully)
immutable. If they're mutable then the PoW alone gives me no confidence
that the money is really mine, and we're left with a much less useful
system. This should be more sacred than the 21m limit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/e6f0b788/attachment.sig>