> OP_TRUE is the obvious way to do this, and it results with a 1 on the
stack,
which plays better with other standardness rules.
What other standardness rules? MINAMALIF? How does that interact with the
proposal?
On Thu, Feb 2, 2023 at 3:22 PM Peter Todd wrote:
> On Thu, Feb 02, 2023 at
On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote:
> Quickly checked, it fails a number of standardness tests in unit/functional
> tests in Bitcoin Core, at least.
>
> OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
> just independently arrived at the same
Quickly checked, it fails a number of standardness tests in unit/functional
tests in Bitcoin Core, at least.
OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
just independently arrived at the same conclusion.
On Thu, Feb 2, 2023 at 10:06 AM Peter Todd wrote:
> On Thu,
I am not an expert with RGB, but it looks limited (only bitcoin chains
from the github repo, apparently on hold), distributed over the
"lightning network" or LN nodes (what is it?), or Bifrost extension,
with a dubious token floating around, like ethereum mess as RGB docs
describe Ethereum (and
On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote:
> Hi Peter,
>
> For the most principled of reasons:
>
> Because I have to change test vectors everywhere!
Specifically, you mean you'd have to change tests that test something is
non-standard?
--
https://petertodd.org
Hi Peter,
For the most principled of reasons:
Because I have to change test vectors everywhere!
Greg
On Thu, Feb 2, 2023 at 9:52 AM Peter Todd wrote:
> On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev
> wrote:
> > Hello again dev,
> >
> > Due to the interest in the
On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev wrote:
> Hello again dev,
>
> Due to the interest in the proposal and the prodding of certain folks, I've
> written up a short draft BIP of the Ephemeral Anchors idea here:
>
On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a
Hi Anthony,
> I think, however, that you can move inscriptions entirely off-chain. I
wrote a little on this idea on twitter already [1], but after a bit more
thought, I think pushing things even further off-chain would be plausible.
Whole point of inscriptions is to keep something on-chain
Hi AJ and List,
This reminds me of a series of blog posts Peter Todd wrote a few years
ago about using "single use seals" for tracking (fungible) assets
anchored to Bitcoin[0]. I believe that the RBG Protocol Project and Taro
are both using the same underlying principle.
Having the actual
Hello Christopher,
I think if the protocol that you were designing always had <80 bytes,
I'd prefer the OP_RETURN. I think the "witness envelope" has two major
disadvantages compared to the OP_RETURN method:
1. You need to first spend to he address that commits to the script that
encodes your
In your system what is the off-chain mechanism? And what prevent a thief
to steal your NFT?
I have submitted several time "A Bitcoin NFT system"
https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
It's more simple, the NFT (whether real or electronic) is referenced by
a initial hash
Thanks, then this limitation should be rethought I think (see the email
I just sent replying to the coloured thread)
Because it forces people to store in witness (less easy to track/show I
believe) or adopt some deviant behavior (like storing in addresses where
the utxo will remain unspendable
As far as I can read nobody replied to the initial question: what is
considered as good/best practice to store in Bitcoin?
Reiterating my question: what are the current rules for OP_RETURN, max
size and number of OP_RETURN per tx
Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit :
> On
On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote:
> As far as I can read nobody replied to the initial question: what is
> considered as good/best practice to store in Bitcoin?
Your answer is beyond not putting unspendable data in the UTXO set, the exact
details don't really matter.
On Wed, Feb 01, 2023 at 02:02:41PM +, Andrew Poelstra wrote:
> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
> >
> >
> > On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev
> > wrote:
> > >All other things being equal, which is better if you
Hi *,
Casey Rodarmor's ordinals use the technique of tracking the identity of
individual satoshis throughout their lifetime:
On Tue, Feb 22, 2022 at 04:43:52PM -0800, Casey Rodarmor via bitcoin-dev wrote:
> Briefly, newly mined satoshis are sequentially numbered in the order in
> which they are
## Intro
Most of it feels like implicit knowledge, but I couldn't find anything written
so here it is. The ideas towards anchor outputs and the conclusions probably
have some new perspectives.
This post is about the game-theoretic security of time-sensitive protocols if
miners are open to
18 matches
Mail list logo
