Re: [bitcoin-dev] bitcoin scripting and lisp

[Russell O'Connor via bitcoin-dev]

The circuit generated from Simplicity was larger than the hand made one.

On Sat, Mar 5, 2022 at 6:20 PM ZmnSCPxj  wrote:

> Good morning Russell,
>
> > On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > It seems like a decent concept for exploration.
> > >
> > > AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the Lightning
> Network look like on Chia?
> > >
> > > One question that I have had is that it seems like to me that neither
> simplicity nor chia lisp would be particularly suited to a ZK prover...
> >
> > Not that I necessarily disagree with this statement, but I can say that
> I have experimented with compiling Simplicity to Boolean circuits.  It was
> a while ago, but I think the result of compiling my SHA256 program was
> within an order of magnitude of the hand made SHA256 circuit for
> bulletproofs.
>
> "Within" can mean "larger" or "smaller" in this context, which was it?
> From what I understand, compilers for ZK-provable circuits are still not
> as effective as humans, so I would assume "larger", but I would be much
> interested if it is "smaller"!
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Jeremy Rubin via bitcoin-dev]

This may be of interest:

https://github.com/sapio-lang/sapio/blob/01830132bbbe39c3225e173e099f6e1a0611461c/sapio/examples/subscription.py

Basically, a (old, python) sapio contract whereby you can make cancellable
subscriptions that are essentially a time based autopay scheme whereby
cancellation gives time for the receiver to claim the correct amount of
money.

--
@JeremyRubin 

On Sat, Mar 5, 2022 at 10:58 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Chris,
>
> > I think this proposal describes arbitrary lines of pre-approved credit
> from a bitcoin wallet. The line can be drawn down with oracle attestations.
> You can mix in locktimes on these pre-approved lines of credit if you would
> like to rate limit, or ignore rate limiting and allow the full utxo to be
> spent by the borrower. It really is contextual to the use case IMO.
>
> Ah, that seems more useful.
>
> Here is an example application that might benefit from this scheme:
>
> I am commissioning some work from some unbranded workperson.
> I do not know how long the work will take, and I do not trust the
> workperson to accurately tell me how complete the work is.
> However, both I and the workperson trust a branded third party (the
> oracle) who can judge the work for itself and determine if it is complete
> or not.
> So I create a transaction whose signature can be completed only if the
> oracle releases a proper scalar and hand it over to the workperson.
> Then the workperson performs the work, then asks the oracle to judge if
> the work has been completed, and if so, the work can be compensated.
>
> On the other hand, the above, where the oracle determines *when* the fund
> can be spent, can also be implemented by a simple 2-of-3, and called an
> "escrow".
> After all, the oracle attestation can be a partial signature as well, not
> just a scalar.
> Is there a better application for this scheme?
>
> I suppose if the oracle attestation is intended to be shared among
> multiple such transactions?
> There may be multiple PTLCs, that are triggered by a single oracle?
>
> Regards,
> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] One testnet to rule them all

[Jeremy Rubin via bitcoin-dev]

Signet degrades to a testnet if you make your key OP_TRUE.


It's not about needing 21M coins it's about easily getting access to said
coins for testing, where it's kinda tricky to get testnet coins.

On Sat, Mar 5, 2022, 6:17 PM  wrote:

> > There's no point to pegging coins that are worthless into a system of
> also worthless coins, unless you want to test the mechanism of testing
> pegging.
>
> But testing pegging is what is needed if we ever want to introduce
> sidechains. On the other hand, even if we don't want sidechains, then the
> question still remains: why we need more than 21 million coins for testing,
> if we don't need more than 21 million coins for real transactions?
>
> > If anything I think we should permanently shutter testnet now that
> signet is available.
>
> Then, in that case, the "mainchain" can be our official signet and other
> signets can be pegged into that. Also, testnet3 is permissionless, so how
> signet can replace that? Because if you want to test mining and you cannot
> mine any blocks in signet, then it is another problem.
>
> On 2022-03-05 17:19:40 user Jeremy Rubin  wrote:
> There's no point to pegging coins that are worthless into a system of also
> worthless coins, unless you want to test the mechanism of testing pegging.
>
>
> As is, it's hard enough to get people set up on a signet, if they have to
> run two nodes and then scramble to find testnet coins and then peg them
> were just raising the barriers to entry for starting to use a signet for
> testing.
>
>
>
>
> If anything I think we should permanently shutter testnet now that signet
> is available.
>
>
> On Sat, Mar 5, 2022, 3:53 PM vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> In testnet3, anyone can become a miner, it is possible to even mine a
> block on some CPU, because the difficulty can drop to one. In signet, we
> create some challenge, for example 1-of-2 multisig, that can restrict who
> can mine, so that chain can be "unreliably reliable". Then, my question is:
> why signets are introducing new coins out of thin air, instead of forming
> two-way peg-in between testnet3 and signet?
>
> The lack of coins is not a bug, it is a feature. We have more halvings in
> testnet3 than in mainnet or signets, but it can be good, we can use this to
> see, what can happen with a chain after many halvings. Also, in testnet3
> there is no need to have any coins if we are mining. Miners can create,
> move and destroy zero satoshis. They can also extend the precision of the
> coins, so a single coin in testnet3 can be represented as a thousand of
> coins in some signet sidechain.
>
> Recently, there are some discussions regarding sidechains. Before they
> will become a real thing, running on mainnet, they should be tested.
> Nowadays, a popular way of testing new features is creating a new signet
> with new rules. But the question still remains: why we need new coins,
> created out of thin air? And even when some signet wants to do that, then
> why it is not pegged into testnet3? Then it would have as much chainwork
> protection as testnet3!
>
> It seems that testnet3 is good enough to represent the main chain during
> sidechain testing. It is permissionless and open, anyone can start mining
> sidechain blocks, anyone with a CPU can be lucky and find a block with the
> minimal difficulty. Also, because of blockstorms and regular chain reorgs,
> some extreme scenarios, like stealing all coins from some sidechain, can be
> tested in a public way, because that "unfriendly and unstable" environment
> can be used to test stronger attacks than in a typical chain.
>
> Putting that proposal into practice can be simple and require just
> creating one Taproot address per signet in testnet3. Then, it is possible
> to create one testnet transaction (every three months) that would move
> coins to and from testnet3, so the same coins could travel between many
> signets. New signets can be pegged in with 1:1 ratio, existing signets can
> be transformed into signet sidechains (the signet miners rule that chains,
> so they can enforce any transition rules they need).
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[ZmnSCPxj via bitcoin-dev]

Good morning Russell,

> On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev 
>  wrote:
>
> > It seems like a decent concept for exploration.
> >
> > AJ, I'd be interested to know what you've been able to build with Chia Lisp 
> > and what your experience has been... e.g. what does the Lightning Network 
> > look like on Chia?
> >
> > One question that I have had is that it seems like to me that neither 
> > simplicity nor chia lisp would be particularly suited to a ZK prover...
>
> Not that I necessarily disagree with this statement, but I can say that I 
> have experimented with compiling Simplicity to Boolean circuits.  It was a 
> while ago, but I think the result of compiling my SHA256 program was within 
> an order of magnitude of the hand made SHA256 circuit for bulletproofs.

"Within" can mean "larger" or "smaller" in this context, which was it?
From what I understand, compilers for ZK-provable circuits are still not as 
effective as humans, so I would assume "larger", but I would be much interested 
if it is "smaller"!

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT

[ZmnSCPxj via bitcoin-dev]

Good morning Billy,

> It sounds like the primary benefit of op_fold is bandwidth savings. 
> Programming as compression. But as you mentioned, any common script could be 
> implemented as a Simplicity jet. In a world where Bitcoin implements jets, 
> op_fold would really only be useful for scripts that can't use jets, which 
> would basically be scripts that aren't very often used. But that inherently 
> limits the usefulness of the opcode. So in practice, I think it's likely that 
> jets cover the vast majority of use cases that op fold would otherwise have.

I suppose the point would be --- how often *can* we add new jets?
Are new jets consensus critical?
If a new jet is released but nobody else has upgraded, how bad is my security 
if I use the new jet?
Do I need to debate `LOT` *again* if I want to propose a new jet?

> A potential benefit of op fold is that people could implement smaller scripts 
> without buy-in from a relay level change in Bitcoin. However, even this could 
> be done with jets. For example, you could implement a consensus change to add 
> a transaction type that declares a new script fragment to keep a count of, 
> and if the script fragment is used enough within a timeframe (eg 1 
> blocks) then it can thereafter be referenced by an id like a jet could be. 
> I'm sure someone's thought about this kind of thing before, but such a thing 
> would really relegate the compression abilities of op fold to just the most 
> uncommon of scripts. 
>
> > * We should provide more *general* operations. Users should then combine 
> > those operations to their specific needs.
> > * We should provide operations that *do more*. Users should identify their 
> > most important needs so we can implement them on the blockchain layer.
>
> That's a useful way to frame this kind of problem. I think the answer is, as 
> it often is, somewhere in between. Generalization future-proofs your system. 
> But at the same time, the boundary conditions of that generalized 
> functionality should still be very well understood before being added to 
> Bitcoin. The more general, the harder to understand the boundaries. So imo we 
> should be implementing the most general opcodes that we are able to reason 
> fully about and come to a consensus on. Following that last constraint might 
> lead to not choosing very general opcodes.

Yes, that latter part is what I am trying to target with `OP_FOLD`.
As I point out, given the restrictions I am proposing, `OP_FOLD` (and any 
bounded loop construct with similar restrictions) is implementable in current 
Bitcoin SCRIPT, so it is not an increase in attack surface.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[ZmnSCPxj via bitcoin-dev]

Good morning Chris,

> I think this proposal describes arbitrary lines of pre-approved credit from a 
> bitcoin wallet. The line can be drawn down with oracle attestations. You can 
> mix in locktimes on these pre-approved lines of credit if you would like to 
> rate limit, or ignore rate limiting and allow the full utxo to be spent by 
> the borrower. It really is contextual to the use case IMO.

Ah, that seems more useful.

Here is an example application that might benefit from this scheme:

I am commissioning some work from some unbranded workperson.
I do not know how long the work will take, and I do not trust the workperson to 
accurately tell me how complete the work is.
However, both I and the workperson trust a branded third party (the oracle) who 
can judge the work for itself and determine if it is complete or not.
So I create a transaction whose signature can be completed only if the oracle 
releases a proper scalar and hand it over to the workperson.
Then the workperson performs the work, then asks the oracle to judge if the 
work has been completed, and if so, the work can be compensated.

On the other hand, the above, where the oracle determines *when* the fund can 
be spent, can also be implemented by a simple 2-of-3, and called an "escrow".
After all, the oracle attestation can be a partial signature as well, not just 
a scalar.
Is there a better application for this scheme?

I suppose if the oracle attestation is intended to be shared among multiple 
such transactions?
There may be multiple PTLCs, that are triggered by a single oracle?

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[Russell O'Connor via bitcoin-dev]

On Sat, Mar 5, 2022 at 8:41 AM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It seems like a decent concept for exploration.
>
> AJ, I'd be interested to know what you've been able to build with Chia
> Lisp and what your experience has been... e.g. what does the Lightning
> Network look like on Chia?
>
>
> One question that I have had is that it seems like to me that neither
> simplicity nor chia lisp would be particularly suited to a ZK prover...
>

Not that I necessarily disagree with this statement, but I can say that I
have experimented with compiling Simplicity to Boolean circuits.  It was a
while ago, but I think the result of compiling my SHA256 program was within
an order of magnitude of the hand made SHA256 circuit for bulletproofs.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Draft Submission

[Billy Tetrud via bitcoin-dev]

If you're serious about this, you should write up considerations around
using the satoshi as a unit. That unit has none of the problems you
describe. Satoshis is already a well accepted unit, and is likely to be a
very practical one that might match within an order of magnitude of (the
current buying power of) US cents.

> this BIP is a consensus change around the display of Bitcoin wallet
balances

Fyi, this is not something that's considered a "consensus change", which is
something that affects the validity of a block.

On Fri, Mar 4, 2022, 09:19 Asher Hopp via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is my first time submitting anything to this mailer list, so I am
> here with humility and I would appreciate any feedback about any aspect of
> my BIP draft submission below. If you want to reach out to me directly you
> can email me at as...@seent.com.
>
> Abstract
> Rather than having a maximum supply of 21 million Bitcoin, there should be
> a maximum supply of 21 trillion Bitcoin. This can be accomplished by moving
> the decimal place 6 places to the right of where it is today, while
> reserving two degrees of accuracy after the decimal point.
>
> Copyright
> This BIP is under the Creative Commons Zero (CC0) license.
>
> Background
> On February 6th, 2010 Satoshi Nakamoto responded to a bitcointalk forum
> discussion about the divisibility and economics of bitcoin as a global
> currency. Satoshi chimed in to the conversation when two ideas formed:
> 1. Bitcoin is so scarce that a perception may exist that there is not
> enough to go around – there is not even 1 Bitcoin available per person on
> Earth.
> 2. If Bitcoin’s value continues to deflate against inflating fiat
> currencies, Bitcoin transactions may become smaller and smaller, requiring
> the potentially tedious use of many leading 0’s after the decimal point.
>
> Satoshi’s suggested response to these issues was a software update to
> change where the decimal place and commas are displayed when software
> interprets a Bitcoin wallet’s balance: “If it gets tiresome working with
> small numbers, we could change where the display shows the decimal point.
> Same amount of money, just different convention for where the ","'s and
> "."'s go.  e.g. moving the decimal place 3 places would mean if you had
> 1.0 before, now it shows it as 1,000.00.” (
> https://bitcointalk.org/index.php?topic=44.msg267#msg267)
>
> Since 2010, when Satoshi wrote that post Bitcoin has indeed become a
> globally adopted currency, the dollar has inflated significantly, and
> Bitcoin has deflated. There are many debates in the Bitcoin community
> concerning the nomenclature of Bitcoin’s atomic unit (satoshis, sats, bits,
> bitcents, mbits, etc). The debate has somewhat spiraled out of control, and
> there is no clearly emerging community consensus. Additionally this issue
> impacts the technology world outside of Bitcoin because there are several
> proposals for various Unicode characters which factions of the Bitcoin
> community have started using to represent the atomic Bitcoin unit despite
> no formalized consensus.  Therefore The conditions are right to move
> forward with Satoshi's vision and move the decimal place.
>
> Details
> There are several benefits to moving the decimal 6 places to the right in
> Bitcoin wallet balance notation:
> 1. Unit bias. It is a widely held belief that Bitcoin’s adoption may be
> hindered because would-be participants have a negative perception of
> Bitcoin’s unit size. One Bitcoin so expensive, and some people may be
> turned off by the idea of only owning a fraction of a unit.
> 2. Community cohesion. The Bitcoin community is deeply divided by various
> proposed atomic unit names, but if this BIP is adopted there is no need to
> debate nomenclature for the Bitcoin atomic unit. Bitcoin software providers
> can simply continue using the Bitcoin Unicode character (₿, U+20BF), and
> there are no additional unicode characters required.
> 3. Simplicity and standardization. Bitcoin has no borders and is used by
> people in just about every corner of the world. Other than the name Bitcoin
> and the Unicode character we have, there is no consensus around other
> notations for Bitcoin as a currency. Rather than introducing new concepts
> for people to learn, this BIP allows Bitcoin to grow under a single
> standardized unit specification, with a single standard unit name, unit
> size, and unit Unicode character.
>
> There is only one drawback I can identify with this BIP, and it is purely
> psychological. Moving the decimal place may produce bad optics in the
> short-term, and Bitcoin’s detractors will likely seize the opportunity to
> spread misinformation that moving the decimal place changes the monetary
> value of anyone’s Bitcoin. It is important to note that if this BIP were to
> gain consensus approval, the community would need to prepare talking points
> and coordinate educational outreach efforts to explain 

Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT

[Billy Tetrud via bitcoin-dev]

It sounds like the primary benefit of op_fold is bandwidth savings.
Programming as compression. But as you mentioned, any common script could
be implemented as a Simplicity jet. In a world where Bitcoin implements
jets, op_fold would really only be useful for scripts that can't use jets,
which would basically be scripts that aren't very often used. But that
inherently limits the usefulness of the opcode. So in practice, I think
it's likely that jets cover the vast majority of use cases that op fold
would otherwise have.

A potential benefit of op fold is that people could implement smaller
scripts without buy-in from a relay level change in Bitcoin. However, even
this could be done with jets. For example, you could implement a consensus
change to add a transaction type that declares a new script fragment to
keep a count of, and if the script fragment is used enough within a
timeframe (eg 1 blocks) then it can thereafter be referenced by an id
like a jet could be. I'm sure someone's thought about this kind of thing
before, but such a thing would really relegate the compression abilities of
op fold to just the most uncommon of scripts.

> * We should provide more *general* operations. Users should then combine
those operations to their specific needs.
> * We should provide operations that *do more*. Users should identify
their most important needs so we can implement them on the blockchain layer.

That's a useful way to frame this kind of problem. I think the answer is,
as it often is, somewhere in between. Generalization future-proofs your
system. But at the same time, the boundary conditions of that generalized
functionality should still be very well understood before being added to
Bitcoin. The more general, the harder to understand the boundaries. So imo
we should be implementing the most general opcodes that we are able to
reason fully about and come to a consensus on. Following that last
constraint might lead to not choosing very general opcodes.

On Sun, Feb 27, 2022, 10:34 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
> =
>
> (This writeup requires at least some programming background, which I
> expect most readers of this list have.)
>
> Recently, some rando was ranting on the list about this weird crap
> called `OP_EVICT`, a poorly-thought-out attempt at covenants.
>
> In reaction to this, AJ Towns mailed me privately about some of his
> thoughts on this insane `OP_EVICT` proposal.
> He observed that we could generalize the `OP_EVICT` opcode by
> decomposing it into smaller parts, including an operation congruent
> to the Scheme/Haskell/Scala `map` operation.
> As `OP_EVICT` effectively loops over the outputs passed to it, a
> looping construct can be used to implement `OP_EVICT` while retaining
> its nice property of cut-through of multiple evictions and reviving of
> the CoinPool.
>
> More specifically, an advantage of `OP_EVICT` is that it allows
> checking multiple published promised outputs.
> This would be implemented in a loop.
> However, if we want to instead provide *general* operations in
> SCRIPT rather than a bunch of specific ones like `OP_EVICT`, we
> should consider how to implement looping so that we can implement
> `OP_EVICT` in a SCRIPT-with-general-opcodes.
>
> (`OP_FOLD` is not sufficient to implement `OP_EVICT`; for
> efficiency, AJ Towns also pointed out that we need some way to
> expose batch validation to SCRIPT.
> There is a follow-up writeup to this one which describes *that*
> operation.)
>
> Based on this, I started ranting as well about how `map` is really
> just a thin wrapper on `foldr` and the *real* looping construct is
> actually `foldr` (`foldr` is the whole FP Torah: all the rest is
> commentary).
> This is thus the genesis for this proposal, `OP_FOLD`.
>
> A "fold" operation is sometimes known as "reduce" (and if you know
> about Google MapReduce, you might be familiar with "reduce").
> Basically, a "fold" or "reduce" operation applies a function
> repeatedly (i.e. *loops*) on the contents of an input structure,
> creating a "sum" or "accumulation" of the contents.
>
> For the purpose of building `map` out of `fold`, the accumulation
> can itself be an output structure.
> The `map` simply accumulates to the output structure by applying
> its given function and concatenating it to the current accumulation.
>
> Digression: Programming Is Compression
> --
>
> Suppose you are a programmer and you are reading some source code.
> You want to wonder "what will happen if I give this piece of code
> these particular inputs?".
>
> In order to do so, you would simulate the execution of the code in
> your head.
> In effect, you would generate a "trace" of basic operations (that
> do not include control structures).
> By then thinking about this linear trace of basic operations, you
> can figure out what the 

Re: [bitcoin-dev] One testnet to rule them all

[vjudeu via bitcoin-dev]

> There's no point to pegging coins that are worthless into a system of also 
> worthless coins, unless you want to test the mechanism of testing pegging.

But testing pegging is what is needed if we ever want to introduce sidechains. 
On the other hand, even if we don't want sidechains, then the question still 
remains: why we need more than 21 million coins for testing, if we don't need 
more than 21 million coins for real transactions?

> If anything I think we should permanently shutter testnet now that signet is 
> available.

Then, in that case, the "mainchain" can be our official signet and other 
signets can be pegged into that. Also, testnet3 is permissionless, so how 
signet can replace that? Because if you want to test mining and you cannot mine 
any blocks in signet, then it is another problem.

On 2022-03-05 17:19:40 user Jeremy Rubin  wrote:
There's no point to pegging coins that are worthless into a system of also 
worthless coins, unless you want to test the mechanism of testing pegging.


As is, it's hard enough to get people set up on a signet, if they have to run 
two nodes and then scramble to find testnet coins and then peg them were just 
raising the barriers to entry for starting to use a signet for testing.




If anything I think we should permanently shutter testnet now that signet is 
available.


On Sat, Mar 5, 2022, 3:53 PM vjudeu via bitcoin-dev 
 wrote:
In testnet3, anyone can become a miner, it is possible to even mine a block on 
some CPU, because the difficulty can drop to one. In signet, we create some 
challenge, for example 1-of-2 multisig, that can restrict who can mine, so that 
chain can be "unreliably reliable". Then, my question is: why signets are 
introducing new coins out of thin air, instead of forming two-way peg-in 
between testnet3 and signet?

The lack of coins is not a bug, it is a feature. We have more halvings in 
testnet3 than in mainnet or signets, but it can be good, we can use this to 
see, what can happen with a chain after many halvings. Also, in testnet3 there 
is no need to have any coins if we are mining. Miners can create, move and 
destroy zero satoshis. They can also extend the precision of the coins, so a 
single coin in testnet3 can be represented as a thousand of coins in some 
signet sidechain.

Recently, there are some discussions regarding sidechains. Before they will 
become a real thing, running on mainnet, they should be tested. Nowadays, a 
popular way of testing new features is creating a new signet with new rules. 
But the question still remains: why we need new coins, created out of thin air? 
And even when some signet wants to do that, then why it is not pegged into 
testnet3? Then it would have as much chainwork protection as testnet3!

It seems that testnet3 is good enough to represent the main chain during 
sidechain testing. It is permissionless and open, anyone can start mining 
sidechain blocks, anyone with a CPU can be lucky and find a block with the 
minimal difficulty. Also, because of blockstorms and regular chain reorgs, some 
extreme scenarios, like stealing all coins from some sidechain, can be tested 
in a public way, because that "unfriendly and unstable" environment can be used 
to test stronger attacks than in a typical chain.

Putting that proposal into practice can be simple and require just creating one 
Taproot address per signet in testnet3. Then, it is possible to create one 
testnet transaction (every three months) that would move coins to and from 
testnet3, so the same coins could travel between many signets. New signets can 
be pegged in with 1:1 ratio, existing signets can be transformed into signet 
sidechains (the signet miners rule that chains, so they can enforce any 
transition rules they need).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] One testnet to rule them all

[Jeremy Rubin via bitcoin-dev]

There's no point to pegging coins that are worthless into a system of also
worthless coins, unless you want to test the mechanism of testing pegging.

As is, it's hard enough to get people set up on a signet, if they have to
run two nodes and then scramble to find testnet coins and then peg them
were just raising the barriers to entry for starting to use a signet for
testing.


If anything I think we should permanently shutter testnet now that signet
is available.

On Sat, Mar 5, 2022, 3:53 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In testnet3, anyone can become a miner, it is possible to even mine a
> block on some CPU, because the difficulty can drop to one. In signet, we
> create some challenge, for example 1-of-2 multisig, that can restrict who
> can mine, so that chain can be "unreliably reliable". Then, my question is:
> why signets are introducing new coins out of thin air, instead of forming
> two-way peg-in between testnet3 and signet?
>
> The lack of coins is not a bug, it is a feature. We have more halvings in
> testnet3 than in mainnet or signets, but it can be good, we can use this to
> see, what can happen with a chain after many halvings. Also, in testnet3
> there is no need to have any coins if we are mining. Miners can create,
> move and destroy zero satoshis. They can also extend the precision of the
> coins, so a single coin in testnet3 can be represented as a thousand of
> coins in some signet sidechain.
>
> Recently, there are some discussions regarding sidechains. Before they
> will become a real thing, running on mainnet, they should be tested.
> Nowadays, a popular way of testing new features is creating a new signet
> with new rules. But the question still remains: why we need new coins,
> created out of thin air? And even when some signet wants to do that, then
> why it is not pegged into testnet3? Then it would have as much chainwork
> protection as testnet3!
>
> It seems that testnet3 is good enough to represent the main chain during
> sidechain testing. It is permissionless and open, anyone can start mining
> sidechain blocks, anyone with a CPU can be lucky and find a block with the
> minimal difficulty. Also, because of blockstorms and regular chain reorgs,
> some extreme scenarios, like stealing all coins from some sidechain, can be
> tested in a public way, because that "unfriendly and unstable" environment
> can be used to test stronger attacks than in a typical chain.
>
> Putting that proposal into practice can be simple and require just
> creating one Taproot address per signet in testnet3. Then, it is possible
> to create one testnet transaction (every three months) that would move
> coins to and from testnet3, so the same coins could travel between many
> signets. New signets can be pegged in with 1:1 ratio, existing signets can
> be transformed into signet sidechains (the signet miners rule that chains,
> so they can enforce any transition rules they need).
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] One testnet to rule them all

[vjudeu via bitcoin-dev]

In testnet3, anyone can become a miner, it is possible to even mine a block on 
some CPU, because the difficulty can drop to one. In signet, we create some 
challenge, for example 1-of-2 multisig, that can restrict who can mine, so that 
chain can be "unreliably reliable". Then, my question is: why signets are 
introducing new coins out of thin air, instead of forming two-way peg-in 
between testnet3 and signet?

The lack of coins is not a bug, it is a feature. We have more halvings in 
testnet3 than in mainnet or signets, but it can be good, we can use this to 
see, what can happen with a chain after many halvings. Also, in testnet3 there 
is no need to have any coins if we are mining. Miners can create, move and 
destroy zero satoshis. They can also extend the precision of the coins, so a 
single coin in testnet3 can be represented as a thousand of coins in some 
signet sidechain.

Recently, there are some discussions regarding sidechains. Before they will 
become a real thing, running on mainnet, they should be tested. Nowadays, a 
popular way of testing new features is creating a new signet with new rules. 
But the question still remains: why we need new coins, created out of thin air? 
And even when some signet wants to do that, then why it is not pegged into 
testnet3? Then it would have as much chainwork protection as testnet3!

It seems that testnet3 is good enough to represent the main chain during 
sidechain testing. It is permissionless and open, anyone can start mining 
sidechain blocks, anyone with a CPU can be lucky and find a block with the 
minimal difficulty. Also, because of blockstorms and regular chain reorgs, some 
extreme scenarios, like stealing all coins from some sidechain, can be tested 
in a public way, because that "unfriendly and unstable" environment can be used 
to test stronger attacks than in a typical chain.

Putting that proposal into practice can be simple and require just creating one 
Taproot address per signet in testnet3. Then, it is possible to create one 
testnet transaction (every three months) that would move coins to and from 
testnet3, so the same coins could travel between many signets. New signets can 
be pegged in with 1:1 ratio, existing signets can be transformed into signet 
sidechains (the signet miners rule that chains, so they can enforce any 
transition rules they need).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

[Chris Stewart via bitcoin-dev]

Hey ZmnSCPxj,

I thought about this for a few days and I think you are right. In the case
of recurring payments this is identical to nLocktime. When doing recurring
payments with this scheme, you probably want to rate limit subsequent UTXOs
_with_ nlocktimes to make sure a malicious Netflix can't withdraw 12 month
so of subscriptions by attesting with their oracle 12 times.

I think this proposal describes arbitrary lines of pre-approved credit from
a bitcoin wallet. The line can be drawn down with oracle attestations. You
can mix in locktimes on these pre-approved lines of credit if you would
like to rate limit, or ignore rate limiting and allow the full utxo to be
spent by the borrower. It really is contextual to the use case IMO.

-Chris

On Fri, Mar 4, 2022 at 2:22 AM ZmnSCPxj  wrote:

>
> Good morning Chris,
>
> Quick question.
>
> How does this improve over just handing over `nLockTime`d transactions?
>
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin scripting and lisp

[Jeremy Rubin via bitcoin-dev]

It seems like a decent concept for exploration.

AJ, I'd be interested to know what you've been able to build with Chia Lisp
and what your experience has been... e.g. what does the Lightning Network
look like on Chia?


One question that I have had is that it seems like to me that neither
simplicity nor chia lisp would be particularly suited to a ZK prover...

Were that the explicit goal, it would seem that we could pretty easily
adapt something like Cairo for Bitcoin transactions, and then we'd get a
big privacy benefit as well as enabling whatever programming paradigm you
find convenient (as it is compiled to a circuit verifier of some kind)...

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Annex Purpose Discussion: OP_ANNEX, Turing Completeness, and other considerations

[Jeremy Rubin via bitcoin-dev]

On Sat, Mar 5, 2022 at 5:59 AM Anthony Towns  wrote:

> On Fri, Mar 04, 2022 at 11:21:41PM +, Jeremy Rubin via bitcoin-dev
> wrote:
> > I've seen some discussion of what the Annex can be used for in Bitcoin.
>
>
> https://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-12-19.00.log.html
>
> includes some discussion on that topic from the taproot review meetings.
>
> The difference between information in the annex and information in
> either a script (or the input data for the script that is the rest of
> the witness) is (in theory) that the annex can be analysed immediately
> and unconditionally, without necessarily even knowing anything about
> the utxo being spent.
>

I agree that should happen, but there are cases where this would not work.
E.g., imagine OP_LISP_EVAL + OP_ANNEX... and then you do delegation via the
thing in the annex.

Now the annex can be executed as a script.



>
> The idea is that we would define some simple way of encoding (multiple)
> entries into the annex -- perhaps a tag/length/value scheme like
> lightning uses; maybe if we add a lisp scripting language to consensus,
> we just reuse the list encoding from that? -- at which point we might
> use one tag to specify that a transaction uses advanced computation, and
> needs to be treated as having a heavier weight than its serialized size
> implies; but we could use another tag for per-input absolute locktimes;
> or another tag to commit to a past block height having a particular hash.
>

Yes, this seems tough to do without redefining checksig to allow partial
annexes. Hence thinking we should make our current checksig behavior
require it be 0, future operations should be engineered with specific
structured annex in mind.



>
> It seems like a good place for optimising SIGHASH_GROUP (allowing a group
> of inputs to claim a group of outputs for signing, but not allowing inputs
> from different groups to ever claim the same output; so that each output
> is hashed at most once for this purpose) -- since each input's validity
> depends on the other inputs' state, it's better to be able to get at
> that state as easily as possible rather than having to actually execute
> other scripts before your can tell if your script is going to be valid.
>

I think SIGHASH_GROUP could be some sort of mutable stack value, not ANNEX.
you want to be able to compute what range you should sign, and then the
signature should cover the actual range not the argument itself.

Why sign the annex literally?

Why require that all signatures in one output sign the exact same digest?
What if one wants to sign for value and another for value + change?



>
> > The BIP is tight lipped about it's purpose
>
> BIP341 only reserves an area to put the annex; it doesn't define how
> it's used or why it should be used.
>
>
It does define how it's used, Checksig must commit to it. Were there no
opcodes dependent on it I would agree, and that would be preferable.




> > Essentially, I read this as saying: The annex is the ability to pad a
> > transaction with an additional string of 0's
>
> If you wanted to pad it directly, you can do that in script already
> with a PUSH/DROP combo.
>

You cannot, because the push/drop would not be signed and would be
malleable.

The annex is not malleable, so it can be used to this as authenticated
padding.



>
> The point of doing it in the annex is you could have a short byte
> string, perhaps something like "0x010201a4" saying "tag 1, data length 2
> bytes, value 420" and have the consensus intepretation of that be "this
> transaction should be treated as if it's 420 weight units more expensive
> than its serialized size", while only increasing its witness size by
> 6 bytes (annex length, annex flag, and the four bytes above). Adding 6
> bytes for a 426 weight unit increase seems much better than adding 426
> witness bytes.
>
>
Yes, that's what I say in the next sentence,

*> Or, we might somehow make the witness a small language (e.g., run length
encoded zeros) such that we can very quickly compute an equivalent number
of zeros to 'charge' without actually consuming the space but still
consuming a linearizable resource... or something like that.*

so I think we concur on that.



> > Introducing OP_ANNEX: Suppose there were some sort of annex pushing
> opcode,
> > OP_ANNEX which puts the annex on the stack
>
> I think you'd want to have a way of accessing individual entries from
> the annex, rather than the annex as a single unit.
>

Or OP_ANNEX + OP_SUBSTR + OP_POVARINTSTR? Then you can just do 2 pops for
the length and the tag and then get the data.


>
> > Now suppose that I have a computation that I am running in a script as
> > follows:
> >
> > OP_ANNEX
> > OP_IF
> > `some operation that requires annex to be <1>`
> > OP_ELSE
> > OP_SIZE
> > `some operation that requires annex to be len(annex) + 1 or does a
> > checksig`
> > OP_ENDIF
> >
> > Now every time you run this,
>
> You only