Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Gavin Andresen via bitcoin-dev]

On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón  wrote:

> This is basically what I meant by
>
> struct hashRootStruct
> {
> uint256 hashMerkleRoot;
> uint256 hashWitnessesRoot;
> uint256 hashextendedHeader;
> }
>
> but my design doesn't calculate other_root as it appears in your tree (is
> not necessary).
>
> It is necessary to maintain compatibility with SPV nodes/wallets.

Any code that just checks merkle paths up into the block header would have
to change if the structure of the merkle tree changed to be three-headed at
the top.

If it remains a binary tree, then it doesn't need to change at all-- the
code that produces the merkle paths will just send a path that is one step
deeper.

Plus, it's just weird to have a merkle tree that isn't a binary tree.

-- 
--
Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Jorge Timón via bitcoin-dev]

On Dec 9, 2015 5:40 PM, "Gavin Andresen"  wrote:
>
> On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> I think it would be logical to do as part of a hardfork that moved
>> commitments generally; e.g. a better position for merged mining (such
>> a hardfork was suggested in 2010 as something that could be done if
>> merged mining was used), room for commitments to additional block
>> back-references for compact SPV proofs, and/or UTXO set commitments.
>> Part of the reason to not do it now is that the requirements for the
>> other things that would be there are not yet well defined. For these
>> other applications, the additional overhead is actually fairly
>> meaningful; unlike the fraud proofs.
>
>
> So just design ahead for those future uses. Make the merkle tree:
>
>
>  root_in_block_header
>  /  \
>   tx_data_root  other_root
>/   \
> segwitness_root reserved_for_future_use_root

This is basically what I meant by

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}

but my design doesn't calculate other_root as it appears in your tree (is
not necessary).

Since stop requiring bip34 (height in coinbase) is also a hardfork (and a
trivial one) I suggested to move it at the same time. But thinking more
about it, since BIP34 also elegantly solves BIP30, I would keep the height
in the coinbase (even if we move it to the extented header tree as well for
convenience).
That should be able to include future consensus-enforced commitments (extra
back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus
data (merged mining data, miner-published data).
Greg Maxwell suggested to move those later and I answered fair enough. But
thinking more about it, if the extra commitments field is extensible, we
don't need to move anything now, and therefore we don't need for those
designs (extra back-refs for compact proofs, txo/utxo commitments, etc) to
be ready to deploy a hardfork segregated witness: you just need to make
sure that your format is extensible via softfork in the future.

I'm therefore back to the "let's better deploy segregated witness as a
hardfork" position.
The change required to the softfork segregated witnesses implementation
would be relatively small.

Another option would be to deploy both parts (sw and the movement from the
coinbase to the extra header) at the same time but with different
activation conditions, for example:

- For sw: deploy as soon as possible with bip9.
- For the hardfork codebase to extra header movement: 1 year grace + bip9
for later miner upgrade confirmation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

[Luke Durback via bitcoin-dev]

>If it's voting for something consensus, you will need something special.
If it's not consensus (ie external) thw voting doesn't have to hit the
chain at all.

I had in mind voting for something that can't be trusted if done
externally:  Perhaps BIPs for instance.  People would somehow "mark" their
BTC as being "For Proposition X" (as opposed to all other propositions) and
the vote would be canceled as soon as the BTC is spent again.

Unfortunately, I've spent the past 2 days trying to find a design that
would allow this (I don't think my original suggestion made sense in the
context of how transactions work), and I haven't gotten much yet.

>But each scriptSig is only executed once with its corresponding
scriptPubKey. Are you proposing we change that?

Sorry, I didn't understand Bitcoin's transaction model well enough when I
first made the proposal.  If Turing Pseudo-Completeness is possible with
Bitcoin, then I understand now that it could not require you to execute a
script more than once.  My current thought is that recursion can be
accomplished via checking if the next output's scriptPubKey is identical in
every way to the current scriptPubKey.  Unfortunately, a lot more is needed
than just recursion in order to do on-chain BTC voting the way I have in
mind.  I'll keep working on this.

On Fri, Dec 11, 2015 at 10:36 AM, Jorge Timón  wrote:

>
> On Dec 10, 2015 7:36 AM, "Luke Durback"  wrote:
> >
> > Tomorrow, I'll work on writing a way to do voting on proposals with BTC
> used as voting shares (This will be difficult as I do not know FORTH).
> That seems like a fairly simple, useful example that will require loops and
> reused functions.  I'll add a fee that goes to the creator.
>
> If it's voting for something consensus, you will need something special.
> If it's not consensus (ie external) thw voting doesn't have to hit the
> chain at all.
> I don't see how "loops and reused functions" are needed in the scripting
> language for this use case, but I'm probably missing some details. Please,
> the more concrete you make your example, the easiest it will be for me to
> understand.
>
> > IMO, if you write a complicated system of scripts that's used
> frequently, it makes sense to charge a fee for its usage.
>
> But each scriptSig is only executed once with its corresponding
> scriptPubKey. Are you proposing we change that?
>
> >  A decentralized exchange between colored coins, for instance might take
> a small fee on each trade.
>
> I've been researching the topic of decentralized exchange from before the
> term "colored coins" was first used (now there's multiple designs and
> implementations); contributed to and reviewed many designs: none of them
> (colored coins or not) required turing completeness.
> I'm sorry, but what you are saying here is too vague for me to concretely
> be able to refute the low level "needs" you claim your use cases to have.
>
> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > This, combined with the ability to make new transactions arbitrarily
> would allow a function to pay its creator.
> >
> > I don't understand what you mean by "a function" in this context, I
> assume you mean a scriptSig, but then "paying its creator" doesn't make
> much sense to me .
> >
> > Could you provide some high level examples of the use cases you would
> like to support with this?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jannes Faber via bitcoin-dev]

Segregated IBLT

I was just wondering if it would make sense when we have SW to also make
Segregated IBLT? Segregating transactions from signatures and then tune the
parameters such that transactions have a slightly higher guarantee and save
a bit of space on the signatures side.

IBLT should of course, most of the time, convey all transactions _and_ all
signatures. However, in suboptimal situations, at least the receiving miner
will be more likely to have all the transactions, just possibly not all the
signatures.

Assuming the miner was already planning on SPV mining anyway, at least now
she knows which transactions to remove from her mempool, taking away an
excuse to mine an empty block. And she can still verify most of the
signatures too (whatever % could be recovered from the IBLT).

I guess this does not improve the worst adversarial case for IBLT block
propagation, but it should improve the effectiveness in cases where the
"normal" IBLT would fail to deliver all transactions. Transactions without
signatures is better than no transactions at all, for a miner that's eager
to start on the next block, right? In "optimal" cases it would reduce the
size of the IBLT.

Sorry if this was already suggested.


--
Jannes

On 10 December 2015 at 13:54, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Note that the unused space in coin base input script allows us to
> soft-fork an additional SW Merkle tree root into the design,
> therefore please make sure the new SW data structure also has a new slot
> for future extension.
>
> Tamas Blummer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev