Good morning Luke and list,
>
> (Aside, in case it wasn't clear on my previous email, the template-script idea
>
> would not make it mandatory to spend in the same block, but that the UTXO
>
> would merely cease to be valid after that block. So the 0-value output does
>
> not take up a UTXO d
I'm not sure about the best way to approach soft-forking (I've opined on it
before, and still find the details mind-numbing) but the end goal seems
fairly clearly to be an all of the above: Have aggregatable public keys
which support simple signatures, taproot with BIP 114 style taproot, and
Graftr
Thanks for the summary,
It may be worth emphasizing the fungibility aspects of all this.
That summary contains ideas to possibly have separate address types,
opcodes and scriptSigs/witnesses for different feature, at least to
start with. To me this would seem bad because it may miss out on the
fu
Thanks for writing this up Anthony.
Do you think that a CHECKSIGFROMSTACK proposal should be included within
this discussion of signature soft-forks, or do you see it as an unrelated
issue?
CHECKSIGFROMSTACK enables some forms of (more) efficent MPC (See
http://people.csail.mit.edu/ranjit/papers/
Olaoluwa Osuntokun writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial versi
Olaoluwa Osuntokun via bitcoin-dev
writes:
> Hi Jimpo,
>
> You're correct that the introduction of symmetric state now
> re-introduces the dependency between the CSV value of the commitment,
> and the HTLC timeouts. It's worth nothing that this issue existed in
> an earlier version of the BOLT s
Fee rates in Bitcoin Core are measured in satoshis/kB. There are a couple
places where a minimum of 1000 satoshis/kB is assumed.
Setting "incrementalrelayfee" to a smaller than default value and either
leaving "minrelaytxfee" unset or also setting it smaller will be sufficient
to allow your node
Hi all,
We're writing with an update on the Dandelion project. As a reminder,
Dandelion
is a practical, lightweight privacy solution that provides Bitcoin users
formal
anonymity guarantees. While other privacy solutions aim to protect
individual
users, Dandelion protects privacy by limiting the ca
Currently, the minimum fee of 1 satoshi per byte corresponds to about
0.09 USD per kB, which is no longer insignificant. Maybe the time has
come now to introduce more decimal places and make the minimum fee 1 of
the new smallest unit. This way, everyday payments would again be
possible with vir
> On 3/17/18, someone posted on the Lightning-dev list, "Can I try
> Lightning without running a fully-fledged bitcoin block chain? (Yubin
> Ruan)." The inquirer was asking because he didn't have much space to
> store the entire blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THI
Good morning karl and Segue,
Specifically for c-lightning, we are not yet rated for pruned bitcoind use,
although if you installed and started running bitcoind before installing the
lightningd, caught up to the chain, and then installed lightningd and set
things up so that bitcoind will get kil
That is a good observation that most of the historical data does not need
to be kept around. I believe what you are suggested is already implemented,
however. Bitcoin Core can operate in a pruned mode, where the bulk of the
historical block data is discarded and only the current UTXO set (and a few
Hello world,
After the core dev meetup in March I wrote up some notes of where I
think things stand for signing stuff post-Schnorr. It was mostly for my
own benefit but maybe it's helpful for others too, so...
They're just notes, so may assume a fair bit of background to be able to
understand the
You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-value
UTXO in another transaction with a normal fee. The idea is that to get the
latter fee, the miner needs to confirm the original tranaction with the
0-value OP_TRUE.
(Aside, in case it wasn't clear on my previous email
But in prnciple I don't oppose to making it stardard, just want to
understand what's the point.
On Thu, 10 May 2018, 02:16 Jorge Timón, wrote:
> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao obvious to you
> th
I fail to see what's the practical difference between sending to op_true
and giving the coins are fees directly. Perhaps it is ao obvious to you
that you forget to mention it?
If you did I honestlt missed it.
On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundat
16 matches
Mail list logo
