Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote: > The multisig scheme is interesting. From my understanding of Single Use > Seals, since seal n commits to seal n+1, for the on-chain aggregation seals > you would want to pick some common aggregation service provider ahead of > time and

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

On Thu, Dec 09, 2021 at 09:49:11AM +, Christian Moss wrote: > p...@petertodd.org, so single use seals require an onchain transaction to > post the proof of publication to the ledger (assuming bitcoin is used as > the ledger) when an asset is transferred, but it can scale because you can >

Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning

On Mon, Dec 06, 2021 at 04:35:19PM +, Christian Moss via bitcoin-dev wrote: > As far as I understand it, RGB doesn't scale NFTs as each > transaction to transfer ownership of an NFT would require an onchain > transaction RGB intends to scale NFTs and similar things in the future via scalable

Re: [bitcoin-dev] death to the mempool, long live the mempool

On Tue, Oct 26, 2021 at 07:44:45PM -0400, Antoine Riard via bitcoin-dev wrote: > Such a list of endpoints couldn't be static otherwise it's an artificial > barrier to enter in the mining competition, and as such a centralization > vector. Dynamic, trust-minimized discovery of the mining endpoints

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

On Sat, Apr 17, 2021 at 03:57:55AM +, Christopher Gilliard via bitcoin-dev wrote: > Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data > in the blockchain and it's not feasible to block all of them. That is why > it's important to, at the same time as limiting the

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

On Sun, Oct 06, 2019 at 08:46:59AM +, ZmnSCPxj wrote: > > Obviously with care you can get the computation right. But at that point > > what's > > the actual advantage over OP_CAT? > > > > We're limited by the size of the script anyway; if the OP_CAT output size > > limit > > is comparable to

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote: > Interesting point. > > The script is under your control, so you should be able to ensure that you > are always using a correctly constructed midstate, e.g., something like: > > scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2>

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote: > Awhile back, Ethan and I discussed having, rather than OP_CAT, an > OP_SHA256STREAM that uses the streaming properties of a SHA256 hash > function to allow concatenation of an unlimited amount of data, provided > the only

Re: [bitcoin-dev] Burying CSV and segwit soft fork activations

On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote: > Once a consensus change has been activated and buried by sufficient work, > we consider the height of that change to be historic fact. The exact > activation method is no longer of practical interest. In some cases the

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

On Mon, Aug 12, 2019 at 09:09:43PM -0500, Bryan Bishop wrote: > > > Multisig gated by ECDSA pubkey recovery for provably-unknown keys > > > = > > > > > > A group can participate in a multisig scheme with provably-unknown ECDSA > >

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev wrote: > Hi, > > I have a proposal for implementing bitcoin vaults in a way that does not > require any soft-forks or other software upgrades, although it could benefit > from SIGHASH_NOINPUT which I'll describe later. > > I

[bitcoin-dev] Single-use-Seal Implementation

On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev wrote: > Single-use seals > > > This proposal may have inadvertedly demonstrated a practical way to implement > Peter Todd's single-use seals concept [4]. I am hesitant to say so, though, > because I think he

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Mon, Jul 22, 2019 at 02:52:10PM -0400, Peter via bitcoin-dev wrote: > Hi, > > I believe two wallets. Andreas' Android Bitcoin wallet and BRD are > significant users of node_bloom. > > Privacy is a matter of individual choice in the current protocol. Why not > let people provide this network

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On Mon, Jul 22, 2019 at 12:56:33AM +0200, Andreas Schildbach via bitcoin-dev wrote: > An estimated 10+ million wallets depend on that NODE_BLOOM to be > updated. So far, I haven't heard of an alternative, except reading all > transactions and full blocks. Can you specify exactly which wallets

Re: [bitcoin-dev] testnet4

On Sat, Jun 08, 2019 at 05:01:50PM +0200, Emil Engler via bitcoin-dev wrote: > I don't get why the testnet shouldn't be resetted just because there is a > (probably better) alternative for it. The testnet is still a thing and is > also used. Remember that the size of testnet itself is an

Re: [bitcoin-dev] Improving Pre and Post Merging Abilities With Rewriting Core In Python

On Tue, Apr 23, 2019 at 03:23:27PM +, Achow101 via bitcoin-dev wrote: > Feel free to re-implement Bitcoin Core in Python. It's open source software > and you can do whatever you want. > > However Bitcoin Core is not going move to Python and rewrite everything in > Python. Besides the fact

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Wed, Apr 03, 2019 at 02:39:32PM -0700, Dave Scotese via bitcoin-dev wrote: > Every block's hash is smaller than the difficulty at that time. Block > 569927's hash was VERY small (started with 21 zeros). The ratio of block > hash to difficulty requirement (0x - difficulty, I think)

Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

On Mon, Apr 01, 2019 at 12:30:34AM +, Luke Dashjr via bitcoin-dev wrote: > Certain parts of the community have been selling bitcoins for unreasonably > low prices. This has halted Bitcoin's valuation at $20k and even driven the > price down below $15k! However, clearly Bitcoin is worth much

Re: [bitcoin-dev] Notice: List Infrastructure Migration

On Mon, Mar 18, 2019 at 06:35:47PM -0400, Warren Togami Jr. via bitcoin-dev wrote: > The new archive will be operated independently outside from the Linux > Foundation as generated by this open source tool. This hopefully will allow > all future archives to never move again even if the underlying

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

On January 24, 2019 10:03:25 AM UTC, ZmnSCPxj via bitcoin-dev wrote: >Good morning Dustin, > >> Wouldn’t a revealed private key for time locked funds create a race >to spend? I imagine miners who are paying attention would have the >advantage but it would still just be a race. > >If Bitcoin

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

On Tue, Dec 18, 2018 at 03:08:26AM +0800, Johnson Lau via bitcoin-dev wrote: > >> If it's not safer in practice, we've spent a little extra complexity > >> committing to a subset of the script in each signature to no gain. If > >> it is safer in practice, we've prevented people from losing funds.

Re: [bitcoin-dev] Testnet3 Reest

On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev wrote: > Hi, > > Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours. > > Is a testnet reset scheduled in the next release or any reason not to do a > reset ? > > Fast onboarding/lower disk overheads

Re: [bitcoin-dev] Brock Pierce?

PM UTC, Peter Todd via bitcoin-dev wrote: >-BEGIN PGP MESSAGE- > >hQEMA8xUMVQPvvGFAQf9HMeq6x4tXQlQEOeVj6IHlY7JRBREjSbmz9vPp9UyZs/v >xCZ4vE6J0AHJBIri8o96Sqfl4JV81DwEg17ex5WgVzrh+7F33o6fEMwm0dnH1Zl+ >yyhbJZzequgZIUHySUanmZMR2k+tPiuUEMXkWKQ0iKOv/mttU

Re: [bitcoin-dev] Brock Pierce?

-BEGIN PGP MESSAGE- hQEMA8xUMVQPvvGFAQf9HMeq6x4tXQlQEOeVj6IHlY7JRBREjSbmz9vPp9UyZs/v xCZ4vE6J0AHJBIri8o96Sqfl4JV81DwEg17ex5WgVzrh+7F33o6fEMwm0dnH1Zl+ yyhbJZzequgZIUHySUanmZMR2k+tPiuUEMXkWKQ0iKOv/mttUnN5M5kL/qMX0dlV oN1u3l5B1XRjLZA6ZZzhMNDztFsUh4RxrIJmKMyZEgZP0ouhLwPvOIP8bXC6VyED

[bitcoin-dev] Brock Pierce?

>From a censorship resistance point of view, I don't see EOS as a viable >solution period. And anything supported by a pedo like Brock is just begging >for failure. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

[bitcoin-dev] Brock Pierce?

>From a censorship resistance point of view, I don't see EOS as a viable >solution period. And anything supported by a pedo like Brock is just begging >for failure. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On August 15, 2018 8:33:43 PM UTC, "Jorge Timón via bitcoin-dev" wrote: >op_return outputs can be pruned because they are not spendable. >putting a hash on in the witness script data won't make things better >(it would actually make them worse) and it definitely doesn't help >"block size

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev wrote: >Hi everyone, > >My name's Lautaro and I'm currently acting as Tech Lead of Po.et >. At Po.et we >use >colored coins

Re: [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 03, 2018 at 11:45:22PM +, Gregory Maxwell wrote: > On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote: > > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing > > about what the flag actually does. > > I believe that making the signature replayable is 1:1

Re: [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote: > Gregory Maxwell via bitcoin-dev > writes: > > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > > wrote: > >> Hi all, > >> > >> I'd like to pick up the discussion from a few months ago, and

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

On Sat, Jun 09, 2018 at 02:51:55PM +0200, Sergio Demian Lerner wrote: > Yo can fool a SPV wallet even if it requires a thousands confirmations > using this attack, and you don't need a Sybil attack, so yes, it impacts > SPV wallets also. The protections a SPV node should have to prevent this >

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

On Sat, Jun 09, 2018 at 01:03:53PM +0200, Sergio Demian Lerner wrote: > Hi Peter, > We reported this as CVE-2017-12842, although it may have been known by > developers before us. It's been known so long ago that I incorrectly thought the attack was ok to discuss in public; I had apparently

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

On Sat, Jun 09, 2018 at 02:21:17PM +0200, Sergio Demian Lerner wrote: > Also it must be noted that an attacker having only 1.3M USD that can > brute-force 72 bits (4 days of hashing on capable ASICs) can perform the > same attack, so the attack is entirely feasible and no person should accept >

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote: > Are you proposing a soft fork to include the number of transactions in a > block in the block headers to compensate for the broken Merkle format? That > sounds like a good idea. > > On Thu, Jun 7, 2018 at 10:13 AM,

[bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

It's well known that the Bitcoin merkle tree algorithm fails to distinguish between inner nodes and 64 byte transactions, as both txs and inner nodes are hashed the same way. This potentially poses a problem for tx inclusion proofs, as a miner could (with ~60 bits of brute forcing) create a

Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE

On Fri, Jun 01, 2018 at 02:53:01AM +0800, Johnson Lau via bitcoin-dev wrote: > I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE without > matched output: > > https://github.com/bitcoin/bitcoin/pull/13360 > > Signature of this form is insecure, as it commits to no output while

Re: [bitcoin-dev] Making OP_TRUE standard?

On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote: > Jim Posen writes: > > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF > > on the spending tx? > > Marco points out that if the parent is RBF, this child inherits it,

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Corallo via bitcoin-dev wrote: > BIP 158 currently includes the following in the "basic" filter: 1) > txids, 2) output scripts, 3) input prevouts. > > I believe (1) could be skipped entirely - there is almost no reason why > you'd not be able to

Re: [bitcoin-dev] Making OP_TRUE standard?

On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote: > > > > On 10 May 2018, at 3:27 AM, Peter Todd wrote: > > > > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: > >> You should make a “0 fee tx with exactly one OP_TRUE output”

Re: [bitcoin-dev] Making OP_TRUE standard?

On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: > You should make a “0 fee tx with exactly one OP_TRUE output” standard, but > nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > output won’t pollute the UTXO set > > Instead, would you

Re: [bitcoin-dev] Few questions regarding ListTransaction

On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote: > On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd wrote: > > Or via full replace-by-fee, which appears to be used by a significant > > minority > > of miners: > > I was of the impression that final transactions

Re: [bitcoin-dev] Few questions regarding ListTransaction

On Wed, Apr 11, 2018 at 02:22:42PM +0900, Karl-Johan Alm via bitcoin-dev wrote: > Clarification on one part below: > > On Wed, Apr 11, 2018 at 2:21 PM, Karl-Johan Alm > wrote: > > On Wed, Apr 11, 2018 at 5:29 AM, Maksim Solovjov via bitcoin-dev > >

Re: [bitcoin-dev] Data structure for efficient proofs of non-inclusion

On Wed, Feb 14, 2018 at 09:09:18PM +, Daniel Robinson wrote: > Hi Peter, > > Thanks for the mind-expanding presentation on client-side validation at > Chaincode last week. > CCing bitcoin-dev because this is of general interest... For background, Daniel is asking about my client-side

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Thu, Mar 08, 2018 at 03:07:43PM -0500, Russell O'Connor wrote: > On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd wrote: > > But that's not a good argument: whether or not normal users are trying to > > attack each other has nothing to do with whether or not you're opening up > >

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote: > On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote: > > I mean, I think in general solving this problem is probably not possible. > > Basically, the fundamental problem is someone else has consumed network > >

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote: > On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > > > > > Ah ok, I misunderstood and didn't realise you were talking about the case > > where > > Alice re-spends her unconfirmed payment. Unfortunately I

Re: [bitcoin-dev] Total fees have almost crossed the block reward

On Mon, Feb 12, 2018 at 08:41:39PM +0100, Christian Decker wrote: > Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> > writes: > > Does shabang.io say anywhere how it determines whether or not a transaction > > funded a Lightning channel? > >

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 06:23:12PM -0500, rha...@protonmail.com wrote: > > On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > I don't actually see where the problem is here. First of all, suppose we > &

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > I don't actually see where the problem is here. First of all, suppose we > > have a > > transaction T_a that already pays Alice with a feerate

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

On Mon, Feb 12, 2018 at 10:52:30AM -0500, Russell O'Connor via bitcoin-dev wrote: > I think it is worth revisiting BIP 125's replace-by-fee policy for when to > replace transactions. > > The current policy can be problematic. As noted earlier by Rhavar, > sometimes one's transaction becomes

Re: [bitcoin-dev] Total fees have almost crossed the block reward

On Mon, Feb 12, 2018 at 06:23:35PM +0100, Melvin Carvalho via bitcoin-dev wrote: > Finally, I came across this wonderful site that shows lightning network > adoption on mainnet > > http://shabang.io/ > > LN is increasing well. Some blocks are not far off 1% lightning funding, > which I think

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

On Tue, Jan 30, 2018 at 03:30:21AM +, CANNON via bitcoin-dev wrote: > On 01/30/2018 01:43 AM, CANNON via bitcoin-dev wrote: > > > > > > Forwarded Message > > Subject: RE: NIST 8202 Blockchain Technology Overview > > Date: Mon, 29 Jan 2018 12:25:05 + > > From: Yaga,

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Tue, Jan 23, 2018 at 10:49:34PM +, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev > wrote: > > Interesting. I didn't think about this before, but it seems like bip125 is > > rather incentive

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Tue, Jan 23, 2018 at 09:31:00PM +, Gregory Maxwell wrote: > On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Most transactions don't have change?! Under what circumstance? For most > > use-cases the rev

Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)

On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote: > So my half-baked idea is very simple: > > Allow users to merge multiple unconfirmed transactions, stripping extraneous > inputs and change as they go. > > This is currently not possible because of the bip125 rule: > "The

Re: [bitcoin-dev] Upgrading PoW algorithm

On Wed, Jan 17, 2018 at 04:31:52PM -0600, Jefferson Carpenter via bitcoin-dev wrote: > Bitcoin's difficulty will be maxed out within about 400 years, by Moore's > law. (After that - supposing the software does not crash when difficulty There's no reason to think Moore's law will last for 400

Re: [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme)

On Sat, Jan 13, 2018 at 03:44:03AM +, nullius via bitcoin-dev wrote: > (I think that next, I may start writing my disks with headers for LUKS, > which I do not use...) > > Whereupon, I challenge plausible deniability designers to `dd` a 6TB disk > with pseudorandom bytes, then try walking it

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Tue, Jan 09, 2018 at 12:43:48PM +, Perry Gibson wrote: > >Trezor's "plausible deniability" scheme could very well result in you going > >to > >jail for lying to border security, because it's so easy for them to simply > >brute force alternate passwords based on your seeds. With that, they

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 08, 2018 at 07:40:38PM -0500, Rhavar via bitcoin-dev wrote: > I think you're under-appreciating how useful the "plausible deniability". > Someone I know was (solo) traveling to the United States when a border agent > asked her to unlocked her phone; thumbed through her apps, ended up

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Tue, Jan 09, 2018 at 09:26:17AM +1100, Ben Kloester wrote: > > This sounds very dangerous. As Gregory Maxwell pointed out, the key > derivation > > function is weak enough that passphrases could be easily brute forced > > So you are essentially imagining that a perpetrator will combine the >

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 08, 2018 at 02:00:17PM +0100, Pavol Rusnak wrote: > On 08/01/18 13:45, Peter Todd wrote: > > Can you explain _exactly_ what scenario the "plausible deniability" feature > > refers to? > > >

Re: [bitcoin-dev] Satoshilabs secret shared private key scheme

On Mon, Jan 08, 2018 at 01:39:20PM +0100, Pavol Rusnak via bitcoin-dev wrote: > > The construction also > > will silently result in the user getting a different private key if > > they enter the wrong passphrase-- which could lead to funds loss. > > Again, this is by design and it is main point

Re: [bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication

On Mon, Dec 11, 2017 at 10:23:21PM +, Pulat Yunusov wrote: > Thank you for your post, Peter. Why is it necessary to centralize the p-o-p > sidechain and have a maintainer? It seems the Bitcoin network will secure > the most critical element, which is the witness authenticity. Wouldn't a >

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

On Tue, Dec 05, 2017 at 07:39:32PM +, Luke Dashjr via bitcoin-dev wrote: > On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote: > > I recently submitted a pull request that would turn on RBF by default, > > which triggered some discussion [2]. To ease the transition for merchants > >

[bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication

I recently wrote this up for a client, and although the material has been covered elsewhere, I thought being a worked example it might be of interest, particularly while sidechains are being discussed again. As per (1) I've perhaps foolishly committed to making an even more fleshed out example,

Re: [bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits, extendability

On Tue, Nov 21, 2017 at 06:45:33PM +, Gregory Maxwell via bitcoin-dev wrote: > With the way pruning works today my expirence is that virtually no one > sets any parameter other than the minimum, though even with that set a > few more blocks can be available. FWIW, I run all my pruned nodes

Re: [bitcoin-dev] Updates on Confidential Transactions efficiency

On Tue, Nov 14, 2017 at 01:21:14AM +, Gregory Maxwell via bitcoin-dev wrote: > The primary advantage of this approach is that it can be constructed > without any substantial new cryptographic assumptions (e.g., only > discrete log security in our existing curve), that it can be high >

Re: [bitcoin-dev] Updates on Confidential Transactions efficiency

On Tue, Nov 14, 2017 at 01:21:14AM +, Gregory Maxwell via bitcoin-dev wrote: > Jump to "New things here" if you're already up to speed on CT and just > want the big news. > This work also allows arbitrarily complex conditions to be proven in > the values, not just simple ranges, with proofs

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Fri, Sep 29, 2017 at 02:45:32PM +0200, Andreas Schildbach via bitcoin-dev wrote: > On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote: > > >>> I'm well aware. As the payment protocol hasn't caught on - and doesn't > >>> fully > >>> overlap all

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

On Thu, Sep 28, 2017 at 07:45:02PM -0700, Mark Friedenbach wrote: > > > > On Sep 28, 2017, at 7:02 PM, Peter Todd wrote: > > > >> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev > >> wrote: > >> Unlike other proposed fixes to the fee model, this

[bitcoin-dev] Why the BIP-72 Payment Protocol URI Standard is Insecure Against MITM Attacks

On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote: > Andreas Schildbach wrote: > > This feels redundant to me; the payment protocol already has an > > expiration time. > > The BIP-70 payment protocol has significant overhead and most importantly > requires back and

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote: > Peter Todd wrote: > Perhaps outside the scope of BIP173, but what about baking it into the > protocol? That way a transaction that's sent too late, simply won't get > confirmed. This removes the need for refund

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

On Fri, Sep 29, 2017 at 01:53:55AM +, Matt Corallo via bitcoin-dev wrote: > I'm somewhat curious what the authors envisioned the real-world implications > of this model to be. While blindly asking users to enter what they're willing > to pay always works in theory, I'd imagine in such a

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote: > Unlike other proposed fixes to the fee model, this is not trivially > broken by paying the miner out of band. If you pay out of band fee > instead of regular fee, then your transaction cannot be included with >

Re: [bitcoin-dev] Revising BIP 2 to expand editorial authority

On Wed, Sep 27, 2017 at 02:01:40PM -0500, Bryan Bishop via bitcoin-dev wrote: > On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > What do people think about modifying BIP 2 to allow editors to merge these > > kinds of changes

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Thu, Sep 28, 2017 at 12:58:30AM +, Gregory Maxwell wrote: > On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Re-use of old addresses is a major problem, not only for privacy, but also > > operationally:

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Thu, Sep 28, 2017 at 12:09:59PM +0200, Andreas Schildbach via bitcoin-dev wrote: > This feels redundant to me; the payment protocol already has an > expiration time. I'm well aware. As the payment protocol hasn't caught on - and doesn't fully overlap all the usecases that addresses do anyway

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Wed, Sep 27, 2017 at 12:06:54PM -0400, Peter Todd via bitcoin-dev wrote: > Being just an expiration time, seconds-level resolution is unnecessary, and > may give the wrong impression. I'd suggest either: > > 1) Hour resolution - 2^24 hours = 1914 years > 2) Month resolutio

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Wed, Sep 27, 2017 at 12:03:44PM -0700, Mark Friedenbach wrote: > While there is a lot that I would like to comment on, for the moment I will > just mention that you should consider using the 17 bit relative time format > used in CSV as an offset from the birthdate of the address, a field all

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

On Wed, Sep 27, 2017 at 01:35:33PM -0600, Chris Priest wrote: > A better solution is to just have the sending wallet check to see if the > address you are about to send to has been used before. If it's a fresh My concern is not primarily people re-using addresses, but rather people using stale

[bitcoin-dev] Address expiration times should be added to BIP-173

Re-use of old addresses is a major problem, not only for privacy, but also operationally: services like exchanges frequently have problems with users sending funds to addresses whose private keys have been lost or stolen; there are multiple examples of exchanges getting hacked, with users

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

On Wed, Sep 13, 2017 at 08:27:36AM +0900, Karl Johan Alm via bitcoin-dev wrote: > On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev > wrote: > >> Without the limit I think we would be DoS-ed to dead > > > > 4MB of secp256k1 signatures takes

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

On Sat, Sep 09, 2017 at 11:11:57PM +0200, Jorge Timón wrote: > Tier Nolan, right, a new tx version would be required. > > I have to look deeper into the CT as sf proposal. > > What futures upgrades could this conflict with it's precisely the > question here. So that vague statement without

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote: > Thanks for the proposal. > > Three points it could see as possible improvements: > > 1. > From what I know, the exact birthday in seconds doesn’t matter that much > therefore it may be possible to just use 13 or

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

On Thu, Sep 07, 2017 at 06:37:19PM +0200, Pavol Rusnak via bitcoin-dev wrote: > On 07/09/17 18:30, Kabuto Samourai wrote: > > Why not make this block height, rather than a timestamp? > > Blockheight depends on the chain. XPUB is not tied to particular > chain/coin. > > Also there are already

Re: [bitcoin-dev] Fast Merkle Trees

On Wed, Sep 06, 2017 at 09:59:54PM -0400, Russell O'Connor via bitcoin-dev wrote: > The fast hash for internal nodes needs to use an IV that is not the > standard SHA-256 IV. Instead needs to use some other fixed value, which > should itself be the SHA-256 hash of some fixed string (e.g. the

Re: [bitcoin-dev] P2WPKH Scripts, P2PKH Addresses, and Uncompressed Public Keys

On Mon, Aug 28, 2017 at 08:55:47PM +, Alex Nagy via bitcoin-dev wrote: > Thanks Gregory - to be clear should Native P2WPKH scripts only appear in > redeem scripts? From reading the various BIPs it had seemed like Native > P2WPKH and Native P2WSH were also valid and identifiable if they were

Re: [bitcoin-dev] "Compressed" headers stream

On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev wrote: > Well, if anything my question may bolster your use-case. If there's a > heavier chain that is invalid, I kind of doubt it matters for timestamping > reasons. Timestamping can easily be *more* vulnerable to malicious

Re: [bitcoin-dev] Fwd: "Compressed" headers stream

On Mon, Aug 28, 2017 at 05:12:15PM +, Gregory Maxwell via bitcoin-dev wrote: > You are leaving a lot of bytes on the table. > > The bits field can only change every 2016 blocks (4 bytes per header), > the timestamp can not be less than the median of the last 11 and is > usually only a small

Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]

On Mon, Jul 17, 2017 at 02:49:22PM -0400, Alex Morcos via bitcoin-dev wrote: > "it was ACKed by everyone else that I heard from" - I don't think you > should read into that much. > > I felt like this whole conversation was putting the cart before the horse. > You might very well have some good

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 29, 2017 at 10:55:37AM -0400, Russell O'Connor wrote: > > This doesn't hold true in the case of pruned trees, as for the pruning to > > be > > useful, you don't know what produced the left merkleRoot, and thus you > > can't > > guarantee it is in fact a midstate of a genuine SHA256

Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat

On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote: > There has been proposal to change the PoW in case of potential 51% attacks > from malicious miners during a fork. But such a change in PoW renders > multi-billion-dollar of ASIC into worthless. which hurts economy so much

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 29, 2017 at 10:55:37AM -0400, Russell O'Connor wrote: > > This doesn't hold true in the case of pruned trees, as for the pruning to > > be > > useful, you don't know what produced the left merkleRoot, and thus you > > can't > > guarantee it is in fact a midstate of a genuine SHA256

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote: > Surprisingly, this requirement (or, more precisely, this incentive) does > not effect miners relative to each other. The incentive to upgrade is only > for the purpose of preventing a "theft" -- defined as: an improper > withdrawal

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 22, 2017 at 06:32:38PM -0400, Russell O'Connor wrote: > On May 22, 2017 23:05, "Peter Todd" wrote: > > On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev > wrote: > > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > >

Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes

On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote: > >It'd help your case if you gave us some examples of such scripts being > used. > > I want OP_CAT so that I can securely and compactly verify many hashes and > hash preimages. This would shrink offchain Tumblebit transactions >

Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes

On Fri, May 19, 2017 at 09:07:41AM +0300, Mark Boldyrev via bitcoin-dev wrote: > Back in 2010, there was a bug found in Core which allowed denial-of-service > attacks due to the software crashing on some machines while executing a > script - see CVE-2010-537. > I believe the removed ("disabled")

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev wrote: > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > sha256Compress : Word256 × Word512 -> Word256 To be clear, what math operations do you mean by "⋅" and "×"? -- https://petertodd.org

Re: [bitcoin-dev] Drivechain -- Request for Discussion

On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote: > This work includes the relatively new concept of "Blind Merged Mining" > [2] which I developed in January to allow SHA256^2 miners to merge-mine > these "drivechains", even if these miners aren't running the actual >

Re: [bitcoin-dev] Barry Silbert segwit agreement

On Mon, May 22, 2017 at 02:12:08AM -0400, shaolinfry via bitcoin-dev wrote: > Someone sent me a copy of the Barry Silbert agreement, an agreement forged > between a select number of participants https://pastebin.com/VuCYteJh It's interesting how changing the bit used to signal could be used as a

<    1   2   3   4   5   >