https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119 covers some details on the topic of context-free and monotonic validity.

The only way to lock a behavior is to spend the funds to a new UTXO. In Bitcoin we don't do this at the script level because we want script authorization to be context-free and monotonic. E.g., if something is true, it should always be true. At the transaction level, you can remove a spending path one by one. This is kinda what CTV is doing fundamentally.

So it seems you have some core misconceptions with how script validation works today.



does exactly what you're saying (unlocks a behavior after a specific time). You can implement the logic you wanted exactly like this.


I'll try to recommend some resources so you can learn more about Bitcoin script, which I think would enhance your understanding! This is hard stuff, but it's worth fully understanding if you're interested in programming Bitcoin.

https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1
https://bitcoin.stackexchange.com/questions/75232/bitcoin-script-tutorial


Once you've done that, feel free to reach back out and we can carry on the conversation, but I think without that context it will be hard to get on the same page about what CTV is accomplishing...

Yep. And because "depend" means contains a cryptographic hash of, we have a hash cycle. If SHA-256 is secure we can't do this.


You're just communicating in a way that is a bit unclear. I'm doing a lot of work to try to explain the concept to you -- which is my burden -- but you aren't giving me a whole lot of detail to understand exactly what you want. Can you maybe draw some diagrams?

1. You can't commit to an exact transaction ahead of time in any scheme because it has the same hash cycle problem (can't observe your own TXID). You could commit to all the outputs. In CTV we elect not to commit to the other inputs, because then we would have more types of hash cycle issues (e.g., input A commits to B, input B commit to A, hash cycle). We therefore commit to none of the inputs. If you want this functionality, it should come as a separate opcode (and I am fine to prepare & propose it after CTV).
2. If I understand what you're asking: You want to have a coin that you say it can be spent in whatever transaction you want, but it MUST go to this specific address? You can do this with CTV if you are OK not specifying additional outputs, which for most applications of this should be fine. (Once OP_CAT is re-added it's a bit more flexible again).
3. I'm not sure what this means. I've separately discussed wanting to have some "safety" opcodes to check the total transaction value.
4. You can do this already in script without CTV using CLTV. Not sure what you're asking for beyond that.

I'm saying that it always would require you to be able to generate a hash cycle, which is cryptographically impossible.

If I have a scriptPubKey corresponding to input 5 to a transaction, there is a txid for input 5 "ABCDEF...". ABCDEF commits to the scriptPubKey. But the scriptPubKey commits to spending ABCDEF. But ABCDEF = H(... || scriptPubKey || ...) = H(... || ABCDEF || ...).

So ABCDEF is a hash which contains itself (not quite a fixed point, but close). That shouldn't be possible for SHA256!


Presently, without an OP_CAT like thing, you always commit to both. But in the future, you may want to restrict just the number of inputs and not the sequences.



Ok then they are the same. Semantics.

Example is given above in the discussion of adding fees dynamically.


Straight from the BIP:


I can't give you a good example of the issue occuring, because CTV is generally not vulnerable to this class of error, the example would probably only confuse you more. But I'll try.

Let's say I create an output R for 1 BTC that is spk <A> OP_CTV. And I create another one P that is 1 BTC to spk <A> OP_CTV.

Let's say hash A covers a transaction that has 2 inputs and one output to address X for 1 BTC.

If you were able to create a transaction that spends P and R to create X, it would be valid, and create 1 output to X for 1 BTC, paying 1 BTC in fees. Spent separately, you would get two payments to X.

HOWEVER because A commits to the input index (e.g., index 0) if those values are actually identical then they can't be co-spent, avoiding the half-spend problem from key reuse.



Then use Ethereum? I'm not kidding; there's no roadmap anywhere for supporting completely arbitrary restrictions in Bitcoin. You need to narrow your request to things that fall within Bitcoin's abstractions and informational barriers, as well as validation computational limits.


Because you commit to the scriptsigs if you're using a P2SH or bare script you can commit to:

1) if non witness, the exact txid via the signatures
2) if witness, the program being spent from

because the hash commits to the scriptSig.

This is a bit weird, but the alternative would be to disallow spending with any scriptSigs in the txn, forcing it to always be segwit spends (or OP_CTVs, things without a scriptSig)

Future work should just add a new covenants mechanism for inspecting the other inputs COutpoint or witness script if we want to have a more robust mechanism for using this (we may).


What do you mean it can't be committed to? Either use OP_CTV again, recursively, or use an OP_CLTV/OP_CSV?

Yeah the law firm case is sort of "everyone is dead" so it doesn't really matter what happens to your money in this event anyways

But yeah you can have the law firm be multisig'd with a key known to all inheritors so they can't simply steal the funds.

This is actually one of the prime use cases for OP_CTV.

As Greg points out, it can be useful to have an automatic clawback period mechanism if an inheritor tries to claim inheritance and you are not dead yet.

But you can go a bit further. Let's say you have 100 BTC that you want to bequeath your children. CTV makes it easy to set it up such that your progeny could get time release bitcoin (e.g., an annuity of 1 BTC a month).

You could also do this by directly creating 100 HTLC outputs with 1 BTC each revocable to you, and different locktimes, but there are some critical drawbacks with such an approach.

One such drawback is knowing when the tax obligation is due. You can't prove to the government that you didn't also receive a private key allowing you to spend at will as a part of the estate. However, with CTV you can prove that the annuity is set up correctly, and defer your tax obligation until the annuity payment is received.

If you have multiple inheritors and want to instead do some multisig scheme, there are similar drawbacks, but now added concerns that some of the inheritors will conspire against the others.


Ready for the galaxy brain....


CTV also would enable the spender to set up sub-inheritence schemes, to cover the case where one of the inheritors also "dies in the same car crash". You can specify a different redemption path if they don't claim their payment. At some point, you might want a will executor of last resort, like a law firm.

Nope, you're not wrong here. My point was that if those sorts of covenants are desirable to express, we can add great support for that functionality with another often requested opcode (OP_CAT or a similar solution). There are a few variants to OP_CAT to consider, but I don't think there would be much objection if someone went through the effort of re-specifying it as a Tapscript upgrade (OP_SUCCESSX makes it easier to introduce opcodes which manipulate the stack).

Personally, I like that there's a "roadmap" for more powerful covenants enabled by OP_CTV, while we can introduce the fundamentals today.



Well it's strictly redundant insofar as the sequences commits to the length which transitively commits to the number of inputs.

I think it's less so that you want a restriction to a specific number of inputs and more that committing the field lets you programmatically select a number of inputs.

You might want to restrict this number in future applications where a script (with a new OP, something like CHECKINPUTVERIFY) checks a property of all the inputs. If you could add or remove an input, then you might break such a script.


This is a class of vulnerability which I believe I originally came up with when writing the BIP. You can review https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki for "half-spend".

Specifically, this is not an issue with OP_CTV because we designed OP_CTV with this in mind. CTV commits to the input index being spent at, which precludes this sort of issue in the context of key reuse for basic CTV scripts. (We meaning myself and other Bitcoin developers I discussed this issue with).



Well so you've said stuff that translates to me as "I want to be able to arbitrarily spend the coins in whatever manner I want". Tongue in cheek, but bitcoin already has this... it's called P2[w]PKH! When you're using a covenant you're generally trying to encumber the coins with new restrictions. I think CTV strikes an elegant balance between encumbrance and flexibility, but you're right that it's far from being able to run an arbitrary piece of code outside of the transaction checking arbitrary properties.

That said, it is possible to do *some* of these things.

1. There's a kinda clunky way to do this when the other input is non-segwit. However, I think this behavior is best left to a separate op_code so that the "checkinput" functionality can be used standalone from op_ctv.
2. So this is the fundamental thing CTV does. But without OP_CAT (or similar), you can't restrict it to just requiring *some* output be specified
3. This exists presently as locktime is comitted.

Generally, I think the right way to design a contract with CTV is to come up with the end states and preconditions for the end states that you want to encode, and then figure out a transaction structure that meets your goal. I've found this to be successful for OP_CTV. If you instead, design an arbitrary system with whichever features you want, map it onto transactions, and then try to convert that into OP_CTV it may not be possible.

With respect to efficiency, you can always create as many outputs as you want, so I'll interpret your comment to be about how many inputs you are co-spending. You can definitely write safe contracts with CTV that spend many inputs together to create the contract, because the first step is not bound by anything.

But I think if you *generally* analyze the program size it will be more transactions (as nodes in your program graph) but the overall size is not too great. Remember, if I have O(N) inputs in O(1) transactions, it's within constant factors of O(1) inputs in O(N) transactions. But without a specific example (e.g., I have these UTXOS, I want to end up with these other UTXOS if preconditions X are met) it's hard for me to tell you how much less efficient or more efficient the CTV version will be. CTV scripts are also *small* and *cheap* to verify, so each node isn't that expensive to verify anyways.


Here are some pics of a vault contract that I implemented a (power user) GUI for https://imgur.com/a/rhxW4F0


Recommend you watch my BPASE 17 talk https://www.youtube.com/watch?v=r7xN7K0OqaA https://cyber.stanford.edu/sites/g/files/sbiybj9936/f/jeremyrubin.pdf

I go over a lot of different covenant mechanisms and designs. Specifically this is the "optically isolated" idea -- it's a security trade-off but sometimes it can be a good design.

I'm confused by this response. There are no private meetings, I've cast a very wide net for this workshop with an open invite on the mailing list, twitter, on https://utxos.org/workshops/, in addition to reaching out personally to many devs to make sure they were aware of the opportunity. Around 35 people from all different parts of the community have expressed excitement to join (edit: and more, including those who have requested materials for remote participation). How does this differ from Taproot, which also held workshops? I actually didn't know about the workshops until after they happened, I never received a notice that they were occurring, otherwise I would have attended.

Further, I have actually been working on covenants related research for three years now, in public venues. This is a culmination and maturation of that work, and I expect the community and network to embrace this innovation as it gets more review and consensus among developers.

I think where we can agree is that additional flexibility is:

1) Worth pursuing.
2) Difficult to get right.

For the benefit of other's tuning in, we've chatted about OP_CTV at some length on IRC, the logs for which are here: http://gnusha.org/bitcoin-wizards/2019-11-28.log

I'll pull some quotes from that conversation for context so that I can respond to these concerns here, and then respond to the closing point of Greg's post, that he hopes the network doesn't adopt CTV.


One of Greg's core objections to CTV is that it's encoding for just a specific use case, one that will be made redundant or not very popular. What I want to make clear is that there is a difference between how Greg is using "use-case" and a general parlance for use-case. Here, I interpret use-case to be a use-pattern. This use-pattern can be used in different contexts (much like an HTLC is core to both atomic swaps and lightning).



Core to this point not just that Greg feels the multi-input case is not really usable, but that the single input use case is not very useful.


This comes up in the context of fees, where Greg shares a specific concern that fees are hard to add.


There are multiple ways to handle fees with OP_CTV (it's pretty flexible). Imagine you have a chain of CTV transactions, where an arrow `->` indicates one of the outputs is spent.

A -> B -> C


There are a few different ways to ensure fees.

One obvious way, in use today by certain services, is to just wildly overpay fees. This isn't robust, as fees can't be perfectly predicted, but if you're signing over 1000 BTC into a vault you may as well over-spend a bit on fees. Let's ignore this, and assume we want something that works when we don't want to over-pay. (In general, overpayment isn't a bad idea, especially because for protocols it can often be only overpay in the non-cooperative case, but assume we want mechanisms robust and not overpaid when we are completely non-interactive).


The next most obvious way is to use Child Pays For Parent.

In this case, you create a spend D

A -> B -> C -> D such that D pays high enough fee to cover A B C. This is kind-of obvious to do, but it turns out that there are two specific drawbacks:

1) The MemPool is not that good at handling long-chain CPFP (we're working on improving this though!)
2) It requires spending from C which you might want to *create* the output D spends, but not consume it.


Gas Outputs:
To make this better, another way of adding fees would be to add an output at some point in the chain which exists only to be spent in a CPFP. E.g. A->B->C{0,1}, C.1->E. Now spending C.1 to E covers the fee, and C.0 can stay unspent. This can be applied recursively.


Imagine a protocol with some really long chain DAG. Now, a user can craft a transaction spending all of the Gas Outputs along that path, and pay an appropriate fee. This has a nice atomicity property -- either you've paid for the full execution trace you wanted, or nothing extra at all and you can re-emit your fee bump transaction.

This is particularly nice because you do not disturb the sub-protocols in the DAG (e.g., LN channels).

Gas outputs also work nicely (if more than one is used, and CPFP becomes more rational) for cooperative fee-sharing.

Gas Inputs

 In this case, we can specify a CTV A which has an additional input slot which can be filled with all fees. But what about change addresses? Well, the solution is to separately create that perfectly-sized UTXO in a transaction to be spent with the desired nodes.

The main issue here is that the transaction is now malleable (both by third party and first party). See below (conditionalizing) for ways of dealing with this.

Conditionalizing
It's also possible to write the script IF <H(A)> ELSE <H(B)> ENDIF OP_CTV.

With taproot, this is even better.

We can specify (at least) four different types of conditions:

1) More Gas Inputs
2) More Gas Outputs
3) More Fees (subtracted from outputs) after a longer sequence from original spend

These options can be hidden from miners so that it's not seen that delaying a txn will get them more fees.


Conditioning more Gas Inputs (from 0 to 1) is slightly problematic in that it introduces malleability. Now an arbitrary third party can malleate the transaction by adding fee. One way of dealing with this would be to write the script:

IF <H(A)> CTV ELSE   IF <N of N Multisig> ELSE <1 month lock> CSV <1 key checksig> <H(B)> CTV ENDIF ENDIF

In this case, the logic expresses that at any time, with no modified fee, and no interaction, the original transaction may be broadcast.

At any time, N of N may agree to a new transaction.

If we haven't made progress for a month, then any participant (assuming the 1 key is known to all N) may make progress, potentially malleating the txid but not the outputs. One can imagine writing a script that goes N, N-1, N-2.... 1 in order to balance agreement and non-malleability of the txid (e.g., if the protocol step contains lightning channel outputs).


New Fee OpCode

In general, it might be advisable to introduce an arbitrary CPFP relationship flag or opcode that allows an unrelated transaction to "observe" if another transaction exists in the present block. This would take some engineering to get right, but it can be expressed using the same logic as CPFP today.

This is nice conceptually because we can then abstract from the transactions you are doing (which are the execution) and how you're paying for it. CTV doesn't contain a proposal for this today, but I think this is of independent interest as more protocols are built on Bitcoin struggle to figure out how to pay fees.

New General OpCode

As opposed to conditionality, it's also possible that with the addition of OP_CAT it's much easier to dynamically add a fee input/output.

It's then trivial to write something like (definitely not correct here -- written expediently for the gist):


stack top: <1 or more> X <other sequences> X <change output>
<pre input data> OP_SWAP OP_CAT OP_SWAP
<1 known sequences> OP_SWAP OP_CAT OP_SHA256 OP_SWAP OP_CAT OP_SWAP
<outputs> OP_SWAP OP_CAT OP_SHA256 OP_SWAP OP_CAT
<other data> OP_SWAP OP_CAT OP_SHA256 OP_CTV

This type of operation would allow the witness to pass in some arbitrary new change input and output data, while keeping the original intent intact. However, like above, you have malleability.



The above presents many different ways of paying fees, and I also hope helps underscore that CTV actually is pretty flexible! In practice, applications will probably just pick one mechanism to work with.

The larger question that I have is what sort of fee paying flexibility is being imagined that isn't provided as above? This seems to cover most cases -- short of, the common protocol desire of "I wish I didn't have to think about fees" (although a new fee opcode seems to get close to that). Keep in mind, any new proposal for a different path to covenants also has to answer similar questions about fees, and I don't think something simple can be accomplished as a part of the covenants mechanisms.


A further contention is that this is something that graftroot has an advantage in.




I think this is a reasonable point. It certainly seems to be the case that were there to be a graftroot like thing available, you would use
it to elide a CTV script for compactness reasons (in fact I've previously suggested being able to hide a CTV hash in a taproot leaf for efficiency). However, it doesn't really suit the CTV use case that well because we want to support non-interactive cases with multiple branches.

Unless there is a script level graftroot which supports recursion, in which case it's possible that you can make it work by conditionalizing different keys to different CTV-equivalents. But a recursive graftroot construction would seem to me to be fraught to design.

Further, if you're doing complex programs which require large compilations, the curve operations may make it prohibitive compared to just hashing.

Lastly, Greg's point that a signature is more flexible than a hash is kind-of incorrect. A hash must be strictly more flexible, in a sense, because a signature contains a hash. As shown above in the discussion of fees, you can do some really flexible stuff with CTV.



Another issue Greg brings up is an important one, which is covered in the BIP.

This is addressed in two different ways. The first, is by restricting the number of inputs.

If you're fitting within a common use case of a single input per branch of a CTV tree, you "for free" don't have to worry about most of the malleability issues and can merrily design your protocol.

If you do need more than one, you now have 2 issues:

1) Malleability
2) Key-Reuse

Malleability is in two categories:

1) Third party
2) First Party



The key reuse issue is "solved" by including the index at which a coin should be spent at in the the hash. This means if I spend to two identical basic CTV scripts, they provably cannot be spent in the same transaction. If you specify two different indexes, that's you indicating that you're open to them being spent together, and should take similar precautions to malleability.

If you're worried about third party malleability, and you have more than one input, one option is to include a public key that is known to all participants in addition to the CTV. Now, no third party can create a spend in an unintended way, because first-parties have to "approve" of the CTV for it to go through (signing other outputs).


If you're worried about first party malleability, it requires some tradeoffs (or something like OP_CAT) to make it truly robust (see as presented in the fees section).


These solutions also end up solving, for the most part, the "half-spend" problem Greg mentioned. In typical uses, it shouldn't come up.





The last application point I wanted to cover, was this claim:

In general, this is exactly what CTV is here to avoid. We don't want signatures because they are interactive and they preclude non-interactive setups. Non interactive setups are a much more scalable solution because it means that senders can *pay into* complex protocol setups immediately.

E.g., coinbase can redeem users *always* into payment pools, where the participants online can immediately begin transacting (I have thoughts on how payment pools should be architected, the conclusion of those thoughts being that creating a CTV tree of multiparty channels which terminates in 2-of-2 channels, and "novates up the tree" when needed, has the best set of tradeoffs for privacy and efficiency).



--------------------------------------------------------------------------------------------------------------------------------------------


I sincerely hope that the network adopts CTV, and reject the notion that it's worth not deploying in the near term to take time to come up with a more powerful model for smart contracts (perhaps one day we'll know how to do a compact zero knowledge EVM for all I know).

With BIP-119, I've worked diligently to look at a wide variety of use cases and patterns to make sure that CHECKTEMPLATEVERIFY is compatible, even with it's restrictions.

I'm not confident that we'd be able to ever make something much more flexible than CHECKTEMPLATEVERIFY given the propensity for such transaction introspection to trigger superlinear hashing issues.

It's also less clear to me that additional flexibility is required for CheckTemplateVerify to cover the bases sufficiently. Is there a particular application that you have in mind that you believe CheckTemplateVerify to not work well for? I am happy to look into it and see if there's a similar design that works well under CTV.

From my experience designing around it, CheckTemplateVerify is going to be a useful tool in the belt for payment channels, vaults, payment pools, and much more. For some protocols where CheckTemplateVerify seems insufficient or unwieldy to use, what I've seen is that a small set of new opcodes (such as OP_CAT, OP_MBV, OP_CHECKINPUT) were required for the design in addition to a covenant system, but the designs were ultimately compatible with OP_CTV (without  crazy scripts like checksigfromstack covenants).

If you can give a concrete protocol example of where you think OP_CTV falls short I'm happy to walk through how you can build something sufficient with OP_CTV.

In general, I also think that rather than pursuing a "magic bullet" (which could be some snark verifier opcode, potentially), it's nice to add functionality in compose-able chunks so that the network can benefit from new use cases immediately and we can inform our later engineering efforts from real world use cases.

Lastly, I apologize to anyone who feels that I've been trying to ram a change down the network's throat. I've tried to make every effort to form an inclusive review and development process, with numerous presentations, online resources at https://utxos.org, mailing lists posts, reference implementations, a BIP, one on one meetings with companies, and a workshop that many will attend next weekend (invite still stands Greg!), but I understand that individuals expectations of procedure vary. At the end of the day, everyone wants something different from Bitcoin.

While I don't agree with Greg's characterizations of my work -- neither on a technical level nor on a procedural level -- I trust the Bitcoin network & it's participants carefully weigh changes and improvements and decide what's best.

The reason that we want to specify the number of inputs but not the exact inputs is because if we were to specify the exact inputs it creates a hash cycle. This then prevents the opcode from actually being used. I recommend reviewing the RPCs branch -- I'm currently in the process of doing a lot of refactoring, so this is a temporary branch -- https://github.com/JeremyRubin/bitcoin/commits/checktemplateverify-v2-rpcs-rb, which shows how templates are constructed with a bottom-up pass and then a top-down pass.


With respect to constructing via script, the reason that separately committing the number of inputs from the sequences makes it possible to write a script that allows the spender to pass in *any* sequences they like, while still be restricted to a specific number of inputs, with the addition of OP_CAT (or similar). E.g.:

<data before sequences hash, including n_inputs set to 7> OP_SWAP OP_CAT <data after sequences hash> OP_CAT OP_SHA256 OP_CTV


It's nice to be able to constrain the passed in hash to be any set of 7 sequences.


I think the above answers your question? But more specifically, the half spend problem crops up if I created 2 CTV outputs with the same script (with no # inputs restriction) they could be spent in the same transaction, creating half the outputs as if spent separately. Restricting the number of inputs to 1 prevents any sort of half-spend issue. The other protection from this is the commitment to the currently executing input index, which means identical basic CTV scripts cannot be spent in the same transaction.


So I think that your vault use case is too general. If you refine it a little, you'll see that CTV works pretty well. You can see code for this in the repo above. Essentially you spend into a single output that can be either withdrawn 1 step at a time or sent back to cold storage. I don't have code for it at writing, but you can also set up a larger script (maybe using taproot) which allows for bigger withdrawals after bigger timeouts, but I think that simple is better as a first pass.

It's also possible to set up these kind of cold vaults which by default leave the coins at rest, but it's a bit more difficult to reason about so I've focused on the simple ones first.



It keeps the BIP and implementation simple and can be added later with OP_CAT or a new template type. Most of the multi-input use cases can be done pretty easily with Taproot. I view OP_CTV as a first, and major, step towards multi-transaction programmability, and as we see the successes of that we can expand to more general mechanisms if the tooling that emerges around OP_CTV is insufficient for a desired use case. But I personally think that CTV is flexible enough to support most of the really compelling use cases in straightforward ways.

Thanks for your support




Hah -- Not a scam. I think I'm ~fairly~ reputable to not being doing such a thing (I'm a bitcoin core contrib, I run Scaling Bitcoin, I co-founded the MIT DCI, I did the MIT Bitcoin project and gave every MIT Student $100 in Bitcoin, I fought the State of NJ over Tidbit in 2013, etc).

It's more or less a fundraiser, and I'm going to put the funds raised to fighting Nazism and other forms of racist extremism in America.

It's fine if the Nazis don't care (I actually prefer that). This is more about bringing unity over the condemnation as a common principle, and doing some good work with any cash raised.




I think you'll find that information on the site under "Sale Structure " (it's uncapped); it has all the information that a whitepaper would have. I can add a roadmap though, but its's heavily dependent on how many tokens are sold what types of the missions I listed we'll be able to do. I'm working with a tech-savvy Rabbi on making sure I'm making the maximum impact with the project.





I hope not! At a minimum I just want to help people to find their voice to speak out against Nazism and other forms of racist extremism. Is that so useless?

But yeah, the tokens are perfunctory. It's not about fake technical features it's about the community that can be built as a response.

I'm guessing you don't need a lesson historically on who the Nazis were...


But who are the Nazis today?

Well, they're the cowards who painted Swastikas and "Work Will Set You Free (1941)" on my universities campus. Who draw "Jews did 9/11" outside of high schools and graffiti crossed out stars of David on walls in the town where some of my relatives live. They're the people who shout at me on the bus because of how the Jews own America. Those are Nazis, no? Sure those are anecdotes, but that's what you asked me... what did they do to me.

These are the people who then go on to commit atrocities like those seen in Holocaust. They are so brash as to even take the same symbols in public. And it's not those Nazis who take those symbols that concern me the most, it's the ones who don't. Because at least if you're wearing a nazi swastika there shouldn't be room to justify your intent.

No, some white male I disagree with isn't automatically a Nazi. But a Nazi is a Nazi. This isn't just a white male thing, there is anti-Semitism and other forms of racialized hate on both the left and the right. Neither get a free pass for what they think about healthcare.


I'm guessing you care about free speech. That you want to have your unique views and not be labeled as a Nazi for them. And you're worried that the left is going to take away your free speech because of it? I'm worried about that too. Free speech is absolutely critical for our society to continue to function. Nazis work on intimidation. They want you to fear for your life to speak out against them.

That's why it is so important to speak now, and to make it known that we will not let people be intimidated out of their voice.

Saying Fuck Nazis is not like racism. To insinuate otherwise is ridiculous.


That saying Fuck Nazis a little bit of a filter is a good thing -- purchasers of the virtual lapel pin are more likely to actually value the cause.

Excited to announce my new project here, the Fuck Nazis Virtual Lapel Pin. The sale is currently underway until September.


You can participate by sending Ethereum to the Sale Address: 0x648f3501556345B5a6e9CC3742F7070382BbEa5F.

The Fuck Nazis Virtual Lapel Pin sale is for those who want to proudly declare "FUCK NAZIS". And if you don't want to condemn Nazis, FUCK YOU TOO.

Saying "Fuck Nazis" out loud is incredibly empowering — try it!

Purchasing and holding a Fuck Nazis Virtual Lapel Pin represents a small act of defiance and measurable virtue signaling against dangerous and violent Nazi ideologies. Large acts of defiance can have large impact, but small reminders of your stake in critical issues create opportunities for you to have the strength to make larger acts. True virtue signaling also serves to build a community of shared values and network of support around those making large acts of defiance.


There's more information on the official website, including a participation guide, but as a sampling of the types of things we aspire to do:

• Donations to organizations like the Southern Poverty Law Center and the Anti-Defamation League.
• Sponsoring guards for synagogues who are denied publicly funded police details.
• Developing curricular guides for parents and teachers instructing their children on the recent rise in Nazism.
• Summit for Rabbis on how to respond to Nazism in 2017.
• Workshops on how to non-violently oppose Nazis in cities where they are staging demonstrations.
• Producing a documentary on the few remaining holocaust survivor's thoughts on how to respond to current events.
• Financial support programs for financially struggling Holocaust survivors in America.
• Support for those in legal trouble as a result of their acts of defiance against Nazis.
• Publishing a quarterly online magazine for pin holders on related topics.
• Operating phone campaigns to call every Senator, Congressman, Governor, etc to collect and document as many comments on fighting Nazism as possible.  
• Running special fund-raisers using FNZ pins to mock Nazis.  
• Running a hackathon on protest technologies -- what is the modern-day megaphone?  How can it be used by us; how could it be used against us?  
• Building statues as symbols of emancipation in the South.
• Sponsoring pro-tolerance guerilla art.
• Planning workshops with other anti-hate movements to train them on how to use crypto.
• Advocating policies to stop the use of Gestapo like secret police in America and related practices.

Join our Slack and Mailing List (link removed by forum, see site for mailing list).
Follow on  @FuckNazis Twitter.
Follow Fuck Nazis on Facecook.


Happy to take any questions!


Jeremy