Published:
In our last Discreet Log Contract post, we explored the problems faced by most existing smart contracts as well as what Discrete Log Contracts (DLCs) are at a high level. In this post we will detail what exactly what it takes to execute a DLC as well as the many benefits we reap for doing so.
Published:
In this post we continue our survey of Schnorr-enabled schemes and their applications to Bitcoin by exploring the exciting world of Scriptless Scripts which are enabled by a signature scheme called Adaptor Signatures. I will note that while it is possible to do adaptor signatures without too much pain in ECDSA (without Schnorr), it is still much much nicer to do with Schnorr and can be integrated with other Schnorr signature variants.
Published:
In this post we will delve into the new ideas brought forward in the paper “Generalized Bitcoin-Compatible Channels” for improving the future Lightning Network.
Published:
In this series about Payment Points on Lightning, we’ve been focusing on mechanisms that enable somewhat generic off-chain contracts. We’ve discussed how points can enforce monotonic access structures and how we can use Barrier Escrows to make multiple payments atomic. In this last post we will further underscore the usefulness of both monotonic access structures and Barrier Escrows and how they can be combined to enable arbitrary multi-payment/contract transfer and update!
Published:
In the previous post, we discussed how to construct multi-payment Lightning contracts by using Barrier Escrows to make multiple payments atomic. In this post, we will discuss various ways of implementing Barrier Escrows and analyze their trade-offs.
Published:
In the previous post in our Payment Points series, we discussed the large class of contracts that can be created on a PTLC-based Lightning Network using monotonic access structures. In this post, we want to further develop the idea that general contracts that can be created through the use of Payment Points by defining Barrier Escrows which allow us to do atomic multi-payment setup.
Published:
In our past series about Payment Points on Lightning, we covered the foundations of Payment Points and explored some important features they enable.
Published:
In our recent posts, we discussed all the benefits and features enabled by Payment Points on the Lightning Network. We explored how they can protect us from wormhole attacks and payment correlation, how they enable “stuckless” payments, and how they allow escrow contracts over Lightning. In this post we will discuss one of my favorite new features: trustlessly selling signatures!
Published:
In our previous post, we discussed a Lightning Network feature referred to as “Stuckless Payments” that requires Payment Points. Stuckless Payments allow users to attempt multiple payments concurrently. For an in depth description of Payment Points themselves and the problems they solve, see our first post in this series. In this post we’ll continue this thread and discuss another outstanding proposal that would require Payment Points be implemented: Escrow Contracts over Lightning!
Published:
In our previous post, we discussed how using pre-images and payment hashes to make lightning payments atomic results in the possibility of payment correlation and vulnerability to wormhole attacks. We also discussed how replacing pre-images and payment hashes with scalars and payment points allows us to have payment de-correlation, solving the problems with payment hashes. In this blog post we will discuss one of a few of the exciting new features that can exist in a Lightning Network based on payment points!
Published:
Published:
Discreet Log Contracts (DLCs) are bitcoin-compatible non-custodial oracle contracts in which participants post Bitcoin collateral which is settled depending on an event in the “real-world” as attested to by a set of oracles. In this post, we will be exploring in-depth the ways in which oracles can fail which DLC users should be aware of, as well as some mitigation strategies.
Published:
A couple weeks ago, we announced that we had successfully executed a DLC on-chain using oracles Bitfinex, Pierre Rochard and Suredbits. In this post, we will be diving into the details of how multi-oracle DLCs are accomplished.
Published:
Published:
In our last Discreet Log Contract post, we explored the problems faced by most existing smart contracts as well as what Discrete Log Contracts (DLCs) are at a high level. In this post we will detail what exactly what it takes to execute a DLC as well as the many benefits we reap for doing so.
Published:
Y’all asked for a high-level, no math, summary of the Schnorr Signature Series and so here you are! If this piques your interest and you are willing/excited to learn some math, check out the series:
Published:
So far in this series we have discussed Schnorr Digital Signatures, their security, and their many variants and benefits. As you may know, Schnorr signatures are going to be introduced to the Bitcoin blockchain using a softfork known as Taproot. In a previous blog post, Ben talked about various ways Taproot may be activated. In this post, we’re going to be talking about exactly what changes are included in the Taproot softfork including how Schnorr signatures will be added!
Published:
In this post we will be discussing one final Schnorr scheme: Blind Signatures. As their name suggests, a Schnorr Blind Signature is a signature where the signer does not know what they have signed. It may be hard to imagine what this could be useful for but it turns out to be a great tool when dealing with “oblivious” servers, which I think have a large role to play in the future of Bitcoin and the internet at large.
Published:
In the last post of this series we discussed Threshold Signature schemes as well as their uses and I’d like to continue that discussion today with an exploration of FROST. FROST can be thought of as the natural extension of MuSig to thresholds (\(t\)-of-\(n\) instead of just \(n\)-of-\(n\)) utilizing distributed key generation. FROST is in some sense the most general threshold scheme we’ve covered so far as it has the awesome feature that it generates keys and signatures indistinguishable (on-chain) from normal (single) Schnorr keys and signatures! In this post, I will be describing FROST in quite a bit of technical detail building up the idea of distributed key generation and then applying it to Schnorr signatures.
Published:
In today’s installment of the Suredbits Schnorr Series, we will begin our exploration of threshold signatures schemes! We will discuss various uses for threshold signatures and then go on to describe three different ways of doing threshold signatures, each with their own pros and cons. The last (and possibly most exciting) threshold signature implementation, FROST, will take a whole blog post to describe, so stay tuned for that post to come next.
Published:
So far in this series, we’ve discussed what Schnorr signatures are, why they are secure, and how Schnorr variants can be used to implement private and scalable multi-signatures and scriptless scripts using adaptor signatures. Today we will be looking at yet another exciting improvement Schnorr will be introducing to the Bitcoin ecosystem, Batch Verification!
Published:
In this post we continue our survey of Schnorr-enabled schemes and their applications to Bitcoin by exploring the exciting world of Scriptless Scripts which are enabled by a signature scheme called Adaptor Signatures. I will note that while it is possible to do adaptor signatures without too much pain in ECDSA (without Schnorr), it is still much much nicer to do with Schnorr and can be integrated with other Schnorr signature variants.
Published:
Welcome to this week’s installment of the introductory Schnorr blog series! So far we have covered (in extreme depth) what Schnorr signatures are and why they work securely. If you didn’t follow or haven’t read the last two posts (detailing Schnorr’s security) you will still be able to read this post (and the remainder of this series) so long as you felt comfortable with the very first post in this series or have a good understanding of how Schnorr signatures work. In this post, we shall begin our exploration of variants of Schnorr signatures which enable countless application use cases, starting with MuSig.
Published:
In the last blog post, we began laying out the groundwork for what will become an argument that Schnorr signatures are secure. We discovered the Schnorr Identity Protocol and proved that it is secure and correct (specifically Complete, Sound, and Honest-Verifier Zero-knowledge). It is very unlikely that this blog post will make much sense if you have not yet read the previous post, so go read it if you haven’t already.
Published:
In the previous post of our introductory Schnorr series, we discussed the definition of Schnorr signatures and tried to build some intuition as to how Schnorr signatures work by looking at a sequence of choices that could have led us to the definition. In this post we will go even deeper and begin an argument for Schnorr’s security by deriving the signature scheme from yet another angle.
Published:
Welcome to the introductory Suredbits Schnorr blog series! In this post, I will explain what Schnorr signatures are and how they intuitively work. In the next post, I will present some evidence as to why this scheme is secure and correct. In the rest of this series, I will be diving into various signatures schemes that Schnorr easily enables and some of their use cases. Before you read on, I recommend you make sure you are comfortable with the following three ideas as I will assume some basic knowledge of them:
Published:
In this post we will delve into the new ideas brought forward in the paper “Generalized Bitcoin-Compatible Channels” for improving the future Lightning Network.
Published:
Transferability of Discreet Log Contracts (DLCs) is of major interest due to the capital inefficiency inherent to contracts which do not rely on custody or counter-party trust. In other words, DLCs require all parties to lock up the maximum collateral that they could lose. This means that if a party wishes to exit their exposure to the DLC outcome, they must either further collateralize themselves by locking up more funds or they can attempt to transfer out of their position by finding themselves a replacement hence unlocking collateral. We have previously discussed how to execute on-chain transfers and transfers of PTLC-based routed DLCs using barrier escrows. In this post we describe a mechanism to transfer in-channel DLC outputs to adjacent channels using HTLCs. Note that the scheme detailed in this post can be used more generally to transfer any generic two-party contract output to an adjacent channel.
Published:
We’ve been discussing Discreet Log Contracts (DLCs) and their implementation a lot in our last couple posts and this week I’d like to take a step back and discuss some new theoretical discoveries regarding DLCs that we’ve made about transferring in and out of DLC positions.
Published:
In this series about Payment Points on Lightning, we’ve been focusing on mechanisms that enable somewhat generic off-chain contracts. We’ve discussed how points can enforce monotonic access structures and how we can use Barrier Escrows to make multiple payments atomic. In this last post we will further underscore the usefulness of both monotonic access structures and Barrier Escrows and how they can be combined to enable arbitrary multi-payment/contract transfer and update!
Published:
In the previous post, we discussed how to construct multi-payment Lightning contracts by using Barrier Escrows to make multiple payments atomic. In this post, we will discuss various ways of implementing Barrier Escrows and analyze their trade-offs.
Published:
In the previous post in our Payment Points series, we discussed the large class of contracts that can be created on a PTLC-based Lightning Network using monotonic access structures. In this post, we want to further develop the idea that general contracts that can be created through the use of Payment Points by defining Barrier Escrows which allow us to do atomic multi-payment setup.
Published:
In our past series about Payment Points on Lightning, we covered the foundations of Payment Points and explored some important features they enable.
Published:
So far in our Discrete Log Contracts series, we’ve covered what they are, how they work, and why they’re great. In this final post, we will enter into a practical discussion of the security and trust considerations involved when dealing with DLCs.
Published:
In previous posts, we discussed both what Discreet Log Contracts (DLCs) are and how they work in detail. Now, let’s talk about the features of DLCs and how they make powerful oracle contracts.
Published:
Previously we have analyzed Discreet Log Contracts (DLCs) at a high level and briefly walked through a specific contract executed between Blockstream and Crypto Garage. In this series we will be delving further into DLCs, looking at what they are, how they work, their security model, trust model and some of their benefits.
Published:
In our recent posts, we discussed all the benefits and features enabled by Payment Points on the Lightning Network. We explored how they can protect us from wormhole attacks and payment correlation, how they enable “stuckless” payments, and how they allow escrow contracts over Lightning. In this post we will discuss one of my favorite new features: trustlessly selling signatures!
Published:
In our previous post, we discussed a Lightning Network feature referred to as “Stuckless Payments” that requires Payment Points. Stuckless Payments allow users to attempt multiple payments concurrently. For an in depth description of Payment Points themselves and the problems they solve, see our first post in this series. In this post we’ll continue this thread and discuss another outstanding proposal that would require Payment Points be implemented: Escrow Contracts over Lightning!
Published:
In our previous post, we discussed how using pre-images and payment hashes to make lightning payments atomic results in the possibility of payment correlation and vulnerability to wormhole attacks. We also discussed how replacing pre-images and payment hashes with scalars and payment points allows us to have payment de-correlation, solving the problems with payment hashes. In this blog post we will discuss one of a few of the exciting new features that can exist in a Lightning Network based on payment points!
Published:
Published:
At Suredbits, we use the Lightning Network to create monetized data services. We currently have Lightning APIs selling NFL and NBA stats as well as cryptocurrency market data. In the future, we think that Lightning will be used to monetize all forms of data. Any content such as games, music, sports, weather, financial, or blog posts will be monetized with cryptocurrency. A couple weeks ago, we posted a proposal Lightning Application Standard (LAS) to the lightning-dev mailing list with some details about how we think data should be sold using lightning. We internally refer to this scheme as PAID (Payment-Atomic Information Decryption).
Published:
In this post we will be discussing one final Schnorr scheme: Blind Signatures. As their name suggests, a Schnorr Blind Signature is a signature where the signer does not know what they have signed. It may be hard to imagine what this could be useful for but it turns out to be a great tool when dealing with “oblivious” servers, which I think have a large role to play in the future of Bitcoin and the internet at large.
Published:
I know what you’re thinking, “Duh, everyone knows that nonce reuse is bad … why are you writing a blog post about how nonce reuse is insecure?” Fair enough, but hear me out. As we’ll discuss, it is pretty trivial to compute someone’s private key if they are unfortunate enough to reuse a Schnorr signature nonce; however, I claim that it is less clear why nonce reuse leads to practical attacks in the multi-signature scheme MuSig2.
Published:
In cryptography, secret sharing is the process of splitting a secret into pieces, called secret shares, so that no individual device stores the original secret, but some group of devices can collectively recover that secret. Classic examples of situations involving secret sharing include missile launch codes and shared custody in the corporate setting; in both cases, multiple individuals’ authorizations are required before any action can be taken. Recently, secret sharing has seen extensive use within multi-party computation (MPC) involving secret data, and private key management, where an individual or organization has cryptocurrency belonging to a secret key and they wish to split this key into \(n\) key shares such that some subset of \(t\) shares is required for using the key.
Published:
Y’all asked for a high-level, no math, summary of the Schnorr Signature Series and so here you are! If this piques your interest and you are willing/excited to learn some math, check out the series:
Published:
So far in this series we have discussed Schnorr Digital Signatures, their security, and their many variants and benefits. As you may know, Schnorr signatures are going to be introduced to the Bitcoin blockchain using a softfork known as Taproot. In a previous blog post, Ben talked about various ways Taproot may be activated. In this post, we’re going to be talking about exactly what changes are included in the Taproot softfork including how Schnorr signatures will be added!
Published:
In this post we will be discussing one final Schnorr scheme: Blind Signatures. As their name suggests, a Schnorr Blind Signature is a signature where the signer does not know what they have signed. It may be hard to imagine what this could be useful for but it turns out to be a great tool when dealing with “oblivious” servers, which I think have a large role to play in the future of Bitcoin and the internet at large.
Published:
In the last post of this series we discussed Threshold Signature schemes as well as their uses and I’d like to continue that discussion today with an exploration of FROST. FROST can be thought of as the natural extension of MuSig to thresholds (\(t\)-of-\(n\) instead of just \(n\)-of-\(n\)) utilizing distributed key generation. FROST is in some sense the most general threshold scheme we’ve covered so far as it has the awesome feature that it generates keys and signatures indistinguishable (on-chain) from normal (single) Schnorr keys and signatures! In this post, I will be describing FROST in quite a bit of technical detail building up the idea of distributed key generation and then applying it to Schnorr signatures.
Published:
In today’s installment of the Suredbits Schnorr Series, we will begin our exploration of threshold signatures schemes! We will discuss various uses for threshold signatures and then go on to describe three different ways of doing threshold signatures, each with their own pros and cons. The last (and possibly most exciting) threshold signature implementation, FROST, will take a whole blog post to describe, so stay tuned for that post to come next.
Published:
So far in this series, we’ve discussed what Schnorr signatures are, why they are secure, and how Schnorr variants can be used to implement private and scalable multi-signatures and scriptless scripts using adaptor signatures. Today we will be looking at yet another exciting improvement Schnorr will be introducing to the Bitcoin ecosystem, Batch Verification!
Published:
In this post we continue our survey of Schnorr-enabled schemes and their applications to Bitcoin by exploring the exciting world of Scriptless Scripts which are enabled by a signature scheme called Adaptor Signatures. I will note that while it is possible to do adaptor signatures without too much pain in ECDSA (without Schnorr), it is still much much nicer to do with Schnorr and can be integrated with other Schnorr signature variants.
Published:
Welcome to this week’s installment of the introductory Schnorr blog series! So far we have covered (in extreme depth) what Schnorr signatures are and why they work securely. If you didn’t follow or haven’t read the last two posts (detailing Schnorr’s security) you will still be able to read this post (and the remainder of this series) so long as you felt comfortable with the very first post in this series or have a good understanding of how Schnorr signatures work. In this post, we shall begin our exploration of variants of Schnorr signatures which enable countless application use cases, starting with MuSig.
Published:
In the last blog post, we began laying out the groundwork for what will become an argument that Schnorr signatures are secure. We discovered the Schnorr Identity Protocol and proved that it is secure and correct (specifically Complete, Sound, and Honest-Verifier Zero-knowledge). It is very unlikely that this blog post will make much sense if you have not yet read the previous post, so go read it if you haven’t already.
Published:
In the previous post of our introductory Schnorr series, we discussed the definition of Schnorr signatures and tried to build some intuition as to how Schnorr signatures work by looking at a sequence of choices that could have led us to the definition. In this post we will go even deeper and begin an argument for Schnorr’s security by deriving the signature scheme from yet another angle.
Published:
Welcome to the introductory Suredbits Schnorr blog series! In this post, I will explain what Schnorr signatures are and how they intuitively work. In the next post, I will present some evidence as to why this scheme is secure and correct. In the rest of this series, I will be diving into various signatures schemes that Schnorr easily enables and some of their use cases. Before you read on, I recommend you make sure you are comfortable with the following three ideas as I will assume some basic knowledge of them:
Published:
Discreet Log Contracts (DLCs) are bitcoin-compatible non-custodial oracle contracts in which participants post Bitcoin collateral which is settled depending on an event in the “real-world” as attested to by a set of oracles. In this post, we will be exploring in-depth the ways in which oracles can fail which DLC users should be aware of, as well as some mitigation strategies.
Published:
A couple weeks ago, we announced that we had successfully executed a DLC on-chain using oracles Bitfinex, Pierre Rochard and Suredbits. In this post, we will be diving into the details of how multi-oracle DLCs are accomplished.
Published:
Published:
In our last Discreet Log Contract post, we explored the problems faced by most existing smart contracts as well as what Discrete Log Contracts (DLCs) are at a high level. In this post we will detail what exactly what it takes to execute a DLC as well as the many benefits we reap for doing so.
Published:
Transferability of Discreet Log Contracts (DLCs) is of major interest due to the capital inefficiency inherent to contracts which do not rely on custody or counter-party trust. In other words, DLCs require all parties to lock up the maximum collateral that they could lose. This means that if a party wishes to exit their exposure to the DLC outcome, they must either further collateralize themselves by locking up more funds or they can attempt to transfer out of their position by finding themselves a replacement hence unlocking collateral. We have previously discussed how to execute on-chain transfers and transfers of PTLC-based routed DLCs using barrier escrows. In this post we describe a mechanism to transfer in-channel DLC outputs to adjacent channels using HTLCs. Note that the scheme detailed in this post can be used more generally to transfer any generic two-party contract output to an adjacent channel.
Published:
We’ve been discussing Discreet Log Contracts (DLCs) and their implementation a lot in our last couple posts and this week I’d like to take a step back and discuss some new theoretical discoveries regarding DLCs that we’ve made about transferring in and out of DLC positions.
Published:
So far in our Discrete Log Contracts series, we’ve covered what they are, how they work, and why they’re great. In this final post, we will enter into a practical discussion of the security and trust considerations involved when dealing with DLCs.
Published:
In previous posts, we discussed both what Discreet Log Contracts (DLCs) are and how they work in detail. Now, let’s talk about the features of DLCs and how they make powerful oracle contracts.
Published:
Previously we have analyzed Discreet Log Contracts (DLCs) at a high level and briefly walked through a specific contract executed between Blockstream and Crypto Garage. In this series we will be delving further into DLCs, looking at what they are, how they work, their security model, trust model and some of their benefits.
Published:
I know what you’re thinking, “Duh, everyone knows that nonce reuse is bad … why are you writing a blog post about how nonce reuse is insecure?” Fair enough, but hear me out. As we’ll discuss, it is pretty trivial to compute someone’s private key if they are unfortunate enough to reuse a Schnorr signature nonce; however, I claim that it is less clear why nonce reuse leads to practical attacks in the multi-signature scheme MuSig2.
Published:
In cryptography, secret sharing is the process of splitting a secret into pieces, called secret shares, so that no individual device stores the original secret, but some group of devices can collectively recover that secret. Classic examples of situations involving secret sharing include missile launch codes and shared custody in the corporate setting; in both cases, multiple individuals’ authorizations are required before any action can be taken. Recently, secret sharing has seen extensive use within multi-party computation (MPC) involving secret data, and private key management, where an individual or organization has cryptocurrency belonging to a secret key and they wish to split this key into \(n\) key shares such that some subset of \(t\) shares is required for using the key.
Published:
Y’all asked for a high-level, no math, summary of the Schnorr Signature Series and so here you are! If this piques your interest and you are willing/excited to learn some math, check out the series:
Published:
So far in this series we have discussed Schnorr Digital Signatures, their security, and their many variants and benefits. As you may know, Schnorr signatures are going to be introduced to the Bitcoin blockchain using a softfork known as Taproot. In a previous blog post, Ben talked about various ways Taproot may be activated. In this post, we’re going to be talking about exactly what changes are included in the Taproot softfork including how Schnorr signatures will be added!
Published:
In this post we will be discussing one final Schnorr scheme: Blind Signatures. As their name suggests, a Schnorr Blind Signature is a signature where the signer does not know what they have signed. It may be hard to imagine what this could be useful for but it turns out to be a great tool when dealing with “oblivious” servers, which I think have a large role to play in the future of Bitcoin and the internet at large.
Published:
In the last post of this series we discussed Threshold Signature schemes as well as their uses and I’d like to continue that discussion today with an exploration of FROST. FROST can be thought of as the natural extension of MuSig to thresholds (\(t\)-of-\(n\) instead of just \(n\)-of-\(n\)) utilizing distributed key generation. FROST is in some sense the most general threshold scheme we’ve covered so far as it has the awesome feature that it generates keys and signatures indistinguishable (on-chain) from normal (single) Schnorr keys and signatures! In this post, I will be describing FROST in quite a bit of technical detail building up the idea of distributed key generation and then applying it to Schnorr signatures.
Published:
In today’s installment of the Suredbits Schnorr Series, we will begin our exploration of threshold signatures schemes! We will discuss various uses for threshold signatures and then go on to describe three different ways of doing threshold signatures, each with their own pros and cons. The last (and possibly most exciting) threshold signature implementation, FROST, will take a whole blog post to describe, so stay tuned for that post to come next.
Published:
So far in this series, we’ve discussed what Schnorr signatures are, why they are secure, and how Schnorr variants can be used to implement private and scalable multi-signatures and scriptless scripts using adaptor signatures. Today we will be looking at yet another exciting improvement Schnorr will be introducing to the Bitcoin ecosystem, Batch Verification!
Published:
In this post we continue our survey of Schnorr-enabled schemes and their applications to Bitcoin by exploring the exciting world of Scriptless Scripts which are enabled by a signature scheme called Adaptor Signatures. I will note that while it is possible to do adaptor signatures without too much pain in ECDSA (without Schnorr), it is still much much nicer to do with Schnorr and can be integrated with other Schnorr signature variants.
Published:
Welcome to this week’s installment of the introductory Schnorr blog series! So far we have covered (in extreme depth) what Schnorr signatures are and why they work securely. If you didn’t follow or haven’t read the last two posts (detailing Schnorr’s security) you will still be able to read this post (and the remainder of this series) so long as you felt comfortable with the very first post in this series or have a good understanding of how Schnorr signatures work. In this post, we shall begin our exploration of variants of Schnorr signatures which enable countless application use cases, starting with MuSig.
Published:
In the last blog post, we began laying out the groundwork for what will become an argument that Schnorr signatures are secure. We discovered the Schnorr Identity Protocol and proved that it is secure and correct (specifically Complete, Sound, and Honest-Verifier Zero-knowledge). It is very unlikely that this blog post will make much sense if you have not yet read the previous post, so go read it if you haven’t already.
Published:
In the previous post of our introductory Schnorr series, we discussed the definition of Schnorr signatures and tried to build some intuition as to how Schnorr signatures work by looking at a sequence of choices that could have led us to the definition. In this post we will go even deeper and begin an argument for Schnorr’s security by deriving the signature scheme from yet another angle.
Published:
Welcome to the introductory Suredbits Schnorr blog series! In this post, I will explain what Schnorr signatures are and how they intuitively work. In the next post, I will present some evidence as to why this scheme is secure and correct. In the rest of this series, I will be diving into various signatures schemes that Schnorr easily enables and some of their use cases. Before you read on, I recommend you make sure you are comfortable with the following three ideas as I will assume some basic knowledge of them:
Published:
In this post we will delve into the new ideas brought forward in the paper “Generalized Bitcoin-Compatible Channels” for improving the future Lightning Network.
Published:
Transferability of Discreet Log Contracts (DLCs) is of major interest due to the capital inefficiency inherent to contracts which do not rely on custody or counter-party trust. In other words, DLCs require all parties to lock up the maximum collateral that they could lose. This means that if a party wishes to exit their exposure to the DLC outcome, they must either further collateralize themselves by locking up more funds or they can attempt to transfer out of their position by finding themselves a replacement hence unlocking collateral. We have previously discussed how to execute on-chain transfers and transfers of PTLC-based routed DLCs using barrier escrows. In this post we describe a mechanism to transfer in-channel DLC outputs to adjacent channels using HTLCs. Note that the scheme detailed in this post can be used more generally to transfer any generic two-party contract output to an adjacent channel.
Published:
In this series about Payment Points on Lightning, we’ve been focusing on mechanisms that enable somewhat generic off-chain contracts. We’ve discussed how points can enforce monotonic access structures and how we can use Barrier Escrows to make multiple payments atomic. In this last post we will further underscore the usefulness of both monotonic access structures and Barrier Escrows and how they can be combined to enable arbitrary multi-payment/contract transfer and update!
Published:
In the previous post, we discussed how to construct multi-payment Lightning contracts by using Barrier Escrows to make multiple payments atomic. In this post, we will discuss various ways of implementing Barrier Escrows and analyze their trade-offs.
Published:
In the previous post in our Payment Points series, we discussed the large class of contracts that can be created on a PTLC-based Lightning Network using monotonic access structures. In this post, we want to further develop the idea that general contracts that can be created through the use of Payment Points by defining Barrier Escrows which allow us to do atomic multi-payment setup.
Published:
In our past series about Payment Points on Lightning, we covered the foundations of Payment Points and explored some important features they enable.
Published:
In our recent posts, we discussed all the benefits and features enabled by Payment Points on the Lightning Network. We explored how they can protect us from wormhole attacks and payment correlation, how they enable “stuckless” payments, and how they allow escrow contracts over Lightning. In this post we will discuss one of my favorite new features: trustlessly selling signatures!
Published:
In our previous post, we discussed a Lightning Network feature referred to as “Stuckless Payments” that requires Payment Points. Stuckless Payments allow users to attempt multiple payments concurrently. For an in depth description of Payment Points themselves and the problems they solve, see our first post in this series. In this post we’ll continue this thread and discuss another outstanding proposal that would require Payment Points be implemented: Escrow Contracts over Lightning!
Published:
In our previous post, we discussed how using pre-images and payment hashes to make lightning payments atomic results in the possibility of payment correlation and vulnerability to wormhole attacks. We also discussed how replacing pre-images and payment hashes with scalars and payment points allows us to have payment de-correlation, solving the problems with payment hashes. In this blog post we will discuss one of a few of the exciting new features that can exist in a Lightning Network based on payment points!
Published:
Published:
At Suredbits, we use the Lightning Network to create monetized data services. We currently have Lightning APIs selling NFL and NBA stats as well as cryptocurrency market data. In the future, we think that Lightning will be used to monetize all forms of data. Any content such as games, music, sports, weather, financial, or blog posts will be monetized with cryptocurrency. A couple weeks ago, we posted a proposal Lightning Application Standard (LAS) to the lightning-dev mailing list with some details about how we think data should be sold using lightning. We internally refer to this scheme as PAID (Payment-Atomic Information Decryption).
Published:
In cryptography, secret sharing is the process of splitting a secret into pieces, called secret shares, so that no individual device stores the original secret, but some group of devices can collectively recover that secret. Classic examples of situations involving secret sharing include missile launch codes and shared custody in the corporate setting; in both cases, multiple individuals’ authorizations are required before any action can be taken. Recently, secret sharing has seen extensive use within multi-party computation (MPC) involving secret data, and private key management, where an individual or organization has cryptocurrency belonging to a secret key and they wish to split this key into \(n\) key shares such that some subset of \(t\) shares is required for using the key.
Published:
Welcome to this week’s installment of the introductory Schnorr blog series! So far we have covered (in extreme depth) what Schnorr signatures are and why they work securely. If you didn’t follow or haven’t read the last two posts (detailing Schnorr’s security) you will still be able to read this post (and the remainder of this series) so long as you felt comfortable with the very first post in this series or have a good understanding of how Schnorr signatures work. In this post, we shall begin our exploration of variants of Schnorr signatures which enable countless application use cases, starting with MuSig.
Published:
In this post we continue our survey of Schnorr-enabled schemes and their applications to Bitcoin by exploring the exciting world of Scriptless Scripts which are enabled by a signature scheme called Adaptor Signatures. I will note that while it is possible to do adaptor signatures without too much pain in ECDSA (without Schnorr), it is still much much nicer to do with Schnorr and can be integrated with other Schnorr signature variants.
Published:
In this series about Payment Points on Lightning, we’ve been focusing on mechanisms that enable somewhat generic off-chain contracts. We’ve discussed how points can enforce monotonic access structures and how we can use Barrier Escrows to make multiple payments atomic. In this last post we will further underscore the usefulness of both monotonic access structures and Barrier Escrows and how they can be combined to enable arbitrary multi-payment/contract transfer and update!
Published:
In the previous post, we discussed how to construct multi-payment Lightning contracts by using Barrier Escrows to make multiple payments atomic. In this post, we will discuss various ways of implementing Barrier Escrows and analyze their trade-offs.
Published:
In the previous post in our Payment Points series, we discussed the large class of contracts that can be created on a PTLC-based Lightning Network using monotonic access structures. In this post, we want to further develop the idea that general contracts that can be created through the use of Payment Points by defining Barrier Escrows which allow us to do atomic multi-payment setup.
Published:
In our past series about Payment Points on Lightning, we covered the foundations of Payment Points and explored some important features they enable.
Published:
In our recent posts, we discussed all the benefits and features enabled by Payment Points on the Lightning Network. We explored how they can protect us from wormhole attacks and payment correlation, how they enable “stuckless” payments, and how they allow escrow contracts over Lightning. In this post we will discuss one of my favorite new features: trustlessly selling signatures!
Published:
In our previous post, we discussed a Lightning Network feature referred to as “Stuckless Payments” that requires Payment Points. Stuckless Payments allow users to attempt multiple payments concurrently. For an in depth description of Payment Points themselves and the problems they solve, see our first post in this series. In this post we’ll continue this thread and discuss another outstanding proposal that would require Payment Points be implemented: Escrow Contracts over Lightning!
Published:
In our previous post, we discussed how using pre-images and payment hashes to make lightning payments atomic results in the possibility of payment correlation and vulnerability to wormhole attacks. We also discussed how replacing pre-images and payment hashes with scalars and payment points allows us to have payment de-correlation, solving the problems with payment hashes. In this blog post we will discuss one of a few of the exciting new features that can exist in a Lightning Network based on payment points!
Published:
Published:
I know what you’re thinking, “Duh, everyone knows that nonce reuse is bad … why are you writing a blog post about how nonce reuse is insecure?” Fair enough, but hear me out. As we’ll discuss, it is pretty trivial to compute someone’s private key if they are unfortunate enough to reuse a Schnorr signature nonce; however, I claim that it is less clear why nonce reuse leads to practical attacks in the multi-signature scheme MuSig2.
Published:
In cryptography, secret sharing is the process of splitting a secret into pieces, called secret shares, so that no individual device stores the original secret, but some group of devices can collectively recover that secret. Classic examples of situations involving secret sharing include missile launch codes and shared custody in the corporate setting; in both cases, multiple individuals’ authorizations are required before any action can be taken. Recently, secret sharing has seen extensive use within multi-party computation (MPC) involving secret data, and private key management, where an individual or organization has cryptocurrency belonging to a secret key and they wish to split this key into \(n\) key shares such that some subset of \(t\) shares is required for using the key.
Published:
Y’all asked for a high-level, no math, summary of the Schnorr Signature Series and so here you are! If this piques your interest and you are willing/excited to learn some math, check out the series:
Published:
So far in this series we have discussed Schnorr Digital Signatures, their security, and their many variants and benefits. As you may know, Schnorr signatures are going to be introduced to the Bitcoin blockchain using a softfork known as Taproot. In a previous blog post, Ben talked about various ways Taproot may be activated. In this post, we’re going to be talking about exactly what changes are included in the Taproot softfork including how Schnorr signatures will be added!
Published:
In this post we will be discussing one final Schnorr scheme: Blind Signatures. As their name suggests, a Schnorr Blind Signature is a signature where the signer does not know what they have signed. It may be hard to imagine what this could be useful for but it turns out to be a great tool when dealing with “oblivious” servers, which I think have a large role to play in the future of Bitcoin and the internet at large.
Published:
In the last post of this series we discussed Threshold Signature schemes as well as their uses and I’d like to continue that discussion today with an exploration of FROST. FROST can be thought of as the natural extension of MuSig to thresholds (\(t\)-of-\(n\) instead of just \(n\)-of-\(n\)) utilizing distributed key generation. FROST is in some sense the most general threshold scheme we’ve covered so far as it has the awesome feature that it generates keys and signatures indistinguishable (on-chain) from normal (single) Schnorr keys and signatures! In this post, I will be describing FROST in quite a bit of technical detail building up the idea of distributed key generation and then applying it to Schnorr signatures.
Published:
In today’s installment of the Suredbits Schnorr Series, we will begin our exploration of threshold signatures schemes! We will discuss various uses for threshold signatures and then go on to describe three different ways of doing threshold signatures, each with their own pros and cons. The last (and possibly most exciting) threshold signature implementation, FROST, will take a whole blog post to describe, so stay tuned for that post to come next.
Published:
So far in this series, we’ve discussed what Schnorr signatures are, why they are secure, and how Schnorr variants can be used to implement private and scalable multi-signatures and scriptless scripts using adaptor signatures. Today we will be looking at yet another exciting improvement Schnorr will be introducing to the Bitcoin ecosystem, Batch Verification!
Published:
In this post we continue our survey of Schnorr-enabled schemes and their applications to Bitcoin by exploring the exciting world of Scriptless Scripts which are enabled by a signature scheme called Adaptor Signatures. I will note that while it is possible to do adaptor signatures without too much pain in ECDSA (without Schnorr), it is still much much nicer to do with Schnorr and can be integrated with other Schnorr signature variants.
Published:
Welcome to this week’s installment of the introductory Schnorr blog series! So far we have covered (in extreme depth) what Schnorr signatures are and why they work securely. If you didn’t follow or haven’t read the last two posts (detailing Schnorr’s security) you will still be able to read this post (and the remainder of this series) so long as you felt comfortable with the very first post in this series or have a good understanding of how Schnorr signatures work. In this post, we shall begin our exploration of variants of Schnorr signatures which enable countless application use cases, starting with MuSig.
Published:
In the last blog post, we began laying out the groundwork for what will become an argument that Schnorr signatures are secure. We discovered the Schnorr Identity Protocol and proved that it is secure and correct (specifically Complete, Sound, and Honest-Verifier Zero-knowledge). It is very unlikely that this blog post will make much sense if you have not yet read the previous post, so go read it if you haven’t already.
Published:
In the previous post of our introductory Schnorr series, we discussed the definition of Schnorr signatures and tried to build some intuition as to how Schnorr signatures work by looking at a sequence of choices that could have led us to the definition. In this post we will go even deeper and begin an argument for Schnorr’s security by deriving the signature scheme from yet another angle.
Published:
Welcome to the introductory Suredbits Schnorr blog series! In this post, I will explain what Schnorr signatures are and how they intuitively work. In the next post, I will present some evidence as to why this scheme is secure and correct. In the rest of this series, I will be diving into various signatures schemes that Schnorr easily enables and some of their use cases. Before you read on, I recommend you make sure you are comfortable with the following three ideas as I will assume some basic knowledge of them:
Published:
In cryptography, secret sharing is the process of splitting a secret into pieces, called secret shares, so that no individual device stores the original secret, but some group of devices can collectively recover that secret. Classic examples of situations involving secret sharing include missile launch codes and shared custody in the corporate setting; in both cases, multiple individuals’ authorizations are required before any action can be taken. Recently, secret sharing has seen extensive use within multi-party computation (MPC) involving secret data, and private key management, where an individual or organization has cryptocurrency belonging to a secret key and they wish to split this key into \(n\) key shares such that some subset of \(t\) shares is required for using the key.
Published:
Welcome to the introductory Suredbits Schnorr blog series! In this post, I will explain what Schnorr signatures are and how they intuitively work. In the next post, I will present some evidence as to why this scheme is secure and correct. In the rest of this series, I will be diving into various signatures schemes that Schnorr easily enables and some of their use cases. Before you read on, I recommend you make sure you are comfortable with the following three ideas as I will assume some basic knowledge of them:
Published:
In cryptography, secret sharing is the process of splitting a secret into pieces, called secret shares, so that no individual device stores the original secret, but some group of devices can collectively recover that secret. Classic examples of situations involving secret sharing include missile launch codes and shared custody in the corporate setting; in both cases, multiple individuals’ authorizations are required before any action can be taken. Recently, secret sharing has seen extensive use within multi-party computation (MPC) involving secret data, and private key management, where an individual or organization has cryptocurrency belonging to a secret key and they wish to split this key into \(n\) key shares such that some subset of \(t\) shares is required for using the key.
Published:
In the last post of this series we discussed Threshold Signature schemes as well as their uses and I’d like to continue that discussion today with an exploration of FROST. FROST can be thought of as the natural extension of MuSig to thresholds (\(t\)-of-\(n\) instead of just \(n\)-of-\(n\)) utilizing distributed key generation. FROST is in some sense the most general threshold scheme we’ve covered so far as it has the awesome feature that it generates keys and signatures indistinguishable (on-chain) from normal (single) Schnorr keys and signatures! In this post, I will be describing FROST in quite a bit of technical detail building up the idea of distributed key generation and then applying it to Schnorr signatures.
Published:
In today’s installment of the Suredbits Schnorr Series, we will begin our exploration of threshold signatures schemes! We will discuss various uses for threshold signatures and then go on to describe three different ways of doing threshold signatures, each with their own pros and cons. The last (and possibly most exciting) threshold signature implementation, FROST, will take a whole blog post to describe, so stay tuned for that post to come next.