Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-25 📝 Original message:> what if/when we ...
📅 Original date posted:2022-02-25
📝 Original message:> what if/when we introduce some Monero-like system and hide coin amounts?
I really don't see a world where bitcoin goes that route. Hiding coin
amounts would make it impossible to audit the blockchain and verify that
there hasn't been inflation and the emission schedule is on schedule. It
would inherently remove unconditional soundness from bitcoin and replace it
with computational soundness. Even if bitcoin did adopt it, it would keep
backwards compatibility with old style addresses which could continue to
use ordinals.
On Thu, Feb 24, 2022 at 3:03 PM Casey Rodarmor <casey at rodarmor.com> wrote:
> > 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.
>
> I think it's probably premature to make a concrete proposal, since any
> proposal made now might be inapplicable to the actual form that a precision
> increase takes.
>
> > What you mean by "the same transaction id" here is unclear. I was
> interpreting the proposal to mean that UTXOs are all assigned a set of
> ordinals, and when that UTXO is spent, it transfers it's ordinals to
> outputs in the transaction the UTXO is spent in. Is that what you mean by
> this sentence? If so, I'd suggest rewording.
>
> There are two pairs of old transactions with duplicate IDs, from blocks
> 91812 and 91842, and 91722 91880. (It's no longer possible to create
> transactions with duplicate IDs, since the BIP 34 soft fork that required
> the height be included in coinbase transaction inputs, making them have
> guaranteed unique IDs.)
>
> This section of the spec defines what ordinal ranges such duplicate
> transactions contain. It tries to match the behavior of Bitcoin Core, which
> considers the second transaction with a given ID to render unspendable
> current UTXOs created by a transaction with the same ID.
>
> I'll add some detail to this part of the BIP, and talk about why this rule
> is needed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/775c5d38/attachment-0001.html>;
📝 Original message:> what if/when we introduce some Monero-like system and hide coin amounts?
I really don't see a world where bitcoin goes that route. Hiding coin
amounts would make it impossible to audit the blockchain and verify that
there hasn't been inflation and the emission schedule is on schedule. It
would inherently remove unconditional soundness from bitcoin and replace it
with computational soundness. Even if bitcoin did adopt it, it would keep
backwards compatibility with old style addresses which could continue to
use ordinals.
On Thu, Feb 24, 2022 at 3:03 PM Casey Rodarmor <casey at rodarmor.com> wrote:
> > 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.
>
> I think it's probably premature to make a concrete proposal, since any
> proposal made now might be inapplicable to the actual form that a precision
> increase takes.
>
> > What you mean by "the same transaction id" here is unclear. I was
> interpreting the proposal to mean that UTXOs are all assigned a set of
> ordinals, and when that UTXO is spent, it transfers it's ordinals to
> outputs in the transaction the UTXO is spent in. Is that what you mean by
> this sentence? If so, I'd suggest rewording.
>
> There are two pairs of old transactions with duplicate IDs, from blocks
> 91812 and 91842, and 91722 91880. (It's no longer possible to create
> transactions with duplicate IDs, since the BIP 34 soft fork that required
> the height be included in coinbase transaction inputs, making them have
> guaranteed unique IDs.)
>
> This section of the spec defines what ordinal ranges such duplicate
> transactions contain. It tries to match the behavior of Bitcoin Core, which
> considers the second transaction with a given ID to render unspendable
> current UTXOs created by a transaction with the same ID.
>
> I'll add some detail to this part of the BIP, and talk about why this rule
> is needed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220224/775c5d38/attachment-0001.html>;