path: root/f7/bb4bbefb8b7bedde4bde5cfb468b8b4374da2f

Return-Path: <g1liusbitcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 334F819E2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Oct 2015 15:22:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com
	[209.85.160.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EB8B63
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Oct 2015 15:22:16 +0000 (UTC)
Received: by ykec126 with SMTP id c126so66093281yke.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 10 Oct 2015 08:22:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=lu2TanMaN3WAOCZLlkiCkKMqiZJgu59JSb2022pvQ2M=;
	b=DY9GocKVnYA68rb6VGAhlDlVtB0BoCoSkuBwi023jd+HSo+jgL50RM3q70lfhBGhfv
	qEDrhR1Y/MPyRdlBzkLe7LvT2NgDLA7YLwrO7BOh0Qx8bVcyTvIzqpCfa5bZopDd/4wc
	tANZ9Lp21LdVOfMliPU2MqFwiuk+3puKu3pYS81sNa074+G1sEIy5V9cAKEY3w3opjdI
	7I2iSaadVlMbDPr0XzSt8gIX4RjERrXa2w2DFDHDWrVRbJFY0FkF+hQfqmvRrqmTaGxe
	8nFt4weKdUe0EKdK0SI/k6JQeZH+x62sbPHAirsK/wJkkWRGpPWDyrQHJonxX7Q8gu/V
	UFHw==
MIME-Version: 1.0
X-Received: by 10.129.145.86 with SMTP id i83mr9029087ywg.101.1444490535782;
	Sat, 10 Oct 2015 08:22:15 -0700 (PDT)
Received: by 10.37.17.67 with HTTP; Sat, 10 Oct 2015 08:22:15 -0700 (PDT)
Date: Sat, 10 Oct 2015 17:22:15 +0200
Message-ID: <CAHK+0KQvwZhrCO8gQyXP0JW061dLQC2tLBCjcCXRjCrPzAdEiw@mail.gmail.com>
From: G1lius Caesar <g1liusbitcoin@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114f86e044503c0521c1a936
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Bitcoin dev meeting in layman's terms (2015-10-8)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2015 15:22:18 -0000

--001a114f86e044503c0521c1a936
Content-Type: text/plain; charset=UTF-8

Once again my attempt to summarize and explain the weekly bitcoin developer
meeting in layman's terms.
Link to last weeks layman's summarization:
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02445.html



*Disclaimer*

Please bare in mind I'm not a developer and I'd have problems coding "hello
world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try
to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone
agrees" this means everyone present in the meeting, that's not consensus,
but since a fair amount of devs are present it's a good representation.
The dev IRC and mailinglist are for bitcoin development purposes. If you
have not contributed actual code to a bitcoin-implementation, this is
probably not the place you want to reach out to. There are many places to
discuss things that the developers read, including this sub-reddit.


link to this week logs (
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1444330778.0 )
link to meeting minutes (
https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQellk/edit
)


Main topics discussed this week where:

Mempool limiting: chain limits
Low-S change
CLTV & CSV review
Creation of bitcoin discuss mailing list


**off-topic but important notice**

This issue ( https://github.com/feross/buffer/pull/81 ) has made most JS
bitcoin software vulnerable to generating incorrect public keys.
"This is an ecosystem threat with the potential to cause millions of
dollars in losses that needs higher visibility; though it's not a bitcoin
core / bitcoin network issue.
Common, critical, JS code is broken that may cause the generation of
incorrect pubkeys (among other issues). Anyone who cares for a JS
implementation should read that PR."


**Mempool limiting: chain limits**

- background

(c/p from last week)
Chain in this context means connected transactions. When you send a
transaction that depends on another transaction that has yet to be
confirmed we talk about a chain of transactions.
Miners ideally take the whole chain into account instead of just every
single transaction (although that's not widely implemented afaik). So while
a single transaction might not have a sufficient fee, a depending
transaction could have a high enough fee to make it worthwhile to mine both.
This is commonly known as child-pays-for-parent.
Since you can make these chains very big it's possible to clog up the
mempool this way.
The first unconfirmed transaction is called the ancestor and the
transactions depending on it the descendants. The total amount of
transactions is reffered to as "packages".

- since last week

As said in "Chain limits" last week Morcos did write a proposal about
lowering the default limits for transaction-chains.
2 use cases came up which are currently in use or happened before:
As example: someone buys bitcoin from a website and can spend those bitcoin
in the marketplace of the same website without waiting for confirmation in
order to improve the bitcoin user-experience. This leaves a sequential
transaction chain. They don't need to chain more than 5 transactions deep
for this, and it falls within the proposed limits.
What's not within the proposed limits is the chain of +/- 100 transactions
a company had during the spam-attacks. These where simply increased
activities by end-users while not enough UTXO's where available (3 to be
precise)(UTXO: unspent transaction output, an output that can be used as
input for a new transaction).
Notably this is with the best practices of using confirmed transactions
first.
Ways this can be solved from the company's end is to have more UTXO's
available before hand, bundling transactions (which requires delaying
customer's request) or using replace-by-fee to add payees (which saves
blockchain space, is cheaper in fees and gets transactions through quicker,
but is not widely deployed by miners atm).
Bare in mind these proposals are for default values for the memorypool, not
in any way hard limits.


- meeting comments

Sense of urgency. Quoting sipa: "my mempool is 2.5G... we better get some
solution!"
Current attack analysis assumes child-pays-for-parent mining, it should
probably be done again without.
Higher limits on number of transactions increase attack-vectors.
Proposed number of transactions gets some push-back, total size limit not.
Mixing default values (for example having a 50% of a 10/10 limit and 50% of
a 100/100 limit) wastes bandwidth while there are too many factors that
limit utility of long chains as well.
25 transaction limit ought to be enough for everyone (for now).

- meeting conclusion

Review & test "Limit mempool by throwing away the cheapest txn and setting
min relay fee to it" ( https://github.com/bitcoin/bitcoin/pull/6722 )
Provide support for "Lower default limits for tx chains" (
https://github.com/bitcoin/bitcoin/pull/6771 ) aka convince people 25
should be enough.



**Low-S change**

- background

This is in regards to the recent malleability attack. Which is caused by a
value 'S' in the ECDSA signature which can be 2 values, a high and low
value and still be valid. Resulting in different transaction id's. more
info:
http://blog.coinkite.com/post/130318407326/ongoing-bitcoin-malleability-attack-low-s-high
A solution for this is to require nodes to have the "low-s" encoding for
signatures.
Downside is that it will block most transactions made by sufficiently out
of date software (+/- pre-march 2014)
This does not replace the need for BIP62, it only eliminates the cheap DOS
attack.


- meeting comments

95% of transactions already confirm to this, and more fixes have been
applied since.
BlueMatt has a node which several people are running that auto-malleates to
low-s transactions.
Questions whether we release it ASAP or wait for the next release and get
it to a couple of miners in the meantime (possibly with
auto-lowS-malleating)


- meeting conclusion

Contact miners about "Test LowS in standardness, removes nuisance
malleability vector" ( https://github.com/bitcoin/bitcoin/pull/6769 )
Release scheduled for the end of the month, together with likely
check-lock-time-verify and possibly check-sequence-verfiy.



**CLTV & CSV backport review**

- background

CLTV: checkLockTimeVerify
CSV: checkSequenceVerify
Both new time-related OP-codes.
Been discussed heavily last week.


- meeting comments

CSV doesn't seem ready enough for release later this month.
There's no clarity on how things look when all 3 time related pull-requests
are merged.
There's a number of people still reviewing the pull-requests.
Uncertainty and confusion about whether the semantics are final or not (in
regards to using bits from nSequence). nSequence are 4 bytes intended for
sequencing time-locked transactions, but this never got used.
Now these bytes are being repurposed for a mixture of things. Currently the
plan is: " bits 0..15 are the relative locktime, bit 30 determines units
(0: height, 1: time w/ 512s granularity), and bit 31 toggles BIP 68 (0: on,
1: off). bits 16..29 are masked off and can take any value."

- meeting conclusion

Clarification from maaku regarding nSequence for BIP68. (after the meeting
he explained he was waiting for opinions, but not enough people seemed to
know the issue at hand)
Continue review of pull requests 6312 (
https://github.com/bitcoin/bitcoin/pull/6312 ), 6564 (
https://github.com/bitcoin/bitcoin/pull/6564 ) and 6566 (
https://github.com/bitcoin/bitcoin/pull/6566 )


**Creation of bitcoin discuss mailing list**

- background

The bitcoin-dev mailing list is intented for technical discussions only.
There's things that don't belong there but need to be discussed anyway.
Now this is done in bitcoin-dev, but the volume of this is getting too big.

There's recently also an influx of really inappropriate posts, level
kindergarden (
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02539.html
).


- meeting comments

No clarity about who are the moderators.
Next week there'll be a bitcoin-discuss list created.
Decisions are needed as to who'll become the moderators for that and
bitcoin-dev.
Decisions are needed as to what will be the list and moderation policies.


- meeting conclusion

The bitcoin-discuss list will be created as well as a simple website
listing all the lists and corresponding policies.
A meeting is scheduled on monday to discuss the moderation and policies of
said lists.


**Participants**

morcos           Alex Morcos
gmaxwell         Gregory Maxwell
wumpus           Wladimir J. van der Laan
sipa             Pieter Wuille
BlueMatt         Matt Corallo
btcdrak          btcdrak
petertodd        Peter Todd
warren           Warren Togami
phantomcircuit   Patrick Strateman
dstadulis        Daniel Stadulis
GreenIsMyPepper  ?? Jospeh Poon ??
bsm117532        Bob McElrath

--001a114f86e044503c0521c1a936
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Once again my attempt to summarize and explain the we=
ekly bitcoin developer meeting in layman&#39;s terms. =C2=A0</div><div>Link=
 to last weeks layman&#39;s summarization: <a href=3D"https://www.mail-arch=
ive.com/bitcoin-dev@lists.linuxfoundation.org/msg02445.html">https://www.ma=
il-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02445.html</a> =C2=
=A0</div><div><br></div><div><br></div><div>*Disclaimer*</div><div><br></di=
v><div>Please bare in mind I&#39;m not a developer and I&#39;d have problem=
s coding &quot;hello world!&quot;, so some things might be incorrect or pla=
in wrong. =C2=A0=C2=A0</div><div>Like any other write-up it likely contains=
 personal biases, although I try to stay as neutral as I can. =C2=A0</div><=
div>There are no decisions being made in these meetings, so if I say &quot;=
everyone agrees&quot; this means everyone present in the meeting, that&#39;=
s not consensus, but since a fair amount of devs are present it&#39;s a goo=
d representation. =C2=A0</div><div>The dev IRC and mailinglist are for bitc=
oin development purposes. If you have not contributed actual code to a bitc=
oin-implementation, this is probably not the place you want to reach out to=
. There are many places to discuss things that the developers read, includi=
ng this sub-reddit.</div><div><br></div><div><br></div><div>link to this we=
ek logs ( <a href=3D"http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/0=
8#l1444330778.0">http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/08#l1=
444330778.0</a> ) =C2=A0</div><div>link to meeting minutes ( <a href=3D"htt=
ps://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv-FyneHjQell=
k/edit">https://docs.google.com/document/d/1hCDuOBNpqrZ0NLzvgrs2kDIF3g97sOv=
-FyneHjQellk/edit</a> )</div><div><br></div><div><br></div><div>Main topics=
 discussed this week where: =C2=A0 =C2=A0</div><div><br></div><div>Mempool =
limiting: chain limits =C2=A0</div><div>Low-S change =C2=A0</div><div>CLTV =
&amp; CSV review =C2=A0</div><div>Creation of bitcoin discuss mailing list<=
/div><div><br></div><div><br></div><div>**off-topic but important notice**<=
/div><div><br></div><div>This issue ( <a href=3D"https://github.com/feross/=
buffer/pull/81">https://github.com/feross/buffer/pull/81</a> ) has made mos=
t JS bitcoin software vulnerable to generating incorrect public keys. =C2=
=A0</div><div>&quot;This is an ecosystem threat with the potential to cause=
 millions of dollars in losses that needs higher visibility; though it&#39;=
s not a bitcoin core / bitcoin network issue.</div><div>Common, critical, J=
S code is broken that may cause the generation of incorrect pubkeys (among =
other issues). Anyone who cares for a JS implementation should read that PR=
.&quot;</div><div><br></div><div><br></div><div>**Mempool limiting: chain l=
imits**</div><div><br></div><div>- background</div><div><br></div><div>(c/p=
 from last week) =C2=A0</div><div>Chain in this context means connected tra=
nsactions. When you send a transaction that depends on another transaction =
that has yet to be confirmed we talk about a chain of transactions.=C2=A0</=
div><div>Miners ideally take the whole chain into account instead of just e=
very single transaction (although that&#39;s not widely implemented afaik).=
 So while a single transaction might not have a sufficient fee, a depending=
 transaction could have a high enough fee to make it worthwhile to mine bot=
h.</div><div>This is commonly known as child-pays-for-parent. =C2=A0</div><=
div>Since you can make these chains very big it&#39;s possible to clog up t=
he mempool this way. =C2=A0=C2=A0</div><div>The first unconfirmed transacti=
on is called the ancestor and the transactions depending on it the descenda=
nts. The total amount of transactions is reffered to as &quot;packages&quot=
;. =C2=A0</div><div><br></div><div>- since last week</div><div><br></div><d=
iv>As said in &quot;Chain limits&quot; last week Morcos did write a proposa=
l about lowering the default limits for transaction-chains. =C2=A0</div><di=
v>2 use cases came up which are currently in use or happened before: =C2=A0=
=C2=A0</div><div>As example: someone buys bitcoin from a website and can sp=
end those bitcoin in the marketplace of the same website without waiting fo=
r confirmation in order to improve the bitcoin user-experience. This leaves=
 a sequential transaction chain. They don&#39;t need to chain more than 5 t=
ransactions deep for this, and it falls within the proposed limits. =C2=A0=
=C2=A0</div><div>What&#39;s not within the proposed limits is the chain of =
+/- 100 transactions a company had during the spam-attacks. These where sim=
ply increased activities by end-users while not enough UTXO&#39;s where ava=
ilable (3 to be precise)(UTXO: unspent transaction output, an output that c=
an be used as input for a new transaction).</div><div>Notably this is with =
the best practices of using confirmed transactions first. =C2=A0</div><div>=
Ways this can be solved from the company&#39;s end is to have more UTXO&#39=
;s available before hand, bundling transactions (which requires delaying cu=
stomer&#39;s request) or using replace-by-fee to add payees (which saves bl=
ockchain space, is cheaper in fees and gets transactions through quicker, b=
ut is not widely deployed by miners atm). =C2=A0</div><div>Bare in mind the=
se proposals are for default values for the memorypool, not in any way hard=
 limits.</div><div><br></div><div><br></div><div>- meeting comments</div><d=
iv><br></div><div>Sense of urgency. Quoting sipa: &quot;my mempool is 2.5G.=
.. we better get some solution!&quot; =C2=A0</div><div>Current attack analy=
sis assumes child-pays-for-parent mining, it should probably be done again =
without. =C2=A0</div><div>Higher limits on number of transactions increase =
attack-vectors. =C2=A0</div><div>Proposed number of transactions gets some =
push-back, total size limit not. =C2=A0</div><div>Mixing default values (fo=
r example having a 50% of a 10/10 limit and 50% of a 100/100 limit) wastes =
bandwidth while there are too many factors that limit utility of long chain=
s as well. =C2=A0</div><div>25 transaction limit ought to be enough for eve=
ryone (for now).</div><div><br></div><div>- meeting conclusion</div><div><b=
r></div><div>Review &amp; test &quot;Limit mempool by throwing away the che=
apest txn and setting min relay fee to it&quot; ( <a href=3D"https://github=
.com/bitcoin/bitcoin/pull/6722">https://github.com/bitcoin/bitcoin/pull/672=
2</a> ) =C2=A0 =C2=A0</div><div>Provide support for &quot;Lower default lim=
its for tx chains&quot; ( <a href=3D"https://github.com/bitcoin/bitcoin/pul=
l/6771">https://github.com/bitcoin/bitcoin/pull/6771</a> ) aka convince peo=
ple 25 should be enough.</div><div><br></div><div><br></div><div><br></div>=
<div>**Low-S change**</div><div><br></div><div>- background</div><div><br><=
/div><div>This is in regards to the recent malleability attack. Which is ca=
used by a value &#39;S&#39; in the ECDSA signature which can be 2 values, a=
 high and low value and still be valid. Resulting in different transaction =
id&#39;s. more info: <a href=3D"http://blog.coinkite.com/post/130318407326/=
ongoing-bitcoin-malleability-attack-low-s-high">http://blog.coinkite.com/po=
st/130318407326/ongoing-bitcoin-malleability-attack-low-s-high</a></div><di=
v>A solution for this is to require nodes to have the &quot;low-s&quot; enc=
oding for signatures. =C2=A0</div><div>Downside is that it will block most =
transactions made by sufficiently out of date software (+/- pre-march 2014)=
 =C2=A0</div><div>This does not replace the need for BIP62, it only elimina=
tes the cheap DOS attack.</div><div><br></div><div><br></div><div>- meeting=
 comments</div><div><br></div><div>95% of transactions already confirm to t=
his, and more fixes have been applied since. =C2=A0</div><div>BlueMatt has =
a node which several people are running that auto-malleates to low-s transa=
ctions. =C2=A0</div><div>Questions whether we release it ASAP or wait for t=
he next release and get it to a couple of miners in the meantime (possibly =
with auto-lowS-malleating)</div><div><br></div><div>=C2=A0</div><div>- meet=
ing conclusion</div><div><br></div><div>Contact miners about &quot;Test Low=
S in standardness, removes nuisance malleability vector&quot; ( <a href=3D"=
https://github.com/bitcoin/bitcoin/pull/6769">https://github.com/bitcoin/bi=
tcoin/pull/6769</a> ) =C2=A0=C2=A0</div><div>Release scheduled for the end =
of the month, together with likely check-lock-time-verify and possibly chec=
k-sequence-verfiy.</div><div><br></div><div><br></div><div><br></div><div>*=
*CLTV &amp; CSV backport review**</div><div><br></div><div>- background</di=
v><div><br></div><div>CLTV: checkLockTimeVerify =C2=A0</div><div>CSV: check=
SequenceVerify =C2=A0</div><div>Both new time-related OP-codes. =C2=A0</div=
><div>Been discussed heavily last week.</div><div><br></div><div><br></div>=
<div>- meeting comments</div><div><br></div><div>CSV doesn&#39;t seem ready=
 enough for release later this month. =C2=A0</div><div>There&#39;s no clari=
ty on how things look when all 3 time related pull-requests are merged. =C2=
=A0</div><div>There&#39;s a number of people still reviewing the pull-reque=
sts. =C2=A0</div><div>Uncertainty and confusion about whether the semantics=
 are final or not (in regards to using bits from nSequence). nSequence are =
4 bytes intended for sequencing time-locked transactions, but this never go=
t used.</div><div>Now these bytes are being repurposed for a mixture of thi=
ngs. Currently the plan is: &quot; bits 0..15 are the relative locktime, bi=
t 30 determines units (0: height, 1: time w/ 512s granularity), and bit 31 =
toggles BIP 68 (0: on, 1: off). bits 16..29 are masked off and can take any=
 value.&quot;</div><div><br></div><div>- meeting conclusion</div><div><br><=
/div><div>Clarification from maaku regarding nSequence for BIP68. (after th=
e meeting he explained he was waiting for opinions, but not enough people s=
eemed to know the issue at hand) =C2=A0=C2=A0</div><div>Continue review of =
pull requests 6312 ( <a href=3D"https://github.com/bitcoin/bitcoin/pull/631=
2">https://github.com/bitcoin/bitcoin/pull/6312</a> ), 6564 ( <a href=3D"ht=
tps://github.com/bitcoin/bitcoin/pull/6564">https://github.com/bitcoin/bitc=
oin/pull/6564</a> ) and 6566 ( <a href=3D"https://github.com/bitcoin/bitcoi=
n/pull/6566">https://github.com/bitcoin/bitcoin/pull/6566</a> )</div><div><=
br></div><div><br></div><div>**Creation of bitcoin discuss mailing list**</=
div><div><br></div><div>- background</div><div><br></div><div>The bitcoin-d=
ev mailing list is intented for technical discussions only. There&#39;s thi=
ngs that don&#39;t belong there but need to be discussed anyway. =C2=A0</di=
v><div>Now this is done in bitcoin-dev, but the volume of this is getting t=
oo big. =C2=A0</div><div>There&#39;s recently also an influx of really inap=
propriate posts, level kindergarden ( <a href=3D"https://www.mail-archive.c=
om/bitcoin-dev@lists.linuxfoundation.org/msg02539.html">https://www.mail-ar=
chive.com/bitcoin-dev@lists.linuxfoundation.org/msg02539.html</a> ).</div><=
div><br></div><div><br></div><div>- meeting comments</div><div><br></div><d=
iv>No clarity about who are the moderators. =C2=A0</div><div>Next week ther=
e&#39;ll be a bitcoin-discuss list created. =C2=A0</div><div>Decisions are =
needed as to who&#39;ll become the moderators for that and bitcoin-dev. =C2=
=A0</div><div>Decisions are needed as to what will be the list and moderati=
on policies.</div><div><br></div><div><br></div><div>- meeting conclusion</=
div><div><br></div><div>The bitcoin-discuss list will be created as well as=
 a simple website listing all the lists and corresponding policies. =C2=A0<=
/div><div>A meeting is scheduled on monday to discuss the moderation and po=
licies of said lists.</div><div><br></div><div><br></div><div>**Participant=
s**</div><div><br></div><div>morcos =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alex=
 Morcos =C2=A0</div><div>gmaxwell =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gregory Maxwe=
ll =C2=A0</div><div>wumpus =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wladimir J. v=
an der Laan =C2=A0</div><div>sipa =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 Pieter Wuille =C2=A0</div><div>BlueMatt =C2=A0 =C2=A0 =C2=A0 =C2=A0 Matt C=
orallo =C2=A0</div><div>btcdrak =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0btcdrak =
=C2=A0</div><div>petertodd =C2=A0 =C2=A0 =C2=A0 =C2=A0Peter Todd =C2=A0</di=
v><div>warren =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Warren Togami =C2=A0</div>=
<div>phantomcircuit =C2=A0 Patrick Strateman =C2=A0</div><div>dstadulis =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Daniel Stadulis =C2=A0</div><div>GreenIsMyPepper =
=C2=A0?? Jospeh Poon ?? =C2=A0</div><div>bsm117532 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Bob McElrath =C2=A0=C2=A0</div></div>

--001a114f86e044503c0521c1a936--