Re: [bitcoin-dev] Fees and the block-finding process

On Tue, Aug 11, 2015 at 11:30 PM, Angel Leon via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: tell that to people in poor countries, or even in first world countries. The competitive thing here is a deal breaker for a lot of people who have no clue/don't care for decentralization,

[bitcoin-dev] Disclosure: consensus bug indirectly solved by BIP66

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, I'd like to disclose a vulnerability I discovered in September 2014, which became unexploitable when BIP66's 95% threshold was reached earlier this month. ## Short description: A specially-crafted transaction could have forked the

[bitcoin-dev] Block size following technological growth

Hello all, here is a proposal for long-term scalability I've been working on: https://gist.github.com/sipa/c65665fc360ca7a176a6 Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the hard

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Let's scale the block size gradually over time, according to technological growth. Yes, lets do that-- that is EXACTLY what BIP101

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: There is a summary of the proposals in my previous mail at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html 1. Initiation: BIP34 style voting, with support of 750

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Regarding the block size increase, at least conceptually it seems to me there should be an easy solution. If we look at what works well with bitcoin, for example the block reward

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

2. Starting date: 30 days after 75% miner support, but not before 2016-01-12 00:00 UTC Rationale: A 30-day grace period is given to make sure everyone has enough time to follow. This is a compromise between 14 day in BIP101 and 1 year in BIP103. I tend to agree with BIP101. Even 1 year is

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I would say that things already demonstrately got terrible. The mining landscape is very centralized

Re: [bitcoin-dev] Wrapping up the block size debate with voting

I would like to withdraw my proposal from your self-appointed vote. If you want to let a majority decide about economic policy of a currency, I suggest fiat currencies. They have been using this approach for quite a while, I hear. Bitcoin's consensus rules are a consensus system, not a

Re: [bitcoin-dev] Block size following technological growth

On Jul 30, 2015 6:20 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion

Re: [bitcoin-dev] Fees and the block-finding process

On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hitting the limit in and of itself is not necessarily a bad thing. The question at hand is whether we should constrain that limit below what technology is capable of delivering. I'm

Re: [bitcoin-dev] Block size following technological growth

On Aug 6, 2015 9:42 PM, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: 2. The market minimum fee should be determined by the market. It should not be up to us to decide when is a good time. I partially agree. The community should decide what risks it is willing to

Re: [bitcoin-dev] Wrapping up the block size debate with voting

On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Miners can do this unilaterally maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding.

Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment

On Sun, Jun 28, 2015 at 9:50 PM, Peter Todd p...@petertodd.org wrote: On Thu, Jun 25, 2015 at 06:33:44PM -0400, Peter Todd wrote: Thoughts? If there are no objections I'll go ahead and write that code, using the same thresholds as BIP66. I've opened a pull-req to deploy CHECKLOCKTIMEVERIFY

Re: [bitcoin-dev] Fwd: Block size following technological growth

On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: You make a logical fallacy; I would agree that nodes are there for people to stop trusting someone that they have no trust-relationship with. Yay, trust! But your conclusion that

Re: [bitcoin-dev] Fees and the block-finding process

On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille pieter.wui...@gmail.com wrote: I guess my question (and perhaps that's what Jorge is after): do you feel that blocks should be increased in response to (or for fear

Re: [bitcoin-dev] Fwd: Block size following technological growth

On Fri, Aug 7, 2015 at 7:00 PM, Thomas Zander via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: If the incentives for running a node don't weight up against the cost/difficulty using a full node yourself for a majority of people in the ecosystem, I would argue that there is a

Re: [bitcoin-dev] Fees and the block-finding process

On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Every once in a while the network will get lucky and we'll find six blocks in ten minutes. If you are deciding what transaction fee to put on your transaction, and you're willing to

Re: [bitcoin-dev] Fees and the block-finding process

On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen gavinandre...@gmail.com wrote: Executive summary: when networks get over-saturated, they become unreliable. Unreliable is bad. Unreliable and expensive is extra bad, and that's where we're headed without an increase to the max block size. I

Re: [bitcoin-dev] What Lightning Is

On Aug 10, 2015 7:03 PM, odinn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Note that I've been in favor of going ahead with Cameron Garnham's dynamic softfork proposal right now, which can be seen at http://is.gd/DiFuRr No offence, but I think that anyone who claims a block

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

On Aug 7, 2015 11:19 PM, Sergio Demian Lerner via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: b. Reduce the block rate to a half (average 5 minute blocks) Suppose this is a one time hard fork. There no drastic technical problems with any of them: SPV mining and the relay network

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

On Aug 11, 2015 12:11 AM, Sergio Demian Lerner sergio.d.ler...@gmail.com wrote: What I'm saying is that this ratio may have improved 20x since miners began using the TheBlueMatt relay network, so deteriorating the ratio 2x does not put miners in a unknown future, but in an future which is far

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: This is a much more reasonable position. I wish this had been starting point of this

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille pieter.wui...@gmail.com wrote: But you seem to consider that a bad thing. Maybe saying that you're claiming that this equals Bitcoin failing is an exaggeration, but

Re: [bitcoin-dev] "Subsidy fraud" ?

I meant a miner claiming more in the coinbase's output than subsidy + fees allow. On Dec 10, 2015 5:26 AM, "xor" wrote: > Pieter Wuille mentions "subsidy fraud" in his recent talk: > https://youtu.be/fst1IK_mrng?t=57m2s > > I was unable to google what this is, and the

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev wrote: > 4.3. Observations on new block economic model > > SW complicates block economics by creating two separate, supply limited > resources. Not correct. I propose defining the

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev wrote: > 2) If block size stays at 1M, the Bitcoin Core developer team should sign a > collective note stating their desire to transition to a new economic policy, > that of "healthy fee market"

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 10:27 PM, Jeff Garzik wrote: >> Not correct. I propose defining the virtual_block_size as base_size + >> witness_size * 0.25, and limiting virtual_block_size to 1M. This >> creates a single variable to optimize for. If accepted, miners are >> incentived

Re: [bitcoin-dev] Segregated Witness features wish list

On Sun, Dec 13, 2015 at 4:25 PM, jl2012--- via bitcoin-dev wrote: > I'm trying to list the minimal consensus rule changes needed for segwit > softfork. The list does not cover the changes in non-consensus critical > behaviors, such as relay of witness data.

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote: >> You present this as if the Bitcoin Core development team is in charge >> of deciding the network consensus rules, and is responsible for making >> changes to it in order to satisfy economic demand. If that is the >> case,

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

> "The problem case is where someone in a contract setup shows you a script, which you accept as being a payment to yourself. An attacker could use a collision attack to construct scripts with identical hashes, only one of which does have the property you want, and steal coins. > > So you really

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Dec 26, 2015 23:55, "Jonathan Toomim" <j...@toom.im> wrote: > > On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Furthermore, 75% is pretty terrible as a switchover point, as it guarantees th

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Dec 27, 2015 00:06, "Jonathan Toomim" wrote: > Given that a supermajority of users and miners have been asking for a hard fork to increase the blocksize for years, I do not think that mobilizing people to upgrade their nodes is going to be hard. > > When we do the hard fork, we

[bitcoin-dev] On the security of softforks

Hello all, For a long time, I was personally of the opinion that soft forks constituted a mild security reduction for old full nodes, albeit one that was preferable to hard forks due to being far less risky, easier, and less forceful to deploy. After thinking more about this, I'm not convinced

Re: [bitcoin-dev] BIP141 segwit consensus rule update: extension of witness program definition

On Jun 8, 2016 18:46, "Luke Dashjr via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Wednesday, June 08, 2016 8:23:51 AM Johnson Lau wrote: > > If someday 32 bytes hash is deemed to be unsafe, the txid would also be > > unsafe and a hard fork might be needed. Therefore, I

Re: [bitcoin-dev] RFC for BIP: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

On Jun 15, 2016 12:53, "Daniel Weigl via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > That would be a big privacy leak, imo. As soon as both outputs are spent, its visible > which one was the P2WPKH-in-P2SH and which one the pure P2WPKH and as a consequence > you leak which

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > In any case, I'd strongly argue that we remove BIP75 from the bips repository, > and boycott wallets that implement it. It's bad strategy for Bitcoin developers > to willingly participate in

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

On Jun 23, 2016 14:10, "Peter Todd" wrote: > Right, so you accept that we'll exert some degree of editorial control; the > question now is what editorial policies should we exert? No, I do not. I am saying that some degree of editorial control will inevitably exist, simply

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd wrote: > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote: >> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> > In any case, I'd strongly argue that we remove

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

On Fri, Jan 8, 2016 at 2:54 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm saying we can eliminate one somewhat unlikely attack (that there is a > bug in the code or test cases, today or some future version, that has to > decide what to do with "version 0"

Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512

On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > >It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). But that's probably just my crypto ignorance... > > SHA256(key|cipher-type|mesg) is an extremely insecure MAC

Re: [bitcoin-dev] Segwit Upgrade Procedures & Block Extension Data

On Thu, Jan 28, 2016 at 7:51 PM, Peter Todd via bitcoin-dev wrote: > A few notes on upgrade procedures associated with segregated witnesses: > While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for > the above problem, the obvious thing to

Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev wrote: > > I really don't like the idea of policing other people's use of the > > protocol. If a transaction pays its fee

Re: [bitcoin-dev] Compact Block Relay BIP

On 05/03/2016 12:13 AM, lf-lists at mattcorallo.com (Matt Corallo) wrote: > Hi all, > > The following is a BIP-formatted design spec for compact block relay > designed to limit on wire bytes during block relay. You can find the > latest version of this document at >

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev wrote: > By sending a public seed, there's no way for someone to use the transmitted > address and trace the total amount of payments to it. Worse. By revealing a public seed, anyone who has

Re: [bitcoin-dev] BIP 151

On Thu, Jun 30, 2016 at 11:57 AM, Eric Voskuil via bitcoin-dev wrote: > The proliferation of node identity is my primary concern - this relates to > privacy and the security of the network. I think this is a reasonable concern. However, node identity is

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

On Aug 17, 2016 00:36, "Russell O'Connor" wrote: > Can I already do something similar with replace by fee, or are there limits on that? BIP125 and mempool eviction both require the replacing transaction to have higher fee, to compensate for the cost of relaying the

Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH

On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > If one's goal is to mess with an transaction to prevent it from being mined, it is more effective to just not relay the transaction rather than to mess with the witness. Given two

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Hi Peter, I really, really don’t want to get into it but segwit has many aspects that are less appealing, not least of which being the amount of time it would take to reach the critical mass.

Re: [bitcoin-dev] BIP151 protocol incompatibility

On Feb 12, 2017 23:58, "Eric Voskuil via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: The BIP151 proposal states: > This proposal is backward compatible. Non-supporting peers will ignore the encinit messages. This statement is incorrect. Sending content that existing nodes do

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

On Feb 25, 2017 22:26, "Steve Davis" wrote: Hi Pieter, > On Feb 25, 2017, at 4:14 PM, Pieter Wuille wrote: > > Any alternative to move us away from RIPEMD160 would require: > “Any alternative”? What about reverting to: [,

Re: [bitcoin-dev] A Better MMR Definition

On Feb 28, 2017 15:10, "Bram Cohen via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew Stone wrote: > > But since transactions' prevouts are not specified by [block height, tx > index, output index] or by TXO

Re: [bitcoin-dev] BIP Status updates (including to Active/Final Status) - BIP 39, BIP 43, BIP 44, BIP 67, BIP 111, BIP 125, BIP 130

This is not the place to discuss the merits and/or issues of these BIPs, only whether they should be treated as final. On Aug 25, 2016 10:51, "Marek Palatinus via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > As Luke pointed, BIP44 is already used by many wallets and to my

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

On Wed, Nov 16, 2016 at 5:58 AM, Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This sort of statement represents one consequence of the aforementioned > bad precedent. > > Are checkpoints good now? > So far in this discussion, and in a thread that has forked off,

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

On Wed, Nov 16, 2016 at 6:16 PM, Eric Voskuil wrote: > On 11/16/2016 05:50 PM, Pieter Wuille wrote: > > > So are checkpoints good now? > > I believe we should get rid of checkpoints because they seem to be > misunderstood as a security feature rather than as an optimization.

[bitcoin-dev] Start time for BIP141 (segwit)

Hello all, We're getting ready for Bitcoin Core's 0.13.1 release - the first one to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin mainnet, after being extensively tested on testnet and in other software. Following the BIP9 recommendation [1] to set the versionbits start time a

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We have models for estimating the probability that a block is orphaned > given average network bandwidth and block size. > > The question is, do we have objective measures of these two

Re: [bitcoin-dev] Issolated Bitcoin Nodes

On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev wrote: > Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is > ok, and those blocks propagate to older nodes with no issues. But when a > block tries to be propagated from

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev wrote: > So I think Core can't decide on hard forks like this. It must be left up to > the users. I think only choice is for Core to add a run-time option to allow > node operators to increase

Re: [bitcoin-dev] Unique node identifiers

On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil wrote: > On 03/08/2017 03:12 PM, Pieter Wuille wrote: >> In that way, I see BIP150 as an extension of IP addresses, except more >> secure against network-level attackers. If you believe the concept of >> people establishing links

Re: [bitcoin-dev] Unique node identifiers

On Wed, Mar 8, 2017 at 1:20 PM, Jonas Schnelli via bitcoin-dev wrote: > >> Am 08.03.2017 um 22:09 schrieb Eric Voskuil : >> >> On 03/08/2017 11:47 AM, Jonas Schnelli wrote: > Nodes are by design not supposed to be identifiable in any

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc wrote: > Pieter, > > I think that you have misrepresented Chris' view by taking it out of > context. His complete quote reads "If drivechains are successful they should > be viewed as the way we scale -- not hard forking the

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Concept ACK. If drivechains are successful they should be viewed as the way we scale I strongly disagree with that statement. Drivechains, and several earlier sidechains ideas, are not a

[bitcoin-dev] Rolling UTXO set hashes

Hello all, I would like to discuss a way of computing a UTXO set hash that is very efficient to update, but does not support any compact proofs of existence or non-existence. Much has been written on the topic of various data structures and derived hashes for the UTXO/TXO set before (including

Re: [bitcoin-dev] Rolling UTXO set hashes

On Tue, May 16, 2017 at 4:01 AM, Peter Todd via bitcoin-dev wrote: > To be clear, *none* of the previous (U)TXO commitment schemes require *miners* > to participate in generating a commitment. While that was previously thought > to > be true by many, I've

Re: [bitcoin-dev] Rolling UTXO set hashes

On Mon, May 22, 2017 at 9:47 PM, Rusty Russell wrote: > Gregory Maxwell via bitcoin-dev > writes: >> On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille >> wrote: >>> just the first - and one that has very low

Re: [bitcoin-dev] A BIP proposal for segwit addresses

On Sun, May 7, 2017 at 2:39 PM, Pieter Wuille wrote: > I'd like to move forward and request a BIP number assignment for this > proposal. The proposal has been submitted as BIP173: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki Cheers, -- Pieter

Re: [bitcoin-dev] A BIP proposal for segwit addresses

On Mon, Mar 20, 2017 at 2:35 PM, Pieter Wuille wrote: > Hello everyone, > > You can find the text here: > https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki > Responding to a few comments: By Andreas Schildbach: > I'm not convinced that transmitting

Re: [bitcoin-dev] proposal: extend WIF format for segwit

On Sep 15, 2017 01:56, "Thomas Voegtlin via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Note 3: we could also use a bech32 format for the private key, if it is going to be used with a bech32 address. I am not sure if such a format has been proposed already. I've been working on

Re: [bitcoin-dev] BIP - Dead Man's Switch

On Dec 11, 2017 10:23, "Nick Pudar via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: This topic has come up several times in recent years. While it is well intentioned, it can have devastating outcomes for people that want to save long term. If such a system were implemented, it

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

On Oct 30, 2017 15:21, "shiva sitamraju via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62 bytes ! ... While I get the

Re: [bitcoin-dev] Should Graftroot be optional?

On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille wrote: > Hello all, > > Given the recent discussions about Taproot [1] and Graftroot [2], I > was wondering if a practical deployment needs a way to explicitly > enable or disable the Graftroot spending path. I have no

[bitcoin-dev] Minimizing the redundancy in Golomb Coded Sets

Hi all, I spent some time working out the optimal parameter selection for the Golomb Coded Sets that are proposed in BIP158: https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845 TL;DR: if we really want an FP rate of exactly 1 in 2^20, the Rice parameter should be 19, not 20. If we

[bitcoin-dev] Should Graftroot be optional?

Hello all, Given the recent discussions about Taproot [1] and Graftroot [2], I was wondering if a practical deployment needs a way to explicitly enable or disable the Graftroot spending path. I have no strong reasons why this would be necessary, but I'd like to hear other people's thoughts. As a

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

On Fri, May 18, 2018, 19:57 Olaoluwa Osuntokun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Greg wrote: > > What about also making input prevouts filter based on the scriptpubkey > being > > _spent_? Layering wise in the processing it's a bit ugly, but if you > > validated

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

On Mon, Jun 11, 2018, 07:37 Bradley Denby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for the comments Pieter! > > We can make descriptions for the intended node behaviors more clear in the > BIP. > > Regarding interaction with BIPs 37 and 133, we have found that if >

[bitcoin-dev] BIP 174 thoughts

Hello all, given some recent work and discussions around BIP 174 (Partially Signed Bitcoin Transaction Format) I'd like to bring up a few ideas. First of all, it's unclear to me to what extent projects have already worked on implementations, and thus to what extent the specification is still

Re: [bitcoin-dev] New serialization/encoding format for key material

On Sun, Jun 3, 2018 at 2:30 PM, Jonas Schnelli wrote: >> If there is interest, I can construct a code + implementation for any >> of these in a few days probably, once the requirements are clear. > > Yes. Please. Here is an example BCH code for base32 data which adds 27 checksum characters, and

Re: [bitcoin-dev] BIP 174 thoughts

On Tue, Jun 19, 2018 at 7:20 AM, matejcik via bitcoin-dev wrote: Thanks for your comments so far. I'm very happy to see people dig into the details, and consider alternative approaches. > 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we > know, which BIP-32 path goes to

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

On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Lighter but SPV secure nodes (filter committed) would help the network > (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW. > > On longer term most users' security

Re: [bitcoin-dev] New serialization/encoding format for key material

On Sun, Jun 3, 2018 at 9:51 AM, Jonas Schnelli via bitcoin-dev wrote: > Hi > > The BIP proposal is now available here: > https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719 > > Reference C code is available here: > https://github.com/jonasschnelli/bech32_keys > > Feedback,

Re: [bitcoin-dev] Should Graftroot be optional?

On Fri, May 25, 2018 at 3:14 AM, Johnson Lau wrote: > A graftroot design like this is a strict subset of existing signature > checking rules. If this is dangerous, the existing signature checking rules > must be dangerous. While you may be right in this situation, I'm not sure that conclusion

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

On Thu, May 10, 2018 at 5:59 AM, Bradley Denby via bitcoin-dev wrote: > Hi all, > > ... > > This iteration of Dandelion has been tested on our own small network, and we > would like to get the implementation in front of a wider audience. An > updated > BIP document with further details on

Re: [bitcoin-dev] Should Graftroot be optional?

On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev wrote: > On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote: >> The best argument for why Graftroot does not need to be optional I >> think was how Greg put it: "since the signer(s) could have si

Re: [bitcoin-dev] BIP 174 thoughts

On Tue, Jun 26, 2018 at 8:33 AM, matejcik via bitcoin-dev wrote: > I'm still going to argue against the key-value model though. > > It's true that this is not significant in terms of space. But I'm more > concerned about human readability, i.e., confusing future implementers. > At this point, the

Re: [bitcoin-dev] BIP 174 thoughts

On Wed, Jun 27, 2018, 07:04 matejcik wrote: > hello, > > On 26.6.2018 22:30, Pieter Wuille wrote: > >> (Moreover, as I wrote previously, the Combiner seems like a weirdly > >> placed role. I still don't see its significance and why is it important > >> to correctly combine PSBTs by agents that

Re: [bitcoin-dev] BIP 174 thoughts

On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev wrote: > I have personally implemented this spec on an embedded micro, as > the signer and finalizer roles, and written multiple parsers for > it as well. There is nothing wrong with it, and it perfectly meets > my needs as a

Re: [bitcoin-dev] New serialization/encoding format for key material

On Fri, Jun 15, 2018 at 8:54 AM, Russell O'Connor wrote: > >> For codes designed for length 341 (the first length enough to support >> 512 bits of data): >> * correct 1 error = 3 checksum characters >> * correct 2 errors = 7 checksum characters >> * correct 3 errors = 11 checksum characters >> *

Re: [bitcoin-dev] BIP 117 Feedback

On Jan 9, 2018 13:41, "Mark Friedenbach via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: The use of the alt stack is a hack for segwit script version 0 which has the clean stack rule. Anticipated future improvements here are to switch to a witness script version, and a new segwit

Re: [bitcoin-dev] BIP 174 thoughts

On Thu, Jun 21, 2018 at 4:29 AM, matejcik wrote: > In the case of everything per-input, the naive Signer can do this: > 1. (in the global section) pre-serialize the transaction > 2. (in each input) find and fill out scriptPubKey from the provided UTXO > 3. (for a given BIP32 path) check if the

[bitcoin-dev] Witness serialization in PSBT non-witness UTXOs

Hello all, BIP174 currently specifies that non-witness UTXOs (the transactions being spent by non-witness inputs) should be serialized in network format. I believe there are two issues with this. 1. Even in case the transaction whose output being spent itself has a witness, this witness is

Re: [bitcoin-dev] Schnorr signatures BIP

On Sat, Jul 14, 2018 at 8:42 AM, Sjors Provoost wrote: > Questions: > > Regarding verification: why does bytes(P) use compressed key serialization > rather than the implicit Y coordinate used for signing? I understand space > savings don't matter since these values don't end up on the

Re: [bitcoin-dev] Extending BIP174 for HTLCs

On Tue, Sep 4, 2018, 04:32 Alex Bosworth via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've been experimenting with a format tag for BIP 174 to help support > HTLC scripts I've been working with. > I've been thinking about this as well. A useful way to look at it IMHO is to

Re: [bitcoin-dev] BIP 174 thoughts

On Thu, Jul 5, 2018 at 4:52 AM, matejcik wrote: >> Allowing combiners to choose any value also allows for intelligent combiners >> to choose the >> correct values in the case of conflicts. A smart combiner could, when >> combining redeem scripts >> and witness scripts, check that the redeem

Re: [bitcoin-dev] Multiparty signatures

On Sun, Jul 8, 2018, 07:26 Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > To save space, start with the wiki terminology on schnorr sigs. > > Consider changing the "e" term in the schnorr algorithm to hash of message > (elligator style) to the power of r, rather

Re: [bitcoin-dev] Multiparty signatures

On Sun, Jul 8, 2018, 19:23 Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Pretty sure these non interactive sigs are more secure. > Schnorr signatures are provably secure in the random oracle model assuming the discrete logarithm problem is hard in the used

Re: [bitcoin-dev] BIP 174 thoughts

On Tue, Jul 10, 2018 at 5:10 AM, matejcik wrote: > On 6.7.2018 00:06, Pieter Wuille wrote:> The only case where "malicious" > conflicting values can occur is when >> one of the Signers produces an invalid signature, or modifies any of >> the other fields already present in the PSBT for

[bitcoin-dev] Schnorr signatures BIP

Hello everyone, Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures, over the same curve as is currently used in ECDSA: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki It is simply a draft specification of the signature scheme itself. It does not concern

Re: [bitcoin-dev] Multiparty signatures

On Sun, Jul 8, 2018, 21:29 Erik Aronesty wrote: > Because it's non-interactive, this construction can produce multisig > signatures offline. Each device produces a signature using it's own > k-share and x-share. It's only necessary to interpolate M of n shares. > > There are no round trips.

Re: [bitcoin-dev] BIP 174 thoughts

On Wed, Jul 4, 2018 at 6:19 AM, matejcik wrote: > hello, > > we still have some concerns about the BIP as currently proposed - not > about the format or data contents, but more about strictness and > security properties. I have raised some in the previous e-mails, but > they might have been lost

  1   2   >