Re: [bitcoin-dev] Rolling UTXO set hashes

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 costs and no normative >> datastructures at all. > > The serialization of the txout

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

Good morning, >What you read is only an introduction of BMM. You may also consult the notes >(at the bottom of the BMM post) or the code, although this is time consuming >of course. Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked in, or hardforked? From my

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

Given the overwhelming support for SegWit across the ecosystem of businesses and users, this seems reasonable to me. On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev wrote: >I would like to propose an implementation that accomplishes the

[bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

I would like to propose an implementation that accomplishes the first part of the Barry Silbert proposal independently from the second: "Activate Segregated Witness at an 80% threshold, signaling at bit 4" in a way that The goal here is to minimize chain split risk and network disruption while

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

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)) > sha256Compress : Word256 × Word512 -> Word256 To be clear, what math operations do you

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

On May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev" wrote: On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that

Re: [bitcoin-dev] I do not support the BIP 148 UASF

I also do not support the BIP 148 UASF, and I'd like to add to the points that Greg has already raised in this thread. BIP 148 would introduce a new consensus rule that softforks out non-segwit signalling blocks in some time period. I reject this consensus rule as both arbitrary and needlessly

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

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain Bitcoin. > I don't think they are the same. With Bitcoin, you only get to reverse

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

My OP_CAT usecase only needs to glue together hash outputs, so two 32 Bytes inputs generating a 64 Byte output. However increasing this would enable additional space savings. I would push for an OP_CAT which can generate an output of no greater than 512 Bytes. Is there are maximum byte vectors

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

On May 22, 2017 10:39 AM, "ZmnSCPxj" wrote: Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ >From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a

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] Drivechain -- Request for Discussion

Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transaction. Do you have a better explanation?

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

Charlie, I'll be mostly in the tech track, of course. And I've already planned to meet RSK guys after their event tomorrow. Ryan, the more review the better. We aren't in any direct rush, other than the natural desire to have cool things as early as possible. Peter, responses below: On May 22,

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

>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 significantly. For instance if I want a transaction TxA which checks that a

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

I couldn't agree more. It would require however for the Devs to throw their weight behind this with a lot of momentum. Spoonnet has been under development for quite some time now. Counter offering SegWit plus Spoonnet 12-24 months later would be a very progressive stance that I think would catch

[bitcoin-dev] BIP135 implementation on Bitcoin Core available for review

I'm pleased to announce the completion of a Bitcoin Core implementation of BIP135: https://github.com/bitcoin/bitcoin/pull/10437 Review comments appreciated, and happy to discuss / answer questions about the implementation in this thread or on Github. Sancho BIP135:

[bitcoin-dev] Drivechain -- Request for Discussion

Dear list, I've been working on "drivechain", a sidechain enabling technology, for some time. * The technical info site is here: www.drivechain.info * The changes to Bitcoin are here: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM * A Blank sidechain template is here:

Re: [bitcoin-dev] Barry Silbert segwit agreement

I'm really happy to see people trying to cooperate to get SegWit activated. But I'm really unsure about the technicalities about Silbert's proposal. If we're going to do a hardfork, it makes most sense to assist Johnson in his spoonnet/forcenet proposals. Just doing a simple 2MB without fixing

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

## Introduction This document aims to specify and justify a method for computing Merkle roots for tree structures whose nodes are annotated with other data. While this proposal could be used to replace Bitcoin's Merkle root calculation, it is primarily aimed at new applications such as MAST,

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

[bitcoin-dev] Barry Silbert segwit agreement

Someone sent me a copy of the Barry Silbert agreement, an agreement forged between a select number of participants https://pastebin.com/VuCYteJh Participants agree to immediately activate Segwit, however, under a different activation proposal. Since I have spent the last few months researching