Carsten Otto [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-26 to 2022-05-17
💬 Posted a total of 8 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:06:04

- reply

📅 Original date posted:2022-05-17
📝 Original message:
Three small updates:
1)
The most recent version of lnd-manageJ now also considers channels that
charge a base fee. In order to make this work, the worst-case scenario
is assumed (which is: a channel is used for the smallest possible amount)
and the fee rate used for the route computation is adjusted accordingly.
With the default settings (quantization 10,000sat), a channel charging a
base fee of Xsat and a fee rate of Yppm is considered with a virtual fee
rate of (Y+X*100)ppm.
This penalty is linear in the quantization amount, i.e. if you use a
quantization of 100,000sat, a base fee of Xsat only results in a
penalty of X*10ppm.
2)
I added a Dockerfile that should help with experiments.
https://github.com/C-Otto/lnd-manageJ/blob/fix-5746/Dockerfile
The only interesting requirement is that your lnd needs to be patched:
https://github.com/lightningnetwork/lnd/pull/6545
You can tweak the lnd-manageJ.conf (as demonstrated in lines 10-12), see
https://github.com/C-Otto/lnd-manageJ/blob/main/PickhardtPayments.md for
the available options.
As I was unable to figure out how to avoid TLS issues with gRPC, you
need to use "--network host" if you run lnd on localhost.
The docker image boots PostgreSQL on the default port 5432, so make sure
it is available and not in use by your host.
For your experiments please take into account that lnd-manageJ needs to
request the LN graph from lnd, which takes a few seconds. This graph is
cached for up to two minutes and, if used, refreshed before it times out.
As such, please issue a test payment (to request the graph) before
measuring the time it takes to send out any real payment.
3)
Route/hop hints provided in the payment request are now considered so that
private/virtual channels are used for the route computation. This only
works for "route hints" which contain a single hop (which should be
fine?). Each "hint" channel is added with a capacity of 50 BTC and the
algorithm is made to believe that 100% of that is available. This "known
liquidity" is not shown in the streaming NDJSON output you get via HTTP,
though, which is just a display issue which doesn't affect the route
computation.
Happy hacking,
Carsten
--
Dr. Carsten Otto
carsten at c-otto.de
https://c-otto.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220517/6f893265/attachment.sig>

2023-06-09 13:06:01

- reply

📅 Original date posted:2022-05-15
📝 Original message:
Dear all,
the most recent version of lnd-manageJ [1] now includes basic, but usable,
support for #PickhardtPayments. I kindly invite you to check out the code, give
it a try, and use this work for upcoming experiments.
Teaser with video: https://twitter.com/c_otto83/status/1525879972786749453
The problem, heavily summarized:
- Sending payments in the LN often fails, especially with larger amounts.
- Splitting a large payment into smaller shards (using MPP) is helpful,
as in general the smaller shards don't fail as often as a single large
payment would. However, the success probability also drops
exponentially with the number of channels included [2].
- Finding routes through the LN is tricky, as the channels' liquidity is
uncertain at the time of computing the routes and a simple "trial and
error" approach might take too long.
- There are several implementations using various heuristics, taking
aspects like fees, previous failures, HTLC deltas, channel age, ...
into account. Comparing these approaches is very hard.
The gist of #PickhardtPayments:
- The issue of finding MPP routes in the LN corresponds to the
well-known minimum-cost flow problem in computer science (graph
theory) with lots of related research, results, algorithms, ...
- As shown in the paper [3] the results are optimal, no matter which
"cost" function is used to reason about routing costs (fees) and/or
reliability. However, depending on the characteristics of the
function, actually finding optimal results can be extremely hard
(NP-complete in some cases). By imposing the zero base fee limitation
and assuming a uniform distribution of funds, fast implementations
(polynomial time with sub-second runtimes) can be used.
- Assuming (!) a uniform distribution of funds in each channel and zero
base fee only, #PickhardtPayments offers an approach that is optimal,
i.e. proven perfect and computationally feasible.
- The most basic version only considers uncertainty costs for
reliability, but it is possible (and implemented in lnd-manageJ) to
also consider routing costs (fee rates) and optimize for both features
to come up with reliable and cheap-ish MPPs.
- The implementation of #PickhardtPayments in lnd-manageJ needs to
ignore non-zero base fee channels to avoid extremely slow
(NP-complete) computations. Furthermore, certain aspects are
approximated [4]. As such, optimality claims are limited to the zero
base fee subset of the LN, and real-world experiments might be tricky
to interpret. However, as also shown in the testnet videos [5][6],
first results are very promising!
The real strength of #PickhardtPayments:
- Liquidity information, for example obtained by previous failures, is
taken into account. For each attempt, the relevant bits of information
are obtained and will be used to guide the following attempts.
- As the underlying algorithm is proven to be optimal, we do not need to
rely on heuristics. Instead, the algorithm happily finds routes that
may be very long (but very probable/cheap, for whatever reason), have
a surprising number of shards, or rather odd amounts.
- The underlying algorithm also deals with shared segments, i.e.
individual channels that are used for more than one shard of the MPP,
without oversaturating it.
The code in lnd-manageJ:
- Highly experimental, but it's a start!
- lnd + gRPC middleware + Java/Spring + PostgreSQL is a bit more complex
than necessary.
- Only works with lnd.
- Doesn't really work with lnd until issue #5746 [7] is fixed. I'd be
very happy for someone to have a look at my proposal (PR #6543 [8])!
- The code doesn't handle all corner cases, especially the
less-than-usual failure codes. For example, if a node decides to raise
the fee rate, the corresponding channel will be ignored for a while as
I'm too lazy to think about how to update the information in the data
structure used to compute the MPP.
- Pending shards (neither failed nor settled) just cause the whole MPP
to hang until something times out. Most likely this can't be fixed
without stuckless payments?
I'd be very happy to discuss implementation details (not on this list, I
guess?) and help with upcoming (mainnet?) benchmarks and experiments
(René Pickhardt is also interested in helping with this). Given a fix
for the blocking lnd issue, I'd be happy to let my node c-otto.de take
part in some experiments.
Last but not least, a huge thank you to René Pickhardt for lots of
insightful discussions, proof reading, and of course (together with
Stefan Richter) the actual work of coming up with #PickhardtPayments!
Best regards,
Carsten
1: https://github.com/C-Otto/lnd-manageJ/blob/main/PickhardtPayments.md
2: https://arxiv.org/abs/2103.08576
3: https://arxiv.org/abs/2107.05322
4: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003510.html
5: https://c-otto.de/pp/pp.mp4
6: https://c-otto.de/pp/lnd.mp4
7: https://github.com/lightningnetwork/lnd/issues/5746
8: https://github.com/lightningnetwork/lnd/pull/6543
--
Dr. Carsten Otto
carsten at c-otto.de
https://c-otto.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220515/d3f70c90/attachment.sig>

2023-06-09 13:05:31

- reply

📅 Original date posted:2022-03-14
📝 Original message:
Hi Rene,
On Mon, Mar 14, 2022 at 12:56:24PM +0100, René Pickhardt via Lightning-dev wrote:
> > 1) What's the reasoning behind combining parallel channels?
> I think that should work and especially when including fees to the
> cost function and considering how nodes handle routing requests on
> parallel channels we might have to do so anyway.
I think lnd accepts the minimum fee of all parallel channels, even if
a higher fee rate is configured for the channel that is actually used.
I'm not too sure about this, though. Having parallel channels with
different fee settings seems weird to me, anyway.
> 1.1) A payment of size 2 needs to be split into 1+1 to fit through
> However I believe in practice one cannot just send a 2 satoshi onion and
> expect the routing node to split the amount correctly / accordingly
> between the two parallel channels. (I might be wrong here).
Exactly. This kind of split could be possible in theory, but at least
lnd doesn't do it. I guess there are lots of interesting questions to
answer before this becomes reality (channel jamming?).
> So in that case
> modelling and computing probabilities for parallel channels might be
> necessary anyway though the math indicates that splitting liquidity in
> parallel channels will get you selected less frequently for routing.
Which is OK, as in reality it IS less likely to succeed.
> 1.2) The Mission Control information provided by lnd [...]
> I think you talk a about a maximum available balance of a channel (and not
> min available balance)?
Yes, although MC also has information about "known" amounts (due to
failures that only happened further down the road).
> In the case of parallel channels I am not even sure if such information is
> accurate as it is my understanding that the routing node may decide to use
> the parallel channel to forward the amount even though the other channel
> was specified in the onion.
The routing node is free to pick any of the parallel channels, yes. The
MC data only reasons about pairs of nodes, though, not individual
channels.
> Assuming that routing nodes indeed do so we would have learnt that neither
> channel has an effective capacity of N. So the combined virtual channel
> could be seen as 2N-1.
You mean 2(N-1) = 2N-2?
> However if routing nodes don't locally split a
> forwarding request across both channels we would know that calaculating
> with 2N-1 is bad as a request of N could not be fulfilled.
Exactly, also for 2N-2. Only N-1 would be a reasonable assumption.
Based on your responses I'll treat parallel channels individually, and
see how it works out.
> > 3) Size of Piecewise Linearization
> The main difference here is that a channel of 1 BTC is highly preferable
> from a probabilistic payment delivery perspective over a channel of 0.01
> BTC. Even approximating the 1 BTC channel with 1000 intervalls of 0.001 BTC
> should still have a lower unit cost in all pieces of the first 0.01 BTC of
> the liquidity than the first piece of the 0.01 BTC channel. So I think
> splitting all channels in the equal number of pieces is pretty well
> motivated but let me elaborate on this:
OK great, got it.
> > 4) Leftovers after Piecewise Linearization
> I am not sure if I understand your question / issue here. The splitting
> works by selecting N points on the domain of the function and splitting the
> domain into segments at those points. This should never leave sats over.
With quantization of 10,000 a channel of size 123,456 ends up as an arc
with a capacity of 12 units. Cutting this into 5 pieces gives us
5*2 with 2 units not ending up in any of those pieces. Or am I missing
something here, and we should split into 5 pieces of size 2.4 = 12/5?
> If the quantization however makes a channel so small that we cannot
> even create 5 (or N) disjoint segments then I guess the likelihood for
> being included into the final result is too small anyway.
It may not be very likely, but flat-out ignoring 20k sat (in my
contrived example above) or up to 4*quantization sats (which is the case
you described) doesn't feel right.
> Again this yield interesting pruning opportunities to reduce the seize of
> the network before doing the expensive min cost flow computation. For
> example I could prune channels with high unit costs on the first segment.
> Especially if they are further away from the source and destination node.
> This would overall reduce the size of the graph and improve runtime.
Let's talk about optimizations later :)
> 5) Fees (and other properties?)
> arcs.append((src,dest,int(cap/(N*QUANTIZATION)),(i+1)*unit_cost +
> mu*fee_rate_ppm))
Great, that helps! Thanks alot!
> Note two things:
> 1. the only requirement for the solver to work is that \mu*fee_rate_ppm
> needs to be an integer. So in case \mu was smaller than 1 we could also
> scale the term from the linearized log probabilities by putting a larger mu
> to the feature arising from the cost of the uncertainty.
Good to know!
Bye,
Carsten
--
Dr. Carsten Otto
carsten at c-otto.de
https://c-otto.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220314/2418fb43/attachment.sig>

2023-06-09 13:05:30

- reply

📅 Original date posted:2022-03-13
📝 Original message:
Hi Rene,
thanks a lot for your contribution! This is exactly what I needed to
start coding again :) I intend to release a somewhat usable version of
your approach in lnd-manageJ [1] soon. Preliminary results indicate that
results (i.e. MPPs to try) can be computed in less than a second, which
is great!
Important remark: my code can only be used for real MPPs once a usable
MPP gRPC call is made available, see lnd issue #5746 [2].
While working on my implementation, a few questions came to mind:
1) What's the reasoning behind combining parallel channels?
I agree that parallel channels make things a lot more complicated, but I
also see the benefit from a node operator's point of view. That being
said, wouldn't it suffice to treat parallel channels individually?
1.1) A payment of size 2 needs to be split into 1+1 to fit through
parallel channels of size 1+1. Combining the 1+1 channels into a virtual
channel of size 2 only complicates the code that has to do come up with
a MPP that doesn't over-saturate the actual channels. On the other hand,
I don't think the probability for the virtual channel of size 2 is more
realistic than reasoning about two individual channels and their
probabilities - but I didn't even try to see the math behind that.
Please prove me wrong? :)
1.2) The Mission Control information provided by lnd can be used to
place a minimum available balance on each of the parallel channels. If
we know that node A isn't able to forward N sats to node B, we can treat
all parallel channels between A and B (in that direction) to have a
capacity of at most N-1 sats. How would this look like if we combined
the parallel channels into a virtual one? Note that it may still be
possible to route two individual payments/onions of size N-1 sats from A
to B, given two parallel channels with that many sats on A's side.
2) Optimal Piecewise Linearization
See Twitter [3].
Is it worth it cutting a channel into pieces of different sizes, instead
of just having (as per your example) 5 pieces of the same size? If it
makes a noticeable difference, adding some complexity to the code might
be worth it.
3) Size of Piecewise Linearization
My gut feeling is that cutting a 1 BTC channel into 5 pieces is
different from cutting a 0.01 BTC channel into 5 pieces. Would it make
sense to use different values of N depending on the channel size?
4) Leftovers after Piecewise Linearization
If I cut some channel into N pieces, I might end up with up to N-1 sats
that don't end up in any of the N pieces, effectively making the channel
look smaller than it is. For smaller values of N that's obviously not an
issue (given the uncertainty we're dealing with), but it might be more
problematic if quantization is used with larger values. Any thoughts on
this?
5) Fees (and other properties?)
How can we integrate fees into the function? I must admit, I haven't
even thought about that, yet. A copy-paste answer would be great,
though! :) Maybe it's also a good idea to punish channels based on their
CLTV delta? Ratio of enabled channels? Age? Manual punishment score? ...
6) Non-Zero Base Fee
See Twitter [4].
According to Stefan [5] it should be possible to integrate ZmnSCPxj's ideas
to make this work with non-zero base fees. How?
Simpler approach: Twitter [6].
7) Private Channels
[very niche topic, not really that interesting nor urgent]
I'm a fan of adding private channels to provide more outbound liquidity,
mainly to reduce gossip and hide my intentions. If my total liquidity to
some peer is below the amount announced in public channels, I don't see
any meaningful complication. However, I might have a public channel of
size N and several private channels bringing my local liquidity to some
value >N. It's rather obvious that not announcing this fact is a bad
idea, as any #pickhardtpayments implementation would think I have 0-N on
my side of the channel(s). Assuming I'm willing to accept this tradeoff,
do you see other complications or issues with hidden liquidity?
My gut feeling is that this isn't an issue, at all, as channel balances
change all the time, which is something the algorithm already has to
deal with.
8) Quality of Approximation
There are some problems in computer science that are hard/impossible to
approximate, in the sense that any kind of deviation from the optimum
could cause the computed results to be extremely bad. Do you have some
idea (or proof) that your kind of approximation isn't causing a major
issue? I guess a piece-wise linearization with an infinite number of
pieces corresponds to the optimal result. Given a finite number of
pieces, how large is the difference to the optimum?
Bye,
Carsten
1: https://github.com/C-Otto/lnd-manageJ/issues/6
2: https://github.com/lightningnetwork/lnd/issues/5746
3: https://twitter.com/c_otto83/status/1502329970349248521
4: https://twitter.com/c_otto83/status/1502329271964033027
5: https://twitter.com/stefanwouldgo/status/1502681455918473217
6: https://twitter.com/c_otto83/status/1502330558793363464
--
Dr. Carsten Otto
carsten at c-otto.de
https://c-otto.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220313/1437e67a/attachment.sig>

2023-06-09 12:50:22

- reply

📅 Original date posted:2018-05-03
📝 Original message:
Hey Christian,
On Thu, May 03, 2018 at 12:51:01PM +0200, Christian Decker wrote:
> The setup transaction is simply a transaction that spends some funds and
> creates a single output, which has the script from Figure 2, but since
> that would be a forward reference, I decided to handwave and call it a
> multisig. A simple fix would be to change the setup phase bullet point
> at the beginning of section 3, would that be sufficient?
A first clarification, which just regards the naming, would be to use
just one of "setup transaction" and "funding transaction". The symbol
T_{u,0} is only used once, on page 6. I'd either remove it, or used it
in other places (Fig. 1?), too.
Without your mail (thanks!) I did not see that the setup transaction
output is complicated (has branches) as shown in Fig. 2. A clarification
at the named bullet point would indeed help (although I see the issue of
forward references).
One idea (just to get my idea across, I'm sure you can do better):
old: "to a 2-of-2 multisig address"
new: "to a script making use of 2-of-2 multisig"
> If instead of calling it a multisig we call it a multiparty output and
> reference the script in Figure 2, that'd be addressed as well.
I agree.
> Well, it has arbitrary inputs, and a single output with the script from
> Figure 2, in the non-trigger case, and in the trigger case it'd be just
> a `2 A B 2 OP_CMSV`.
Got it. Follow up question: would a second output (change) be OK? I see
some advantages, but I'm not sure if it would work.
Thanks
Carsten
--
andrena objects ag
Ganghoferstraße 70
80339 München
http://www.andrena.de
Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger
Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
http://www.andrena.de/events
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180503/e1f0770c/attachment.sig>

2023-06-09 12:50:21

- reply

📅 Original date posted:2018-05-03
📝 Original message:
Hi ZmnSCPxj, Christian, list,
the paper is a bit confusing regarding the setup transaction, as it is
not described formally. There also seems to be a mixup of "setup
transaction" and "funding transaction", also named T_{u,0} without
showing it in the diagrams.
In 3.1 the funding transaction is described as funding "to a multisig
address". In the description of trigger transactions the change is
described as "The output from the setup transaction is changed into a
simple 2-of-2 multisig output" - which it already is?
As far as I understand the situation, the trigger transaction is needed
because the broadcasted initial/funding/setup transaction includes an
OP_CLV, which then starts the timer and could lead to premature
settlement. Removing OP_CLV (and having in a transaction that is only
published later when it is needed), i.e. by changing it to a simple
multisig output, seems to solve this issue.
Could you (Christian?) explain how the "setup transaction" is supposed
to look like without the changes described in section 4.2?
I like the idea proposed by ZmnSCPxj, but I'm not able to weigh the
pro/cons of both approaches. For a direct unilateral close both peers
would need to know the first update transaction and an attached
settlement transaction, which is comparable to the approach presented in
the paper (trigger transaction and settlement transaction).
The main advantage of getting rid of the trigger transaction seems to be
that only two transactions (latest update and settlement) have to be
committed to the blockchain in the unilateral case, compared to three
(trigger, latest update, settlement) in the approach presented in the
paper. As a minor advantage the peers do not need to remember the
trigger transaction.
Bye,
Carsten
--
andrena objects ag
Ganghoferstraße 70
80339 München
http://www.andrena.de
Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger
Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
http://www.andrena.de/events
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180503/118d50e1/attachment.sig>

2023-06-09 12:50:21

- reply

📅 Original date posted:2018-05-03
📝 Original message:
Hi ZmnSCPxj, Christian, list,
the paper is a bit confusing regarding the setup transaction, as it is
not described formally. There also seems to be a mixup of "setup
transaction" and "funding transaction", also named T_{u,0} without
showing it in the diagrams.
In 3.1 the funding transaction is described as funding "to a multisig
address". In the description of trigger transactions the change is
described as "The output from the setup transaction is changed into a
simple 2-of-2 multisig output" - which it already is?
As far as I understand the situation, the the trigger transaction is
needed because the broadcasted initial/funding/setup transaction
includes an OP_CLV (possibly enforcing premature settlement). Removing
OP_CLV, i.e. by changing it to a simple multisig output, seems to solve
this issue.
Could you (Christian?) explain how the "setup transaction" is supposed
to look like without the changes described in section 4.2?
I like the idea proposed by ZmnSCPxj, but I'm not able to weigh the
pro/cons of both approaches. For a direct unilateral close both peers
would need to know the first update transaction and an attached
settlement transaction, which is comparable to the approach presented in
the paper (trigger transaction and settlement transaction).
The main advantage of getting rid of the trigger transaction seems to be
that only two transactions (latest update and settlement) have to be
committed to the blockchain in the unilateral case, compared to three
(trigger, latest update, settlement) in the approach presented in the
paper.
Bye,
Carsten
--
andrena objects ag
Ganghoferstraße 70
80339 München
http://www.andrena.de
Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
Aufsichtsratsvorsitzender: Rolf Hetzelberger
Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
http://www.andrena.de/events
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180503/571cf9bf/attachment.sig>

2023-06-07 15:39:53

- reply

📅 Original date posted:2015-06-26
📝 Original message:Dear all,
On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
The URL is dead, and the BIP moved here:
https://github.com/gavinandresen/bips/blob/blocksize/bip-0101.mediawiki
Corresponding Pull Request:
https://github.com/bitcoin/bips/pull/163/
Best regards,
Dr. Carsten Otto
--
andrena objects ag
Büro Frankfurt
Clemensstr. 8
60487 Frankfurt
Tel: +49 (0) 69 977 860 38
Fax: +49 (0) 69 977 860 39
http://www.andrena.de
Vorstand: Hagen Buchwald, Matthias Grund, Dr. Dieter Kuhn
Aufsichtsratsvorsitzender: Rolf Hetzelberger
Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824
Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
http://www.andrena.de/events
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/610fc0e7/attachment.sig>