From a system developer standpoint, CHECKMATURITYVERIFY ties together
the semantics of this opcode with another existing feature in the system
(coinbase maturity).
HOWEVER...
from an application developer standpoint, I think the concept of a
timelock is more relevant. Maturity is a concept th
1. Technically is it promoting address reuse, but in this case, I
think it's OK. The primary purpose of a coalescing transaction is to
clear out *all* funds associated with one address and send them to
another address (belonging to the same owner). If you coalesce the
inputs to the same address ove
Few issues I can think of:
1. In its basic form this encourages address reuse. Unless the wildcard can
be constructed such that it can match a whole branch of an HD wallet.
Although I guess that would tie all those addresses together making HD moot
to begin with.
2. Sounds pretty dangerous durin
> This idea could be applied by having the wildcard signature apply to all
> UTXOs that are of a standard form and paid to a particular address, and be
> a signature of some kind of message to that effect.
I think this is true. Not *all* transactions will be able to match the
wildcard. For instanc
What is required to spend bitcoin is that input be provided to the UTXO
script that causes it to return true. What Chris is proposing breaks the
programmatic nature of the requirement, replacing it with a requirement
that the secret be known. Granted, the secret is the only requirement in
most ca
On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> **OP_CHECKWILDCARDSIGVERIFY**
Some (minor) discussion of this idea in -wizards earlier today starting
near near "09:50" (apologies for having no anchor links):
http://gnusha.org/bitco
A coalescing transaction in my scheme is the same size as a normal
transaction. You only include one UTXO, the rest are implied based on
the presence of the OP_CHECKWILDCARDSIGVERIFY opcode.
The code that determines if a UTXO is spent or not will need to be
modified to include a check to see if an
On Tue, Nov 24, 2015 at 12:34 PM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The technical reason for this is that you have to explicitly list each
> UTXO individually when making bitcoin transactions. There is no way to
> say "all the utxos". This post describe
Here is the problem I'm trying to solve with this idea:
Lets say you create an address, publish the address on your blog, and
tell all your readers to donate $0.05 to that address if they like
your blog. Lets assume you receive 10,000 donations this way. This all
adds up to $500. The problem is th
On Nov 24, 2015 1:21 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Whatever we call it, deciding on that is a simple s/FOO/BAR/ prior to
> release.
While I agree we're not in a hurry, the more we wait, the longer docs (to
be modified later) will accumulate ma
I agree, I believe the first name that an op with equivalent functionality
had was simply op_maturity.
At least I remember we discussed such an opcode when discussing pegged
sidechains' design.
I kind of dislike the check_x_verify naming pattern. We want all new
operands to return if whatever they
On Tue, Nov 24, 2015 at 10:30:52AM +, Btc Drak via bitcoin-dev wrote:
> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
>
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifi
BIP68 introduces relative lock-time semantics to part of the nSequence
field leaving the majority of bits undefined for other future applications.
BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
limited to verifying transaction inputs according to BIP68's relative
lock-t
13 matches
Mail list logo
