Re: [bitcoin-dev] Making OP_TRUE standard?

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

Re: [bitcoin-dev] Making OP_TRUE standard?

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, <

Re: [bitcoin-dev] Making OP_TRUE standard?

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

> 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

[bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

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

Re: [bitcoin-dev] BIP sighash_noinput

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,

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

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

[bitcoin-dev] MAST/Schnorr related soft-forks

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

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

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

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

[bitcoin-dev] Idea: More decimal places for lower minimum fee

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

Re: [bitcoin-dev] Idea: More decimal places for lower minimum fee

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

He can use pruning to only store the last X MB of the blockchain. It will store the UTXO set though, which is a couple of GBs. In total, a pruned node with pruning set to 1000 MB ends up using 4.5 GB currently, but it varies slightly due to the # of UTXOs in existence. On Thu, May 10, 2018 at

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

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

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

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

Re: [bitcoin-dev] Making OP_TRUE standard?

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