Daniel Robinson [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-10-14 to 2018-02-21
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:10:58

- reply

📅 Original date posted:2018-02-20
📝 Original message:Yes, although it's a functionality of Bitcoin Script generally, not OP_CSV
in particular. Bitcoin Script allows you to use nested IF statements, and
enforce whatever different conditions you want in each branch.
Here's your contract in Ivy <https://ivy-lang.org/bitcoin/>:
contract MultiCSV(
bob: PublicKey,
carol: PublicKey,
bobDelay: Duration,
carolDelay: Duration,
val: Value
) {
clause bobSpend(sig: Signature) {
verify checkSig(bob, sig)
verify older(bobDelay)
unlock val
}
clause carolSpend(sig: Signature) {
verify checkSig(carol, sig)
verify older(carolDelay)
unlock val
}
clause bothSpend(bobSig: Signature, carolSig: Signature) {
verify checkMultiSig([bob, carol], [bobSig, carolSig])
unlock val
}
}
It compiles to the following Bitcoin Script:
PUSH(carolKey) PUSH(bobKey) 2 PICK 2 EQUAL IF ROT DROP 0 4 ROLL 4 ROLL 2
2ROT 2 CHECKMULTISIG ELSE ROT IF DROP CHECKSIGVERIFY PUSH(carolDelay)
CHECKSEQUENCEVERIFY DROP 1 ELSE NIP CHECKSIGVERIFY PUSH(bobDelay)
CHECKSEQUENCEVERIFY DROP 1 ENDIF ENDIF
On Tue, Feb 20, 2018 at 5:32 PM Praveen Baratam via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Everybody,
>
> I need a little clarity about how OP_CHECKSEQUENCEVERIFY (CSV) works in
> transactions.
>
> Can I use multiple CSV end points as depicted in the figure below? I
> basically want to allow different conditions at different delays.
>
> [image: Multi CSV.png]
>
> I just want to know if OP_CHECKSEQUENCEVERIFY can be used to achieve the
> above.
>
> Thank you.
>
> Praveen
> ᐧ
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180221/c8f680ea/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Multi CSV.png
Type: image/png
Size: 119739 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180221/c8f680ea/attachment-0001.png>

2023-06-07 18:10:50

- reply

📅 Original date posted:2018-02-13
📝 Original message:Custom open-source licenses are basically never a good idea. Every
deviation in wording from universally-accepted open-source licensing terms
is a major compliance headache from the perspective of any organization
trying to use the software. You don’t want users having to clear their use
of Bitcoin Core through their employers’ legal departments, whether or not
they would ultimately approve that use. For that reason alone I think such
a change is not viable, no matter how you phrased it.
On Tue, Feb 13, 2018 at 9:27 AM Adam Ficsor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I agree with the opposition on changing the license, because of the
> branding attacks.
>
> However having two coins with the same Proof Of Work is a zero sum game
> from a security point of view. It may not be a bad idea to consider
> changing the license in a way that only limits cryptocurrencies with the
> same Proof Of Work, since they directly affect the stability and security
> of Bitcoin.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180213/3c912384/attachment.html>

2023-06-07 18:09:45

- reply

📅 Original date posted:2018-01-15
📝 Original message:Hi Matt,
Thanks for raising this. Since the compiler only produces SegWit addresses,
I hadn't worried at all about malleability, but as you pointed out
out-of-band, malleability in the length of an argument can allow an
attacker to deflate the feerate of a transaction.
There was in fact a minor witness malleability problem with how the
compiler was handling clause selection. It's now been fixed in version
0.0.7 of the compiler.
As far as I can tell (and I haven't looked all that carefully), any
sensible Ivy contract won't have any witness malleability problem. (A funny
exception is the RevealCollision contract, since you can length-extend the
arguments to get another collision. But without a signature check, that one
has a more serious transaction malleability problem anyway.) But the
compiler currently doesn't prevent you from doing dumb unconstrained stuff
like:
```
clause spend(a: Bytes, b: Bytes, sig: Signature) {
verify a == b
verify checkSig(publicKey, sig)
unlock val
}
```
Maybe it should, particularly since there's no reason to include a trivial
condition like that anyway. But I think it would probably be about as easy
(and more generally useful) to build a static analyzer that solved this
problem for low-level Bitcoin Script.
On Sun, Jan 14, 2018 at 5:42 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> I'm curious if you've considered adding some form of compiler-time
> enforcement to prevent witness malleability? With that, Ivy could help to
> resolve for it's users one of the things that can make Bitcoin scripts more
> complicated to write, instead of simply type-checking and providing a
> high-level language mapped 1-to-1 with Bitcoin script.
>
>
> On December 18, 2017 8:32:17 PM UTC, Daniel Robinson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Today, we’re releasing Ivy, a prototype higher-level language and
>> development environment for creating custom Bitcoin Script programs. You
>> can see the full announcement here
>> <https://blog.chain.com/ivy-for-bitcoin-a-smart-contract-language-that-compiles-to-bitcoin-script-bec06377141a>,
>> or check out the docs <https://docs.ivy-lang.org/bitcoin/> and source
>> code <https://github.com/ivy-lang/ivy-bitcoin>.
>>
>> Ivy is a simple smart contract language that can compile to Bitcoin
>> Script. It aims to improve on the useability of Bitcoin Script by adding
>> affordances like named variables and clauses, static (and domain-specific)
>> types, and familiar syntax for function calls.
>>
>> To try out Ivy, you can use the Ivy Playground for Bitcoin
>> <https://ivy-lang.org/bitcoin/>, which allows you to create and test
>> simulated contracts in a sandboxed environment.
>>
>> This is prototype software intended for educational and research purposes
>> only. Please don't try to use Ivy to control real or testnet Bitcoins.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180115/ee189ac5/attachment.html>

2023-06-07 18:08:54

- reply

📅 Original date posted:2017-12-18
📝 Original message:Today, we’re releasing Ivy, a prototype higher-level language and
development environment for creating custom Bitcoin Script programs. You
can see the full announcement here
<https://blog.chain.com/ivy-for-bitcoin-a-smart-contract-language-that-compiles-to-bitcoin-script-bec06377141a>,
or check out the docs <https://docs.ivy-lang.org/bitcoin/> and source code
<https://github.com/ivy-lang/ivy-bitcoin>.
Ivy is a simple smart contract language that can compile to Bitcoin Script.
It aims to improve on the useability of Bitcoin Script by adding
affordances like named variables and clauses, static (and domain-specific)
types, and familiar syntax for function calls.
To try out Ivy, you can use the Ivy Playground for Bitcoin
<https://ivy-lang.org/bitcoin/>, which allows you to create and test
simulated contracts in a sandboxed environment.
This is prototype software intended for educational and research purposes
only. Please don't try to use Ivy to control real or testnet Bitcoins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171218/88572040/attachment-0001.html>

2023-06-07 17:59:26

- reply

📅 Original date posted:2017-04-06
📝 Original message:I think you're misreading Luv. He's defending the idea of blocking covert
ASICBOOST, not defending ASICBOOST.
On Thu, Apr 6, 2017 at 11:16 AM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Apr 6, 2017 at 2:30 PM, Luv Khemani via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Just to add on to the ethical issue of blocking this.
> >
> >
> > If blocking the covert form of ASICBOOST is seen as unethical, then the
> same can be said about libsecp256k1, various client optimisations,
> Compactblocks.
>
> This is simply a non sequitur. These optimizations benefit users. On
> the other hand, asicboost doesn't benefit users in any way, it only
> benefits some miners if and only if not all miners use it. It
> obviously harms the miners that aren't using it by making them less
> profitable (maybe to the point that they lose money).
> If all miners use it or if no one of them uses it is equivalent from
> the point of view of the user. In fact, the very fact of allowing it
> makes the network less secure unless every single honest miner uses
> it, for an attacker could use it against the network.
>
> Even if asicboost was good for users in any way (which as explained
> isn't), this proposal doesn't disable it, only the covert form that
> cannot be proven to be used.
>
> Therefore there's no rational arguments to oppose this proposal unless
> you are (or are invested in):
>
> A) A Miner currently using the covert form of asicboost.
>
> B) A Miner planning to use the covert form of asicboost soon.
>
> C) An attacker using or planning to use the covert form of asicboost.
>
> > All of which seek to reduce the efficacy of large miners and selfish
> mining.
>
> Asicboost doesn't seek this and doesn't help with this in any way.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/f688b993/attachment.html>

2023-06-07 17:54:14

- reply

📅 Original date posted:2016-11-03
📝 Original message:Really cool!
How about "poison transactions," the other covenants use case proposed by
Möser, Eyal, and Sirer? (I think OP_CHECKSIGFROMSTACKVERIFY will also make
it easier to check fraud proofs, the other prerequisite for poison
transactions.)
Seems a little wasteful to do those two "unnecessary" signature checks, and
to have to construct the entire transaction data structure, just to verify
a single output in the transaction. Any plans to add more flexible
introspection opcodes to Elements, such as OP_CHECKOUTPUTVERIFY?
Really minor nit: "Notice that we have appended 0x83 to the end of the
transaction data"—should this say "to the end of the signature"?
On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Right. There are minor trade-offs to be made with regards to that design
point of OP_CHECKSIGFROMSTACKVERIFY. Fortunately this covenant
construction isn't sensitive to that choice and can be made to work with
either implementation of OP_CHECKSIGFROMSTACKVERIFY.
On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a different
way from the Elements. Instead of hashing the data on stack, I directly put
the 32 byte hash to the stack. This should be more flexible as not every
system are using double-SHA256
https://github.com/jl2012/bitcoin/commits/mast_v3_master
On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Hi all,
It is possible to implement covenants using two script extensions: OP_CAT
and OP_CHECKSIGFROMSTACKVERIFY. Both of these op codes are already
available in the Elements Alpha sidechain, so it is possible to construct
covenants in Elements Alpha today. I have detailed how the construction
works in a blog post at <
https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html>. As
an example, I've constructed scripts for the Moeser-Eyal-Sirer vault.
I'm interested in collecting and implementing other useful covenants, so if
people have ideas, please post them.
If there are any questions, I'd be happy to answer.
--
Russell O'Connor
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161103/32c6918b/attachment-0001.html>

2023-06-07 17:53:56

- reply

📅 Original date posted:2016-10-14
📝 Original message:First, non-practicing entities are definitely a problem, but they're far
from the only companies involved in software patent litigation. As you say
yourself, one reason companies obtain patents is to "prevent
competition"—meaning they produce a competing product. Look at the
billion-dollar lawsuits in the smartphone patent wars.
(Unless you're referring to "patent privateers" that assert claims and are
only indirectly sponsored and controlled by real tech companies. I don't
think the Defensive Patent License directly addresses that problem—Section
7.1 defines an "affiliate" relatively narrowly—although the Apache 2.0
license arguably does, with its broad definition of "Legal Entity." I don't
profess to know anything about the reasoning behind the DPL's wording, and
I may be missing something; maybe a future version of the DPL will close
that loophole if it becomes an actual problem.)
Second, as several people have noted on this list, patent applications
unfortunately seem to be more effective than defensive publication at
getting prior art under the noses of the patent examiners. So obtaining a
patent for defensive purposes makes it more difficult for others to obtain
patents on the same subject matter.
(Usual disclaimers apply. Nothing you read on bitcoin-dev is legal advice;
don't take legal advice from mailing lists; come on)
On Fri, Oct 14, 2016 at 12:01 PM Nick ODell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Pledging to not use patents offensively defeats the point of owning patents.
The point of owning a patent is so that you can use it offensively, either
to
prevent competition, or get licensing fees.
Obtaining a patent for defense doesn't make sense. The litigants you need to
worry about do not produce or make anything. Their 'product' is patent
lawsuits.
Unless you have a patent on using a mail-merge program to sue people, your
defensive patents are useless in that situation.
On Fri, Oct 14, 2016 at 4:57 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Oct 14, 2016 at 07:38:07AM -0300, Sergio Demian Lerner via
bitcoin-dev wrote:
>> I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current
>> users may be confident they are protected but in fact they are not, as
the
>> future generations of users can be attacked, making Bitcoin technology
>> fully proprietary and less valuable.
>
> Glad to hear you're taking a conservative approach.
>
> So I assume Rootstock is going to do something stronger then, like
> Blockstream's DPL + binding patent pledge to only use patents defensively?
>
> https://www.blockstream.com/about/patent_pledge/
>
> Because if not, the DPL is still better than the status quo.
>
>> If you read the DPL v1.1 you will see that companies that join DPL can
>> enforce their patents against anyone who has chosen not to join the DPL.
>> (http://defensivepatentlicense.org/content/defensive-patent-license)
>>
>> So basically most users of Bitcoin could be currently under threat of
being
>> sued by Bitcoin companies and individuals that joined DPL in the same way
>> they might be under threat by the remaining companies. And even if they
>> joined DPL, they may be asked to pay royalties for the use of the
>> inventions prior joining DPL.
>>
>> DPL changes nothing for most individuals that cannot and will not hire
>> patent attorneys to advise them on what the DPL benefits are and what
>> rights they are resigning. Remember that patten attorneys fees may be
>> prohibitive for individuals in under-developed countries.
>>
>> Also DPL is revocable by the signers (with only a 180-day notice), so if
>> Bitcoin Core ends up using ANY DPL covered patent, the company owning the
>> patent can later force all new Bitcoin users to pay royalties.
>
> Indeed. However, you're also free to adopt the DPL irrevocably by
additionally
> stating that you will never invoke that 180-day notice provision (or more
> humorously, make it a 100 year notice period to ensure any patents
expire!).
>
> If you're concerned about this problem, I'd suggest that Rootstock do
exactly
> that.
>
>> Because Bitcoin user base grows all the time with new individuals, the
sole
>> existence of DPL licensed patents in Bitcoin represents a danger to
Bitcoin
>> future almost the same as the existence of non-DPL license patents.
>
> To be clear, modulo the revocability provision, it's a danger mainly to
those
> who are unwilling to adopt the DPL themselves, perhaps because they
support
> software patents.
>
>> If you're publishing all your ideas and code (public disclosure), you
>> cannot later go and file a patent in most of the world except the US,
where
>> you have a 1 year grace period. So we need to do something specific to
>> prevent the publishers filing a US patent.
>
> Again, lets remember that you personally proposed a BIP[1] that had the
effect
> of aiding your ASICBOOST patent[2] without disclosing that fact in your
BIP nor
> your pull-req[3]. The simple fact is we can't rely solely on voluntary
> disclosure - your own behavior is a perfect example of why not.
>
> [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
> [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
> [3]: Extra nonce pull request:
https://github.com/bitcoin/bitcoin/pull/5102
>
>> What we need much more than DPL, we need that every BIP and proposal to
the
>> Bitcoin mailing list contains a note that grants all Bitcoin users a
>> worldwide, royalty-free, no-charge, non-exclusive, irrevocable license
for
>> the content of the e-mail or BIP.
>
> A serious problem here is the definition of "Bitcoin users". Does Bitcoin
> Classic count? Bitcoin Unlimited? What if Bitcoin forks?
>
> Better to grant _everyone_ a irrevocable license.
>
>
> Along those lines, it'd be reasonable to consider changing the Bitcoin
Core
> license to something like an Apache2/LGPL3 dual license to ensure the
copyright
> license also has anti-patent protections.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161014/7830fb7d/attachment-0001.html>

2023-06-07 17:53:54

- reply

📅 Original date posted:2016-10-14
📝 Original message:>
> Because if not, the DPL is still better than the status quo.
Agreed. Also worth noting that it has a potential advantage over unilateral
patent disarmament, analogous to the advantage of copyleft licenses over
MIT/BSD: it provides an incentive (at least a theoretical one) for other
companies to adopt it too.
As many people have proposed, the best option, though one that would
require a lot of work, might be a dedicated Bitcoin-related defensive
patent pool—similar to Linux's Open Invention Network—that could
strategically deploy patent licenses to incentivize cooperation and punish
aggressors.
Along those lines, it'd be reasonable to consider changing the Bitcoin
> Core license to something like an Apache2/LGPL3 dual license to ensure the
> copyright license also has anti-patent protections.
I think Apache 2.0 would be a great license for Bitcoin Core. It not only
contains an explicit patent license grant (rather than MIT's implicit one),
but terminates that license if the licensee asserts a claim alleging that
the covered work infringes a patent. That might be an effective deterrent
against bringing patent claims based on alleged infringement in Bitcoin
Core. (I'm not sure I see a good reason to dual-license under the LGPL3,
but am curious to hear more.)
It would probably be feasible to upgrade to the Apache license for new
releases and contributions (leaving already-existing code and previous
releases under the MIT license—so basically a copyright "soft-fork"). Has
this been discussed before? Are there any obstacles or objections?
(These are my personal opinions, do not necessarily reflect the views of
any company, and are definitely not legal advice.)
On Fri, Oct 14, 2016 at 3:58 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Oct 14, 2016 at 07:38:07AM -0300, Sergio Demian Lerner via
> bitcoin-dev wrote:
> > I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current
> > users may be confident they are protected but in fact they are not, as
> the
> > future generations of users can be attacked, making Bitcoin technology
> > fully proprietary and less valuable.
>
> Glad to hear you're taking a conservative approach.
>
> So I assume Rootstock is going to do something stronger then, like
> Blockstream's DPL + binding patent pledge to only use patents defensively?
>
> https://www.blockstream.com/about/patent_pledge/
>
> Because if not, the DPL is still better than the status quo.
>
> > If you read the DPL v1.1 you will see that companies that join DPL can
> > enforce their patents against anyone who has chosen not to join the DPL.
> > (http://defensivepatentlicense.org/content/defensive-patent-license)
> >
> > So basically most users of Bitcoin could be currently under threat of
> being
> > sued by Bitcoin companies and individuals that joined DPL in the same way
> > they might be under threat by the remaining companies. And even if they
> > joined DPL, they may be asked to pay royalties for the use of the
> > inventions prior joining DPL.
> >
> > DPL changes nothing for most individuals that cannot and will not hire
> > patent attorneys to advise them on what the DPL benefits are and what
> > rights they are resigning. Remember that patten attorneys fees may be
> > prohibitive for individuals in under-developed countries.
> >
> > Also DPL is revocable by the signers (with only a 180-day notice), so if
> > Bitcoin Core ends up using ANY DPL covered patent, the company owning the
> > patent can later force all new Bitcoin users to pay royalties.
>
> Indeed. However, you're also free to adopt the DPL irrevocably by
> additionally
> stating that you will never invoke that 180-day notice provision (or more
> humorously, make it a 100 year notice period to ensure any patents
> expire!).
>
> If you're concerned about this problem, I'd suggest that Rootstock do
> exactly
> that.
>
> > Because Bitcoin user base grows all the time with new individuals, the
> sole
> > existence of DPL licensed patents in Bitcoin represents a danger to
> Bitcoin
> > future almost the same as the existence of non-DPL license patents.
>
> To be clear, modulo the revocability provision, it's a danger mainly to
> those
> who are unwilling to adopt the DPL themselves, perhaps because they support
> software patents.
>
> > If you're publishing all your ideas and code (public disclosure), you
> > cannot later go and file a patent in most of the world except the US,
> where
> > you have a 1 year grace period. So we need to do something specific to
> > prevent the publishers filing a US patent.
>
> Again, lets remember that you personally proposed a BIP[1] that had the
> effect
> of aiding your ASICBOOST patent[2] without disclosing that fact in your
> BIP nor
> your pull-req[3]. The simple fact is we can't rely solely on voluntary
> disclosure - your own behavior is a perfect example of why not.
>
> [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
> [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
> [3]: Extra nonce pull request: https://github.com/bitcoin/bit
> coin/pull/5102
>
> > What we need much more than DPL, we need that every BIP and proposal to
> the
> > Bitcoin mailing list contains a note that grants all Bitcoin users a
> > worldwide, royalty-free, no-charge, non-exclusive, irrevocable license
> for
> > the content of the e-mail or BIP.
>
> A serious problem here is the definition of "Bitcoin users". Does Bitcoin
> Classic count? Bitcoin Unlimited? What if Bitcoin forks?
>
> Better to grant _everyone_ a irrevocable license.
>
>
> Along those lines, it'd be reasonable to consider changing the Bitcoin Core
> license to something like an Apache2/LGPL3 dual license to ensure the
> copyright
> license also has anti-patent protections.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161014/df3faf83/attachment-0001.html>