Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1

Hi Yuri, While not exactly the same, the idea of using Lamport chains was analyzed circa 2012 in the context of cryptocurrencies. I proposed a new signature scheme called MAVE [1], and then a cryptocurrency scheme called MAVEPAY [2] to reduce the size of signatures to a minimum of 3 hash

Re: [bitcoin-dev] Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

Hi Roben, It's an interesting proposal, but I have two issues with it, one technical and one philosophical. On the technical side, I don't understand how your proposal prevents miners proposing a peg-out for an invalid sidechain fork which is not made available to the nodes (there are missing

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

Seems to be comparable to the proposed "Tick Method" from 2013: https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565 However I remember that someone told me the tick method had a flaw.. On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <

[bitcoin-dev] Fwd: Simple change to the "merkleblock" command to protect from SPV proof extension attacks

Hi, While fixing RSK's SPV bridge I came up with an idea to fix the MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using Bitcoin's Merkle tree structure flaws. The most annoying attack is the one that tries to confuse a victim peer into thinking a transaction is an inner

[bitcoin-dev] Simple change to the "merkleblock" command to protect from SPV proof extension attacks

Hi, While fixing RSK's SPV bridge I came up with an idea to fix the MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using Bitcoin's Merkle tree structure flaws. The most annoying attack is the one that tries to confuse a victim peer into thinking a transaction is an inner

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

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 attack are different, so it must be considered separately. It should be said

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

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 more than 1M USD using a SPV wallet. Also the attack can be repeated: once you

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

Hi Peter, We reported this as CVE-2017-12842, although it may have been known by developers before us. There are hundreds of SPV wallets out there, without even considering other more sensitive systems relying on SPV proofs. As I said we, at RSK, discovered this problem in 2017. For RSK it's very

Re: [bitcoin-dev] [BIP] Stratum protocol specification

When we worked on the extensions for RSK merge mining, I prepared an internal document with the most up to date Straum protocol description I could get. This is the document: https://docs.google.com/document/d/1ocEC8OdFYrvglyXbag1yi8WoskaZoYuR5HGhwf0hWAY/edit?usp=sharing Regards On Fri, Feb 9,

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

If the variable size increase is only a few bytes, then three possibilities arise: - one should allow signatures to be zero padded (to reach the maximum size) and abandon strict DER encoding - one should allow spare witness stack elements (to pad the size to match the maximum size) and remove

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

But generally before one signs a transaction one does not know the signature size (which may be variable). One can only estimate the maximum size. On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach wrote: > > On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner < >

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

> > There are other solutions to this problem that could have been taken > instead, such as committing to the number of items or maximum size of > the stack as part of the sighash data, but cleanstack was the approach > taken. The lack of signed maximum segwit stack size was one of the

Re: [bitcoin-dev] Responsible disclosure of bugs

Historically people have published vulnerabilities in Bitcoin only after >80% of the nodes have upgraded. This seems to be the general (but not publicly stated) policy. If you're a core developer and you know better, please correct me. This means that: - a critical vulnerability, like a remote

Re: [bitcoin-dev] A Segwit2x BIP

The BIP has been updated. Changes: - The technical spec has been improved: now the block size increase is specified in terms of weight and not in terms of bytes. - The increase in the maximum block sigops after HF has been documented. - Comments added about the worst case block size. Happy

Re: [bitcoin-dev] A Segwit2x BIP

Well, 40 bytes reduction per input is excessive too :) But 30 bytes reduction will do fine. On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner < sergio.d.ler...@gmail.com> wrote: > Some responses.. > >> >> The proposal adds another gratuitous limit to the system: A maximum >> transaction

Re: [bitcoin-dev] A Segwit2x BIP

Some responses.. > > The proposal adds another gratuitous limit to the system: A maximum > transaction size where none existed before, yet this limit is almost > certainly too small to prevent actual DOS attacks while it is also > technically larger than any transaction that can be included today

Re: [bitcoin-dev] A Segwit2x BIP

ors to try and > gain more support (not limited to, but including approaching company > investors to twist arms and veiled threats of blacklisting companies from > further funding/collaboration). > > I think the best you can hope for this hard fork proposal is for it to be &g

[bitcoin-dev] A Segwit2x BIP

Hello, Here is a BIP that matches the reference code that the Segwit2x group has built and published a week ago. This BIP and code satisfies the requests of a large part of the Bitcoin community for a moderate increase in the Bitcoin non-witness block space coupled with the activation of Segwit.

Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

Currently the only implementation that fulfills the requirements of the NYA agreement is the segwit2x/btc1 implementation, which is being finalized this week. Segwit2mb does not fulfill the NYA agreement. I'm asking now the segwit2x development team when a BIP will be ready so that Core has the

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

I'm a bit late to this party. I just want to add that there exists an hybrid model where both a federation and the miners provide acknowledges (sometimes known as "votes" in drivechain terms and "multi-signatures" in a federation) of the sidechain state. My Drivechain proposal (Feb 2016) was

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

I don't see LukeJr 2MB limit to be compatible with the NY agreement. For the rest, seems fine for me. On Fri, Jun 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > The above decision may quickly become very controversial. I don't think

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

I'm not advocating. I'm mediating. This is out of On Wed, May 10, 2017 at 1:39 PM, Matt Corallo wrote: > I highly disagree about the "not shit" part. You're advocating for > throwing away one of the key features of Segwit, something that is very > important for

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It has always been good enough. And at the beginning it was quite simple. Simple enough it allowed gradual improvements that anyone with some technical background could understand. Now we need a full website to explain an

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

I agree with you Matt. I'm artificially limiting myself to changing the parameters of Segwit as it is.. This is motivated by the idea that a consensual HF in the current state would have greater chance of acceptance if it changes the minimum number of lines of code. On Tue, May 9, 2017 at 5:13

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7. Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4) n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000 Then n=4,000,000 / 5.7 = 701K Average block size = 701K*(1+1.7)=1.8 Mbytes Maximum block size = 4 MBytes Segwit with 50% discount + 2MB

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

> > > > You suggested "If the maximum block weight is set to 2.7M, each byte of > non-witness block costs 1.7", but these numbers dont work out - setting > the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft > fork), not 2.7MB. Yes. In a soft-fork is true. I was thinking about

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

November, then for the next Segwit attempt I would choose a more conservative 50% discount. On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2...@xbt.hk> wrote: > > > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote:

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

es a guideline on how much capacity is gained > through a particular discount. With the data you show, it would imply that > those blocks, with SegWit used where possible, would result in blocks of > ~1.8MB. > > > > On Mon, May 8, 2017 at 5:42 PM, Sergio Dem

[bitcoin-dev] Some real-world results about the current Segwit Discount

I have processed 1000 blocks starting from Block #461653. I computed several metrics, including the supposed size of witness data and non-witness data (onchain), assuming all P2SH inputs/outputs are converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH. This takes into account

Re: [bitcoin-dev] Full node "tip" function

this soon. On Mon, May 8, 2017 at 6:44 PM, Natanael <natanae...@gmail.com> wrote: > > Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org>: > > I'll soon present a solution to encourage full nodes to

Re: [bitcoin-dev] Full node "tip" function

A full node provides several services to the network: 1•Broadcasts blocks (public service) 2•Broadcasts transactions (public/private service) 3•Increases privacy by hiding other node’s IPs 4•Increases network security by protecting it from global DoS. 5•Provides information filtering services to

[bitcoin-dev] BIP Proposal: Inhibiting a covert optimization on the Bitcoin POW function

BIP: TBD Layer: Consensus Title: Inhibiting a covert optimization on the Bitcoin POW function Author: Sergio Demian Lerner Status: Draft Type: Standards Track Created: 2016-04-07 License: PD ==Abstract== This proposal inhibits the covert use of a

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

s, the limits of miner "voting" and the quorums we can expect. Regards, Sergio. > > On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists. > linuxfoundation.org> wrote: > >> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoi

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

, 2017 at 11:40 AM, Btc Drak <btcd...@gmail.com> wrote: > On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> The hard-fork is conditional to 95% of the hashing power has approved the >> segwit

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

o the > > value it is securing, betting the security of Bitcoin on its price > > rising exponentially to match decreasing subsidy does not strike me as a > > particularly inspiring tradeoff. > > > > There aren't many great technical solutions to some of these

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

m for > testing and implementation. > > On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <lf-li...@mattcorallo.com> >> wrote: >&g

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

but RSK value proposition is "supporting the advance of Bitcoin, the cryptocurrecy with highest network effect". You understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to be the cryptocurrencies with higher volume/market cap/network effect. Therefore all RSK people t

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Praxelogy_guy, Yes I understand that segwit2mb represents a "potential" 4Mb block size increase. But Segwit does not immediately lead to 2 Mb blocks, but can only achieve close to a 2Mb increase if all Bitcoin wallets switch to segwit, which will take a couple of years. Therefore I don't expect

[bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hi everyone, Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to untangle the current conflict between different political positions regarding segwit activation vs. an increase of the on-chain blockchain space through a standard block size increase. It is not a new

Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain

On Mon, Feb 13, 2017 at 8:58 AM, John Hardy wrote: > Hi Sergio, > > > Thanks for your response, interesting work, very excited for RSK. > > > I like the ephemeral payload, I suppose that aspect of my proposal could > be described as ephemeral blockspace. > > > I'm curious

Re: [bitcoin-dev] Proof of Nodework (PoNW) - a method to trustlessly reward nodes for storing and verifying the blockchain

Hi John, RSK platform (a Bitcoin sidechain) is already prepared to do something similar to this, although very efficiently. We set apart 1% of the block reward to automatically reward full nodes. We have two systems being evaluated: the first is based on PoUBS (Proof of Unique Blockchain

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via >> bitcoin- >> dev wrote: >> > Without a detailed analysis, unlimited block size seems a risky change >> to >&

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via > bitcoin- > dev wrote: > > Without a detailed analysis, unlimited block size seems a risky

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

Hi Peter, How would a person or exchange decide to accept a payment in BU if it does not know the gate policy of 51% of the miners? Suppose that the exchange receives B1,S2,S3,S4 (a big block at height 1, and 3 small blocks at height 2, 3 and 4), and an alternate chain A1,A2,A3 (three small

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

uent miners. A honest pre-fork miner would never include a redeemScript that that verifies an OP_COUNT_ACKS, since that transaction would never be received by the p2p protocol (it could if the miner accepts non-standard txs by a different channnel). But I must check this in the BIP source code if OP_COUNT

Re: [bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users

Oh God... here we go again.. > > Again, lets remember that you personally proposed a BIP[1] that had the > effect > of aiding your ASICBOOST patent[2] without disclosing that fact in your > BIP nor > your pull-req[3]. > > This is false. The first sentence of the BIP states: "There are incentives

[bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users

I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current users may be confident they are protected but in fact they are not, as the future generations of users can be attacked, making Bitcoin technology fully proprietary and less valuable. If you read the DPL v1.1 you will see that

[bitcoin-dev] The use OP_COUNT_ACKS for paying for a common good for miners

One side benefit of OP_COUNT_ACKS is that it enables a completely different use case: It allow users to pay for any service miners can provide as group for the common good (e.g. fee payment smoothing over many blocks). For instance, users could pay miners to jointly buy better Internet service to

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > But I would argue that in this scenario, the only way it >> would become invalid is the equivalent of a double-spend... and therefore >> it >> may be acceptable in relation to this

Re: [bitcoin-dev] About ASICBoost

It's good you bring that point, and it's very interesting to analyze what happened then. We shared our findings with some core developers much earlier than the BIP proposal. Wether they kept it secret or they shared it with some ASIC manufacturers is something I don't know. I even mentioned my

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL endorse DPL or will make the required actions to make sure the things developed by RSK remain free and open. This was not a priority until now, but coding was. For me, coding always is the priority. I will discuss

[bitcoin-dev] About ASICBoost

Please Peter Todd explain here all what you want to say about a patent of a hardware design for an ASIC. Remember that ASICBoost is not the only patent out there, there are at least three similar patents, filed by major Bitcoin ASIC manufacturers in three different countries, on similar

Re: [bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

believe it. Let's open another thread elsewhere to discuss hardware and software patents, and that particular one, if you wish, this is NOT the place. On Sun, Oct 2, 2016 at 1:17 PM, Peter Todd <p...@petertodd.org> wrote: > On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian L

[bitcoin-dev] Drivechain proposal using OP_COUNT_ACKS

Since ScalingBitcoin is close, I think this is a good moment to publish our proposal on drivechains. This BIP proposed the drivechain we'd like to use in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented in Bitcoin. Until that happens, we're using a federated approach. I'm

Re: [bitcoin-dev] Attack by modifying non-segwit transactions after segwit is accepted ?

Because there was a discussion on reddit about this topic, I want to clarify that Johnson Lau explained how a check in the code prevents this attack. So there is no real attack. Also note that the subject of this thread has a question mark, which means that I'm asking the community for

[bitcoin-dev] Attack by modifying non-segwit transactions after segwit is accepted ?

In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH") it was briefly discussed what happens if someone modifies segwit data during transmission. I think the discussion should continue. What worries me is what happens with non-segwit transactions after segwit is

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

On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > I think that we're not attacking the real source of the problem: t

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

I think that we're not attacking the real source of the problem: that the witness data size is not signed. It may be the case that a new source of malleability is detected in witness programs later, or related to new opcodes we'll soft-fork in the future. The problem is real, as some systems

Re: [bitcoin-dev] BIP: OP_PRANDOM

Missing link to paper: https://arxiv.org/abs/1605.04559 Another relevant paper: On Bitcoin as a public randomness source Joseph Bonneau, Jeremy Clark, and Steven Goldfeder https://eprint.iacr.org/2015/1015.pdf On Tue, May 24, 2016 at 11:30 AM, Sergio Demian Lerner < sergio.d.ler...@gmail.com>

Re: [bitcoin-dev] Making AsicBoost irrelevant

Jorge Timón said.. > What do you mean by "embrace" in the context of a patented optimization that one miner can prevent the rest from using? Everyone seems to assume that one ASIC manufacturer will get the advantage of AsicBoost while others won't. If a patent license is non-exclusive, then all

Re: [bitcoin-dev] Making AsicBoost irrelevant

On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner < sergio.d.ler...@gmail.com> wrote: > > > You can find it here: > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/ > > Basically, the idea is to put in the first 64 bytes a 4 byte hash of the > second 64-byte

Re: [bitcoin-dev] Making AsicBoost irrelevant

Your idea of moving the Merkle root to the second chunk does not work. The AsicBoost can change the version bits and it does not need to find a collision. (However *Spondoolies patent *only mentions Merkle collisions:

Re: [bitcoin-dev] p2p authentication and encryption BIPs

It seems that every message must be signed (the protocols lacks MACs). This can be very resource consuming in terms of CPU and bandwidth since most p2p messages are small. On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wednesday 23 Mar

Re: [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment

Congratulations! It a property of the SKCP system that the person who performed the trusted setup cannot extract any information from a proof? In other words, is it proven hard to obtain information from a proof by the buyer? On Fri, Feb 26, 2016 at 6:42 PM, Gregory Maxwell via bitcoin-dev <

[bitcoin-dev] This thread is not about the soft/hard fork technical debate

Some of the people on this mailing list are blindly discussing the technicalities of a soft/hard fork without realizing that is not Mike's main intention. At least I perceive (and maybe others too) something else is happening. Let me try to clarify: the discussion has nothing to do with technical

Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin

Guys, I strongly think the original prabhat e-mail is a parody. And I find very funny that important people have responded. But maybe I'm wrong! *:)* El jue., 27 ago. 2015 a las 11:04, Chris Pacia via bitcoin-dev ( bitcoin-dev@lists.linuxfoundation.org) escribió: On 08/27/2015 09:39 AM,

Re: [bitcoin-dev] A solution to increase the incentive of running a node

Hector, I can only say 2 things in the brief time I have now: 1. There is a solution that I proposed for proving you own a copy of the block-chain. It's using aymmetric-time functions: https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/ 2. I'm finishing a paper on a

[bitcoin-dev] How DECOR++ can eradicate selfish mining incentive by design

In these shocking forking times, nothing more relaxing that to immerse yourself in a pure technical reading about cryptocurrency design, letting aside Bitcoin politics for a moment. This message is about cryptocurrencies design in general, so you're free to skip my message if you think it will

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

On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille pieter.wui...@gmail.com wrote: 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

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

a single thing to change to Bitcoin, I would lower the payment time, even within the minute scale. Sergio On Fri, Aug 7, 2015 at 7:46 PM, Natanael natanae...@gmail.com wrote: Den 7 aug 2015 23:37 skrev Sergio Demian Lerner via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org: Mark

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

, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: What would you do? a. Double the block size 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

Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation

Is there any up to date documentation about TheBlueMatt relay network including what kind of block compression it is currently doing? (apart from the source code) Regards, Sergio. On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On