Are there any plans other than `raw` to support time locks in descriptors?
Any plans for descriptors offering closer integration with miniscript?
All of Blockchain Commons libraries and tools are multisig descriptor
centric, and there are many scenarios that require describing time locks:
- [
On 6/29/21 6:22 PM, Christopher Allen wrote:
> Are there any plans other than `raw` to support time locks in descriptors?
>
> Any plans for descriptors offering closer integration with miniscript?
I expect miniscript to be a followup BIP that extends these descriptors.
Miniscript has timelock fu
Good morning Raymo,
> Hey Alex,
>
> Your scenario works perfectly unless we put some restrictions on
> accepting transaction by creditor (in our case Bob).
> These are restrictions:
> Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
> transaction input.
> Alice has to reserve 1
> On Jun 29, 2021, at 12:28, Jorge Timón wrote:
>
>
> "Confirmation" isn't needed for softforks.
All transactions require confirmation. Splitting does not change this.
Softforks are not compatible without miner enforcement. So soft forking without
it has essentially the same effect as hard
"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.
You may say users chosing the rules is "
Hi All,
I've been working on formalizing the Output Script Descriptors that have
been available in Bitcoin Core for a while into BIPs. Since descriptors
are modular and have optional components, I've decided to split it into
7 BIPs, rather than a single one. The first describes descriptors in
gene
> On Jun 29, 2021, at 10:55, Luke Dashjr wrote:
>
> The only alternative to a split in the problematic scenarios are 1) concede
> centralised miner control over the network,
Miners control confirmation, entirely.
This is the nature of bitcoin. And merchants control validation, entirely.
Any
The only alternative to a split in the problematic scenarios are 1) concede
centralised miner control over the network, and 2) have inconsistent
enforcement of rules by users who don't agree on what the correct rules are,
again leading to centralised miner control over the network.
In other wor
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
https://github.com/ariard/L2-zoology/blob/master/workshops/package-rel
Good thinking. Your point also applies to CoinJoins (both equal-output
and payjoin), and to any transaction where multiple parties contribute
inputs.
The BIP should say "at least one of the inputs of the transaction" with
a suggestion that on-chain wallets just randomly pick an input.
On 28/06/20
At least we are now acknowledging that splitting is what it’s about. That’s
progress.
e
> On Jun 29, 2021, at 01:32, Jorge Timón wrote:
>
>
> I think the option of "permanent failure because miners veto" should actually
> be abandoned.
> No, I don't think we should avoid splits when possib
I think the option of "permanent failure because miners veto" should
actually be abandoned.
No, I don't think we should avoid splits when possible, I don't think we
should avoid splits at all costs.
On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote:
> @Luke
> > They can still slow it down.
>
> Abs
12 matches
Mail list logo
