## 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, (U)TX
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 any
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:
https://git
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: https://github.com/bitcoin
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 th
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
> sid
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 'peter'[:-1]@pete
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") op
>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 tra
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, 2
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?
OP_is_
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
> signi
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 side->main
unlocking transacti
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 size
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 recent
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 di
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 in mainchain Bitcoin.
>
I don't think t
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 mean by "⋅" and "×"?
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 ma
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 first
>part of the Barry Silbert proposal i
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 under
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 itself is normative, but very minimal.
I do prefer the (2) approach
On Mon, May 22, 2017 at 12:05 AM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The SHA256 compression function takes two inputs:
>
> 1. A 256-bit value for the previous chunk in a chain, or an initial vector
> in the case of the first chunk.
> 2. A 512-bit chu
I'm glad some discussion has been moved back here.
Correct me if I am wrong, but currently core developers are arguing over
whether or not to allow an optional configuration switch which defaults off
but signals and enforces BIP148 when used. Who are we protecting users
from, themselves? Are you p
Seems like it would work fine. But why would we expect 80pct to signal for
the exact same implementation - when we can't get 40pct.
It will be contingent on some HF code that allows him to continue using
asicboost, or is too aggressive, or some other unreasonable request.
On May 22, 2017 6:4
25 matches
Mail list logo
