Good morning Zac,
> Hi ZmnSCPxj,
>
> Any benefits of my proposal depend on my presumption that using a standard
> transaction for storing data must be inefficient. Presumably a transaction
> takes up significantly more on-chain space than the data it carries within
> its OP_RETURN. Therefore, n
Hi ZmnSCPxj,
Any benefits of my proposal depend on my presumption that using a standard
transaction for storing data must be inefficient. Presumably a transaction
takes up significantly more on-chain space than the data it carries within
its OP_RETURN. Therefore, not requiring a standard transacti
Good morning Zac,
> Reducing the footprint of storing data on-chain might better be achieved by
> *supporting* it.
>
> Currently storing data is wasteful because it is embedded inside an OP_RETURN
> within a transaction structure. As an alternative, by supporting storing of
> raw data without c
Reducing the footprint of storing data on-chain might better be achieved by
*supporting* it.
Currently storing data is wasteful because it is embedded inside an
OP_RETURN within a transaction structure. As an alternative, by supporting
storing of raw data without creating a transaction, waste can
On 2/24/2022 7:49 AM, ZmnSCPxj via bitcoin-dev wrote:
...
... it is easy for 51% hashrate to double-spend in the LN ...
... the above statement is unequivocally ***true***.
Both LN and Drivechain are vulnerable to miner-theft; and both use their design
to deter theft.
However, I believe th
> One thought I had was: what happens if/when it comes to pass that we
increase payment precision by going sub-satoshi on chain? It seems like it
would be fairly simple to extend that to ordinals by having fraction
ordinals like 1.1 or 4.85. Could be an interesting thought to add to the
proposal.
> When we talk about future improvements, there could be even bigger
problem with ordinal numbers: what if/when we introduce some Monero-like
system and hide coin amounts? (for example by using zero satoshi, because
we have to use something that will be backward-compatible). Zero is quite
interesti
> what happens if/when it comes to pass that we increase payment precision by
> going sub-satoshi on chain?
When we talk about future improvements, there could be even bigger problem with
ordinal numbers: what if/when we introduce some Monero-like system and hide
coin amounts? (for example by us
I think the proposal is interesting in that it could be an interesting way
to solve the dust problem. While most solutions to dust focus on reducing
how much are created and encouraging consolidating utxos to avoid them
becoming dust, this proposal could utilize dust for valuable purposes. Why
use
In Q = P + hash(P||commitment)G you cannot spend from Q without knowing
both the private key of P as well as the commitment (i.e. 32 bytes,
assuming the commitment itself is another hash). This is generally not a
problem for tapscript, as the scripts are deterministically generated (i.e.
backing up
> Also, tweaking an ECC point (this includes tapscript) in non-deterministic
> ways also makes it harder to recover from backup, because you can't recover
> the key without knowing the full commitment.
I don't think so. You can spend coins from taproot by key or by script. If you
spend by key, m
Good morning lightning-dev and bitcoin-dev,
Recently, some dumb idiot, desperate to prove that recursive covenants are
somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caused
Paul Sztorc to [revive][1] and make the following statement:
> As is well known, it is easy for 51
Good morning aj,
> > Logically, if the construct is general enough to form Drivechains, and
> > we rejected Drivechains, we should also reject the general construct.
>
> Not providing X because it can only be used for E, may generalise to not
> providing Y which can also only be used for E, but it
Note this has always been possible, and is not specifically related to
tapscript. As long as you're committing to an ECC point, you can tweak it
to commit data inside it (i.e. pay-to-contract). This includes P2PK and
P2PKH.
Committing to 1.5GB of data has equally been possible with OP_RETURN
, or
Since Taproot was activated, we no longer need separate OP_RETURN outputs to be
pushed on-chain. If we want to attach any data to a transaction, we can create
"OP_RETURN " as a branch in the TapScript. In this way, we can store
that data off-chain and we can always prove that they are connected
Not all people who have been stolen from believe that they have lost the
right and title to what has been stolen and in many cases they have not.
I do not excuse Bitcoin that it is impossible to have any individual
Bitcoin identified but also I do not care, if I receive Bitcoin honestly
I do no
What about zero satoshis?
A zero satoshi input or output carries no ordinals, so an ordinal index can
ignore them.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> The system sounds expensive eventually to cope with approximately
> 2,100,000,000,000,000 ordinals.
What about zero satoshis? There are transactions, where zero satoshis are
created or moved. Typical users cannot do that, but miners can, we currently
have such transactions in the blockchain, f
18 matches
Mail list logo
