[Bitcoin-development] BIP process

[Bitcoin-development] BIP process

[Gavin Andresen]

Amir started the "get more formal about changes to bitcoin" ball
rolling by creating BIP 0001, starting from the Python "PEP" /
BitTorrent "BEP" processes:
  https://en.bitcoin.it/w/index.php?title=BIP_0001

The idea is to use BIPs for changes that may or will affect every
bitcoin implementation (not to use them for proposed changes to one
particular implementation).

I'd like to propose some minor changes to the process:

• I propose that BIPs be wiki pages, with a social convention that the
Author gets final word if any editing wars break out.

• If he's willing, I propose that Amir take the role of BIP editor.

• I think bitcoin is still too small to have a specialized
"bitcoin-ideas" mailing list; I propose that new potential BIPs be
discussed either here or on the bitcoin-dev mailing list.

What do y'all think?

-- 
--
Gavin Andresen

Re: [Bitcoin-development] BIP process

[Nils Schneider]

> • I propose that BIPs be wiki pages, with a social convention that the
> Author gets final word if any editing wars break out.

That's a good idea. What about using GitHub's Wiki feature for BIPs?
They support MarkDown which is easy to read in text editors so we could
someday create a repo with all finalized BIPs. That's a lot easier than
importing a mediawiki dump. The last time en.bitcoin.it went down I
tried to setup a static mirror and that was nearly impossible without a
full LAMP stack. Also, BIPs should only contain images when absolutely
necessary.

> • If he's willing, I propose that Amir take the role of BIP editor.

ack

> • I think bitcoin is still too small to have a specialized
> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
> discussed either here or on the bitcoin-dev mailing list.

ack

Re: [Bitcoin-development] BIP process

[Alex Waters]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

>
>
> • I propose that BIPs be wiki pages, with a social convention that the
> Author gets final word if any editing wars break out.


ACK

>

• If he's willing, I propose that Amir take the role of BIP editor.
>
> ACK


> • I think bitcoin is still too small to have a specialized
> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
> discussed either here or on the bitcoin-dev mailing list.
>

ACK

As for what Nils mentioned on using GitHub's Wiki feature, Gavin seems to
have started a few proposals at
https://github.com/gavinandresen/bitcoin-git/wiki. I think this is the right
direction to head in, and a composite list of similar proposals could be
maintained on their own repository (to maintain separation from the core
Bitcoin repo.)

-Alex

[-- Attachment #2: Type: text/html, Size: 1482 bytes --]

Re: [Bitcoin-development] BIP process

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters <ampedal@gmail.com> wrote:

>
>> • I propose that BIPs be wiki pages, with a social convention that the
>> Author gets final word if any editing wars break out.
>
>
> ACK
>
Does it have to be wiki pages if we're going through an editorial process
anyway, and there will be few who can actually edit the pages directly? I'd
go for simple HTML documents in a repository.

>
>
> • If he's willing, I propose that Amir take the role of BIP editor.
>>
>> ACK
>
ACK

>
>
>> • I think bitcoin is still too small to have a specialized
>> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
>> discussed either here or on the bitcoin-dev mailing list.
>>
>
> ACK
>
Definitely. I don't think too many requests will come right away, and by
posting them here we make sure that the most knowledgeable people are there
to check and improve what might eventually end up in the clients.

>
> As for what Nils mentioned on using GitHub's Wiki feature, Gavin seems to
> have started a few proposals at
> https://github.com/gavinandresen/bitcoin-git/wiki. I think this is the
> right direction to head in, and a composite list of similar proposals could
> be maintained on their own repository (to maintain separation from the core
> Bitcoin repo.)
>
> -Alex
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3749 bytes --]

[Bitcoin-development] BIP process

[Wladimir]

Hello,

I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.

A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on changes to be
merged.

Currently all BIP changes have to go through the Bitcoin Core team,
which is a narrow bottleneck and makes little sense when you think
about it. But I don't want to go back to the wiki state in which
everyone can make arbitrary changes to any BIP - we need to distribute
the process somehow.

I'd like to propose to make the author (or someone they delegate to)
the primary contact for each BIP. They should comment on changes, and
either accept or reject them. If they accept them, the change will be
merged.

Of course this means that there is a responsibility for the author to
adhere to BIP 1. For example if your BIP is final, don't allow any
technical changes. To do small clarifications, spelling or adding
implementations or examples is OK, but changing or adding to a
protocol is not - this needs a new BIP. Changing your BIP status
without community consensus is also not OK.

B) I also think it makes sense to move the BIP discussion (both about
the BIP process and individual BIPs) to a separate mailing list.

bitcoin-development currently has a dual function: discussion of
Bitcoin Core implementation concerns, as well as global changes to
Bitcoin (in the form of BIPs).

This makes the list too busy for some people, but it is critical that
everyone writing a Bitcoin node or client is up-to-date with proposals
and can comment on them.

Wladimir

Re: [Bitcoin-development] BIP process

[Gregory Maxwell]

On Wed, Oct 15, 2014 at 8:29 AM, Wladimir <laanwj@gmail.com> wrote:
> Hello,
>
> I'm trying to create a bit of process around the
> https://github.com/bitcoin/bips repository.
>
> A) Currently a lot of pulls are open for various BIPs and it is not
> clear who should comment on them, or who decides on changes to be
> merged.
>
> Currently all BIP changes have to go through the Bitcoin Core team,
> which is a narrow bottleneck and makes little sense when you think
> about it. But I don't want to go back to the wiki state in which
> everyone can make arbitrary changes to any BIP - we need to distribute
> the process somehow.
>
> I'd like to propose to make the author (or someone they delegate to)
> the primary contact for each BIP. They should comment on changes, and
> either accept or reject them. If they accept them, the change will be
> merged.
>
> Of course this means that there is a responsibility for the author to
> adhere to BIP 1. For example if your BIP is final, don't allow any
> technical changes. To do small clarifications, spelling or adding
> implementations or examples is OK, but changing or adding to a
> protocol is not - this needs a new BIP. Changing your BIP status
> without community consensus is also not OK.
>
> B) I also think it makes sense to move the BIP discussion (both about
> the BIP process and individual BIPs) to a separate mailing list.
>
> bitcoin-development currently has a dual function: discussion of
> Bitcoin Core implementation concerns, as well as global changes to
> Bitcoin (in the form of BIPs).
>
> This makes the list too busy for some people, but it is critical that
> everyone writing a Bitcoin node or client is up-to-date with proposals
> and can comment on them.


This all makes a lot of sense to me, and would help a lot with the
workflow.  Unfortunately github pulls and issues really have nothing
to faciltate a multistage workflow... e.g. where something can go
through several steps.

We're also having problems with people failing to comment on things,
not even "I looked at this and have no opinion", which is really
obstructing things.

Re: [Bitcoin-development] BIP process

[Wladimir]

> This all makes a lot of sense to me, and would help a lot with the
> workflow.  Unfortunately github pulls and issues really have nothing
> to faciltate a multistage workflow... e.g. where something can go
> through several steps.

Indeed, pull requests don't have a "status".
It would be possible to (ab)use labels for this.

The drawback of labels is that only the repository team can set these,
there is no way to delegate. But I suppose it'd be possible to build
something on top of the github API that handles this.

> We're also having problems with people failing to comment on things,
> not even "I looked at this and have no opinion", which is really
> obstructing things.

Well - the only way to avoid that is to set a reasonable deadline,
after which there is a default decision. You'd hope this would
motivate people to get involved in time.

Wladimir

Re: [Bitcoin-development] BIP process

[Cory Fields]

Sounds like this is what you're after, it's a fairly new feature:
https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments

I've been meaning to use it in a PR to try it out.

Cory

On Wed, Oct 15, 2014 at 5:36 AM, Wladimir <laanwj@gmail.com> wrote:
>> This all makes a lot of sense to me, and would help a lot with the
>> workflow.  Unfortunately github pulls and issues really have nothing
>> to faciltate a multistage workflow... e.g. where something can go
>> through several steps.
>
> Indeed, pull requests don't have a "status".
> It would be possible to (ab)use labels for this.
>
> The drawback of labels is that only the repository team can set these,
> there is no way to delegate. But I suppose it'd be possible to build
> something on top of the github API that handles this.
>
>> We're also having problems with people failing to comment on things,
>> not even "I looked at this and have no opinion", which is really
>> obstructing things.
>
> Well - the only way to avoid that is to set a reasonable deadline,
> after which there is a default decision. You'd hope this would
> motivate people to get involved in time.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP process

[Thomas Zander]

On Wednesday 15. October 2014 11.36.58 Wladimir wrote:
> > We're also having problems with people failing to comment on things,
> > not even "I looked at this and have no opinion", which is really
> > obstructing things.
> 
> Well - the only way to avoid that is to set a reasonable deadline,
> after which there is a default decision. You'd hope this would
> motivate people to get involved in time.

I have been part of both the OSI (NEN) and the OASIS standards committees for 
a while, working on standards as a technical adviser.

There I learned a lot about how to manage this process, maybe some ideas from 
such committees can be useful.

The idea that one person owns a BIP makes total sense, (s)he is the only one 
that should be putting forward the BIP when its mature enough for making it 
final. Note that this can be already after its been implemented once or twice.

So you have a phase where you have random people propose changes, which should 
all go in the public mailinglist, and they can be accepted by the owner 
without discussion.
If anyone that sees that change has an objection to the change, (s)he speaks 
up and you follow group consensus. This means (and this is actually in an ISO 
standard ;) that consensus is reached when nobody is left objecting to the 
change.

At some point the BIP is mature enough to vote on, at the discretion of the 
owner, and the owner puts it forward and requests a vote. If the above process 
was handled cleanly there is a very small chance of it being down-voted so an 
actual vote may not be needed (its hard to decide who gets a vote..).
You obviously need a deadline for this and afterwards you mark the proposal 
final. Or you close it as "needs more work".
-- 
Thomas Zander

Re: [Bitcoin-development] BIP process

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

RE: process:

I like author == primary control, and an "assume they will do the right
thing, revert if they don't"

RE: separate mailing list for BIP discussion:

Great idea. Jeff Garzik was looking for a better mailing list solution than
SourceForge, but assuming
there isn't a clearly better solution I think "we" should create a strictly
moderated bitcoin-bips@lists.sourceforge list.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 703 bytes --]

Re: [Bitcoin-development] BIP process

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

>
> Great idea. Jeff Garzik was looking for a better mailing list solution
> than SourceForge, but assuming
> there isn't a clearly better solution I think "we" should create a
> strictly moderated bitcoin-bips@lists.sourceforge list.
>

Let's stay away from SF.net or any mailman-controlled lists if at all
possible. They break DKIM signatures which means they're no longer
compatible with Yahoo, all mail from Yahoo users gets spamfoldered
immediately. Google Groups gets this right. Perhaps other list operators do
too. Groups also has moderation features.

[-- Attachment #2: Type: text/html, Size: 886 bytes --]

Re: [Bitcoin-development] BIP process

[Adam Back]

please not google groups *, I'd vote for sourceforge or other simple
open list software over google groups.

Adam

* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe with a non-google
address if google has any hint that your address is associated with a
gmail account.  Quite frustrating.

On 15 October 2014 16:46, Mike Hearn <mike@plan99.net> wrote:
>> Great idea. Jeff Garzik was looking for a better mailing list solution
>> than SourceForge, but assuming
>> there isn't a clearly better solution I think "we" should create a
>> strictly moderated bitcoin-bips@lists.sourceforge list.
>
>
> Let's stay away from SF.net or any mailman-controlled lists if at all
> possible. They break DKIM signatures which means they're no longer
> compatible with Yahoo, all mail from Yahoo users gets spamfoldered
> immediately. Google Groups gets this right. Perhaps other list operators do
> too. Groups also has moderation features.
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] BIP process

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Wed, Oct 15, 2014 at 04:54:57PM +0100, Adam Back wrote:
> please not google groups *, I'd vote for sourceforge or other simple
> open list software over google groups.
> 
> Adam
> 
> * Google lists are somehow a little proprietary or gmail lockin
> focused eg it makes things extra hard to subscribe with a non-google
> address if google has any hint that your address is associated with a
> gmail account.  Quite frustrating.

I'll second that request. Something mailman based; don't particularly
care where it's hosted.

After all, one of the big advantages of open mailing lists is that
multiple third-parties can easily provide archives, for instance
www.mail-archive.com

-- 
'peter'[:-1]@petertodd.org
00000000000000000a91d3bbf16d2b80e142f98e6ff45b615f668dba558a4413

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] BIP process

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

I don't care much what exact list software/service is used, but lists.sf.net
hasn't changed in years and is basically dying. Trashing all @yahoo
accounts because ancient mailman does a MITM attack on people's email is no
good, it's not any better than a web proxy that breaks every SSL
connection. For a project that is based on digital signatures, it's really
bad that the mailing list is incompatible with Yahoo's "mail signatures
must be valid" policy.

Plus its moderation features suck, its mail archiving features suck, etc.
It essentially has no redeeming features at all.

mail-archive.com can be easily used with any mailing list, so not sure why
that's brought up. You just add it as a member, as documented here:
http://www.mail-archive.com/faq.html#newlist

[-- Attachment #2: Type: text/html, Size: 1045 bytes --]

Re: [Bitcoin-development] BIP process

[Thomas Zander]

On Wednesday 15. October 2014 20.13.11 Mike Hearn wrote:
> Plus its moderation features suck, its mail archiving features suck, etc.
> It essentially has no redeeming features at all.

Other than it being open source, an open platform with no lock-in 'features' 
and it works with everyone that uses the standards properly.
Naturally, if an old version fails to function with Yahoo, I'm all for finding 
a different provider. Thats what open platforms, like Mailman, are about.

-- 
Thomas Zander

Re: [Bitcoin-development] BIP process

[Oliver Egginger]

15.10.2014 at 20:13 Mike Hearn wrote:
> For a project that is based on digital signatures, it's really
> bad that the mailing list is incompatible with Yahoo's "mail signatures
> must be valid" policy.

# Mailman: Do not break existing DKIM signatures
DEFAULT_SUBJECT_PREFIX  = ""
DEFAULT_MSG_HEADER = ""
DEFAULT_MSG_FOOTER = ""

Maybe you should remove these settings. They make little sense and cause
apparently problems for some recipients.

Also the mail body must not be altered through advertising or something
else.

- oliver

Re: [Bitcoin-development] BIP process

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Wed, Oct 15, 2014 at 4:54 PM, Adam Back <adam@cypherspace.org> wrote:

> please not google groups *, I'd vote for sourceforge or other simple
> open list software over google groups.
>

Please not sourceforge.


> * Google lists are somehow a little proprietary or gmail lockin
> focused eg it makes things extra hard to subscribe with a non-google
> address if google has any hint that your address is associated with a
> gmail account.  Quite frustrating.


Mailman is good enough...

[-- Attachment #2: Type: text/html, Size: 968 bytes --]

Re: [Bitcoin-development] BIP process

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
> > * Google lists are somehow a little proprietary or gmail lockin
> > focused eg it makes things extra hard to subscribe with a non-google
> > address if google has any hint that your address is associated with a
> > gmail account.  Quite frustrating.
> 
> 
> Mailman is good enough...

I used these guys for awhile to host a small mailman list with
absolutely no issues. Just $5/month for 1000 subscribers.

https://www.mailmanlist.net/

-- 
'peter'[:-1]@petertodd.org
000000000000000019e75ca8667f175b61a41ad950d15b61d83d3faf1a128f94

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] BIP process

[Luke Dashjr]

On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote:
> On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
> > > * Google lists are somehow a little proprietary or gmail lockin
> > > focused eg it makes things extra hard to subscribe with a non-google
> > > address if google has any hint that your address is associated with a
> > > gmail account.  Quite frustrating.
> > 
> > Mailman is good enough...
> 
> I used these guys for awhile to host a small mailman list with
> absolutely no issues. Just $5/month for 1000 subscribers.
> 
> https://www.mailmanlist.net/

I've been using http://lists.nongnu.org/ for BFGMiner announce/dev mailing 
lists for a while. I don't know what software it runs, but it works.

Catch is that we'd need to go through Savannah's free software auditing.
That might be a good idea anyway?

Luke

Re: [Bitcoin-development] BIP process

[xor]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
> B) I also think it makes sense to move the BIP discussion (both about
> the BIP process and individual BIPs) to a separate mailing list.
> 
> bitcoin-development currently has a dual function: discussion of
> Bitcoin Core implementation concerns, as well as global changes to
> Bitcoin (in the form of BIPs).
> 
> This makes the list too busy for some people, but it is critical that
> everyone writing a Bitcoin node or client is up-to-date with proposals
> and can comment on them.

I joined the list when Bitcoin was already in the 10-billions of market 
capitalization, and it actually really surprised me how low the traffic is here 
given the importance of Bitcoin.

So as a random stranger to the project, I would vote against that if I was 
allowed to. There really should be *more* discussion here, and splitting the 
list up won't help with that.

Greetings

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] BIP process

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Sun, Oct 19, 2014 at 8:17 AM, xor <xor@freenetproject.org> wrote:

> I joined the list when Bitcoin was already in the 10-billions of market
> capitalization, and it actually really surprised me how low the traffic is
> here
> given the importance of Bitcoin.
>
> So as a random stranger to the project, I would vote against that if I was
> allowed to. There really should be *more* discussion here, and splitting
> the
> list up won't help with that.


I agree. This is also where the best peer review is to be found. Splitting
the list will dilute this.

[-- Attachment #2: Type: text/html, Size: 889 bytes --]

Re: [Bitcoin-development] BIP process

[Wladimir]

On Sun, Oct 19, 2014 at 9:17 AM, xor <xor@freenetproject.org> wrote:

> So as a random stranger to the project, I would vote against that if I was
> allowed to. There really should be *more* discussion here, and splitting the
> list up won't help with that.

The problem is not one of traffic, but of confusion of concerns, and of focus.

That specific questions about Bitcoin Core are being asked, for
example about watch-only functionality, in the same list where changes
to the entire system (BIPs) should be decided on doesn't make sense.

This has in practice caused some developers of alternative clients to
not subscribe to this list, even though they *should* follow BIP
discussion otherwise it makes no sense to have a process in the first
place.

Wladimir

Re: [Bitcoin-development] BIP process

[Thomas Zander]

On Sunday 19. October 2014 09.17.51 xor wrote:
> I joined the list when Bitcoin was already in the 10-billions of market 
> capitalization, and it actually really surprised me how low the traffic is
> here  given the importance of Bitcoin.

I gather that actual code changes to bitcoin-core and naturally all the other 
clients are already done in another place. Which is likely the reason for your 
impression.
 
> So as a random stranger to the project, I would vote against that if I was 
> allowed to. There really should be *more* discussion here, and splitting
> the  list up won't help with that.

I agree with your stance that more discussion in public is always good.

Lets allow people that work on bitcoin java, or completely other bitcoin based 
stuff to have a simple way to filter out the topics they are interested in.
Mailinglist handling is pretty trivial in practically all email software, 
people can equally trivially subscribe to multiple lists as their interests 
go.

As a long time open source developer, my experience is that more lists has 
never really caused fragmentation in the way that you fear.

Re: [Bitcoin-development] BIP process

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Earlier in the discussion I suggested Discourse so that the BIP page
would be able to look smoother and draw more input.
Unsystem forum is run on Discourse and has twitter, github, and e-mail
integration.
For those who haven't explored it, here is what that looks / feels like:
https://forum.unsystem.net/

I'm curious as to why this sort of solution should or should not be
considered from someone else's perspective. In the end, whatever
works best for all concerned, I'm fine with it, but I'd like to hear
more about people's thoughts on Discourse. (I kind of like the feel
of it.)

xor wrote:
> On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
>> B) I also think it makes sense to move the BIP discussion (both 
>> about the BIP process and individual BIPs) to a separate mailing
>>  list.
>> 
>> bitcoin-development currently has a dual function: discussion of 
>> Bitcoin Core implementation concerns, as well as global changes 
>> to Bitcoin (in the form of BIPs).
>> 
>> This makes the list too busy for some people, but it is critical
>>  that everyone writing a Bitcoin node or client is up-to-date 
>> with proposals and can comment on them.
> 
> I joined the list when Bitcoin was already in the 10-billions of 
> market capitalization, and it actually really surprised me how low
>  the traffic is here given the importance of Bitcoin.
> 
> So as a random stranger to the project, I would vote against that 
> if I was allowed to. There really should be *more* discussion here,
> and splitting the list up won't help with that.
> 
> Greetings
> 
> 
> 
> ------------------------------------------------------------------------------
>
>
>
> 
Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month. Get alerted through email, SMS, 
> voice calls or mobile push notifications. Take corrective actions 
> from your mobile device. http://p.sf.net/sfu/Zoho
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJURFhXAAoJEGxwq/inSG8Cpc0H+wZauz7iOj4XZJSI3VBv+5WL
YAe8kDSOpa5ZprFntsFfKVU+cmSjXckPjCRI9+LsrfTR2L+VjAimjQTct1m6oRAo
+5ZQ8Tn2CLEVRJRUzd8zbW8QPMuQCdzvwjs1oq8anaAPdwseEC/QhTZY6Av1MB8y
nH+05mMu4YeF3RRIyjXgvxDiBBK3knoaBkbsORkVbIb7MojUBy7FnsS1JFmSs8wv
XwWnkmFjVlhC8wSQYohcTWdJablxjpKRFq1ZNgDtIoXEi0dsC+G9Gc+8xub4hA/Y
nDk85ihX17TBbB47SOJEAdpGrJjkb8OvdX2ubLnQPYth82wX/MWJTTdv2a4JGik=
=uYGH
-----END PGP SIGNATURE-----