Ricardo Filipe [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-05-16 to 2021-06-28
💬 Posted a total of 25 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:17:14

- reply

📅 Original date posted:2019-03-31
📝 Original message:one year seems too long. i think with the BIP-148 experience you have
we could easily get there in 6 months at most.
Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
escreveu no dia segunda, 1/04/2019 à(s) 01:33:
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip at dashjr.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to the
> price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing, weight
> calculation, and so on, the output count must be incremented by one. Prior to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero, and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip at dashjr.org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions. Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1), a
> block is reject as invalid unless all transactions it contains both declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:40:21

- reply

📅 Original date posted:2015-06-28
📝 Original message:Then demonstrate it. He has been raising quite valid points over the
maintenance of bitcoin core.
This is the same problem as the changes to consensus rules in bitcoin
core: they aren't explicitly defined for the external audience. Thus
forcing people to lobby for hard forks.
2015-06-28 21:16 GMT+01:00 Mark Friedenbach <mark at friedenbach.org>:
> Milly you are absolutely wrong as has been pointed out by numerous people
> numerous times. Your idea of how bitcoin development decision making works
> is demonstrably false. Please stop filling our inboxes with trolling
> accusations, or else this will have to become a moderated list. And no one
> wants that.
>
> On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly at bitcoins.info> wrote:
>>
>> I really don't know who has power to do what behind the scenes. From what
>> i understand, if push comes to shove, it is under the ultimate control of
>> one person who can revoke commit privileges. Maybe I am wrong about that
>> but the point is most people don't know for sure.
>>
>> You are correct about the people having the choice to download but the
>> influence of the official release is way beyond the influence of any forked
>> release. What that means in the real world is an open question and would be
>> different depending upon the specific circumstances and difficult to
>> predict. It is significant power to have control over the official release
>> at the present time. If they did not have significant power people would
>> not spend significant efforts lobbying them to make changes. Any new
>> developers hired by companies will do so because they can influence over the
>> official release since that is the only incentive.
>>
>> It seems to me that this block size fork is only the beginning of the
>> issues that will arise over the coming years. Whatever powers the core
>> maintainers have it is going to be exploited one way or another as time goes
>> on. Maybe there are enough feedback mechanisms to protect against that, I
>> don't really know.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/28/2015 3:05 PM, Patrick Murck wrote:
>>
>> Wladimir has no more or less “power” to push change to the Bitcoin Core
>> codebase than any other person with commit privileges to the GitHub repo. If
>> I’m not mistaken there are 7 people with commit privileges and five of them
>> are active. If Wladimir committed a change it could be reverted by any of
>> the others. This is by design and ensures that changes will have reached
>> some level of technical consensus before they are merged, among other
>> things.
>>
>> Furthermore even assuming the Core Maintainer commits a change to Bitcoin
>> Core (that isn’t reverted and that gets packaged up into the next code
>> release) that still doesn’t push a change to the bitcoin network. There is
>> no auto-update on Bitcoin Core so individuals and companies running Bitcoin
>> Core software have to choose to upgrade. Further still, developers that
>> maintain alternative implementations would have to decide to merge those
>> changes to the codebase they are indepently maintaining (and their users
>> would need to update, etc.).
>>
>> I understand why it might *seem* to be the case that the Core Maintainer
>> is empowered to make changes to "teh Bitcoin" but the reality is that the
>> Core Maintainer role is really about cat herding and project management of
>> Bitcoin Core the open-source software project and not the bitcoin network.
>> We’re lucky Wladimir has agreed to take on so much of the scut work to keep
>> the project moving forward.
>>
>> The process might get ugly and inefficient but that’s the cost of having
>> no wizard behind the curtain.
>>
>> -pm
>>
>> --
>> Patrick Murck
>>
>> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly at bitcoins.info) wrote:
>>
>> The core maintainer has always been in control of the consensus rules.
>> Satoshi came up with the rules and put them in there. Since then any
>> changes to any part of the code go through the core maintainer. It
>> looks to me as if people are saying it somehow changed along the way
>> because they don't want to hurt people's feeling, upset up, get them to
>> quit, etc. Sure there are checks and balances and people don't have to
>> use the main code base but if they change the consensus rules they are
>> incompatible.
>>
>> The notion that because people can download different rules and run them
>> is interesting from a theoretical perspective but that is constrained by
>> the network effect. I can say the US government is not the "decider" of
>> laws because I can vote them out, recall them, challenge things in
>> court, or secede and start my own country. You can also say the
>> judge/jury in a criminal court case is not a "decider" because the
>> president can always issue a pardon. But those points are generally not
>> useful in a practical sense.
>>
>> The issue about the developers is the tremendous influence they have to
>> veto any changes. I don't have veto power yet I have more bitcoins than
>> garzik says he has. The whole Bitcoin software development system is
>> subject to attack from just a couple of people who have this veto
>> power. With all the crying and moaning about centralization on this
>> list I would think that would be a concern.
>>
>> Russ
>>
>>
>>
>> On 6/28/2015 11:35 AM, Jorge Timón wrote:
>> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly at bitcoins.info>
>> > wrote:
>> >> I never said something was approved by garzik added something after it
>> >> was
>> >> opposed. What I said was a proposal was made and 4 people commented on
>> >> the
>> >> Github. He then tweeted there was near universal approval before most
>> >> people even heard about the subject. It was not controversial but i was
>> >> pointing out the arrogance of some of the developers. He considers the
>> >> entire universe of Bitcoin stakeholders to be a very small group of
>> >> insiders, not the entire universe of Bitcoin users. Another thing I
>> >> have
>> >> seen on Github for bitcoin.org is how some the maintainers change the
>> >> rules
>> >> on the fly. Sometimes they say a proposal had no objections so it is
>> >> approved. Other times they say a proposal has no support so it is
>> >> rejected.
>> > Ok, I misunderstood.
>> > Well, the fact is that the number of capable reviewers is quite small.
>> > If more companies hired and trained more developers to become bitcoin
>> > core developers that situation could change, but that's where we are
>> > now.
>> >
>> >> You are also trying to say that the core developers actually have
>> >> little
>> >> influence and are not "deciders" because anyone can fork the code. That
>> >> has
>> >> already been discussed at length and such an argument is faulty because
>> >> there is a constraint that your software is incompatible with everyone
>> >> else.
>> > Only if you change the consensus rules (which are, in fact, a
>> > relatively small part of the code).
>> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
>> > with the replace by fee policy, libbitcoin also changes many
>> > non-consensus things, there's code written in other languages...
>> > There's multiple counter-examples to your claim of that argument being
>> > faulty.
>> > Seriously, forking the project is just one click. You should try it
>> > out like at least 9627 other people have done.
>> > >From there, you can pay your own developers (if you don't know how to
>> > code yourself) and maybe they're also fine being insulted by you as
>> > part of the job.
>> > What you still can't do is unilaterally change the consensus rules of
>> > a running p2p consensus system, because you cannot force the current
>> > users to run any software they don't want to run.
>> >
>> >> The issue is that there is no way right now to change the consensus
>> >> rules
>> >> except to go through the core maintainer unless you get everybody on
>> >> the
>> >> network to switch to your fork. People who keep repeating that the
>> >> software
>> >> development is "decentralized because you fork the code" without
>> >> explaining
>> >> the constraints are just cultists.
>> > Please, stop the cultist crap. Maybe insulting people like that is how
>> > you got people to call you a troll.
>> > But, yes, you are right: there's no known mechanism for safely
>> > deploying controversial changes to the consensus rules
>> >
>> >> The discussion has nothing to do with who has the position now and I
>> >> never
>> >> said he has "control over the consensus rules." The maintainer has a
>> >> very
>> >> large influence way beyond anyone else. As for your claim that I want
>> >> someone hurt because I am explaining the process, that is ridiculous.
>> >> If
>> >> the Core maintainers did not have significant influence to change the
>> >> consensus rules then everybody would not be spending all this time
>> >> lobbying
>> >> them to have them changed.
>> > Well, if you don't think he has control over the consensus rules we're
>> > advancing.
>> > I think that was implied from some of your previous claims. He is no
>> > "decider" on consensus changes.
>> > Insisting on it can indeed get him hurt, so I'm happy that you're
>> > taking that back (or clarifying that really wasn't your position).
>> > Influence is very relative and not only core devs have "influence".
>> > Maybe Andreas Antonopolous has more "influence" than I have because he
>> > is a more public figure?
>> > Well, that's fine I think. I don't see the point in discussing who has
>> > how much influence.
>> >
>> >> The outside influences and stake of the developer is a relevant topic.
>> >> The
>> >> same types of things are discussed on this list all the time in the
>> >> context
>> >> of miners, users, merchants, and exchanges. Again, the developers try
>> >> to
>> >> place themselves on some kind of pedestal where they are the protectors
>> >> and
>> >> pure and everyone else (miners, users, merchants) are abusers,
>> >> spammers,
>> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made
>> >> an
>> >> issue of how many bitcoins he holds and he made that issue in the same
>> >> place
>> >> where he announces many of the technical issues. It is very relevant
>> >> that
>> >> he has a minimal stake in Bitcoin holdings yet he goes around making
>> >> major
>> >> decisions about Bitcoin and trying to dictate who is allowed to
>> >> participate
>> >> in discussions. If a core developer has minimal stake in Bitcoin yet
>> >> has
>> >> major veto power over code change that is a problem.
>> > Please, don't generalize. I don't think I put myself in any kind of
>> > pedestal.
>> > That is insulting to me and many others (you may not even know and
>> > you're insulting them).
>> > And I think my Bitcoin holdings are completely irrelevant when judging
>> > my contributions to the software: either they're good or not, and who
>> > I am or how many Bitcoins I have at any given time shouldn't matter.
>> > Again, nobody forces you to use our software, as said there's
>> > alternatives (including forking the project right now).
>> >
>> >> You are correct that you cannot give power to any person over the
>> >> Internet
>> >> which is why some kind of process needs to be developed that does not
>> >> involve trying to convince one person to make the changes or a system
>> >> that
>> >> depends on unwritten, ever-changing rules maintained by a handful of
>> >> people.
>> > Well, for now the process we have is seeking consensus, and although
>> > our definition of "uncontroversial" is very vague, I think it is quite
>> > obvious when a proposed change is not "uncontroversial" (like in the
>> > block size debate).
>> > It seems to me that any other "formal process" would imply
>> > centralization in the decision making of the consensus rules (and from
>> > there you only have to corrupt that centralized organization to
>> > destroy Bitcoin).
>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:36:11

- reply

📅 Original date posted:2015-06-01
📝 Original message:I've been following the discussion of the block size limit and IMO it
is clear that any constant block size limit is, as many have said
before, just kicking the can down the road.
My problem with the dynamic lower limit solution based on past blocks
is that it doesn't account for usage spikes. I would like to propose
another dynamic lower limit scheme:
Let the block size limit be a function of the number of current
transactions in the mempool. This way, bitcoin usage regulates the
block size limit.
I'm sorry i don't have the knowledge of the code base or time to make
simulations on this kind of approach, but nevertheless I would like to
leave it here for discussion or foster other ideas.
cheers

2023-06-07 15:35:59

- reply

📅 Original date posted:2015-05-31
📝 Original message:He also said that the equation for miners has many variables, as it
should. There is no disadvantage if the network speed is the same
between the miners. If there is a difference in network speed, the
miner is incentivized to invest in their network infrastructure.
2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
>> Yes, if you are on a slow network then you are at a (slight) disadvantage.
>> So?
>
>
> Chun mentioned that his pool is on a slow network, and thus bigger blocks
> give it an disadvantage. (Orphan rate is proportional to block size.)
> You said that no, on contrary those who make big blocks have a disadvantage.
> And now you say that yes, this disadvantage exist.
>
> Did you just lie to Chun?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:35:59

- reply

📅 Original date posted:2015-05-31
📝 Original message:2015-06-01 0:40 GMT+01:00 Pindar Wong <pindar.wong at gmail.com>:
>
>
> On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe <ricardojdfilipe at gmail.com>
> wrote:
>>
>> He also said that the equation for miners has many variables, as it
>> should. There is no disadvantage if the network speed is the same
>> between the miners.
>
>
> Hi,
>
> Is that an assumption?
no, let me rephrase: The disadvantage alex refers to only exists if
miners do not have the same network speed.
>
>> If there is a difference in network speed, the
>> miner is incentivized to invest in their network infrastructure.
>
>
> Perhaps it's best not to assume that investing in Internet network
> infrastructure's a free or open market everywhere.
Just like easy ASIC access, low price electricity, etc are not a free
and open market.
>
> p.
>
>>
>>
>> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi <alex.mizrahi at gmail.com>:
>> >> Yes, if you are on a slow network then you are at a (slight)
>> >> disadvantage.
>> >> So?
>> >
>> >
>> > Chun mentioned that his pool is on a slow network, and thus bigger
>> > blocks
>> > give it an disadvantage. (Orphan rate is proportional to block size.)
>> > You said that no, on contrary those who make big blocks have a
>> > disadvantage.
>> > And now you say that yes, this disadvantage exist.
>> >
>> > Did you just lie to Chun?
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

2023-06-07 15:31:26

- reply

📅 Original date posted:2015-03-11
📝 Original message:i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in standards as our industries have in
the past...
2015-03-11 19:04 GMT+00:00 Jim <jim618 at fastmail.co.uk>:
> The wallet words system isn't perfect for sure but it does help the user in two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
>
> I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
>
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
>
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
>
> --
> http://bitcoin-solutions.co.uk
>
> On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
>> Sigh. The wallet words system is turning into kind of a mess.
>>
>> I thought the word list is in fact not a fixed part of the spec, because
>> the entropy is a hash of the words. But perhaps I'm misunderstanding
>> something.
>>
>> The main problem regular SPV wallets have with BIP39 is that there is no
>> birth time included in the data. Therefore we must ask users to write down
>> a timestamp as well, so we know where to start rescanning the chain. It
>> sounds like the Electrum version doesn't fix this, so now we have at least
>> FIVE incompatible results from a 12 word list:
>>
>> - Electrum v2 with a version number but no date
>> - myTREZOR with no version and no date and BIP44 key derivation. Some
>> seeds I believe are now being generated with 24 words instead of 12.
>> - MultiBit HD with no version and a date in a custom form that creates
>> non-date-like codes you are expected to write down. I think BIP32 and BIP44
>> are both supported (sorta).
>> - GreenAddress with no version, no date and BIP32
>> - Other bitcoinj based wallets, with no version and a date written down
>> in normal human form, BIP32 only.
>>
>> I really hope we can recover from this somehow because otherwise all
>> wallets will have to provide the user with a complicated matrix of
>> possibilities and software combinations, and in practice many won't bother
>> so these word combinations will actually end up being wallet specific for
>> no particularly good reason, just very minor details like the presence or
>> absence of single fields.
>>
>> It feels like we somehow fell flat on our faces just before the finishing
>> line. This is deeply unfortunate. Compatibility and UX consistency is
>> important!
>>
>> Currently, I don't have any bright ideas for how to get everyone back onto
>> the same page with a fully compatible system that is acceptable to all. If
>> anyone else has suggestions, I'm all ears.
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development