Hi Zac,
> Regarding “Fees paid: 150 BTC” (uh, *citation needed*):
https://dune.com/queries/2008613/3326984
> Your other arguments are nonsensical so excuse me for ignoring them.
There were zero browser extensions that could sign PSBT to be used in different
bitcoin projects that have web
Hi alicexbtc,
Under no circumstance should Bitcoin add any functionality intended to
support private businesses that rely on on-chain storage for their business
model.
Regarding “Fees paid: 150 BTC” (uh, *citation needed*):
To optimize for profitability a business would generally attempt to
"want bitcoin to be money and money means different things for people in
this world"
I think we can all agree that a property of money is fungibility, and by
its very definition NFTs are not fungible and thus not money.
On Wed, Mar 29, 2023 at 4:56 PM alicexbt via bitcoin-dev <
Hi Zac,
Let me share what those parasites achieved:
- Fees paid: 150 BTC
- Lot of users and developers trying bitcoin that either never tried or gave up
early in 2013-15
- Mempools of nodes of being busy on weekends and got lots of transactions
- PSBT became cool and application devs are trying
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
On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin-dev wrote:
> I think there are perhaps four opcodes that are interesting in this class:
>
>idx sPK OP_FORWARD_TARGET
> -- sends the value to a particular output (given by idx), and
> requires that output have a
Hi Luke,
I think this works as with OP_FLU based construct, for the simplest single
key case.
e.g., single key hot wallet(or MuSig2/FROST wallet)
1 " OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG"
OP_FORWARD_LEAF_UPDATE
The is appended at spending time.
This allows the utxo to go to $recover
Hi Brandon,
Thank you for chiming in, causing me to think a bit more deeply on the
privacy issues
and what seems possible.
> I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all
Hi Gents,
> > I don't think replacing the internal-public-key makes sense -- if it
> was immediately spendable via the keypath before there's no reason for
> it not to be immediately spendable now.
>
> Slavishly following the current proposal was the idea to make sure all
> functionality was
In ordinary use cases, you wouldn't clawback; that would only be in the
extreme case of the wallet being compromised. So typical usage would
just be receive -> send, like wallets currently do.
Luke
On 3/13/23 10:56, Greg Sanders wrote:
Didn't finish sentence: but in practice would end up
Didn't finish sentence: but in practice would end up with pretty similar
usage flows imho, and as noted in PR, would take a different wallet
paradigm,
among other technical challenges.
On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders wrote:
> Hi Luke,
>
> Can you elaborate why the current
Hi Luke,
Can you elaborate why the current idealized functionality of deposit ->
trigger -> withdrawal is too complicated for
everyday use but the above deposit -> withdrawal ->
resolve(claim/clawback) wouldn't be? I admit at a high level
it's a fine paradigm, but in practice would end
Let's
I started reviewing the BIP, but stopped part way through, as it seems
to have a number of conceptual issues.
I left several comments on the PR
(https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
but ultimately I think it isn't simplified enough for day-to-day use,
and
On 10 March 2023 4:45:15 am AEST, Greg Sanders via bitcoin-dev
wrote:
>1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe
>obvious but I missed this initially and thought it was useful to be pointed
>out.
That was true for TLUV - iirc "FALSE FALSE 0 TLUV" would preserve
AJ,
Interesting stuff! Just a couple thoughts on these proposed opcodes, at
least one we discussed elsewhere:
1) OP_FORWARD_SELF is a JET of OP_FLU in the revaulting common case. Maybe
obvious but I missed this initially and thought it was useful to be pointed
out.
2) Using these extended
On Mon, Mar 06, 2023 at 10:25:38AM -0500, James O'Beirne via bitcoin-dev wrote:
> What Greg is proposing above is to in essence TLUV-ify this proposal.
FWIW, the way I'm thinking about this is that the "OP_VAULT" concept is
introducing two things:
a) the concept of "forwarding" the input amount
Hi James,
I think everything except the hinted "withdrawal authorization" is spot on.
For withdrawal authorization, I think we'll have to go deeper into the TLUV
direction
as AJ suggested for at least a couple reasons:
1) You need the withdrawal authorization committed at deposit time
2) You
I'm glad to see that Greg and AJ are forming a habit of hammering
this proposal into shape. Nice work fellas.
To summarize:
What Greg is proposing above is to in essence TLUV-ify this proposal.
I.e. instead of relying on hashed commitments and recursive script
execution (e.g. + later
I read the draft and this seems to have some functionality that I am looking
for. I'm pretty new to bitcoin-dev, but I'm persistent and have a lot of time
on my hands.
I would like multiple tapleaves be restricted on the amount that they can spend.
Say an input of 1 BTC, has a locking script of
Greetings AJ,
Glad I could resurrect the idea!
> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`
Interesting idea! (I'll let you be the one to scope creep the proposal :) )
To be pedantic, EXPR_TRIGGER
On Wed, Mar 01, 2023 at 10:05:47AM -0500, Greg Sanders via bitcoin-dev wrote:
> Below is a sketch of a replacement for the two opcodes.
I like this! I tried to come up with something along similar lines for
similar reasons, but I think I tried too hard to reduce it to two opcodes
or something
Hello James,
First off, thank you for crafting an interesting idea like this that is
aimed at solving a serious problem. I see a lot of excitement about the use
cases, and I think it's worth iterating on.
Attempting to keep the idealized functionality constant, I'd like to
explore a design
Since the last related correspondence on this list [0], a number of
improvements have been made to the OP_VAULT draft [1]:
* There is no longer a hard dependence on package relay/ephemeral
anchors for fee management. When using "authorized recovery," all
vault-related transactions can be
23 matches
Mail list logo
