Hi Laolu,
Could you explain please how facilitating registering non-Bitcoin assets on
the Bitcoin blockchain is beneficial for the Bitcoin economy?
Thanks,
Zac
On Wed, 6 Sep 2023 at 21:02, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> After more than a
e email.
>
> --- Original Message ---
> On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > I’m not sure why any effort should be spent on theorizing how new
> opcodes mi
I’m not sure why any effort should be spent on theorizing how new opcodes
might be used to facilitate parasitical use cases of the blockchain.
If anything, business models relying on the ability to abuse the blockchain
as a data store must be made less feasible, not more.
Zac
On Fri, 24 Mar
> your proof is incorrect (or, rather, relies on a highly unrealistic
assumption)
The assumption that coin are lost ar a constant rate is not required. Tail
emission will asymptotically decrease the rate of inflation to zero, at
which point the increase in coin exactly matches the amount of coin
Sorting a seed alphabetically reduces entropy by ~29 bits.
A 12-word seed has (12, 12) permutations or 479 million, which is ln(469m)
/ ln(2) ~= 29 bits of entropy. Sorting removes this entropy entirely,
reducing the seed entropy from 128 to 99 bits.
Zac
On Fri, 8 Jul 2022 at 16:09, James
On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj wrote
CTV *can* benefit layer 2 users, which is why I switched from vaguely
> apathetic to CTV, to vaguely supportive of it.
Other proposals exist that also benefit L2 solutions. What makes you
support CTV specifically?
Centrally documenting the
On Fri, 22 Apr 2022 at 09:56, Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think that trying to find ways to activate non-invasive changes should
> be everyone's goal, *even if* they personally may not have an immediate use
> case
>
A change that
On Wed, 20 Apr 2022 at 15:49, Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he
Hi ZmnSCPxj,
> Either you consume the entire UTXO (take away the "U" from the "UTXO")
completely and in full, or you do not touch the UTXO
Ok, so enabling spending a UTXO partly would be a significant departure
from the systems’ design philosophy.
I have been unclear about the fee part. In my
Hi ZmnSCPxj,
To me it seems that more space can be saved.
The data-“transaction” need not specify any output. The network could
subtract the fee amount of the transaction directly from the specified
UTXO. A fee also need not to be specified. It can be calculated in advance
both by the network
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
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
The name of the fund should ideally unambiguously clarify its scope, i.e.,
Bitcoin & development. So maybe “Bitcoin Developers Community LDF”. Or
perhaps “Bitcoin Technical Community LDF” which nicely abbreviates to
BTCLDF.
Zac
On Thu, 13 Jan 2022 at 19:49, jack via bitcoin-dev <
Hi ZmnSCPxj,
The rate-limiting algorithm would be relatively straightforward. I
documented the rate-limiting part of the algorithm below, perhaps they can
evoke new ideas of how to make this MAST-able or otherwise implement this
in a privacy preserving way.
Something like the following:
=>
Hi ZmnSCPxj,
Thank you for your helpful response. We're on the same page concerning
privacy so I'll focus on that. I understand from your mail that privacy
would be reduced by this proposal because:
* It requires the introduction of a new type of transaction that is
different from a "standard"
Hi ZmnSCPxj,
> I suggest looking into the covenant opcodes and supporting those instead
of your own proposal, as your application is very close to one of the
motivating examples for covenants in the first place.
I believe it is not the right approach to take a proposal, chop off key
aspects of
Hi ZmnSCPxj,
Thank you for your counterproposal. I fully agree that as a first step we
must establish whether the proposed functionality can be implemented
without making any changes to consensus.
Your counterproposal is understandably more technical in nature because it
explores an
Hi ZmnSCPxj,
Thank you for your insightful response.
Perhaps I should take a step back and take a strictly functional angle.
Perhaps the list could help me to establish whether the proposed
functionality is:
Desirable;
Not already possible;
Feasible to implement.
The proposed functionality is
Hi Billy,
> It sounds like you're proposing an opcode
No. I don’t have enough knowledge of Bitcoin to be able to tell how (and
if) rate-limiting can be implemented as I suggested. I am not able to
reason about opcodes, so I kept my description at a more functional level.
> I still don't
> Ah I see, this is all limited to within a single epoch.
No, that wouldn't be useful. A maximum amount is allowed to be spent within
EVERY epoch.
Consider an epoch length of 100 blocks with a spend limit of 200k per
epoch. The following is allowed:
epoch1 (800101 - 800200): spend 120k in block
[Note: I've moved your reply to the newly started thread]
Hi Billy,
Thank you for your kind and encouraging feedback.
I don't quite understand why you'd want to define a specific span of blocks
> for the rate limit. Why not just specify the size of the window (in blocks)
> to rate limit within,
[Resubmitting to list with minor edits. My previous submission ended up
inside an existing thread, apologies.]
Hi list,
I'd like to explore whether it is feasible to implement new scripting
capabilities in Bitcoin that enable limiting the output amount of a
transaction based on the total value
Hi list,
I'd like to explore whether it is feasible to implement new scripting
capabilities in Bitcoin that enable limiting the output amount of a
transaction based on the total value of its inputs. In other words, to
implement the ability to limit the maximum amount that can be sent from an
Hi Billy,
Thank you for your comprehensive reply. My purpose was to find out whether
a proposal to somehow limit the amount being sent from an address exists
and to further illustrate my thoughts by giving a concrete example of how
this might work functionally without getting to deep into the
Hi Billy,
On the topic of wallet vaults, are there any plans to implement a way to
limit the maximum amount to be sent from an address?
An example of such limit might be: the maximum amount allowed to send is
max(s, p) where s is a number of satoshi and p a percentage of the total
available
Eric,
> A million nodes saying a transaction is invalid does nothing to enforce
that knowledge
It does. Nodes disregard invalid transactions and invalid blocks as if they
never existed. It is not possible for any party to transact bitcoin in a
way that violates the set of rules enforced by the
Hi Eric,
> A node (software) doesn’t enforce anything. Merchants enforce consensus
rules
… by running a node which they believe to enforce the rules of Bitcoin.
A node definitely enforces consensus rules and defines what is Bitcoin. I
am quite disturbed that this is even being debated here.
> Majority hash power does have the ability to determine what gets
confirmed.
Miners don’t have the ability to decide whether a block is valid.
Hash power is only recognized as such if it is used for creating a valid
block, i.e., a block that strictly follows all the rules as set by the node
Hi ZmnSCPxj,
Please note that I am not suggesting VDFs as a means to save energy, but
solely as a means to make the time between blocks more constant.
Zac
On Tue, 18 May 2021 at 12:42, ZmnSCPxj wrote:
> Good morning Zac,
>
> > VDFs might enable more constant block times, for instance by
VDFs might enable more constant block times, for instance by having a
two-step PoW:
1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to
difficulty adjustments similar to the as-is). As per the property of VDFs,
miners are able show proof of work.
2. Use current PoW mechanism
>
>
> Are there people who can freely produce new mining equipment to an
> arbitrary degree?
>
Close. Bitmain for example produces their own ASICs and rigs which they
mine with. Antpool is controlled by Bitmain and has a significant amount of
the hash power. The marginal cost of an ASIC chip or
> if energy is only expended for 10% of the same duration, this money must
now be spent on hardware.
More equipment obviously increases the total energy usage.
You correctly point out that the total expenses of a miner are not just
energy but include capital expenses for equipment and
Hi Michael,
Your proposal won’t save any energy because it does nothing to decrease the
budget available to mine a block (being the block reward).
Even if it were technically possible to find a way for nodes to somehow
reach consensus on a hash that gets generated after 9 minutes, all it
> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
> think) for OP_RETURN versus 40 bytes for a BIP141 payload.
> Maximizing payload size better amortizes the overhead cost of the
> containing transaction and the output's nValue field.
In order to reduce the footprint
34 matches
Mail list logo
