Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Tier Nolan]

On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón  wrote:

> You mean the timewarp fix can be coded as a softfork instead of a
> hardfork? How so?
>

The easiest would be a rule requiring that all blocks are within 1 day of
the median of the previous 11 blocks.  At the moment, you need to be
greater than that value.  This would add a condition at the other end.

It wouldn't be a total fix, but it would protect against the exploit.

A stricter soft fork would be that the two blocks in question have to have
the same timestamp.  This would force the off by 1 and the correct value to
give the same result.

If that's the case, do you have a better candidate?
>

I think it is fine, since fixing it "right" does require a hard fork,
especially if it is only to show a non controversial hard fork.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Tier Nolan]

The off by 1 bug could be fixed by a soft fork.  Since the point is to show
how a non-controversial hard fork works, it doesn't matter much.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Hard fork via miner vote

[Tier Nolan]

I agree giving notice that the change is going to happen is critical for a
hard fork.  If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).

The BIP 100 proposal is that no change will happen until a timestamp is
reached.  It isn't clear exactly how it would work.

Testnet: Sep 1st 2015
Mainnet: Jan 11th 2016

It suggests 90% of 12000 blocks (~83 days).

This means that if 10800 of the last 12000 blocks are the updated version,
then the change is considered locked in.

I think having an earlier "fail" threshold would be a good idea too.  This
guarantees notice.

Assuming 3 is  and 4 is 

If the median of 11 timestamp is after 1st Sep 2015 and less than 10800 of
the last 12000 blocks are version 4+, then reject version 4 blocks
If the median of 11 timestamp is after 1st Nov 2015 and at least 10800 of
the last 12000 blocks are version 4+, then reject version 3 blocks
(lock-in)
If the median of 11 timestamp is after 1st Jan 2016 and at least 10800 of
the last 12000 blocks are version 4+, the allow 

This means that if the 90% threshold is lost at any time between 1st Sep
and 1st Nov, then the fork is rejected.  Otherwise, after the 1st Nov, it
is locked in, but the new rules don't activate until 1st Jan.

For block size, miners could still soft fork back to 1MB after 1st Nov, it
there is a user/merchant revolt (maybe that would be version 5 blocks).


On Sat, Jun 20, 2015 at 6:13 PM, Pieter Wuille 
wrote:

> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Tier Nolan]

On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo  wrote:

> If we want a non-repudiation mechanism in the protocol, we should
> explicitly define one rather than relying on “prima facie” assumptions.
> Otherwise, I would recommend not relying on the existence of a signed
> transaction as proof of intent to pay…
>

Outputs could be marked as "locked".  If you are performing a zero
confirmation spend, then the recipient could insist that you flag the
output for them as non-reducible.

This reduces privacy since it would be obvious which output was change.  If
both are locked, then the fee can't be increased.

This would be information that miners could ignore though.

Creating the right incentives is hard though.  Blocks could be
"discouraged" if they have a double spend that is known about for a while
which reduces payment for a locked output.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Tier Nolan]

On Tue, Jun 16, 2015 at 6:18 AM, Venzen  wrote:

> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.


The main principle of open source software is that anyone can fork the code
if they wish.  They don't do it very often, but they can.

This means that if a project dies, someone can take it over.  If some of
the devs want to take things in a different direction, they can.  Users can
decide which version they prefer.

The software itself is what is valuable.

In the case of bitcoin, the blockchain is also (very) valuable.  Simply
splitting into two projects is not possible for bitcoin.

Otherwise, the discussion would have ended already, those who want a larger
block would simply create a fork of the software and create an alt chain.

The fundamental problem is that there is no clear way to make this decision
once and for all.

An agreed set of rules for a hard fork would be a nice thing to have, but
it is hard to have rules about how to change fundamental rules.

I think using the soft fork rules (maybe with a higher threshold than 95%)
plus a delay is a reasonable compromise on hard fork rules.

Even then, it would be nice to include users of the software too.  Peter
Todd's suggestion of encoding a vote in transactions is a step in that
direction (YES transactions in YES blocks and NO transactions in NO blocks).


> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.


Nobody owns it, so there is no court of final appeal.

If miners vote >95% for the fork, users could still refuse to accept the
change.

Maybe the sequence could be

version 3 blocks means no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
version 6 blocks means YES to fork & NO transactions

Transaction matching rule:

version 1, 2, 3 transactions means no opinion (can be in any block)
version 4 transactions means YES to fork (cannot be in version 6 blocks)
version 5 transactions means NO to fork (cannot be in version 5 blocks)

Rules
0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching
rule activates for version 5 & 6 blocks
1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4
blocks are rejected
2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6
blocks are rejected
3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the
last 1000 are version 5 or 6, then the fork is accepted
4) 25,000 blocks after 3 is accepted, hard fork actually takes effect

Once miner acceptance is achieved, then only version 5 and 6 blocks are
allowed.  The split between version 5 and 6 blocks should be roughly in
proportion to the number of transactions of each kind produced.

75% of miners can kill the fork by producing version 4 blocks, but 95% is
needed for acceptance.  Even then, transaction volume needs to support the
fork.  I think 75% is reasonable here.  (95% of miners and 75% of
merchants/users is a pretty strong majority).


> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>

They are still suggesting some kind of fork threshold process (or at least
that is what is being suggested)

If their system requires 95% miner approval, they aren't taking unilateral
action.  Miners are though if they vote in favour.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66

[Tier Nolan]

Once the 75% threshold is reached, miners who haven't updated are at risk
of mining on invalid blocks.

If someone produces a version 3 block that violates the new rules, then
miners who haven't upgraded will end up wasting mining power building on
that block.

This could be used as an expensive way to attack miners who haven't
upgraded.  It is low risk of happening, since creating an invalid version 3
block costs 25BTC in hashing power and the miner who does it ends up
creating an invalid block.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

[Tier Nolan]

On Tue, Jun 9, 2015 at 2:36 PM, Gavin Andresen 
wrote:

> How about this for mitigating this potential attack:
>
> 1. Limit the memory pool to some reasonable number of blocks-worth of
> transactions (e.g. 11)
> 2. If evicting transactions from the memory pool, prefer to evict
> transactions that are part of long chains of unconfirmed transactions.
> 3. Allow blocks to grow in size in times of high transaction demand.
>
>
I think 2 should just be fee per kB.  If the pool is full and a transaction
arrives, it has to have a fee per kB that is higher than the lowest
transaction in the pool.

The effect is that the fee per kB threshold for getting a transaction into
the memory pool increases as the attack proceeds.  This means that the cost
to maintain the attack increases.

With replace by fee, the new transaction would have to have a fee that is
more than a fixed amount more than the lowest already in the pool.  I think
the replace by fee code already does this.  This prevents transactions with
fees that increase by 1 Satoshi at a time being relayed.

For allowing large blocks when block space is in high demand, you could
limit the average block size.

If the average was set to 1MB, the rule could be that blocks must be 2MB or
lower and the total size of the a block and the previous 99 must be 100MB
or lower.  This gives an average of 1MB per block, but allows bursts.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Tier Nolan]

I am glad to see the transaction version number increase.  The commit
doesn't update the default transaction version though.  The node would
still produce version 1 transactions.

Does the reference client already produce transactions with final sequence
numbers?  If so, then they will be valid version 2 transactions.  If it
sets the sequence to all zeros, then it won't trigger the new code either.
I think simply bumping the default version number to 2 would be safe.

For the timestamp locktime, median block time would be better than raw
block time.  Median time is the median timestamp of the previous 11
blocks.  This reduces the incentive to mess with the timestamp.  Median
time is earlier than block time, but since things are relative, it should
balance out.

Miners have around 2 hours worth of flexibility when setting the
timestamps, so it may not be that big a deal.



On Tue, Jun 2, 2015 at 5:34 AM, Stephen Morse 
wrote:

> I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right
> before, and then check that the input spending the prevout has nSequence
> corresponds to at least the sequence specified by the stack value. Good
> idea! Keeps the script code from depending on external chain specific data,
> which is nice.
>
> Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
> one for OP_CHECKSEQUENCEVERIFY. Very complementary.
>
> Best,
> Stephen
>
>
> On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach 
> wrote:
>
>> You are correct! I am maintaining a 'checksequenceverify' branch in my
>> git repository as well, an OP_RCLTV using sequence numbers:
>>
>> https://github.com/maaku/bitcoin/tree/checksequenceverify
>>
>> Most of the interesting use cases for relative lock-time require an RCLTV
>> opcode. What is interesting about this architecture is that it possible to
>> cleanly separate the relative lock-time (sequence numbers) from the RCLTV
>> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
>> CLTV, the CSV opcode only checks transaction data and requires no
>> contextual knowledge about block headers, a weakness of the other RCLTV
>> proposals that violate the clean separation between libscript and
>> libconsensus. In a similar way, this BIP proposal only touches the
>> transaction validation logic without any impact to script.
>>
>> I would like to propose an additional BIP covering the
>> CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one
>> thing at a time.
>>
>> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <
>> stephencalebmo...@gmail.com> wrote:
>>
>>> Hi Mark,
>>>
>>> Overall, I like this idea in every way except for one: unless I am
>>> missing something, we may still need an OP_RCLTV even with this being
>>> implemented.
>>>
>>> In use cases such as micropayment channels where the funds are locked up
>>> by multiple parties, the enforcement of the relative locktime can be done
>>> by the first-signing party. So, while your solution would probably work in
>>> cases like this, where multiple signing parties are involved, there may be
>>> other, seen or unforeseen, use cases that require putting the relative
>>> locktime right into the spending contract (the scriptPubKey itself).
>>> When there is only one signer, there's nothing that enforces using an
>>> nSequence and nVersion=2 that would prevent spending the output until a
>>> certain time.
>>>
>>> I hope this is received as constructive criticism, I do think this is an
>>> innovative idea. In my view, though, it seems to be less fully-featured
>>> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
>>> obviously that it saves transaction space by repurposing unused space, and
>>> would likely work for most cases where an OP_RCLTV would be needed.
>>>
>>> Best,
>>> Stephen
>>>
>>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach 
>>> wrote:
>>>
 I have written a reference implementation and BIP draft for a soft-fork
 change to the consensus-enforced behaviour of sequence numbers for the
 purpose of supporting transaction replacement via per-input relative
 lock-times. This proposal was previously discussed on the mailing list in
 the following thread:

 http://sourceforge.net/p/bitcoin/mailman/message/34146752/

 In short summary, this proposal seeks to enable safe transaction
 replacement by re-purposing the nSequence field of a transaction input to
 be a consensus-enforced relative lock-time.

 The advantages of this approach is that it makes use of the full range
 of the 32-bit sequence number which until now has rarely been used for
 anything other than a boolean control over absolute nLockTime, and it does
 so in a way that is semantically compatible with the originally envisioned
 use of sequence numbers for fast mempool transaction replacement.

 The disadvantages are that external constraints often prevent the full
 range of sequence numbers from being

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

[Tier Nolan]

On Fri, May 29, 2015 at 5:39 PM, Raystonn .  wrote:

>   Regarding Tier’s proposal: The lower security you mention for extended
> blocks would delay, possibly forever, the larger blocks maximum block size
> that we want for the entire network.  That doesn’t sound like an optimal
> solution.
>

I don't think so.  The lower security is the potential centralisation
risk.  If you have your money in the "root" chain, then you can watch it.
You can probably also watch it in a 20MB chain.

Full nodes would still verify the entire block (root + extended).  It is a
"nuclear option", since you can make any changes you want to the rules for
the extended chain.  The only safe guard is that people have to voluntarly
transfer coins to the extended block.

The extended block might have 10-15% of the total bitcoins, but still be
useful, since they would be the ones that move the most.  If you want to
store your coins long term, you move them back to the root block where you
can watch them more closely.

It does make things more complex though.  Wallets would have to list 2
balances.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Fri, May 29, 2015 at 3:09 PM, Tier Nolan  wrote:

>
>
> On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen 
> wrote:
>
>> But if there is still no consensus among developers but the "bigger
>> blocks now" movement is successful, I'll ask for help getting big miners to
>> do the same, and use the soft-fork block version voting mechanism to
>> (hopefully) get a majority and then a super-majority willing to produce
>> bigger blocks. The purpose of that process is to prove to any doubters that
>> they'd better start supporting bigger blocks or they'll be left behind, and
>> to give them a chance to upgrade before that happens.
>>
>
> How do you define that the movement is successful?
>

Sorry again, I keep auto-sending from gmail when trying to delete.

In theory, using the "nuclear option", the block size can be increased via
soft fork.

Version 4 blocks would contain the hash of the a valid extended block in
the coinbase.

 <32 byte extended hash>

To send coins to the auxiliary block, you send them to some template.

OP_P2SH_EXTENDED  OP_TRUE

This transaction can be spent by anyone (under the current rules).  The
soft fork would lock the transaction output unless it transferred money
from the extended block.

To unlock the transaction output, you need to include the txid of
transaction(s) in the extended block and signature(s) in the scriptSig.

The transaction output can be spent in the extended block using P2SH
against the scriptPubKey hash.

This means that people can choose to move their money to the extended
block.  It might have lower security than leaving it in the root chain.

The extended chain could use the updated script language too.

This is obviously more complex than just increasing the size though, but it
could be a fallback option if no consensus is reached.  It has the
advantage of giving people a choice.  They can move their money to the
extended chain or not, as they wish.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen 
wrote:

> But if there is still no consensus among developers but the "bigger blocks
> now" movement is successful, I'll ask for help getting big miners to do the
> same, and use the soft-fork block version voting mechanism to (hopefully)
> get a majority and then a super-majority willing to produce bigger blocks.
> The purpose of that process is to prove to any doubters that they'd better
> start supporting bigger blocks or they'll be left behind, and to give them
> a chance to upgrade before that happens.
>

How do you define that the movement is successful?

For


> Because if we can't come to consensus here, the ultimate authority for
> determining consensus is what code the majority of merchants and exchanges
> and miners are running.
>

The measure is miner consensus.  How do you intend to measure
exchange/merchant acceptance?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Fri, May 29, 2015 at 12:26 PM, Mike Hearn  wrote:

> IMO it's not even clear there needs to be a size limit at all. Currently
> the 32mb message cap imposes one anyway
>

If the plan is a fix once and for all, then that should be changed too.  It
could be set so that it is at least some multiple of the max block size
allowed.

Alternatively, the merkle block message already incorporates the required
functionality.

Send
- headers message (with 1 header)
- merkleblock messages (max 1MB per message)

The transactions for each merkleblock could be sent directly before each
merkleblock, as is currently the case.

That system can send a block of any size.  It would require a change to the
processing of any merkleblocks received.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Tier Nolan]

On Thu, May 28, 2015 at 5:22 PM, s7r  wrote:

> In this scenario, if channel is closed, Alice is the only one who can
> take the coins back after a relative locktime of 150 blocks. Bob is not
> able to do this.
>

Yes, Alice is assumed to be the one who funded the channel.  It is a single
direction channel (Alice to Bob).


> How is Bob protected in this scenario?


Assuming the deposit is 1 BTC.

When the channel is created, Alice can broadcast the refund transaction
immediately and the get her money back 150 blocks later.

The full scriptPubKey for the refund transaction would be

OP_IF
<150> OP_RELATIVE_CHECKLOCKTIME_VERIFY OP_DROP 
OP_CHECKSIGVERIFY
OP_ELSE
OP_2   OP_2
OP_CHECKMULTISIGVERIFY
OP_ENDIF

This means that Alice can spend the output after 150 blocks but with both
signatures Bob and Alice can spend the output without the delay.

She can send money to Bob by spending the non-locked output of the refund
transaction (0.01BTC for Bob and 0.99BTC for Alice).

Bob has a transaction that pays him 0.01BTC and pays Alice 0.99BTC from the
refund transaction and is signed by Alice, but still requires his
signature.  Only Bob can make the transaction valid.

It can be spent as soon as the refund transaction is broadcast.

He has the refund transaction, so he can start the process whenever he
wishes.

Assume the channel runs for a while, and Alice sends 0.3BTC total.

Bob has a transaction which pays him 0.3BTC and Alice 0.7BTC.  He also has
some that pay him less than 0.3, but there is no point in him using those
ones.

Alice decides she wants to close the channel, so asks bob to sign his final
transaction and broadcast it and the refund transaction.

If Bob refuses to do that, then Alice can just broadcast the refund
transaction.

If Bob still refuses to broadcast his final transaction, then Alice gets
1BTC and he gets nothing, after 150 blocks.

This means he will send his final transaction before the 150 blocks have
passed.  This gets him 0.3 and Alice 0.7.

Bob can close the channel immediately and Alice can force it to be closed
within 150 blocks (~1 day).


> If Alice sings a transaction
> which spends the output of the refund transaction and gives it to Bob,
> Bob can just add its signature and claim his slice of the output,
> without necessarily shipping the goods or delivering the services to Alice.
>

Protection against that type of fraud isn't covered by channels.  They are
just to make sure money is handed over.


>  Can you be more explicit here? It doesn't make sense for me.
>

Does the explanation above help?

With some risks.
>

As long as Bob is online and sees the refund transaction being broadcast by
Alice, then there is no risk to him.

Alice can close the transaction whenever she wants, so there is no holdup
risk for her.


> How do you apply a locktime path to a tx in the current network consensus?
>

I mean with OP_CHECKLOCKTIMEVERIFY.

She could say that TXA pays to her in 6 months.

If TXA ends up mutated after being broadcast, then she would have to wait
the 6 months.  It's better than nothing and maybe Bob would sign the
mutated transaction.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Tier Nolan]

What are the use cases for relative lock time verify?  I have 1 and I think
that is the kind of thing it is useful for.

I think that most cases are just to guarantee that the other party has a
chance to react.  This means that 8191 blocks should be more than enough
(and most would set it lower).

For long term, the absolute version is just as good.  That depends on use
cases.  "You can't take step 4 until 3 months after step 3 has completed"
doesn't seem useful.

On Thu, May 28, 2015 at 4:38 PM, Mark Friedenbach 
wrote:

> Oh ok you mean a semantic difference for the purpose of explaining. It
> doesn't actually change the code.
>
> Regarding saving more bits, there really isn't much room if you consider
> time-based relative locktimes and long-lived channels on the order of a
> year or more.
>
> On Thu, May 28, 2015 at 8:18 AM, Tier Nolan  wrote:
>
>> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach 
>> wrote:
>>
>>> Why 3? Do we have a version 2?
>>>
>> I meant whatever the next version is, so you are right, it's version 2.
>>
>>> As for doing it in serialization, that would alter the txid making it a
>>> hard fork change.
>>>
>> The change is backwards compatible (since there is no restrictions on
>> sequence numbers).   This makes it a soft fork.
>>
>> That doesn't change the fact that you are changing what a field in the
>> transaction represents.
>>
>> You could say that the sequence number is no longer encoded in the
>> serialization, it is assumed to be 0x for all version 2+
>> transactions and the relative locktime is a whole new field that is the
>> same size (and position).
>>
>> I think keeping some of the bytes for other uses is a good idea.  The
>> entire top 2 bytes could be ignored when working out relative locktime
>> verify.  That leaves them fully free to be set to anything.
>>
>> It could be that if the MSB of the bottom 2 bytes is set, then that
>> activates the rule and the top 2 bytes are ignored.
>>
>> Are there any use-cases which need a RLTV of more than 8191 blocks delay
>> (that can't be covered by the absolute version)?
>>
>>
>> --
>>
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Tier Nolan]

On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach 
wrote:

> Why 3? Do we have a version 2?
>
I meant whatever the next version is, so you are right, it's version 2.

> As for doing it in serialization, that would alter the txid making it a
> hard fork change.
>
The change is backwards compatible (since there is no restrictions on
sequence numbers).   This makes it a soft fork.

That doesn't change the fact that you are changing what a field in the
transaction represents.

You could say that the sequence number is no longer encoded in the
serialization, it is assumed to be 0x for all version 2+
transactions and the relative locktime is a whole new field that is the
same size (and position).

I think keeping some of the bytes for other uses is a good idea.  The
entire top 2 bytes could be ignored when working out relative locktime
verify.  That leaves them fully free to be set to anything.

It could be that if the MSB of the bottom 2 bytes is set, then that
activates the rule and the top 2 bytes are ignored.

Are there any use-cases which need a RLTV of more than 8191 blocks delay
(that can't be covered by the absolute version)?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Tier Nolan]

On Thu, May 28, 2015 at 1:04 PM, Peter Todd  wrote:

> For that matter, we probably don't want to treat this as a *version*
> change, but rather a *feature* flag.


I think it is still a version change.  At the moment, the 4 bytes refer to
the sequence number and afterwards they mean something else.

For relative locktime verify, I think most use cases could be block count
based and don't need to be able to count very high.

I think the main benefit is that protocols can have one party trigger a
step while giving the other party guaranteed time to respond.


*Fast Channel Close*

This assumes that malleability is fixed.

Alice creates

TXA:
output (x) to [multisig A1 & B1]

Refund:
input TXA (signed by Alice)
Output [(A2 & relative_check_locktime(150)) OR (multisig A3 &  B2)]

Alice sends Refund to Bob

Bob signs it and sends it back to Alice

Alice verifies the signature, adds her own and sends it to Bob.

She broadcasts TXA (would wait until Bob confirms acceptance).

This means that both Alice and Bob have the refund transaction and can use
it to close the channel (assuming TXA is not mutated).

Alice can send money to Bob by creating a transaction which spends the
output of the refund transaction (splitting the output x-b for Alice and b
for Bob), signing it and sending it to Bob.

Alice can force Bob to close the channel by broadcasting the refund
transaction.  150 blocks later, she gets the channel deposit if he doesn't
act.

If she had sent some money to Bob, he has 150 blocks to sign the
transaction that pays him the most money and broadcast it.  Alice gets the
remainder of the deposit.

Alice cannot broadcast earlier version, since Bob doesn't send her the
signed versions.

This means that the channel doesn't need a defined end date.  Either party
can close the channel whenever they want.

TXA could be protected against malleability by adding a locktime path.
This would only be for use if the transaction is mutated.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Tier Nolan]

Can you update it so that it only applies to transactions with version
number 3 and higher.  Changing the meaning of a field is exactly what the
version numbers are for.

You could even decode version 3 transactions like that.

Version 3 transactions have a sequence number of 0x and the
sequence number field is re-purposed for relative lock time.

This means that legacy transactions that have already been signed but have
a locktime in the future will still be able to enter the blockchain
(without having to wait significantly longer than expected).

On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach 
wrote:

> I have no problem with modifying the proposal to have the most significant
> bit signal use of the nSequence field as a relative lock-time. That leaves
> a full 31 bits for experimentation when relative lock-time is not in use. I
> have adjusted the code appropriately:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn  wrote:
>
>> Mike, this proposal was purposefully constructed to maintain as well as
>>> possible the semantics of Satoshi's original construction. Higher sequence
>>> numbers -- chronologically later transactions -- are able to hit the chain
>>> earlier, and therefore it can be reasonably argued will be selected by
>>> miners before the later transactions mature. Did I fail in some way to
>>> capture that original intent?
>>>
>>
>> Right, but the original protocol allowed for e.g. millions of revisions
>> of the transaction, hence for high frequency trading (that's actually how
>> Satoshi originally explained it to me - as a way to do HFT - back then the
>> channel concept didn't exist).
>>
>> As you point out, with a careful construction of channels you should only
>> need to bump the sequence number when the channel reverses direction. If
>> your app only needs to do that rarely, it's a fine approach.And your
>> proposal does sounds better than sequence numbers being useless like at the
>> moment. I'm just wondering if we can get back to the original somehow or at
>> least leave a path open to it, as it seems to be a superset of all other
>> proposals, features-wise.
>>
>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version bits proposal

[Tier Nolan]

On Wed, May 27, 2015 at 11:15 AM, Peter Todd  wrote:

> The median time mechanism is basically a way for hashing power to show
> what time they think it is. Equally, the nVersion soft-fork mechanism is
> a way for hashing power to show what features they want to support.
>
>
Fair enough.  It means slightly more processing, but the median time could
be cached in the header index, so no big deal.

Block counts are inconvenient for planning, as there's no guarantee
> they'll actually happen in any particular time frame, forward and back.
>

I don't think the deadline needs to be set that accurately.  A roughly 6
month deadline should be fine, but as you say a majority of miners is
needed to abuse the median time and it is already a miner poll.

Perhaps the number of blocks used in the median could be increased to
reduce "noise".

The median time could be median of the last 144 blocks plus 12 hours.


> If you assume no large reorganizations, your table of known BIPs can
> just as easily be a list of block heights even if the median time
> mechanism is used.
>

I think it makes it easier to write the code.  It reduced the state that
needs to be stored per BIP.  You don't need to check if the previous bips
were all accepted.

Each bit is assigned to a particular BIP for a particular range of times
(or blocks).

If block numbers were used for the deadline, you just need to check the
block index for the deadline block.

enum {
BIP_INACTIVE = 0,
BIP_ACTIVE,
BIP_LOCKED
BIP_INVALID_BLOCK,
}

int GetBIPState(block, bip)
{
if (block.height == bip.deadline)  // Bit must be set to match
locked/unlocked at deadline
{
int bipState = check_supermajority(...);
if (bipState == BIP_LOCKED && (block.nVersion & bip.bit)
return BIP_LOCKED;

if (bipState != BIP_LOCKED && (block.nVersion & (~bip.bit)))
return BIP_INACTIVE;

return BIP_INVALID_BLOCK;
}

if (block.height > deadline) // Look at the deadline block to determine
if the BIP is locked
return (block_index[deadline].nVersion & bip_bit) != 0 ? BIP_LOCKED
: BIP_INACTIVE;

if (block.height < startline + I) // BIP cannot activate/lock until
startline + implicit window size
return INACTIVE;

return check_supermajority() // Check supermajority of bit
}

The block at height deadline would indicate if the BIP was locked in.

Block time could still be used as long as the block height was set after
that.  The deadline_time could be in six months.  The startline height
could be the current block height and the deadline_height could be
startline + 35000.

The gives roughly

start time = now
deadline time = now + six months
deadline height = now + eight months

The deadline height is the block height when the bit is returned to the
pool but the deadline time is when the BIP has to be accepted.

It also helps with the warning system.  For each block height, there is a
set of known BIP bits that are allowed.  Once the final deadline is passed,
the expected mask is zeros.

On Wed, May 27, 2015 at 11:15 AM, Jorge Timón  wrote:

> On May 27, 2015 11:35 AM, "Tier Nolan"  wrote:
>
> > Was the intention to change the 95% rule.  You need 750 of the last 1000
> to activate and then must wait at least 1000 for implication?
>
> You need 75% to start applying it, 95% to start rejecting blocks that
> don't apply it.
>

I think the phrasing is ambiguous.  I was just asking for clarification.

"Whenever I out of any W *subsequent* blocks (regardless of the block
itself) have bit B set,"

That suggests that the I of W blocks for the 95% rule must happen after
activation.  This makes the rule checking harder.  Easier to use the
current system, where blocks that were part of the 750 rule also count
towards the 95% rule.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Tier Nolan]

This could cause legacy transactions to become unspendable.


A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.

Legacy transactions should not have the rule applied to them.

On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell  wrote:

> On Wed, May 27, 2015 at 7:47 AM, Peter Todd  wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
>
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced.   A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).
>
> It makes sequence numbers work exactly like you'd expect-- within the
> bounds of whats possible in a decentralized system.  At the same time,
> all it is ... is relative nlocktime.
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version bits proposal

[Tier Nolan]

I think it would be better to have the deadlines set as block counts.  That
eliminates the need to use the median time mechanism.

The deadline could be matched to a "start-line".  The definition would then
be something like

BIP 105
Start block: 325000
End block: 35
Activation: 750 of 1000
Implication: 950 of 1000
Bit: 9

This would allow creation of a simple table of known BIPs.  It also keeps
multiple users of the bit as strictly separate.

The alternative to the start time is that it is set equal to the deadline
or implication time of the previous user of the bit.

Was the intention to change the 95% rule.  You need 750 of the last 1000 to
activate and then must wait at least 1000 for implication?


On Wed, May 27, 2015 at 4:51 AM, Jorge Timón  wrote:

> It would also help to see the actual code changes required, which I'm sure
> will be much shorter than the explanation itself.
> On May 27, 2015 5:47 AM, "Luke Dashjr"  wrote:
>
>> On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
>> > Feel free to comment. As the gist does not support notifying
>> participants
>> > of new comments, I would suggest using the mailing list instead.
>>
>> I suggest adding a section describing how this interacts with and changes
>> GBT.
>>
>> Currently, the client tells the server what the highest block version it
>> supports is, and the server indicates a block version to use in its
>> template,
>> as well as optional instructions for the client to forcefully use this
>> version
>> despite its own maximum version number. Making the version a bitfield
>> contradicts the increment-only assumption of this design, and since GBT
>> clients are not aware of overall network consensus state, reused bits can
>> easily become confused. I suggest, therefore, that GBT clients should
>> indicate
>> (instead of a maximum supported version number) a list of softforks by
>> identifier keyword, and the GBT server respond with a template indicating:
>> - An object of softfork keywords to bit values, that the server will
>> accept.
>> - The version number, as presently conveyed, indicating the preferred
>> softfork
>> flags.
>>
>> Does this sound reasonable, and/or am I missing anything else?
>>
>> Luke
>>
>>
>> --
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

On Tue, May 19, 2015 at 9:28 AM, Christian Decker <
decker.christ...@gmail.com> wrote:

> Thanks Stephen, I hadn't thought about BIP 34 and we need to address this
> in both proposals. If we can avoid it I'd like not to have one
> transaction hashed one way and other transactions in another way.
>

The normalized TXID cannot depend on height for other transactions.
Otherwise, it gets mutated when been added to the chain, depending on
height.

An option would be that the height is included in the scriptSig for all
transactions, but for non-coinbase transctions, the height used is zero.

I think if height has to be an input into the normalized txid function, the
specifics of inclusion don't matter.

The previous txid for coinbases are required to be all zeros, so the
normalized txid could be to add the height to the txids of all inputs.
Again, non-coinbase transactions would have heights of zero.


> Is there a specific reason why that was not chosen at the time?
>

I assumed that since the scriptSig in the coinbase is specifically intended
to be "random" bytes/extra nonce, so putting a restriction on it was
guaranteed to be backward compatible.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Mon, May 18, 2015 at 2:42 AM, Rusty Russell 
wrote:

> OK.  Be nice if these were cleaned up, but I guess it's a sunk cost.
>

Yeah.

On the plus side, as people spend their money, old UTXOs would be used up
and then they would be included in the cost function.  It is only people
who are storing their money long term that wouldn't.

They are unlikely to have consumed their UTXOs anyway, unless miners
started paying for UTXOs.

We could make it a range.

UTXOs from below 355,000 and above 375,000 are included.  That can create
incentive problems for the next similar change, I think a future threshold
is better.


>  He said "utxo_created_size" not "utxo_created" so I assumed scriptlen?
>

Maybe I mis-read.


> But you made that number up?  The soft cap and hard byte limit are
> different beasts, so there's no need for soft cost cap < hard byte
> limit.
>

I was thinking about it being a soft-fork.

If it was combined with the 20MB limit change, then it can be anything.

I made a suggestion somewhere (her or forums not sure), that transactions
should be allowed to store bytes.

For example, a new opcode could be added,  OP_LOCK_BYTES.

This makes the transaction seem  larger.  However, when
spending the UTXO, that transaction counts as  smaller, even
against the hard-cap.

This would be useful for channels.  If channels were 100-1000X the
blockchain volume and someone caused lots of channels to close, there
mightn't be enough space for all the close channel transactions.  Some
people might be able to get their refund transactions included in the
blockchain because the timeout expires.

If transactions could store enough space to be spent, then a mass channel
close would cause some very large blocks, but then they would have to be
followed by lots of tiny blocks.

The block limit would be an average not fixed per block.  There would be 3
limits

Absolute hard limit (max bytes no matter what): 100MB
Hard limit (max bytes after stored bytes offset): 30MB
Soft limit (max bytes equivalents): 10MB

Blocks lager than ~32MB require a new network protocol, which makes the
hard fork even "harder".  The protocol change could be "messages can now be
150MB max" though, so maybe not so complex.


>
> > This requires that transactions include scriptPubKey information when
> > broadcasting them.
>
> Brilliant!  I completely missed that possibility...
>

I have written a BIP about it.  It is still in the draft stage.  I had a
look into writing up the code for the protocol change.

https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki
https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Tier Nolan]

On Sat, May 16, 2015 at 5:39 AM, Stephen 
wrote:

> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block that met their own size restrictions but not the
> miners', then they would simply count it as unconfirmed.
>

In effect, there is a confirm penalty for less strict blocks.  Confirms =
max(miner_confirms, merchant_confirms - 3, 0)

Merchants who don't upgrade end up having to wait longer to hit
confirmations.

If they get deep enough in the chain, though, the client should probably
> count them as being confirmed anyway, even if they don't meet the client
> nodes' expectation of the miners' block size limit. This happening probably
> just means that the client has not updated their software (or
> -minermaxblocksize configuration, depending on how it is implemented) in a
> long time.
>

That is a good idea.  Any parameters that have miner/merchant differences
should be modifiable (but only upwards) in the command line.

"Why are my transactions taking longer to confirm?"

"There was a soft fork to make the block size larger and your client is
being careful.  You need to add "minermaxblocksize=4MB" to your
bitcoin.conf file."

Hah, it could be called a "semi-hard fork"?
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Tier Nolan]

On Sat, May 9, 2015 at 4:08 AM, Peter Todd  wrote:

> > I wonder if having a "miner" flag would be good for the network.
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>

To mitigate against this, two chaintips could be tracked.  The miner tip
and the client tip.

Miners would build on the miner tip.  When performing client services, like
wallets, they would use the client tip.

The client would act exactly the same as any node, the only change would be
that it gives miner work based on the mining tip.

If the two tips end up significantly forking, there would be a warning to
the miner and perhaps eventually refuse to give out new work.

That would happen when there was a miner level hard-fork.


> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>

To launch that attack, you need to produce fake blocks.  That is
expensive.

Stephen Cale's suggestion to wait more than one block before counting a
transaction as confirmed would also help mitigate.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Sat, May 16, 2015 at 1:22 AM, Rusty Russell 
wrote:

> Some tweaks:
>
> 1) Nomenclature: call tx_size "tx_cost" and real_size "tx_bytes"?
>

Fair enough.

>
> 2) If we have a reasonable hard *byte* limit, I don't think that we need
>the MAX().  In fact, it's probably OK to go negative.
>

I agree, we want people to compress the UTXO space and a transaction with
100 inputs and one output is great.

It may have privacy problem though.


>
> 3) ... or maybe not, if any consumed UTXO was generated before the soft
>fork (reducing Tier's perverse incentive).
>

The incentive problem can be fixed by excluding UTXOs from blocks before a
certain count.

UTXOs in blocks before 375000 don't count.


>
> 4) How do we measure UTXO size?  There are some constant-ish things in
>there (eg. txid as key, height, outnum, amount).  Maybe just add 32
>to scriptlen?
>

They can be stored as a fixed digest.  That can be any size, depending on
security requirements.

Gmaxwell's cost proposal is 3-4 bytes per UTXO change.  It isn't
4*UXTO.size - 3*UTXO.size

It is only a small nudge.  With only 10% of the block space to play with it
can't be massive.

This requires that transactions include scriptPubKey information when
broadcasting them.


>
> 5) Add a CHECKSIG cost.  Naively, since we allow 20,000 CHECKSIGs and
>1MB blocks, that implies a cost of 50 bytes per CHECKSIG (but counted
>correctly, unlike now).
>
> This last one implies that the initial cost limit would be 2M, but in
> practice probably somewhere in the middle.
>
>   tx_cost = 50*num-CHECKSIG
> + tx_bytes
> + 4*utxo_created_size
> - 3*utxo_consumed_size
>
> > A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
> > size of 252 bytes.
>
> Now cost == 352.
>

That is to large a cost for a 10% block change.  It could be included in
the block size hard fork though.  I think have one combined "cost" for
transactions is good.  It means much fewer spread out transaction checks.
The code for the cost formula would be in one place.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

On Sat, May 16, 2015 at 4:58 AM, Stephen 
wrote:

> We should make sure to consider how BIP34 affects normalized transaction
> ids, since the height of the block is included in the scriptSig ensuring
> that the txid will be different. We wouldn't want to enable replay attacks
> in the form of spending coinbase outputs in the same way they were spent
> from a previous block.
>
> So maybe normalized txids should strip the scriptSigs of all transactions
> except for coinbase transactions? This seems to make sense, since coinbase
> transactions are inherently not malleable anyway.
>

That is a good point.  Since the point is the change is to use good
practice right back until the genesis block, maybe the scriptSig for
coinbases could be replaced by the height expressed as a varint.  That
means that all coinbases get a unique normalized txid.  The coinbases with
duplicate txids still wouldn't be spendable though.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

On Fri, May 15, 2015 at 10:54 AM, s7r  wrote:

> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
>

The signature signs everything except the signature itself.  The normalized
txid doesn't include that signature, so mutations of the signature don't
cause the normalized txid to change.

If the refund transaction refers to the parent using the normalised txid,
then it doesn't matter if the parent has a mutated signature.  The
normalized transaction ignores the mutation.

If the parent is mutated, then the refund doesn't even have to be modified,
it still refers to it.

If you want a multi-level refund transaction, then all refund transactions
must use the normalized txids to refer to their parents.  The "root"
transaction is submitted to the blockchain and locked down.


> b) replays
>

If there are 2 transactions which are mutations of each other, then only
one can be added to the block chain, since the other is a double spend.

The normalized txid refers to all of them, rather than a specific
transaction.


> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>

Mutation is only a problem if it occurs after signing.  The signature signs
everything except the signature itself.


> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays.


Correct, but normalized txids are safe against replays, so are better.

I think the new signature opcode fixes things too.  The question is hard
fork but clean solution vs a soft fork but a little more hassle.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille 
wrote:

>
> This was what I was suggesting all along, sorry if I wasn't clear.
>
>
That's great.  So, basically the multi-level refund problem is solved by
this?
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

After more thought, I think I came up with a clearer description of the
recursive version.

The simple definition is that the hash for the new signature opcode should
simply assume that the normalized txid system was used since the
beginning.  All txids in the entire blockchain should be replaced with the
"correct" values.

This requires a full re-index of the blockchain.  You can't work out what
the TXID-N of a transaction is without knowning the TXID-N of its parents,
in order to do the replacement.

The non-recursive version can only handle refunds one level deep.

A:
from: IN
sigA: based on hash(...)

B:
from A
sig: based on hash(from: TXID-N(A) | "")  // sig removed

C:
from B
sig: based on hash(from: TXID-N(B) | "")  // sig removed

If A is mutated before being added into the chain, then B can be modified
to a valid transaction (B-new).

A-mutated:
from: IN
sig_mutated: based on hash(...) with some mutation

B has to be modified to B-new to make it valid.

B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-mutated), "")

Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is
still valid.

Howver, C-new cannot be created.

C-new:
from B-new
sig: based on hash(from: TXID-N(B-new), "")

TXID-N(B-new) is not the same as TXID-N(B).  Since the from field is not
removed by the TXID-N operation, differences in that field mean that the
TXIDs are difference.

This means that the signature for C is not valid for C-new.

The recursive version repairs this problem.

Rather than simply delete the scriptSig from the transaction.  All txids
must also be replaced with their TXID-N versions.

Again, A is mutated before being added into the chain and B-new is produced.

A-mutated:
from: IN
sig_mutated: based on hash(...) with some mutation
TXID-N: TXID-N(A)

B has to be modified to B-new to make it valid.

B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-mutated), "")
TXID-N: TXID-N(B)

Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is
still valid.

Likewise the TXID-N(B-new) is equal to TXID-N(B).

The from field is replaced by the TXID-N from A-mutated which is equal to
TXID-N(A) and the sig is the same.

C-new:
from B-new
sig: based on hash(from: TXID-N(B-new), "")

The signature is still valid, since TXID-N(B-new) is the same as TXID-N(B).

This means that multi-level refunds are possible.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

On Wed, May 13, 2015 at 6:14 PM, Pieter Wuille 
wrote:

> Normalized transaction ids are only effectively non-malleable when all
> inputs they refer to are also non-malleable (or you can have malleability
> in 2nd level dependencies), so I do not believe it makes sense to allow
> mixed usage of the txids at all.
>

The txid or txid-norm is signed, so can't be changed after signing.

The hard fork is to allow transactions to refer to their inputs by txid or
txid-norm.  You pick one before signing.

> They do not provide the actual benefit of guaranteed non-malleability
> before it becomes disallowed to use the old mechanism.
>
A signed transaction cannot have its txid changed.  It is true that users
of the system would have to use txid-norm.

The basic refund transaction is as follows.

 A creates TX1: "Pay w BTC to  if signed by A & B"

 A creates TX2: "Pay w BTC from TX1-norm to , locked 48
hours in the future, signed by A"

 A sends TX2 to B

 B signs TX2 and returns to A

A broadcasts TX1.  It is mutated before entering the chain to become
TX1-mutated.

A can still submit TX2 to the blockchain, since TX1 and TX1-mutated have
the same txid-norm.

>
> That, together with the +- resource doubling needed for the UTXO set (as
> earlier mentioned) and the fact that an alternative which is only a
> softfork are available, makes this a bad idea IMHO.
>
> Unsure to what extent this has been presented on the mailinglist, but the
> softfork idea is this:
> * Transactions get 2 txids, one used to reference them (computed as
> before), and one used in an (extended) sighash.
> * The txins keep using the normal txid, so not structural changes to
> Bitcoin.
> * The ntxid is computed by replacing the scriptSigs in inputs by the empty
> string, and by replacing the txids in txins by their corresponding ntxids.
> * A new checksig operator is softforked in, which uses the ntxids in its
> sighashes rather than the full txid.
> * To support efficiently computing ntxids, every tx in the utxo set
> (currently around 6M) stores the ntxid, but only supports lookup bu txid
> still.
>
> This does result in a system where a changed dependency indeed invalidates
> the spending transaction, but the fix is trivial and can be done without
> access to the private key.
>
The problem with this is that 2 level malleability is not protected against.

C spends B which spends A.

A is mutated before it hits the chain.  The only change in A is in the
scriptSig.

B can be converted to B-new without breaking the signature.  This is
because the only change to A was in the sciptSig, which is dropped when
computing the txid-norm.

B-new spends A-mutated.  B-new is different from B in a different place.
The txid it uses to refer to the previous output is changed.

The signed transaction C cannot be converted to a valid C-new.  The txid of
the input points to B.  It is updated to point at B-new.  B-new and B don't
have the same txid-norm, since the change is outside the scriptSig.  This
means that the signature for C is invalid.

The txid replacements should be done recursively.  All input txids should
be replaced by txid-norms when computing the txid-norm for the
transaction.  I think this repairs the problem with only allowing one level?

Computing txid-norm:

- replace all txids in inputs with txid-norms of those transactions
- replace all input scriptSigs with empty scripts
- transaction hash is txid-norm for that transaction

The same situation as above is not fatal now.

C spends B which spends A.

A is mutated before it hits the chain.  The only change in A is in the
scriptSig.

B can be converted to B-new without breaking the signature.  This is
because the only change to A was in the sciptSig, which is dropped when
computing the txid-norm (as before).

B-new spends A mutated.  B-new is different from B in for the previous
inputs.

The input for B-new points to A-mutated.  When computing the txid-norm,
that would be replaced with the txid-norm for A.

Similarly, the input for B points to A and that would have been replaced
with the txid-norm for A.

This means that B and B-new have the same txid-norm.

The signed transaction C can be converted to a valid C-new.  The txid of
the input points to B.  It is updated to point at B-new.  B-new and B now
have have the same txid-norm and so C is valid.

I think this reasoning is valid, but probably needs writing out actual
serializations.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

On Wed, May 13, 2015 at 4:24 PM, Christian Decker <
decker.christ...@gmail.com> wrote

> It does and I should have mentioned it in the draft, according to my
> calculations a mapping legacy ID -> normalized ID is about 256 MB in size,
> or at least it was at height 330'000, things might have changed a bit and
> I'll recompute that. I omitted the deprecation of legacy IDs on purpose
> since we don't know whether we will migrate completely or leave keep both
> options viable.
>

There are around 20 million UTXOs.  At 2*32 bytes per entry, that is more
than 1GB.  There are more UTXOs than transactions, but 256MB seems a little
low.

I think both IDs can be used in the merkle tree, since we lookup an ID in
> both indices we can use both to address them and we will find them either
> way.
>

The id that is used to sign should be used in the merkle tree.  The hard
fork should simply be to allow transactions that use the normalized
transaction hash.


> As for the opcodes I'll have to check, but I currently don't see how they
> could be affected.
>

Agreed, the transaction is simply changed and all the standard rules apply.


> We can certainly split the proposal should it get too large, for now it
> seems manageable, since opcodes are not affected.
>

Right it is just a database update.  The undo info also needs to be changed
so that both txids are included.


> Bloom-filtering is resolved by adding the normalized transaction IDs and
> checking for both IDs in the filter.
>

Yeah, if a transaction spends with a legacy txid, it should still match if
the normalized txid is included in the filter.

> Since you mention bundling the change with other changes that require a
hard-fork it might be a good idea to build a separate proposal for a
generic hard-fork rollout mechanism.

That would be useful.  On the other hand, we don't want to make them to
easy.

I think this is a good choice for a hard fork test, since it is
uncontroversial.  With a time machine, it would have been done this way at
the start.

What about the following:

The reference client is updated so that it uses version 2 transactions by
default (but it can be changed by user).  A pop-up could appear for the GUI.

There is no other change.

All transactions in blocks 375000 to 385000 are considered votes and
weighted by bitcoin days destroyed (max 60 days).

If > 75% of the transactions by weight are version 2, then the community
are considered to support the hard fork.

There would need to be a way to protect against miners censoring
transactions/votes.

Users could submit their transactions directly to a p2p tallying system.
The coin would be aged based on the age in block 375000 unless included in
the blockchain.  These votes don't need to be ordered and multiple votes
for the same coin would only count once.

In fact, votes could just be based on holding in block X.

This is an opinion poll rather than a referendum though.

Assuming support of the community, the hard fork can then proceed in a
similar way to the way a soft fork does.

Devs update the reference client to produce version 4 blocks and version 3
transactions.  Miners could watch version 3 transactions to gauge user
interest and use that to help decide if they should update.

If 750 of the last 1000 blocks are version 4 or higher, reject blocks with
transactions of less than version 3 in version 4 blocks

This means that legacy clients will be slow to confirm their
transactions, since their transactions cannot go into version 4 blocks.
This is encouragement to upgrade.

If 950 of the last 1000 blocks are version 4 or higher, reject blocks with
transactions of less than version 3 in all blocks

This means that legacy nodes can no longer send transactions but can
still receive.  Transactions received from other legacy nodes would remain
unconfirmed.

If 990 of the last 1000 blocks are version 4 or higher, reject version 3 or
lower blocks

This is the point of no return.  Rejecting version 3 blocks means that
the next rule is guaranteed to activate within the next 2016 blocks.
Legacy nodes remain on the main chain, but cannot send.  Miners mining with
legacy clients are (soft) forked off the chain.

If 1000 of the last 1000 blocks are version 4 or higher and the difficulty
retarget has just happened, activate hard fork rule

This hard forks legacy nodes off the chain.  99% of miners support this
change and users have been encouraged to update.  The block rate for the
non-forked chain is ast most 1% of normal.  Blocks happen every 16 hours.
By timing activation after a difficulty retarget, it makes it harder for
the other fork to adapt to the reduced hash rate.

>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with t

Re: [Bitcoin-development] Long-term mining incentives

[Tier Nolan]

On Wed, May 13, 2015 at 1:26 PM, Alex Mizrahi 
wrote:

> He tries to investigate, and after some time discovers that his router (or
> his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of
> the legitimate nodes, and thus got a complete fake chain from the attacker.
> Bitcoins he received were totally fake.
>
> Bitcoin Core did a shitty job and confirmed some fake transactions.
>

I don't really see how you can protect against total isolation of a node
(POS or POW).  You would need to find an alternative route for the
information.

Even encrypted connections are pointless without authentication of who you
are communicating with.

Again, it is part of the security model that you can connect to at least
one honest node.

Someone tweated all the bitcoin headers at one point.  The problem is that
if everyone uses the same check, then that source can be compromised.

> WIthout checkpoints an attacker could prepare a fork for $10.
> With checkpoints, it would cost him at least $1000, but more likely
upwards of $10.
> That's quite a difference, no?

Headers first mean that you can't knock a synced node off the main chain
without winning the POW race.

Checkpoints can be replaced with a minimum amount of POW for initial sync.
This prevents spam of low POW blocks.  Once a node is on a chain with at
least that much POW, it considers it the main chain.,
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[Tier Nolan]

I think this is a good way to handle things, but as you say, it is a hard
fork.

CHECKLOCKTIMEVERIFY covers many of the use cases, but it would be nice to
fix malleability once and for all.

This has the effect of doubling the size of the UTXO database.  At minimum,
there needs to be a legacy txid to normalized txid map in the database.

An addition to the BIP would eliminate the need for the 2nd index.  You
could require a SPV proof of the spending transaction to be included with
legacy transactions.  This would allow clients to verify that the
normalized txid matched the legacy id.

The OutPoint would be {LegacyId | SPV Proof to spending tx  | spending tx |
index}.  This allows a legacy transaction to be upgraded.  OutPoints which
use a normalized txid don't need the SPV proof.

The hard fork would be followed by a transitional period, in which both
txids could be used.  Afterwards, legacy transactions have to have the SPV
proof added.  This means that old transactions with locktimes years in the
future can be upgraded for spending, without nodes needing to maintain two
indexes.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Long-term mining incentives

[Tier Nolan]

On Wed, May 13, 2015 at 11:31 AM, Alex Mizrahi 
wrote:

>
> But this matters if a new node has access to the globally strongest chain.
>

A node only needs a path of honest nodes to the network.

If a node is connected to 99 dishonest nodes and 1 honest node, it can
still sync with the main network.

>
> In practice, Bitcoin already embraces "weak subjectivity" e.g. in form of
> checkpoints embedded into the source code. So it's hard to take PoW purists
> seriously.
>
>
That isn't why checkpoints exist.  They are to prevent a disk consumption
DOS attack.

They also allow verification to go faster.  Signature operations are
assumed to be correct without checking if they are in blocks before the
last checkpoint.

They do protect against multi-month forks though, even if not the reason
that they exist.

If releases happen every 6 months, and the checkpoint is 3 months deep at
release, then for the average node, the checkpoint is 3 to 9 months old.

A 3 month reversal would be devastating, so the checkpoint isn't adding
much extra security.

With headers first downloading, the checkpoints could be removed.  They
could still be used for speeding up verification of historical blocks.
Blocks behind the last checkpoint wouldn't need their signatures checked.

Removing them could cause a hard-fork though, so maybe they could be
defined as legacy artifacts of the blockchain.  Future checkpoints could be
advisory.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell  wrote:

> An example would
> be tx_size = MAX( real_size >> 1,  real_size + 4*utxo_created_size -
> 3*utxo_consumed_size).


This could be implemented as a soft fork too.

* 1MB hard size limit
* 900kB soft limit

S = block size
U = UTXO_adjusted_size = S + 4 * outputs - 3 * inputs

A block is valid if S < 1MB and U < 1MB

A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
size of 252 bytes.

The memory pool could be sorted by fee per adjusted_size.

 Coin selection could be adjusted so it tries to have at least 2 inputs
when creating transactions, unless the input is worth more than a threshold
(say 0.001 BTC).

This is a pretty weak incentive, especially if the block size is
increased.  Maybe it will cause a "nudge"
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Long-term mining incentives

[Tier Nolan]

On Wed, May 13, 2015 at 10:49 AM, Thomas Voegtlin 
wrote:

>
> The reason I am asking that is, there seems to be no consensus among
> core developers on how Bitcoin can work without miner subsidy. How it
> *will* work is another question.
>

The position seems to be that it will continue to work for the time being,
so there is still time for more research.

Proof of stake has problems with handling long term reversals.  The main
proposal is to slightly weaken the security requirements.

With POW, a new node only needs to know the genesis block (and network
rules) to fully determine which of two chains is the strongest.

Penalties for abusing POS inherently create a time horizon.  A suggested
POS security model would assume that a full node is a node that resyncs
with the network regularly (every N blocks).N would be depend on the
network rules of the coin.

The alternative is that 51% of the holders of coins at the genesis block
can rewrite the entire chain.  The genesis block might not be the first
block, a POS coin might still use POW for minting.

https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed additional options for pruned nodes

[Tier Nolan]

On Wed, May 13, 2015 at 6:19 AM, Daniel Kraft  wrote:

> 2) Divide the range of all blocks into intervals with exponentially
> growing size.  I. e., something like this:
>
> 1, 1, 2, 2, 4, 4, 8, 8, 16, 16, ...
>

Interesting.  This can be combined with the system I suggested.

A node broadcasts 3 pieces of information

Seed (16 bits): This is the seed
M_bits_lsb (1 bit):  Used to indicate M during a transition
N (7 bits):  This is the count of the last range held (or partially held)

M = 1 << M_bits

M should be set to the lowest power of 2 greater than double the block
chain height

That gives M = 1 million at the moment.  During changing M, some nodes will
be using the higher M and others will use the lower M.

The M_bits_lsb field allows those to be distinguished.

As the block height approaches 512k, nodes can begin to upgrade.  For a
period around block 512k, some nodes could use M = 1 million and others
could use M = 2 million.

Assuming M is around 3 times higher than the block height, then the odds of
a start being less than the block height is around 35%.  If they runs by
25% each step, then that is approx a double for each hit.

Size(n) = ((4 + (n & 0x3)) << (n >> 2)) * 2.5MB

This gives an exponential increase, but groups of 4 are linearly
interpolated.


*Size(0) = 10 MB*
Size(1) = 12.5MB
Size(2) = 15 MB
Size(3) = 17.5MB
Size(4) = 20MB

*Size(5) = 25MB*
Size(6) = 30MB
Size(7) = 35MB

*Size(8) = 40MB*

Start(n) = Hash(seed + n) mod M

A node should store as much of its last start as possible.  Assuming start
0, 5, and 8 were "hits" but the node had a max size of 60MB.  It can store
0 and 5 and have 25MB left.  That isn't enough to store all of run 8, but
it should store 25MB of the blocks in run 8 anyway.

Size(255) = pow(2, 31) * 17.5MB = 35,840 TB

Decreasing N only causes previously accepted runs to be invalidated.

When a node approaches a transition point for N, it would select a block
height within 25,000 of the transition point.  Once it reaches that block,
it will begin downloading the new runs that it needs.  When updating, it
can set N to zero.  This spreads out the upgrade (over around a year), with
only a small number of nodes upgrading at any time.

New nodes should use the higher M, if near a transition point (say within
100,000).
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed additional options for pruned nodes

[Tier Nolan]

On Tue, May 12, 2015 at 8:03 PM, Gregory Maxwell  wrote:

>
> (0) Block coverage should have locality; historical blocks are
> (almost) always needed in contiguous ranges.   Having random peers
> with totally random blocks would be horrific for performance; as you'd
> have to hunt down a working peer and make a connection for each block
> with high probability.
>
> (1) Block storage on nodes with a fraction of the history should not
> depend on believing random peers; because listening to peers can
> easily create attacks (e.g. someone could break the network; by
> convincing nodes to become unbalanced) and not useful-- it's not like
> the blockchain is substantially different for anyone; if you're to the
> point of needing to know coverage to fill then something is wrong.
> Gaps would be handled by archive nodes, so there is no reason to
> increase vulnerability by doing anything but behaving uniformly.
>
> (2) The decision to contact a node should need O(1) communications,
> not just because of the delay of chasing around just to find who has
> someone; but because that chasing process usually makes the process
> _highly_ sybil vulnerable.
>
> (3) The expression of what blocks a node has should be compact (e.g.
> not a dense list of blocks) so it can be rumored efficiently.
>
> (4) Figuring out what block (ranges) a peer has given should be
> computationally efficient.
>
> (5) The communication about what blocks a node has should be compact.
>
> (6) The coverage created by the network should be uniform, and should
> remain uniform as the blockchain grows; ideally it you shouldn't need
> to update your state to know what blocks a peer will store in the
> future, assuming that it doesn't change the amount of data its
> planning to use. (What Tier Nolan proposes sounds like it fails this
> point)
>
> (7) Growth of the blockchain shouldn't cause much (or any) need to
> refetch old blocks.
>

M = 1,000,000
N = number of "starts"

S(0) = hash(seed) mod M
...
S(n) = hash(S(n-1)) mod M

This generates a sequence of start points.  If the start point is less than
the block height, then it counts as a hit.

The node stores the 50MB of data starting at the block at height S(n).

As the blockchain increases in size, new starts will be less than the block
height.  This means some other runs would be deleted.

A weakness is that it is random with regards to block heights.  Tiny blocks
have the same priority as larger blocks.

0) Blocks are local, in 50MB runs
1) Agreed, nodes should download headers-first (or some other compact way
of finding the highest POW chain)
2) M could be fixed, N and the seed are all that is required.  The seed
doesn't have to be that large.  If 1% of the blockchain is stored, then 16
bits should be sufficient so that every block is covered by seeds.
3) N is likely to be less than 2 bytes and the seed can be 2 bytes
4) A 1% cover of 50GB of blockchain would have 10 starts @ 50MB per run.
That is 10 hashes.  They don't even necessarily need to be crypt hashes
5) Isn't this the same as 3?
6) Every block has the same odds of being included.  There inherently needs
to be an update when a node deletes some info due to exceeding its cap.  N
can be dropped one run at a time.
7) When new starts drop below the tip height, N can be decremented and that
one run is deleted.

There would need to be a special rule to ensure the low height blocks are
covered.  Nodes should keep the first 50MB of blocks with some probability
(10%?)
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed additional options for pruned nodes

[Tier Nolan]

On Tue, May 12, 2015 at 6:16 PM, Peter Todd  wrote:

>
> Lots of people are tossing around ideas for partial archival nodes that
> would store a subset of blocks, such that collectively the whole
> blockchain would be available even if no one node had the entire chain.
>

A compact way to describe which blocks are stored helps to mitigate against
fingerprint attacks.

It also means that a node could compactly indicate which blocks it stores
with service bits.

The node could pick two numbers

W = window = a power of 2
P = position = random value less than W

The node would store all blocks with a height of P mod W.  The block hash
could be used too.

This has the nice feature that the node can throw away half of its data and
still represent what is stored.

W_new = W * 2
P_new = (random_bool()) ? P + W/2 : P;

Half of the stored blocks would match P_new mod W_new and the other half
could be deleted.  This means that the store would use up between 50% and
100% of the allocated size.

Another benefit is that it increases the probability that at least someone
has every block.

If N nodes each store 1% of the blocks, then the odds of a block being
stored is pow(0.99, N).  For 1000 nodes, that gives odds of 1 in 23,164
that a block will be missing.  That means that around 13 out of 300,000
blocks would be missing.  There would likely be more nodes than that, and
also storage nodes, so it is not a major risk.

If everyone is storing 1% of blocks, then they would set W to 128.  As long
as all of the 128 buckets is covered by some nodes, then all blocks are
stored.  With 1000 nodes, that gives odds of 0.6% that at least one bucket
will be missed.  That is better than around 13 blocks being missing.

Nodes could inform peers of their W and P parameters on connection.  The
version message could be amended or a "getparams" message of some kind
could be added.

W could be encoded with 4 bits and P could be encoded with 16 bits, for 20
in total.  W = 1 << bits[19:16] and P = bits[14:0].  That gives a maximum W
of 32768, which is likely to many bits for P.

Initial download would be harder, since new nodes would have to connect to
at least 100 different nodes.  They could download from random nodes, and
just download the ones they are missing from storage nodes.  Even storage
nodes could have a range of W values.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

[Tier Nolan]

On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen 
wrote:

> RE: fixing sigop counting, and building in UTXO cost: great idea! One of
> the problems with this debate is it is easy for great ideas get lost in all
> the noise.
>

If the UTXO set cost is built in, UTXO database entries suddenly are worth
something, in addition to the bitcoin held in that entry.

A user's client might display how many they own.  When sending money to a
merchant, the user might demand the merchant indicate a slot to pay to.

The user could send an ANYONE_CAN_PAY partial transaction.  The transaction
would guarantee that the user has at least as many UTXOs as before.

Discussing the possibility of doing this creates an incentive to bloat the
UTXO set right now, since UTXOs would be valuable in the future.

The objective would be to make them valuable enough to encourage
conservation, but not so valuable that the UTXO contains more value than
the bitcoins in the output.

Gmaxwell's suggested "tx_size = MAX( real_size >> 1,  real_size +
4*utxo_created_size - 3*utxo_consumed_size)" for a 250 byte transaction
with 1 input and 2 outputs has very little effect.

real_size + 4 * (2) - 3 * 1 = 255

That gives a 2% size penalty for adding an extra UTXO.  I doubt that is
enough to change behavior.

The UTXO set growth could be limited directly.  A block would be invalid if
it increases the number of UTXO entries above the charted path.

RE: a hard upper limit, with a dynamic limit under it:
>

If the block is greater than 32MB, then it means an update to how blocks
are broadcast, so that could be a reasonable hard upper limit (or maybe
31MB, or just the 20MB already suggested).
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Tier Nolan]

On Fri, May 8, 2015 at 5:37 PM, Peter Todd  wrote:

> The soft-limit is there miners themselves produce smaller blocks; the
> soft-limit does not prevent other miners from producing larger blocks.
>

I wonder if having a "miner" flag would be good for the network.

Clients for general users and merchants would have a less strict rule than
the rule for miners.  Miners who don't set their miners flag might get
orphaned off the chain.

For example, the limits could be setup as follows.

Clients: 20MB
Miners: 4MB

When in "miner mode", the client would reject 4MB blocks and wouldn't build
on them.  The reference client might even track the miner and the non-miner
chain tip.

Miners would refuse to build on 5MB blocks, but merchants and general users
would accept them.

This allows the miners to soft fork the limit at some point in the future.
If 75% of miners decided to up the limit to 8MB, then all merchants and the
general users would accept the new blocks.  It could follow the standard
soft fork rules.

This is a more general version of the system where miners are allowed to
vote on the block size (subject to a higher limit).

A similar system is where clients track all header trees.  Your wallet
could warn you that there is an invalid tree that has > 75% of the hashing
power and you might want to upgrade.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

[Tier Nolan]

Sorry for the spam of the last mail.  I hit send by accident.

Assurance contracts are better than simple donations.

Donating to a project means that you always end up losing the money but the
project might still not get funded.

An assurance contract is like Kickstarter, you only get your CC charged if
the project is fully funded.

There is lower risk, either you get your money back or the project is
funded.  It might still be worth risking it and hoping it gets funded.

Kickstarter does have pledge rewards to reward pledgers.  That helps with
creating the momentum to encourage people to pledge.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

[Tier Nolan]

On Fri, May 8, 2015 at 3:54 PM, Benjamin 
wrote:

> AC does not solve the problem. AC works if people gain directly from
> the payment.


Not necessarily.









> Imagine a group of people paying tax - nobody gains from
> paying it. You have to actually need to enforce negative outcomes to
> enable it (jail for tax fraud). Hence in Bitcoin we have the enforced
> subsidy. AFAIK the problem of how to incentivize transaction
> verification without subsidy is unsolved. Who determines a fair price?
> People around here should study more economics, game theory, etc.
> instead of debating low level encodings all the time.
>
> On Fri, May 8, 2015 at 4:15 PM, Tier Nolan  wrote:
> > Just to clarify the process.
> >
> > Pledgers create transactions using the following template and broadcast
> > them.  The p2p protocol could be modified to allow this, or it could be a
> > separate system.
> >
> > Input: 0.01 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Output 50BTC
> > Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE
> >
> > Output 0.01BTC
> > Paid to OP_TRUE
> >
> > This transaction is invalid, since the inputs don't pay for the output.
> The
> > advantage of the sighash "anyone can pay" field is that other people can
> add
> > additional inputs without making the signature invalid.  Normally, any
> > change to the transaction would make a signature invalid.
> >
> > Eventually, enough other users have added pledges and a valid transaction
> > can be broadcast.
> >
> > Input: 0.01 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Input: 1.2 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Input: 5 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > 
> >
> > Input: 1.3 BTC
> > Signed with SIGHASH_ANYONE_CAN_PAY
> >
> > Output 50BTC
> > Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE
> >
> > Output 0.01BTC
> > Paid to OP_TRUE
> >
> > This transaction can be submitted to the main network.  Once it is
> included
> > into the blockchain, it is locked in.
> >
> > In this example, it might be included in block 999,500.  The 0.01BTC
> output
> > (and any excess over 50BTC) can be collected by the block 999,500 miner.
> >
> > The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be
> > spent until block 1 million.  Once block 1 million arrives, the output is
> > completely unprotected.  This means that the miner who mines block 1
> million
> > can simply take it, by including his own transaction that sends it to an
> > address he controls.  It would be irrational to include somebody else's
> > transaction which spent it.
> >
> > If by block 999,900, the transaction hasn't been completed (due to not
> > enough pledgers), the pledgers can spend the coin(s) that they were
> going to
> > use for their pledge.  This invalidates those inputs and effectively
> > withdraws from the pledge.
> >
> > On Fri, May 8, 2015 at 11:01 AM, Benjamin 
> > wrote:
> >>
> >> 2. "A merchant wants to cause block number 1 million to effectively
> >> have a minting fee of 50BTC." - why should he do that? That's the
> >> entire tragedy of the commons problem, no?
> >
> >
> > No, the pledger is saying that he will only pay 0.01BTC if the miner
> gets a
> > reward of 50BTC.
> >
> > Imagine a group of 1000 people who want to make a donation of 50BTC to
> > something.  They all way that they will donate 0.05BTC, but only if
> everyone
> > else donates.
> >
> > It still isn't perfect.  Everyone has an incentive to wait until the last
> > minute to pledge.
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

[Tier Nolan]

Just to clarify the process.

Pledgers create transactions using the following template and broadcast
them.  The p2p protocol could be modified to allow this, or it could be a
separate system.


*Input: 0.01 BTC*


*Signed with SIGHASH_ANYONE_CAN_PAY*

*Output 50BTC*

*Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE*


*Output 0.01BTC*

*Paid to OP_TRUE*
This transaction is invalid, since the inputs don't pay for the output.
The advantage of the sighash "anyone can pay" field is that other people
can add additional inputs without making the signature invalid.  Normally,
any change to the transaction would make a signature invalid.

Eventually, enough other users have added pledges and a valid transaction
can be broadcast.


*Input: 0.01 BTC*

*Signed with SIGHASH_ANYONE_CAN_PAY*

*Input: 1.2 BTCSigned with SIGHASH_ANYONE_CAN_PAY*


*Input: 5 BTCSigned with SIGHASH_ANYONE_CAN_PAY*

**





*Input: 1.3 BTCSigned with SIGHASH_ANYONE_CAN_PAYOutput 50BTC*
*Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE*

*Output 0.01BTC**Paid to OP_TRUE*

This transaction can be submitted to the main network.  Once it is included
into the blockchain, it is locked in.

In this example, it might be included in block 999,500.  The 0.01BTC output
(and any excess over 50BTC) can be collected by the block 999,500 miner.

The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be
spent until block 1 million.  Once block 1 million arrives, the output is
completely unprotected.  This means that the miner who mines block 1
million can simply take it, by including his own transaction that sends it
to an address he controls.  It would be irrational to include somebody
else's transaction which spent it.

If by block 999,900, the transaction hasn't been completed (due to not
enough pledgers), the pledgers can spend the coin(s) that they were going
to use for their pledge.  This invalidates those inputs and effectively
withdraws from the pledge.

On Fri, May 8, 2015 at 11:01 AM, Benjamin 
wrote:

> 2. "A merchant wants to cause block number 1 million to effectively
> have a minting fee of 50BTC." - why should he do that? That's the
> entire tragedy of the commons problem, no?
>

No, the pledger is saying that he will only pay 0.01BTC if the miner gets a
reward of 50BTC.

Imagine a group of 1000 people who want to make a donation of 50BTC to
something.  They all way that they will donate 0.05BTC, but only if
everyone else donates.

It still isn't perfect.  Everyone has an incentive to wait until the last
minute to pledge.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

[Tier Nolan]

One of the suggestions to avoid the problem of fees going to zero is
assurance contracts.  This lets users (perhaps large merchants or
exchanges) pay to support the network.  If insufficient people pay for the
contract, then it fails.

Mike Hearn suggests one way of achieving it, but it doesn't actually create
an assurance contract.  Miners can exploit the system to convert the
pledges into donations.

https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770

Consider a situation in the future where the minting fee has dropped to
almost zero.  A merchant wants to cause block number 1 million to
effectively have a minting fee of 50BTC.

He creates a transaction with one input (0.1BTC) and one output (50BTC) and
signs it using SIGHASH_ANYONE_CAN_PAY.  The output pays to OP_TRUE.  This
means that anyone can spend it.  The miner who includes the transaction
will send it to an address he controls (or pay to fee).  The transaction
has a locktime of 1 million, so that it cannot be included before that
point.

This transaction cannot be included in a block, since the inputs are lower
than the outputs.  The SIGHASH_ANYONE_CAN_PAY field mean that others can
pledge additional funds.  They add more input to add more money and the
same sighash.

There would need to be some kind of notice boeard system for these pledges,
but if enough pledge, then a valid transaction can be created.  It is in
miner's interests to maintain such a notice board.

The problem is that it counts as a pure donation.  Even if only 10BTC has
been pledged, a miner can just add 40BTC of his own money and finish the
transaction.  He nets the 10BTC of the pledges if he wins the block.  If he
loses, nobody sees his 40BTC transaction.  The only risk is if his block is
orphaned and somehow the miner who mines the winning block gets his 40BTC
transaction into his block.

The assurance contract was supposed to mean "If the effective minting fee
for block 1 million is 50 BTC, then I will pay 0.1BTC".  By adding his
40BTC to the transaction the miner converts it to a pure donation.

The key point is that *other* miners don't get 50BTC reward if they find
the block, so it doesn't push up the total hashing power being committed to
the blockchain, that a 50BTC minting fee would achieve.  This is the whole
point of the assurance contract.

OP_CHECKLOCKTIMEVERIFY could be used to solve the problem.

Instead of paying to OP_TRUE, the transaction should pay 50 BTC to "<1
million> OP_CHECKLOCKTIMEVERIFY OP_TRUE" and 0.01BTC to "OP_TRUE".

This means that the transaction could be included into a block well in
advance of the 1 million block point.  Once block 1 million arrives, any
miner would be able to spend the 50 BTC.  The 0.01BTC is the fee for the
block the transaction is included in.

If the contract hasn't been included in a block well in advance, pledgers
would be recommended to spend their pledged input,

It can be used to pledge to many blocks at once.  The transaction could pay
out to lots of 50BTC outputs but with the locktime increasing by for each
output.

For high value transactions, it isn't just the POW of the next block that
matters but all the blocks that are built on top of it.

A pledger might want to say "I will pay 1BTC if the next 100 blocks all
have at least an effective minting fee of 50BTC"
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mechanics of a hard fork

[Tier Nolan]

In terms of miners, a strong supermajority is arguably sufficient, even 75%
would be enough.

The near total consensus required is merchants and users.  If (almost) all
merchants and users updated and only 75% of the miners updated, then that
would give a successful hard-fork.

On the other hand, if 99.99% of the miners updated and only 75% of
merchants and 75% of users updated, then that would be a serioud split of
the network.

The advantage of strong miner support is that it effectively kills the fork
that follows the old rules.  The 25% of merchants and users sees a
blockchain stall.

Miners are likely to switch to the fork that is worth the most.  A mining
pool could even give 2 different sub-domains.  A hasher can pick which
rule-set to follow.  Most likely, they would converge on the fork which
paid the most, but the old ruleset would likely still have some hashing
power and would eventually re-target.

On Thu, May 7, 2015 at 9:00 PM, Roy Badami  wrote:

> I'd love to have more discussion of exactly how a hard fork should be
> implemented.  I think it might actually be of some value to have rough
> consensus on that before we get too bogged down with exactly what the
> proposed hard fork should do.  After all, how can we debate whether a
> particular hard fork proposal has consensus if we haven't even decided
> what level of supermajority is needed to establish consensus?
>
> For instance, back in 2012 Gavin was proposing, effectively, that a
> hard fork should require a supermajority of 99% of miners in order to
> succeed:
>
> https://gist.github.com/gavinandresen/2355445
>
> More recently, Gavin has proposed that a supermoajority of only 80% of
> miners should be needed in order to trigger the hard fork.
>
>
> http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html
>
> Just now, on this list (see attached message) Gavin seems to be
> aluding to some mechanism for a hard fork which involves consensus of
> full nodes, and then a soft fork preceeding the hard fork, which I'd
> love to see a full explanation of.
>
> FWIW, I think 80% is far too low to establish consensus for a hard
> fork.  I think the supermajority of miners should be sufficiently
> large that the rump doesn't constitute a viable coin.  If you don't
> have that very strong level of consensus then you risk forking Bitcoin
> into two competing coins (and I believe we already have one exchange
> promissing to trade both forks as long as the blockchains are alive).
>
> As a starting point, I think 35/36th of miners (approximately 97.2%)
> is the minimum I would be comfortable with.  It means that the rump
> coin will initially have an average confirmation time of 6 hours
> (until difficulty, very slowly, adjusts) which is probably far enough
> from viable that the majority of holdouts will quickly desert it too.
>
> Thoughs?
>
> roy
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Tier Nolan]

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo 
wrote:

> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
>

Miners can always reduce the block size (if they coordinate).  Increasing
the maximum block size doesn't necessarily cause an increase.  A majority
of miners can soft-fork to set the limit lower than the hard limit.

Setting the hard-fork limit higher means that a soft fork can be used to
adjust the limit in the future.

The reference client would accept blocks above the soft limit for wallet
purposes, but not build on them.  Blocks above the hard limit would be
rejected completely.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Tier Nolan]

On Wed, May 6, 2015 at 11:12 PM, Matt Corallo 
wrote:

> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.


Miners can already soft-fork to reduce the maximum block size.  If 51% of
miners agree to a 250kB block size, then that is the maximum block size.

The question being discussed is what is the maximum block size merchants
and users will accept.  This puts a reasonable limit on the maximum size
miners can increase the block size to.

In effect, the block size is set by the minimum of the miner's and the
merchants/user's size.min(miner, merchants/users).


> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
>

Would you accept a rule that the maximum size is 20MB (doubling every 2
years), but that miners have an efficient method for choosing a lower size?

If miners could specify the maximum block size in their block headers, then
they could coordinate to adjust the block size.  If 75% vote to lower the
size, then it is lowered and vice versa for raiding.

Every 2016 blocks, the votes are counter.  If the 504th lowest of the 2016
blocks is higher than the previous size, then the size is set to that
size.  Similarly, if the 504th highest is lower than the previous size, it
becomes the new size.

There could be 2 default trajectories.  The reference client might always
vote to double the size every 4 years.

To handle large blocks (>32MB) requires a change to the p2p protocol
message size limits, or a way to split blocks over multiple messages.

It would be nice to add new features to any hard-fork.

I favour adding an auxiliary header.  The Merkle root in the header could
be replaced with hash(merkle_root | hash(aux_header)).  This is a fairly
simple change, but helps with things like commitments.  One of the fields
in the auxiliary header could be an extra nonce field.  This would mean
fast regeneration of the merkle root for ASIC miners.  This is a pretty
simple change.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Tier Nolan]

On Wed, May 6, 2015 at 8:37 AM, Jorge Timón  wrote:

>
> This gives you less flexibility and I don't think it's necessary.
> Please let's try to avoid this if it's possible.


It is just a switch that turns on and off the new mode.

In retrospect, it would be better to just up the transaction version.

In transactions from v2 onwards, the sequence field means height.  That
means legacy transactions would be spendable.

This is a pure soft-fork.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Tier Nolan]

I think that should be greater than in the comparison?  You want it to fail
if the the height of the UTXO plus the sequence number is greater than the
spending block's height.

There should be an exception for final inputs.  Otherwise, they will count
as relative locktime of 0x.  Is this check handled elsewhere?

if (!tx.vin[i].IsFinal() && nSpendHeight < coins->nHeight +
tx.vin[i].nSequence)
   return state.Invalid(false, REJECT_INVALID,
"bad-txns-non-final-input");

Is the intention to let the script check the sequence number?

 OP_RELATIVELOCKTIMEVERIFY

would check if  is less than or equal to the sequence number.

It does make sequence mean something completely different from before.
Invalidating previously valid transactions has the potential to reduce
confidence in the currency.

A workaround would be to have a way to enable it in the sigScript by
extending Peter Todd's suggestion in the other email chain.

<1> OP_NOP2 means OP_CHECKLOCKTIMEVERIFY (absolute)
<2> OP_NOP2 means OP_RELATIVECHECKLOCKTIMEVERIFY

<3> OP_NOP2 means OP_SEQUENCE_AS_RELATIVE_HEIGHT

OP_SEQUENCE_AS_RELATIVE_HEIGHT would cause the script to fail unless it was
the first opcode in the script.  It acts as a flag to enable using the
sequence number as for relative block height.

This can be achieved using a simple pattern match.

bool CScript::IsSequenceAsRelativeHeight() const
{
// Extra-fast test for pay-to-script-hash CScripts:
return (this->size() >= 4 &&
this->at(0) == OP_PUSHDATA1 &&
this->at(1) == 1 &&
this->at(2) == 0xFF &&
this->at(3) == OP_NOP2);
}

if (!tx.vin[i].IsFinal() &&
tx.vin[i].scriptSig.IsSequenceAsRelativeHeight() && nSpendHeight <
coins->nHeight + tx.vin[i].nSequence)
   return state.Invalid(false, REJECT_INVALID,
"bad-txns-non-final-input");

On Mon, May 4, 2015 at 12:24 PM, Jorge Timón  wrote:

> for (unsigned int i = 0; i < tx.vin.size(); i++) {
> // ...
> if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
> return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
> // ...
> }
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

[Tier Nolan]

I was going to look into creating reference code for this.

The first BIP could be reasonably easy, since it just needs to check for
the presence of the 2 special transactions.

That would mean that it doesn't actually create version 3 blocks at all.

Ideally, I would make it easy for miners to mine version 3 blocks.  I could
add a new field to the getblocktemplate that has the 2 transactions ready
to go.

What do pools actually use for generating blocks.  I assume it's custom
code but that they use (near) standard software for the memory pool?


On Mon, Nov 10, 2014 at 11:39 PM, Tier Nolan  wrote:

> I have added the network BIP too.  It only has the aheaders message and
> the extra field for getheaders.
>
>
> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network.mediawiki
>
> The transaction definitions are still at:
>
> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
>
> On Mon, Nov 10, 2014 at 9:21 PM, Tier Nolan  wrote:
>
>> I updated the BIP to cover only the specification of the transactions
>> that need to be added.  I will create a network BIP tomorrow.
>>
>> On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan 
>> wrote:
>>
>>> The aheaders message is required to make use of the data by SPV
>>> clients.  This could be in a separate BIP though.  I wanted to show that
>>> the merkle path to the aux-header transaction could be efficiently encoded,
>>> but a reference to the other BIP would be sufficient.
>>>
>>> For the other messages, the problem is that the hash of the aux header
>>> is part of the block, but the aux header itself is not.  That means that
>>> the aux header has to be sent for validation of the block.
>>>
>>> I will change it so that the entire aux-header is encoded in the block.
>>> I think encoding the hash in the final transaction and the full aux-header
>>> in the 2nd last one is the best way to do it.  This has the added advantage
>>> of reducing the changes to block data storage, since the aux-header doesn't
>>> have to be stored separately.
>>>
>>>
>>> On Mon, Nov 10, 2014 at 12:52 AM, Gregory Maxwell 
>>> wrote:
>>>
>>>> Some initial comments...
>>>>
>>>> Tying in the protocol changes is really confusing and the fact that
>>>> they seem to be required out the gates would seemingly make this much
>>>> harder to deploy.   Is there a need to do that? Why can't the p2p part
>>>> be entirely separate from the comitted data?
>>>>
>>>> On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan 
>>>> wrote:
>>>> > I made some changes to the draft.  The merkleblock now has the
>>>> auxiliary
>>>> > header information too.
>>>> >
>>>> > There is a tradeoff between overhead and delayed transactions.  Is
>>>> 12.5%
>>>> > transactions being delayed to the next block unacceptable?  Would
>>>> adding
>>>> > padding transactions be an improvement?
>>>> >
>>>> > Creating the "seed" transactions is an implementation headache.
>>>> >
>>>> > Each node needs to have control over an UTXO to create the final
>>>> transaction
>>>> > in the block that has the digest of the auxiliary header.  This means
>>>> that
>>>> > it is not possible to simply start a node and have it mine.  It has to
>>>> > somehow be given the private key.  If two nodes were given the same
>>>> key by
>>>> > accident, then one could end up blocking the other.
>>>> >
>>>> > On one end of the scale is adding a transaction with a few thousand
>>>> outputs
>>>> > into the block chain.  The signatures for locktime restricted
>>>> transactions
>>>> > that spend those outputs could be hard-coded into the software.  This
>>>> is the
>>>> > easiest to implement, but would mean a large table of signatures.  The
>>>> > person who generates the signature list would have to be trusted not
>>>> to
>>>> > spend the outputs early.
>>>> >
>>>> > The other end of the scale means that mining nodes need to include a
>>>> wallets
>>>> > to manage their UTXO entry.  Miners can split a zero value output
>>>> into lots
>>>> > of outputs, if they wish.
>>>> >
>>>> > A middle ground would be for nodes to be able 

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

[Tier Nolan]

I have added the network BIP too.  It only has the aheaders message and the
extra field for getheaders.

https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network.mediawiki

The transaction definitions are still at:

https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki

On Mon, Nov 10, 2014 at 9:21 PM, Tier Nolan  wrote:

> I updated the BIP to cover only the specification of the transactions that
> need to be added.  I will create a network BIP tomorrow.
>
> On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan  wrote:
>
>> The aheaders message is required to make use of the data by SPV clients.
>> This could be in a separate BIP though.  I wanted to show that the merkle
>> path to the aux-header transaction could be efficiently encoded, but a
>> reference to the other BIP would be sufficient.
>>
>> For the other messages, the problem is that the hash of the aux header is
>> part of the block, but the aux header itself is not.  That means that the
>> aux header has to be sent for validation of the block.
>>
>> I will change it so that the entire aux-header is encoded in the block.
>> I think encoding the hash in the final transaction and the full aux-header
>> in the 2nd last one is the best way to do it.  This has the added advantage
>> of reducing the changes to block data storage, since the aux-header doesn't
>> have to be stored separately.
>>
>>
>> On Mon, Nov 10, 2014 at 12:52 AM, Gregory Maxwell 
>> wrote:
>>
>>> Some initial comments...
>>>
>>> Tying in the protocol changes is really confusing and the fact that
>>> they seem to be required out the gates would seemingly make this much
>>> harder to deploy.   Is there a need to do that? Why can't the p2p part
>>> be entirely separate from the comitted data?
>>>
>>> On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan 
>>> wrote:
>>> > I made some changes to the draft.  The merkleblock now has the
>>> auxiliary
>>> > header information too.
>>> >
>>> > There is a tradeoff between overhead and delayed transactions.  Is
>>> 12.5%
>>> > transactions being delayed to the next block unacceptable?  Would
>>> adding
>>> > padding transactions be an improvement?
>>> >
>>> > Creating the "seed" transactions is an implementation headache.
>>> >
>>> > Each node needs to have control over an UTXO to create the final
>>> transaction
>>> > in the block that has the digest of the auxiliary header.  This means
>>> that
>>> > it is not possible to simply start a node and have it mine.  It has to
>>> > somehow be given the private key.  If two nodes were given the same
>>> key by
>>> > accident, then one could end up blocking the other.
>>> >
>>> > On one end of the scale is adding a transaction with a few thousand
>>> outputs
>>> > into the block chain.  The signatures for locktime restricted
>>> transactions
>>> > that spend those outputs could be hard-coded into the software.  This
>>> is the
>>> > easiest to implement, but would mean a large table of signatures.  The
>>> > person who generates the signature list would have to be trusted not to
>>> > spend the outputs early.
>>> >
>>> > The other end of the scale means that mining nodes need to include a
>>> wallets
>>> > to manage their UTXO entry.  Miners can split a zero value output into
>>> lots
>>> > of outputs, if they wish.
>>> >
>>> > A middle ground would be for nodes to be able to detect the special
>>> > transactions and use them.  A server could send out timelocked
>>> transactions
>>> > that pay to a particular address but the transaction would be
>>> timelocked.
>>> > The private key for the output would be known.  However, miners who
>>> mine
>>> > version 2 blocks wouldn't be able to spend them early.
>>> >
>>> >
>>> > On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan 
>>> wrote:
>>> >>
>>> >> I created a draft BIP detailing a way to add auxiliary headers to
>>> Bitcoin
>>> >> in a bandwidth efficient way.  The overhead per auxiliary header is
>>> only
>>> >> around 104 bytes per header.  This is much smaller than would be
>>> required by
>>> >> embedding the hash of the header in the coinbase of the block.
>>

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

[Tier Nolan]

I updated the BIP to cover only the specification of the transactions that
need to be added.  I will create a network BIP tomorrow.

On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan  wrote:

> The aheaders message is required to make use of the data by SPV clients.
> This could be in a separate BIP though.  I wanted to show that the merkle
> path to the aux-header transaction could be efficiently encoded, but a
> reference to the other BIP would be sufficient.
>
> For the other messages, the problem is that the hash of the aux header is
> part of the block, but the aux header itself is not.  That means that the
> aux header has to be sent for validation of the block.
>
> I will change it so that the entire aux-header is encoded in the block.  I
> think encoding the hash in the final transaction and the full aux-header in
> the 2nd last one is the best way to do it.  This has the added advantage of
> reducing the changes to block data storage, since the aux-header doesn't
> have to be stored separately.
>
>
> On Mon, Nov 10, 2014 at 12:52 AM, Gregory Maxwell 
> wrote:
>
>> Some initial comments...
>>
>> Tying in the protocol changes is really confusing and the fact that
>> they seem to be required out the gates would seemingly make this much
>> harder to deploy.   Is there a need to do that? Why can't the p2p part
>> be entirely separate from the comitted data?
>>
>> On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan 
>> wrote:
>> > I made some changes to the draft.  The merkleblock now has the auxiliary
>> > header information too.
>> >
>> > There is a tradeoff between overhead and delayed transactions.  Is 12.5%
>> > transactions being delayed to the next block unacceptable?  Would adding
>> > padding transactions be an improvement?
>> >
>> > Creating the "seed" transactions is an implementation headache.
>> >
>> > Each node needs to have control over an UTXO to create the final
>> transaction
>> > in the block that has the digest of the auxiliary header.  This means
>> that
>> > it is not possible to simply start a node and have it mine.  It has to
>> > somehow be given the private key.  If two nodes were given the same key
>> by
>> > accident, then one could end up blocking the other.
>> >
>> > On one end of the scale is adding a transaction with a few thousand
>> outputs
>> > into the block chain.  The signatures for locktime restricted
>> transactions
>> > that spend those outputs could be hard-coded into the software.  This
>> is the
>> > easiest to implement, but would mean a large table of signatures.  The
>> > person who generates the signature list would have to be trusted not to
>> > spend the outputs early.
>> >
>> > The other end of the scale means that mining nodes need to include a
>> wallets
>> > to manage their UTXO entry.  Miners can split a zero value output into
>> lots
>> > of outputs, if they wish.
>> >
>> > A middle ground would be for nodes to be able to detect the special
>> > transactions and use them.  A server could send out timelocked
>> transactions
>> > that pay to a particular address but the transaction would be
>> timelocked.
>> > The private key for the output would be known.  However, miners who mine
>> > version 2 blocks wouldn't be able to spend them early.
>> >
>> >
>> > On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan 
>> wrote:
>> >>
>> >> I created a draft BIP detailing a way to add auxiliary headers to
>> Bitcoin
>> >> in a bandwidth efficient way.  The overhead per auxiliary header is
>> only
>> >> around 104 bytes per header.  This is much smaller than would be
>> required by
>> >> embedding the hash of the header in the coinbase of the block.
>> >>
>> >> It is a soft fork and it uses the last transaction in the block to
>> store
>> >> the hash of the auxiliary header.
>> >>
>> >> It makes use of the fact that the last transaction in the block has a
>> much
>> >> less complex Merkle branch than the other transactions.
>> >>
>> >>
>> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
>> >>
>> >
>> >
>> >
>> --
>> >
>> > ___
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>
>
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

[Tier Nolan]

The aheaders message is required to make use of the data by SPV clients.
This could be in a separate BIP though.  I wanted to show that the merkle
path to the aux-header transaction could be efficiently encoded, but a
reference to the other BIP would be sufficient.

For the other messages, the problem is that the hash of the aux header is
part of the block, but the aux header itself is not.  That means that the
aux header has to be sent for validation of the block.

I will change it so that the entire aux-header is encoded in the block.  I
think encoding the hash in the final transaction and the full aux-header in
the 2nd last one is the best way to do it.  This has the added advantage of
reducing the changes to block data storage, since the aux-header doesn't
have to be stored separately.

On Mon, Nov 10, 2014 at 12:52 AM, Gregory Maxwell 
wrote:

> Some initial comments...
>
> Tying in the protocol changes is really confusing and the fact that
> they seem to be required out the gates would seemingly make this much
> harder to deploy.   Is there a need to do that? Why can't the p2p part
> be entirely separate from the comitted data?
>
> On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan  wrote:
> > I made some changes to the draft.  The merkleblock now has the auxiliary
> > header information too.
> >
> > There is a tradeoff between overhead and delayed transactions.  Is 12.5%
> > transactions being delayed to the next block unacceptable?  Would adding
> > padding transactions be an improvement?
> >
> > Creating the "seed" transactions is an implementation headache.
> >
> > Each node needs to have control over an UTXO to create the final
> transaction
> > in the block that has the digest of the auxiliary header.  This means
> that
> > it is not possible to simply start a node and have it mine.  It has to
> > somehow be given the private key.  If two nodes were given the same key
> by
> > accident, then one could end up blocking the other.
> >
> > On one end of the scale is adding a transaction with a few thousand
> outputs
> > into the block chain.  The signatures for locktime restricted
> transactions
> > that spend those outputs could be hard-coded into the software.  This is
> the
> > easiest to implement, but would mean a large table of signatures.  The
> > person who generates the signature list would have to be trusted not to
> > spend the outputs early.
> >
> > The other end of the scale means that mining nodes need to include a
> wallets
> > to manage their UTXO entry.  Miners can split a zero value output into
> lots
> > of outputs, if they wish.
> >
> > A middle ground would be for nodes to be able to detect the special
> > transactions and use them.  A server could send out timelocked
> transactions
> > that pay to a particular address but the transaction would be timelocked.
> > The private key for the output would be known.  However, miners who mine
> > version 2 blocks wouldn't be able to spend them early.
> >
> >
> > On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan 
> wrote:
> >>
> >> I created a draft BIP detailing a way to add auxiliary headers to
> Bitcoin
> >> in a bandwidth efficient way.  The overhead per auxiliary header is only
> >> around 104 bytes per header.  This is much smaller than would be
> required by
> >> embedding the hash of the header in the coinbase of the block.
> >>
> >> It is a soft fork and it uses the last transaction in the block to store
> >> the hash of the auxiliary header.
> >>
> >> It makes use of the fact that the last transaction in the block has a
> much
> >> less complex Merkle branch than the other transactions.
> >>
> >>
> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
> >>
> >
> >
> >
> --
> >
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

[Tier Nolan]

I made some changes to the draft.  The merkleblock now has the auxiliary
header information too.

There is a tradeoff between overhead and delayed transactions.  Is 12.5%
transactions being delayed to the next block unacceptable?  Would adding
padding transactions be an improvement?

Creating the "seed" transactions is an implementation headache.

Each node needs to have control over an UTXO to create the final
transaction in the block that has the digest of the auxiliary header.  This
means that it is not possible to simply start a node and have it mine.  It
has to somehow be given the private key.  If two nodes were given the same
key by accident, then one could end up blocking the other.

On one end of the scale is adding a transaction with a few thousand outputs
into the block chain.  The signatures for locktime restricted transactions
that spend those outputs could be hard-coded into the software.  This is
the easiest to implement, but would mean a large table of signatures.  The
person who generates the signature list would have to be trusted not to
spend the outputs early.

The other end of the scale means that mining nodes need to include a
wallets to manage their UTXO entry.  Miners can split a zero value output
into lots of outputs, if they wish.

A middle ground would be for nodes to be able to detect the special
transactions and use them.  A server could send out timelocked transactions
that pay to a particular address but the transaction would be timelocked.
The private key for the output would be known.  However, miners who mine
version 2 blocks wouldn't be able to spend them early.


On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan  wrote:

> I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
> in a bandwidth efficient way.  The overhead per auxiliary header is only
> around 104 bytes per header.  This is much smaller than would be required
> by embedding the hash of the header in the coinbase of the block.
>
> It is a soft fork and it uses the last transaction in the block to store
> the hash of the auxiliary header.
>
> It makes use of the fact that the last transaction in the block has a much
> less complex Merkle branch than the other transactions.
>
> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP draft - Auxiliary Header Format

[Tier Nolan]

I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
in a bandwidth efficient way.  The overhead per auxiliary header is only
around 104 bytes per header.  This is much smaller than would be required
by embedding the hash of the header in the coinbase of the block.

It is a soft fork and it uses the last transaction in the block to store
the hash of the auxiliary header.

It makes use of the fact that the last transaction in the block has a much
less complex Merkle branch than the other transactions.

https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

[Tier Nolan]

On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell  wrote:

> For the non-error-coded case I believe nodes
> with random spans of blocks works out asymptotically to the same
> failure rates as random.
>

If each "block" is really 512 blocks in sequence, then each "slot" is more
likely to be hit.  It effectively reduces the number of blocks by the
minimum run lengths.

ECC seemed cooler though.


> (The conversation Peter Todd was referring to was one where I was
> pointing out that with suitable error coding you also get an
> anti-censorship effect where its very difficult to provide part of the
> data without potentially providing all of it)
>

Interesting too.

>
> I think in the network we have today and for the foreseeable future we
> can reasonably count on there being a reasonable number of nodes that
> store all the blocks... quite likely not enough to satisfy the
> historical block demand from the network alone, but easily enough to
> supply blocks that have otherwise gone missing.
>

That's true.  Scaling up the transactions per second increases the chance
of data lost.

With side/tree chains, the odds of data loss in the less important chains
increases (though they are by definition lower value chains)
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol

[Tier Nolan]

I updated again.

The new version only requires non-standard transactions on one of the two
networks.

Next step is a simple TCP / RPC server that will implement the protocol to
trade between testnet and mainnet.  Timeouts of much less than 24 hours
should be possible now.


On Wed, Apr 30, 2014 at 9:48 PM, Tier Nolan  wrote:

> On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr  wrote:
>
>> Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
>> for
>> these transactions?
>>
>
> Sorry, that is the names come from the original thread, where I was
> outlining the idea.  I updated the names.
>
>
>> TX1 and TX2 *cannot* be signed until after TX0 is completely signed by
>> both
>> parties.
>
>
> The bail in transactions are only signed by one of the parties.  They are
> kept secret until the refund/payout transactions are all properly signed.
>
> There is a malleability risk though, hence the need for the 3rd party.
>
> It works on the same refund principle as payment channels.
>
> After TX0 is signed, but before TX2 is signed, either party could
>> walk away or otherwise hold the funds hostage. The sequence of signing
>> proposed in this BIP is *not possible to perform*.
>
>
> TX0 is not broadcast until the refund transactions are complete.
>
>
>> How did you implement and test this? :/
>>
>
> This is a draft at the moment.
>
> There is an implementation of (almost) this system but not by me.  This
> proposal reduces the number of non-standard transaction types required.
>
> A full implement is the next step.
>
>
>> What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...
>>
>
> That is a typo, I have updated it.
>
>
>> IMO, there should be separate BIPs for the exchange itself, and the
>> protocol
>> to negotiate the exchange.
>
>
> I can do that.
>
>
>> I would recommend changing the latter from JSON-RPC
>> to some extension of the Payment Protocol, if possible.
>>
>
> I wanted it to be as simple as possible, but I guess MIME is just a
> different way of doing things.
>
>>
>> Perhaps it would be good to only support compressed keys, to discourage
>> use of
>> uncompressed ones..
>>
>
> I would have no objection.
>
>
>>
>> Luke
>>
>
>
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol

[Tier Nolan]

On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr  wrote:

> Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
> for
> these transactions?
>

Sorry, that is the names come from the original thread, where I was
outlining the idea.  I updated the names.


> TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both
> parties.


The bail in transactions are only signed by one of the parties.  They are
kept secret until the refund/payout transactions are all properly signed.

There is a malleability risk though, hence the need for the 3rd party.

It works on the same refund principle as payment channels.

After TX0 is signed, but before TX2 is signed, either party could
> walk away or otherwise hold the funds hostage. The sequence of signing
> proposed in this BIP is *not possible to perform*.


TX0 is not broadcast until the refund transactions are complete.


> How did you implement and test this? :/
>

This is a draft at the moment.

There is an implementation of (almost) this system but not by me.  This
proposal reduces the number of non-standard transaction types required.

A full implement is the next step.


> What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...
>

That is a typo, I have updated it.


> IMO, there should be separate BIPs for the exchange itself, and the
> protocol
> to negotiate the exchange.


I can do that.


> I would recommend changing the latter from JSON-RPC
> to some extension of the Payment Protocol, if possible.
>

I wanted it to be as simple as possible, but I guess MIME is just a
different way of doing things.

>
> Perhaps it would be good to only support compressed keys, to discourage
> use of
> uncompressed ones..
>

I would have no objection.


>
> Luke
>
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol

[Tier Nolan]

Due to "popular" demand, I have created a BIP for cross chain atomic
transfers.

Unlike the previous version, this version only requires hash locking.   The
previous version required a "selector" transaction based on if statements.

OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG

OP_HASH160 OP_EQUAL_VERIFY OP_N [public key 1] ... [public key m]
OP_M OP_CHECK_MULTISIG

https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

On Sat, Apr 26, 2014 at 12:11 PM, Jorge Timón  wrote:

> script IsStandard
> main IsStandardTx
> main AcceptToMemoryPool
>

Accept to memory pool could probably be replaced with an
IsStandard(scriptPubKey, scriptSig) method.  The only "isStandard" part of
the process is the check inputs method (and AcceptToMemoryPool calls
IsStandardTx).

The standard script methods at the moment are also used for extracting
addresses for wallet management.

The standard script check could be made easier if it just checked for
pattern matches.

Is there any objections to this change, other than it doesn't go far enough?
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?

[Tier Nolan]

Maybe the solution is to have a defined way to import an unknown wallet?

This means that the gap space and a search ordering needs to be defined.

Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.

The hierarchy that the wallet actually uses could be anything.


On Sat, Apr 26, 2014 at 11:36 AM, Thomas Voegtlin  wrote:

> I totally agree with gmaxwell here. The cost of interoperability is too
> high. It would force us to freeze all features, and to require a broad
> consensus everytime we want to add something new.
>
> In addition, some partial level of compatibility would probably lead to
> users not able to recover all their funds when they enter their seed in
> another wallet. That is not acceptable, and should be avoided.
>
>
>
>
> Le 25/04/2014 17:46, Gregory Maxwell a écrit :
> >
> > I don't believe that wallet interoperability at this level is possible
> > in general except as an explicit compatibility feature. I also don't
> > believe that it is a huge loss that it is so.
> >
> > The structure of the derivation defines and constrains functionality.
> > You cannot be structure compatible unless you have the same features
> > and behavior with respect to key management.  To that extent that
> > wallets have the same features, I agree its better if they are
> > compatible— but unless they are dead software they likely won't keep
> > the same features for long.
> >
> > Even if their key management were compatible there are many other
> > things that go into making a wallet portable between systems; the
> > handling of private keys is just one part:  a complete wallet will
> > have other (again, functionality specific) metadata.
> >
> > I agree that it would be it would be possible to support a
> > compatibility mode where a wallet has just a subset of features which
> > works when loaded into different systems, but I'm somewhat doubtful
> > that it would be widely used. The decision to use that mode comes at
> > the wrong time— when you start, not when you need the features you
> > chose to disable or when you want to switch programs. But the obvious
> > thing to do there is to just specify that a linear chain with no
> > further branching is that mode: then that will be the same mode you
> > use when someone gives you a master public key and asks you to use it
> > for reoccurring changes— so at least the software will get used.
> >
> > Compatibility for something like a recovery tool is another matter,
> > and BIP32 probably defines enough there that with a bit of extra data
> > about how the real wallet worked that recovery can be successful.
> >
> > Calling it "vendor lock in" sounds overblown to me.  If someone wants
> > to change wallets they can transfer the funds— manual handling of
> > private keys is seldom advisable, and as is they're going to lose
> > their metadata in any case.  No one expects to switch banks and to
> > keep their account records at the new bank. And while less than
> > perfect, the price of heavily constraining functionality in order to
> > get another result is just too high.
> >
> >
> --
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd  wrote:

> Along those lines, rather than doing up yet another format specific type
> as Tier Nolan is doing with his BIP, why not write a BIP looking at how
> the IsStandard() rules could be removed?


Removal of isStandard() would be even better/more flexible.

A whitelist of low risk opcodes seems like a reasonable compromise.

My thoughts behind these two BIPs are that they are a smaller change that
adds functionality required for a particular use-case (and some others).

Changing the entire philosophy behind isStandard() is a much bigger change
than just adding one new type.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Selector Script

[Tier Nolan]

On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr  wrote:

> They define standard for interoperability between
> software. So, if you want nodes to relay these transactions, you need to
> convince them, not merely write a BIP for the transaction format.


I agree with you in theory, each miner could decide their inclusion rules
for themselves.

In practice, if the reference client is updated, then most miners will
accept those transactions.  In addition, it would eventually propagate to
alt-coins (or at least the supported ones).

I could simply submit the changes as a pull request for the reference
client, but I was hoping that by doing it this way, it would increase the
odds of it being accepted.


> Defining a BIP for cross-chain trading would be one way to do that.
>

I don't think it quite requires the same coordination in the short term.  I
could write up the sequence as an info BIP.

The malleability "issue" has been known for years.
> I wouldn't expect any special effort made to fix it...
>

It is possible to tweak the protocol so that it still works.  However, it
means that 3rd parties are required (that could go in the BIP too).


> There is some ongoing discussion of a softfork to basically redo the Script
> language entirely, but it will take quite a bit of time and development
> before
> we'll see it in the wild.
>

Implementing multi-P2SH gets a lot of the benefits of MAST, in terms of
efficiency.


>
> Luke
>
> P.S. Did the BIP editor assign these numbers? If not, best to keep them
> numberless until assigned, to avoid confusion when people Google the real
> BIP
> 44 and 45...
>

Not yet, but that is just my personal repo.  I did email gmaxwell, but he
said that they can't be assigned until some discussion has happened.

I take your point that the name appears in the link though, so could cause
issues with searching.


>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Selector Script

[Tier Nolan]

On Fri, Apr 25, 2014 at 8:58 PM, Peter Todd  wrote:

> Keep in mind that P2SH redeemScripts are limited to just 520 bytes;
> there's going to be many cases where more complex transactions just
> can't be encoded in P2SH at all.
>

True.  Having said that, this is just a change to isStandard(), rather than
a protocol change.

These transactions can already be mined into blocks.


> --
> 'peter'[:-1]@petertodd.org
> 6407c80d5d4506a4253b4b426e0c7702963f8bf91e7971aa
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Selector Script

[Tier Nolan]

On Fri, Apr 25, 2014 at 8:17 PM, Luke-Jr  wrote:

> I believe you meant to link here instead?
> https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
>
> Yeah, sorry.


> This looks reasonable from a brief skim over, but does not define any use
> cases (it mentions "necessary for atomic cross chain transfers", but does
> not
> explain how it is useful for that - perhaps that belongs in another BIP you
> haven't written yet, though).


One use case should be enough.  The atomic cross chain proposal has been
discussed for a while.  It feels like bitcoin works on an "ask permission
first" basis.

It always stalls at the fact that non-standard transactions are hard to get
confirmed on other coins.  It is hard to find pools on other coins which
have weaker isStandard() checks.  The timeouts have to be set so that they
are long enough to guarantee that transactions are accepted before they
expire.

A testnet to testnet transfer is the best that would be possible at the
moment.

I don't think the cross chain system needs a BIP (except to justify this
one).

If cross chain transfer become popular, then it would be useful to ensure
that clients are interoperable, but first things first.  If the
transactions aren't accepted in any chains, then everything stalls.

Secure transfers require that the malleability issue is fixed, but that is
a separate issue.  I am assuming that will be fixed at some point in the
future, since micro-payment channels also requires that it is fixed.


> IMO, it should also require P2SH.
>

It could be restricted to only P2SH, I don't think there would be a loss in
doing that.

Personally, I would make it so that P2SH is mandatory after a certain
time.  It makes distributed verification of the block chain easier.
Everything needed to verify a script is present in the transaction (except
that the output actually exists).

A soft fork that expands P2SH functionality would be even better, but I
would rather not let the best be the enemy of the good.

>
>
> Luke
>
>
> On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote:
> > This is a BIP to allow the spender to choose one of multiple standard
> > scripts to use for spending the output.
> >
> > https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
> >
> > This is required as part of the atomic cross chain transfer protocol.  It
> > is required so that outputs can be retrieved, if the process ends before
> > being committed.
> >
> > https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
> >
> > The script allows multiple standard scripts to be included in the
> > scriptPubKey.
> >
> > When redeeming the script the spender indicates which of the standard
> > scripts to use.
> >
> > Only one standard script is actually executed, so the only cost is the
> > extra storage required.
> >
> > A more ambitious change would be a soft fork like P2SH, except the
> spender
> > is allowed to select from multiple hashes.  Effectively, it would be
> > "Multi-P2SH".
> >
> > This gets much of the benefits of MAST, but it requires a formal soft
> fork
> > to implement.
> >
> > If there is agreement, I can code up the reference implementation as a
> PR.
> > The multi-P2SH might actually be easier.
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr  wrote:

> This one looks entirely useless (it cannot be made secure)


The hash locking isn't to prevent someone else stealing your coin.  Once a
user broadcasts a transaction with x in it, then everyone has access to x.

It is to release the coin on the other chain.  If you spend the output, you
automatically give the other participant the password to take your coin on
the other chain (completing the trade).

The BIP allows the hash to protect any of other standard transactions
(except P2SH, since that is a template match).

For example, it would allow a script of the form

OP_HASH160 [20-byte-password-hash] OP_EQUAL_VERIFY OP_DUP OP_HASH160
 OP_EQUALVERIFY OP_CHECKSIG


To spend it, you would need to provide the password and also sign the
transaction using the private key.



> and the assertion
> that it is necessary for atomic cross-chain transfers seems unfounded and
> probably wrong...
>
>
I meant that it is required for the particular protocol.



> Luke
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP - Selector Script

[Tier Nolan]

This is a BIP to allow the spender to choose one of multiple standard
scripts to use for spending the output.

https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki

This is required as part of the atomic cross chain transfer protocol.  It
is required so that outputs can be retrieved, if the process ends before
being committed.

https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

The script allows multiple standard scripts to be included in the
scriptPubKey.

When redeeming the script the spender indicates which of the standard
scripts to use.

Only one standard script is actually executed, so the only cost is the
extra storage required.

A more ambitious change would be a soft fork like P2SH, except the spender
is allowed to select from multiple hashes.  Effectively, it would be
"Multi-P2SH".

This gets much of the benefits of MAST, but it requires a formal soft fork
to implement.

If there is agreement, I can code up the reference implementation as a PR.
The multi-P2SH might actually be easier.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

As part of the atomic cross chain system, outputs need to be hash locked.

https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki

https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949

A user needs to provide x corresponding to hash(x) in order to spend an
output.

Under the protocol, one of the participants is required to provide the
secret number in order to spend an output.  Once they do that, the other
participant can use the secret number to spend an output on the other
chain.  This provides a mechanism to link the 2 chains together (in
addition to lock times).  Once the first output is spent, that commits the
transfer.

This is half of the scripting operations required to implement the protocol.

The proposal is to make this an adder on to the other standard
transactions.  It does a check that the hash matches, and then runs the
standard transaction as normal.

Adding the prefix to a P2SH transactions wouldn't work, since the template
wouldn't match.

A script of this form could be embedded into a P2SH output.

I think that is ok, since embedding the "password" in the hashed script
gets all the benefits.

If there is agreement, I can code up the reference implementation as a PR.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Tier Nolan]

On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell wrote:

> You can see me proposing this kind of thing in a number of places (e.g.
> http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool
> only forces the subsidy today, but the same mechnism could instead
> force transactions..


Interesting.  You set the share-block size to 16kB and set the share POW to
1/64 of the main target.

Each share-block would be allowed to append up to 16kB on the previous
share-block.

This would keep the bandwidth the same, but on average blocks would be only
512kB.

e.g. to get you fast confirmation.", or
> previously on BCT for the last couple years) but there are still
> limits here:  If you don't follow the fast-confirmation share chain
> you cannot mine third party transactions because you'll be at risk of
> mining a double spend that gets you orphaned, or building on a prior
> block that other miners have decided is bad.  This means that if the
> latency or data rate requirements of the share chain are too large
> relative to ordinary mining it may create some centralization
> pressure.
>

This effect could be reduced by having "colours" for blocks and
transactions.

The block colour would be a loop based on block height.

You could have 16 transaction "colours" based on the lowest 4 bits in the
txId.

A transaction is only valid if all inputs into the transaction are the
correct colour for that block.

This allows blocks to be created in advance.  If you are processing colour
7 at the moment, you can have a colour 8 block ready.

16 colours is probably to many.   It would only be necessary for things
like 1 second block rates.

The disadvantage is that wallets would have to make sure that they have
coins for each of the 16 colours.

If you spend the wrong colour, you add 16 block times of latency.


>
> That said, I think using a fast confirmation share-chain is much
> better than decreasing block times and could be a very useful tool if
> we believe that there are many applications which could be improved
> with e.g. a 30 second or 1 minute interblock time.  Mostly my thinking
> has been that these retail applications really want sub-second
> confirmation, which can't reasonably be provided in this manner so I
> didn't mention it in this thread.
>

In a shop setting, you could set it up so that the person scans a QR-code
to setup a channel with the shop.

They can then scan all their stuff and by the time they have done that, the
channel would be ready.

If there was a queue, it could be done when the person enters the queue.

In fact, there could be QR-codes at multiple locations.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Tier Nolan]

An interesting experiment would be a transaction "proof of publication"
chain.

Each transaction would be added to that chain when it is received.  It
could be merge mined with the main chain.

If the size was limited, then it doesn't even require spam protection.

Blocks could be "discouraged" if they have transactions which violate the
ordering in that chain.  Miners could still decide which transactions they
include, but couldn't include transactions which are double spends.

The locktime/final field could be used for transactions which want to be
replaceable.

The chain could use some of the fast block proposals.  For example, it
could include orphans of a block when computing the block's POW.



On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell  wrote:

> On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter  wrote:
> > Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> > the problem? If there would be a safe way for 0-confirmation
> transactions,
> > the Bitcoin blockchain wouldn't even be needed.
>
> Large scale consensus can't generally provide instantly irreversible
> transactions directly: Increasing the block speed can't help past the
> point where the time starts getting close to the network diameter...
> you simply can't tell what a consensus of a group of nodes is until
> several times the light cone that includes all of them.  And if you
> start getting close to the limit you dilute the power working on the
> consensus and potentially make life easier for a large attacker.
>
> Maybe other chains with different parameters could achieve a different
> tradeoff which was better suited to low value retail transactions
> (e.g. where you want a soft confirmation fast). A choice of tradeoffs
> could be very useful, and maybe you can practically get close enough
> (e.g. would knowing you lost a zero-conf double spend within 30
> seconds 90% of the time be good enough?)... but I'm not aware of any
> silver bullet there which gives you something identical to what a
> centralized service can give you without invoking at least a little
> bit of centralization.
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure

[Tier Nolan]

On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak  wrote:

>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>

I meant for a merchant with a server that is handing out hundreds of
addresses.

The point is to have a single system that is compatible over a large number
of systems.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Tier Nolan]

Bitcoin has various checks and balances that help keep everything honest.

Even if a pool had 60% of the hashing power, they couldn't reverse 6 blocks
without anyone noticing that it had happened.

There are sites which monitor the blocks and estimate the percentage of the
blocks found by each pool.

In a way, bitcoin doesn't depend on the majority of miners following the
protocol, it depends on miners believing that a majority of the other
miners will follow the protocol.

If a miner has 5% of the hashing power and believes that the other 95% will
follow the protocol, then the system should be set up so that it is in that
miner's interests to follow the protocol too.

This is why soft forks work.  The formal process convinces all the miners
that the new rules are locked in.

In a system where miners can vote to cancel coinbases, each pool has an
incentive to vote to reject everyone else's blocks.

Pools on the receiving end will be less profitable and lose customers.

It is possible that "predatory" pools would lose hashing power as miners
switch to other pools, in protest.

The proposal allows "established" pools to vote to disallow new entrants.
They could even justify it by saying that those pools haven't invested in
"anti-double spending" infrastructure.

The proposal doesn't suddenly give the majority the ability to do it, but
it isn't clear that making the process less disruptive is a good thing.



On Wed, Apr 23, 2014 at 7:37 PM, Mike Hearn  wrote:

> If you want to try and argue that the development list is the wrong place
> to discuss development, please do so on another thread (or your blog).
> Let's keep this thread for discussion of the original proposal - ideally,
> discussed with the dryness that a topic as nerdy as distributed consensus
> algorithms deserves ;)
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] New BIP32 structure

[Tier Nolan]

Different users could have different gap limit requirements.  20 seems very
low as the default.

A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.

Setting the gap limit to high is just a small extra cost in that case.

Bip-32 serialization doesn't have a way of adding meta data though.


On Wed, Apr 23, 2014 at 7:18 PM, slush  wrote:

> For those who don't follow github pull requests regularly; there's pull
> request for BIP64 defining HD wallet structure as discussed in this thread:
>
> https://github.com/bitcoin/bips/pull/52
>
>
>
> On Wed, Apr 23, 2014 at 8:01 PM, slush  wrote:
>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille 
>> wrote:
>>>
>>> Storing the seed is superior to storing the master node already
>>> (whether coin specific or not), as it is smaller.
>>>
>>>
>> ...Except that you're loosing flexibility (serialization,
>> deserialization) which gives you BIP32 node.
>>
>> I see "bip32 seed" as some transitional, internal state from raw entropy
>> to bip32 master node and this seed should not be handled by the end user in
>> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
>> mnemonic format) can be used very widely and have no downsides against
>> using raw "bip32 seed".
>>
>>
>>>
>>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>>> *Bitcoin* improvement proposal, and not something that necessarily
>>> applies to other coins (they can adopt it of course, I don't care).
>>>
>>>
>> I also don't care too much about altcoins, but people want them so me, as
>> infrastructure developer, need to think about it. And I don't see any
>> reason for breaking compatibility between Bitcoin and other altcoins. I
>> would be happier if there will be another sentence than "Bitcoin seed", but
>> honestly, who cares. It is just some magic string for hashing the raw
>> seed...
>>
>>
>>> What I dislike is that this removes the ability of using the magic in
>>> the serialization to prevent importing a chain from the wrong coin.
>>>
>>
>> The truth is that even existing software which handle bip32 don't care
>> about 'version' at all. I think that "xpub/xprv" distinction is the only
>> useful feature of version, so user se if it stores public or private
>> information.
>>
>> But using prefixes which doesn't enforce anything is even more dangerous.
>> If somebody exports node "dogeblablabla", it creates false exceptations
>> that there's only dogecoin stored.
>>
>>  Marek
>>
>
>
>
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Tier Nolan]

On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd  wrote:

> Of course, in reality smaller miners can just mine on top of block headers
> and include no transactions and do no validation, but that is extremely
> harmful to the security of Bitcoin.
>

I don't think it reduces security much.  It is extremely unlikely that
someone would publish an invalid block, since they would waste their POW.

Presuming that new headers are correct is reasonable, as long as you check
the full block within a few minutes of receiving the header.

If anything, it increases security, since less hashing power is wasted
while the full block is broadcast.

Block propagation could take the form

- broadcast new header
- all miners switch to mining empty blocks
- broadcast new block
- miners update to a block with transactions

If the block doesn't arrive within a timeout, then the miner could switch
back to the old block.

This would mean that a few percent of empty blocks end up in the
blockchain, but that doesn't do any harm.

It is only harmful, if it is used as a DOS attack on the network.

The empty blocks will only occur when 2 blocks are found in quick
succession, so it doesn't have much affect on average time until 1
confirm.  Empty blocks are just as good for providing 1 of the 6 confirms
needed too.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Tree-chains preliminary summary

[Tier Nolan]

How does this system handle problems with the lower chains after they have
been "locked-in"?

The rule is that if a block in the child chain is pointed to by its parent,
then it effectively has infinite POW?

The point of the system is that a node monitoring the parent chain only has
to watch the header chain for its 2 children.

A parent block header could point to an invalid block in one of the child
chains.  That parent block could end up built on top of before the problem
was discovered.

This would mean that a child chain problem could cause a roll-back of a
parent chain.  This violates the principle that parents are dominant over
child chains.

Alternatively, the child chain could discard the infinite POW blocks, since
they are illegal.

P1 -> C1
P2 -> ---
P3 -> C3
P4 -> C5

It turns out C4 (or C5) was an invalid block

P5 -> C4'
P6 -> ---
P7 -> C8'

This is a valid sequence.  Once P7 points at C8, the alternative chain
displaces C5.

This displacement could require a compact fraud proof to show that C4 was
an illegal block and that C5 was built on it.

This shouldn't happen if the miner was actually watching the log(N) chains,
but can't be guaranteed against.

I wonder if the proof of stake "nothing is at stake" principle applies
here.  Miners aren't putting anything at stake by merge mining the lower
chains.

At minimum, they should get tx-fees for the lower chains that they merge
mine.  The rule could require that the minting reward is divided over the
merge mined chains.
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Chain pruning

[Tier Nolan]

On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille wrote:

> If you trust hashrate for determining which UTXO set is valid, a 51%
> attack becomes worse in that you can be made to believe a version of
> history which is in fact invalid.
>

If there are invalidation proofs, then this isn't strictly true.

If you are connected to 10 nodes and only 1 is honest, it can send you the
proof that your main chain is invalid.

For bad scripts, it shows you the input transaction for the invalid input
along with the merkle path to prove it is in a previous block.

For double spends, it could show the transaction which spent the output.

Double spends are pretty much the same as trying to spend non-existent
outputs anyway.

If the UTXO set commit was actually a merkle tree, then all updates could
be included.

Blocks could have extra data with the proofs that the UTXO set is being
updated correctly.

To update the UTXO set, you need the paths for all spent inputs.

It puts a large load on miners to keep things working, since they have to
run a full node.

If they commit the data to the chain, then SPV nodes can do local checking.

One of them will find invalid blocks eventually (even if one of the other
miners don't).

>
> --
> Pieter
>
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

[Tier Nolan]

Error correction is an interesting suggestion.

If there was 1 nodes and each stored 0.1% of the blocks, at random,
then the odds of a block not being stored is 45 in a million.

Blocks are stored on average 10 times, so there is already reasonable
redundancy.

With 1 million blocks, 45 would be lost in that case, even though most are
stored multiple times.

With error correction codes, the chances of blocks going missing is much
lower.

For example, if there was 32 out of 34 Reed-Solomon-like system, then 2
blocks out of 34 could be lost without any actual data loss for the network.

As a back of the envelop check, the odds of 2 missing blocks landing within
34 of another is 68/100.  That means that the odds of 2 missing blocks
falling in the same correction section is 45 * 34 / 100 = 0.153%.  Even
in that case, the missing blocks could be reconstructed, as long as you
know that they are missing.

The error correction code has taken it from being a near certainty that
some blocks would be lost to less than 0.153%.

A simple error correction system would just take 32 blocks in sequence and
then compute 2 extra blocks.

The extra blocks would have to be the same length as the longest block in
the 32 being corrected.

The shorter blocks would be padded with zeroes so everything is the same
size.

For each byte position in the blocks you compute the polynomial that goes
through byte (x, data(x)), for x = 0 to 31.  This could be a finite field,
or just mod 257.

You can then compute the value for x=32 and x = 33.  Those are the values
for the 2 extra blocks.

If mod 257 is used, then only the 2 extra blocks have to deal with symbols
from 0 to 256.

If you have 32 of the 34 blocks, you can compute the polynomial and thus
generate the 32 actual blocks.

This could be achieved by a soft fork by having a commitment every 32
blocks in the coinbase.

It makes the header chain much longer though.

Longer sections are more efficient, but need more calculations to recover
everything.  You could also do interleaving to handle the case where entire
sections are missing.


On Thu, Apr 10, 2014 at 12:54 PM, Peter Todd  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 10 April 2014 07:50:55 GMT-04:00, Gregory Maxwell 
> wrote:
> >(Just be glad I'm not suggesting coding the entire blockchain with an
> >error correcting code so that it doesn't matter which subset you're
> >holding)
>
> I forgot to ask last night: if you do that, can you add new blocks to the
> chain with the encoding incrementally?
> -BEGIN PGP SIGNATURE-
> Version: APG v1.1.1
>
> iQFQBAEBCgA6BQJTRoZ+MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYudCAC7ImifMnLIFHv1UifV
> zRxtDkx7UxIf9dncDAcrTIyKEDhoouh0TmoZl3HKQ3KUEETAVKsMzqXLgqVe6Ezr
> ny1bm0pQlkBCZFRwuZvmB27Y3mwC8PD6rT9ywtWzFjWd8PEg6/UaM547nQPw7ir0
> 27S3XMfE/BMiQWfWnWc/nqpbmJjd8x/dM3oiTG9SVZ7iNxotxAqfnW2X5tkhJb0q
> dAV08wpu6aZ5hTyLpvDxXDFjEG119HJeLkT9QVIrg+GBG55PYORqE4gQr6uhrF4L
> fGZS2EIlbk+kAiv0EjglQfxWM7KSRegplSASiKEOuX80tqLIsEugNh1em8qvG401
> NOAS
> =CWql
> -END PGP SIGNATURE-
>
>
>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Tier Nolan]

On Mon, Apr 7, 2014 at 10:55 PM, Paul Lyon  wrote:

>  I actually ask for headers from each peer I'm connected to and then dump
> them into the backend to be sorted out.. is this abusive to the network?
>

I think downloading from a subset of the peers and switching out any slow
ones is a reasonable compromise.

Once you have a chain, you can quickly check that all peers have the same
main chain.

Your backend system could have a method that gives you the hash of the last
10 headers on the longest chain it knows about.  You can use the block
locator hash system.

This can be used with the getheaders message and if the new peer is on a
different chain, then it will just send you the headers starting at the
genesis block.

If that happens, you need to download the entire chain from that peer and
see if it is better than your current best.


*From:* Tier Nolan 
*Sent:* Monday, April 07, 2014 6:48 PM
*To:* bitcoin-development@lists.sourceforge.net


On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer  wrote:

> You have to load headers sequantially to be able to connect them and
> determine the longest chain.
>

The isn't strictly true.  If you are connected to a some honest nodes, then
you could download portions of the chain and then connect the various
sub-chains together.

The protocol doesn't support it though.  There is no system to ask for
block headers for the main chain block with a given height,

Finding one high bandwidth peer to download the entire header chain
sequentially is pretty much forced.  The client can switch if there is a
timeout.

Other peers could be used to parallel download the block chain while the
main chain is downloading.  Even if the header download stalled, it
wouldn't be that big a deal.

> Blocks can be loaded in random order once you have their order given by
the headers.
> Computing the UTXO however will force you to at least temporarily store
the blocks unless you have plenty of RAM.

You only need to store the UTXO set, rather than the entire block chain.

It is possible to generate the UTXO set without doing any signature
verification.

A lightweight node could just verify the UTXO set and then do random
signature verifications.

The keeps disk space and CPU reasonably low.  If an illegal transaction is
added to be a block, then proof could be provided for the bad transaction.

The only slightly difficult thing is confirming inflation.  That can be
checked on a block by block basis when downloading the entire block chain.

> Regards,
> Tamas Blummer
> http://bitsofproof.com <http://bitsofproof.com>

On 07.04.2014, at 21:30, Paul Lyon  wrote:

I hope I'm not thread-jacking here, apologies if so, but that's the
approach I've taken with the node I'm working on.

Headers can be downloaded and stored in any order, it'll make sense of what
the winning chain is. Blocks don't need to be downloaded in any particular
order and they don't need to be saved to disk, the UTXO is fully
self-contained. That way the concern of storing blocks for seeding (or not)
is wholly separated from syncing the UTXO. This allows me to do the initial
blockchain sync in ~6 hours when I use my SSD. I only need enough disk
space to store the UTXO, and then whatever amount of block data the user
would want to store for the health of the network.

This project is a bitcoin learning exercise for me, so I can only hope I
don't have any critical design flaws in there. :)

--
From: ta...@bitsofproof.com
Date: Mon, 7 Apr 2014 21:20:31 +0200
To: gmaxw...@gmail.com
CC: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?


Once headers are loaded first there is no reason for sequential loading.

Validation has to be sequantial, but that step can be deferred until the
blocks before a point are loaded and continous.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:03, Gregory Maxwell  wrote:

On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer 
wrote:

therefore I guess it is more handy to return some bitmap of pruned/full
blocks than ranges.


A bitmap also means high overhead and-- if it's used to advertise
non-contiguous blocks-- poor locality, since blocks are fetched
sequentially.



--
Put Bad Developers to Shame Dominate Development with Jenkins Continuous
Integration Continuously Automate Build, Test & Deployment Start a new
project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees

___ Bitcoin-development mailing
list Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Con

Re: [Bitcoin-development] Why are we bleeding nodes?

[Tier Nolan]

On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer  wrote:

> You have to load headers sequantially to be able to connect them and
> determine the longest chain.
>

The isn't strictly true.  If you are connected to a some honest nodes, then
you could download portions of the chain and then connect the various
sub-chains together.

The protocol doesn't support it though.  There is no system to ask for
block headers for the main chain block with a given height,

Finding one high bandwidth peer to download the entire header chain
sequentially is pretty much forced.  The client can switch if there is a
timeout.

Other peers could be used to parallel download the block chain while the
main chain is downloading.  Even if the header download stalled, it
wouldn't be that big a deal.

> Blocks can be loaded in random order once you have their order given by
the headers.
> Computing the UTXO however will force you to at least temporarily store
the blocks unless you have plenty of RAM.

You only need to store the UTXO set, rather than the entire block chain.

It is possible to generate the UTXO set without doing any signature
verification.

A lightweight node could just verify the UTXO set and then do random
signature verifications.

The keeps disk space and CPU reasonably low.  If an illegal transaction is
added to be a block, then proof could be provided for the bad transaction.

The only slightly difficult thing is confirming inflation.  That can be
checked on a block by block basis when downloading the entire block chain.

> Regards,
> Tamas Blummer
> http://bitsofproof.com 

On 07.04.2014, at 21:30, Paul Lyon  wrote:

I hope I'm not thread-jacking here, apologies if so, but that's the
approach I've taken with the node I'm working on.

Headers can be downloaded and stored in any order, it'll make sense of what
the winning chain is. Blocks don't need to be downloaded in any particular
order and they don't need to be saved to disk, the UTXO is fully
self-contained. That way the concern of storing blocks for seeding (or not)
is wholly separated from syncing the UTXO. This allows me to do the initial
blockchain sync in ~6 hours when I use my SSD. I only need enough disk
space to store the UTXO, and then whatever amount of block data the user
would want to store for the health of the network.

This project is a bitcoin learning exercise for me, so I can only hope I
don't have any critical design flaws in there. :)

--
From: ta...@bitsofproof.com
Date: Mon, 7 Apr 2014 21:20:31 +0200
To: gmaxw...@gmail.com
CC: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?


Once headers are loaded first there is no reason for sequential loading.

Validation has to be sequantial, but that step can be deferred until the
blocks before a point are loaded and continous.

Tamas Blummer
http://bitsofproof.com

On 07.04.2014, at 21:03, Gregory Maxwell  wrote:

On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer 
wrote:

therefore I guess it is more handy to return some bitmap of pruned/full
blocks than ranges.


A bitmap also means high overhead and-- if it's used to advertise
non-contiguous blocks-- poor locality, since blocks are fetched
sequentially.



--
Put Bad Developers to Shame Dominate Development with Jenkins Continuous
Integration Continuously Automate Build, Test & Deployment Start a new
project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees

___ Bitcoin-development mailing
list Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



>
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Tier Nolan]

On Mon, Apr 7, 2014 at 8:03 PM, Gregory Maxwell  wrote:

> A bitmap also means high overhead and-- if it's used to advertise
> non-contiguous blocks-- poor locality, since blocks are fetched
> sequentially.
>

A range seems like a great compromise.  Putting it in the address is also a
pretty cool.

If light nodes selected a random contiguous 1GB of the block-chain, then
they could handle most of the download overhead, rather than the full nodes.

Another way to do it would be to have something like a routing table.  If a
node is queried for a block, it can reply with the IP of a node with that
block instead of sending the block.

One problem is that it means that light nodes have to accept incoming
connections.  Otherwise, it would have to be routed through the network.
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Malleability and MtGox's announcement

[Tier Nolan]

On Mon, Feb 10, 2014 at 7:47 PM, Oliver Egginger  wrote:

> As I understand this attack someone renames the transaction ID before
> being confirmed in the blockchain. Not easy but if he is fast enough it
> should be possible. With a bit of luck for the attacker the new
> transaction is added to the block chain and the original transaction is
> discarded as double-spend. Right?
>

No, the problem was that the transaction MtGox produced was poorly
formatted.

It wouldn't cause a block containing the transaction to be rejected, but
the default client wouldn't relay the transaction or add it into a block.

This means that transaction stalls.

If the attacker has a direct connection to MtGox, they can receive the
transaction directly.

The attacker would fix the formatting (which changes the transaction id,
but doesn't change the signature) and then forward it to the network, as
normal.

The old transaction never propagates correctly.

Up to this point the attacker has nothing gained. But next the attacker
> stressed the Gox support and refers to the original transaction ID. Gox
> was then probably fooled in such cases and has refunded already paid
> Bitcoins to the attackers (virtual) Gox-wallet.
>

They sent out the transaction a second time.

The right solution is that the new transaction should re-spend at least one
of the coins that the first transaction spent.  That way only one can
possibly be accepted.
--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] An idea for alternative payment scheme

[Tier Nolan]

The random number that the buyer uses could be generated from a root key
too.

This would allow them to regenerate all random numbers that they used and
recreate their receipts.  The master root would have to be stored on your
computer though.

The payment protocol is supposed to do something like this already though.


On Fri, Jan 3, 2014 at 6:00 PM, Nadav Ivgi  wrote:

> I had an idea for a payment scheme that uses key derivation, but instead
> of the payee deriving the addresses, the payer would do it.
>
> It would work like that:
>
>1. The payee publishes his master public key
>2. The payer generates a random "receipt number" (say, 25 random bytes)
>3. The payer derives an address from the master public key using the
>receipt number and pays to it
>4. The payer sends the receipt to the payee
>5. The payee derives a private key with that receipt and adds it to
>his wallet
>
>
> Advantages:
>
>- It increases privacy by avoiding address reuse
>- The process is asynchronous. The payee is completely passive in the
>payment process and isn't required to provide new addresses before each
>payment (so no payment server required)
>- Its usable as a replacement for cases where re-used addresses are
>the most viable solution (like putting an address in a forum signature or
>as a development fund in a github readme)
>- The receipt also acts as a proof of payment that the payer can
>provide to the payee
>- Also, if the master is known to belong to someone, this also allows
>the payer prove to a third-party that the payment was made to that someone.
>If the output was spent, it also proves that he was aware of the payment
>and has the receipt.
>- Its a really thin abstraction layer that doesn't require much changes
>
> Disadvantages:
>
>- Losing the receipt numbers means losing access to your funds, they
>are random and there's no way to restore them
>- It requires sending the receipt to the payee somehow. Email could
>work for that, but a better defined channel that also can talk to the
>Bitcoin client and add the receipt would be much better.
>
> What do you think?
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Tier Nolan]

On Fri, Jan 3, 2014 at 9:59 AM, Drak  wrote:

> Which is why, as pointed out several times at 30c3 by several renowned
> figures, why cryptography has remained squarely outside of mainstream use.
> It needs to just work and until you can trust the connection and what the
> end point sends you, automatically, it's a big fail and the attack vectors
> are many.
>
> I can just see my mother or grandma manually checking the hash of
> a download... 
>

Maybe a simple compromise would be to add a secure downloader to the
bitcoin client.

The download link could point to a meta-data file that has info on the
download.

file_url=
hash_url=
sig_url=
message=This is version x.y.z of the bitcoin client

It still suffers from the root CA problem though.  The bitcoin client would
accept Gavin's signature or a "core team" signature.

At least it would provide forward security.

It could also be used to download files for different projects, with
explicit warnings that you are adding a new trusted key.

When you try to download, you would be given a window

Project: Some Alternative Wallet
Signed by: P. Lead
Message:

Confirm download Yes No

However, even if you do that, each trusted key is only linked to a
particular project.

It would say if the project and/or leader is unknown.
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Peer Discovery and Overlay

[Tier Nolan]

On Tue, Dec 24, 2013 at 8:52 AM, Jeremy Spilman  wrote:

> Are there any past instances of applications hijacking or interfacing with
> the exiting p2p messages, or abusing 'getaddr' functionality? Are there
> any guidelines on this, or should there be?
>
>
There was a BIP by Stefan Thomas for adding custom services to the
protocol.  Discovery would be helpful here too.  If this was added, it
wouldn't be intended for use in a hostile way though.

This one was the custom services BIP.  It defines a change to the version
message and also custom sub-commands.
https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki

This one discusses how network discovery should be handles.
https://en.bitcoin.it/wiki/User:Justmoon/BIP_Draft:_Custom_Service_Discovery
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network

[Tier Nolan]

On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo wrote:

> Relay node details:
>  * The relay nodes do some data verification to prevent DoS, but in
> order to keep relay fast, they do not fully verify the data they are
> relaying, thus YOU SHOULD NEVER mine a block building on top of a
> relayed block without fully checking it with your own bitcoin validator
> (as you would any other block relayed from the P2P network).
>

Wouldn't this cause disconnects due to misbehavior?

A standard node connecting to a relay node would receive
blocks/transactions that are not valid in some way and then disconnect.

Have you looked though the official client to find what things are
considered signs that a peer is hostile?  I assume things like double
spending checks count as misbehavior and can't be quickly checked by a
relay node.

Maybe another bit could be assigned in the services field as "relay".  This
means that the node doesn't do any checking.

Connects to relay nodes could be command line/config file only.  Peers
wouldn't connect to them.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Distributing low POW headers

[Tier Nolan]

On Sun, Jul 28, 2013 at 7:42 PM, John Dillon
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, Jul 24, 2013 at 11:55 AM, Tier Nolan  wrote:
> > Distributing headers with 1/64 of the standard POW means that a header
> would
> > be broadcast approximately once every 9 seconds (assuming a 10 minute
> block
> > time).  This was picked because sending 80 byte headers every 9 seconds
> > shouldn't represent much load on the network.
>
> As Peter said, "much" should be quantified.
>

It has the same statistic properties as normal blocks just 64 times faster.

Even if there is a new block 30 seconds after the previous one, that
doesn't cause a burst of 64 low POW block headers in the 30 second window.
They are all statistically independent hashing attempts.


> Sounds like you are changing economics and requiring miners to have even
> better
> network connections. This is not a thing to do lightly and it probably a
> bad
> idea.
>

No, it just breaks ties.  In most cases there would be only 1 contender
block, so all miners are equal.

If 10% of blocks were ties/orphans, then only 1% of blocks would be a 3-way
tie.  That probably overestimates the orphan rate.

This means the miner has to download 2 blocks 10% of the time and 3 blocks
1% of the time.

However, even then, half the network wouldn't have to download the 2nd
block of the tie, since they happened to get the winner first.  This means
5% extra bandwidth on average.

16 low POW headers at 9 seconds per header is more than 2 minutes for a
miner to switch to the other contender.

A miner would only lose out if he doesn't notice that block he is mining
against is not getting built on by anyone else.

He needs to download both tied blocks so that he can switch, but he has 2
minutes to actually switch.

I understand Pieter Wuille is working on letting Bitcoin propagate and make
> use
> of pure block headers, a step towards SPV and partial UTXO mode.
>

That would need to happen before low POW ones are broadcast.  There is a
basic set of rules in the first post.

At the moment, the client only provides headers when asked, but never
broadcasts them.


> Orphan measurement would be very useful for a lot of reasons, how about you
> think about that first?


I think distributing the low POW headers on an advisory basis a reasonable
first step.  However, just broadcasting the headers is a zeroth step.

Miners would probably break ties towards the block that seems to be getting
the most hashing anyway.

I think for orphan rate, the best is to have a system to link to orphans.
This would add the POW of the orphan to the main chain's total.

Unfortunately adding fields to the header is hard.  It could be done as a
coinbase extra-nonce thing.  A better option would be if the merkle tree
could include non-transactions.

The merkle root could be replaced by hash(auxiliary header).  This has the
advantage of not impacting ASIC miners.

Broadcasting all headers would at least allow clients to count orphans,
even if they aren't integrated into the block chain.

It wouldn't have the potential data rate issues either
> and should be a very simple change.


I don't think the data rate is really that high.  It would be 80 bytes
every 9 seconds, or 9 bytes per second.

Blocks are 500kB every 10 minutes, or 853 bytes per second.


> Just set some threshold relative to the
> height of the best block where you will not further propagate and orphan
> block(header) and prior to that limit do so freely. I believe the change
> would
> be 100% compatible with the P2P protocol as it is based on inventories.
>

Right absolutely.  Headers of blocks that add to the block tree within
recent history should be forwarded.

The inv system would need to be tweaked, since it can only say block and
transaction.

A block header field would allow the node to say that it only has the
header.  Alternatively, it would reply with a header message to the
getblocks message.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Distributing low POW headers

[Tier Nolan]

On Wed, Jul 24, 2013 at 10:42 AM, Peter Todd  wrote:

> Please provide equations and data justifying the 'magic constants' in
> this proposal.
>

The are a range of workable values.  Ideally, there would first need to be
agreement on the general principle.

Distributing headers with 1/64 of the standard POW means that a header
would be broadcast approximately once every 9 seconds (assuming a 10 minute
block time).  This was picked because sending 80 byte headers every 9
seconds shouldn't represent much load on the network.

The second magic number is how much credit to give for mini-headers.
Setting it at 1/16 means that the headers will be worth around 4 times as
much as a block (since there would be around 63 low POW headers for each
full POW one).

This creates an incentive for miners to take headers into account.  If all
the headers were worth less than a full block, then a fork which was losing
would suddenly be winning if a block is found.  A fork will only become the
main chain due to a new block, if it is within 16 mini-confirms.

Miners don't have to mine against the absolute best fork, but they do need
to make sure they stay within 16 of the best one (so if they find a block,
that block would be considered part of the main chain).  Some hysteresis
might be helpful.  The rule could be to only switch unless the current fork
is losing by at least 4 mini-confirms.

In most cases, this won't be a problem, since orphans don't happen that
often anyway.

Since it isn't a chain, this doesn't give the full benefits of a 9 second
block, but it should bring things to consensus faster.  6 full confirms
would be much more secure against random and hostile reversals.

It doesn't have the risks of 9 second blocks in causing network collapse,
since it isn't a chain, the headers are short, and there is no
confirmations of the required (other than checking the hash).

Each "mini" confirms adds to the strength of leaf blocks of the tree.  If
there is a tie, and 20% of the network is mining one block and 80% is
mining the other, the mining power of the network will be split until the
next block arrives.

With mini confirms, the entire network is aware of the 2 blocks (since the
headers would be forwarded) and the mini-confirms would show which one has
majority hashing power.

The least risk option would be to make them purely advisory.  The proposal
takes it further than that.

The proposal means that if the network is split 80/20, then miners should
stick with the 80% fork, even if the 20% fork wins the race for the next
block.

Winning a few rounds is easier than wining many rounds worth of
mini-confirms.

The key is that as long as the honest miners stay on the main chain, they
will eventually overwhelm any rewrite attack with less than 50% of the
mining power.  This is a system to agree on what is the main chain in the
face of a re-write attack.


>
> Currently we do not relay blocks to peers if they conflict with blocks
> in the best known chain. What changes exactly are you proposing to that
> behavior?
>

The (sub) proposal is that headers would still be broadcast.  The blocks
would not be forwarded.

If a header extends the header tree, meets full POW and is "near" the end
of the chain, then it is broadcast.  This means that all nodes will have
the entire header tree, including orphans.

The full blocks would only be sent if they extend the main chain.

Second, if a header builds on a header that is in the header tree, then it
is broadcast, even if it doesn't meet full POW (only 1/64 required).  This
gives information on which fork is getting the most power.

It gives information about potential "consensus loss" forks, where a
significant number of miners are following an alternative chain.

In fact, this is probably worth doing as an initial step.

A warning could be displayed on the client if a fork is getting more than
15% of the hashing power.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Distributing low POW headers

[Tier Nolan]

I was thinking about a change to the rules for distinguishing between forks
and maybe a BIP..

*Summary*

- Low POW headers should be broadcast by the network

If a header has more than 1/64 of the POW of a block, it should be
broadcast.  This provides information on which fork is getting most of the
hashing power.

- Miners should use the header information to decide on longest chain

The fork selection rule for miners should be biased towards staying on the
fork that has the most hashing power.

This means that they might keep hashing on a fork that is 1-2 blocks
shorter.

If most miners follow the rule, then it is the best strategy for other
miners to also follow this rule.

- Advantages

This lowers the probability of natural and malicious reversals.

*Distributing low POW headers*

First block header messages that have more than 1/64 of the standard POW
requirements would be forwarded.

This means the client needs to maintain a short term view of the entire
header tree.

if (header extends header tree) {
  if (header meets full POW) {
add to header tree;
forward to peers;
check if any blocks in storage now extend the header tree
  } else {
if (header meets POW / 64) {
  forward to peers;
}
} else {
  if (header meets POW) {
add to orphan header storage
  }
}

The storage could be limited and headers could be discarded after a while.

This has the extra advantage that it informs clients of forks that are
receiving hashing power.

This could be linked to a protocol version to prevent disconnects due to
invalid header messages.

*Determining the longest chain*

Each link would get extra credit for headers received.

Assume there are 2 forks starting at block A as the fork point.

A(63) <- B(72) <- C(37) <- D(58)

and

A(63) <- B'(6) <- C'(9) <- D'(4) <- E(7) <- F(6)

The numbers in brackets are the number of low POW headers received that
have those blocks as parent.

The new rule is that the POW for a block is equal to

POW * (1 + (headers / 16))

Only headers within  of the end of the (shorter) chain
count.  However, in most cases, that doesn't matter since the fork point
will act as the start point.  As long as miners keep headers for 30-40
blocks, they will likely have all headers back to any reasonable fork point.

This means that the top fork is considered longer, since it has much more
headers, even though it has 2 less blocks.

If 75% of the miners follow this rule, then the top fork will eventually
catch up and win, so it is in the interests of the other 25% to follow the
rule too.

Even if there isn't complete agreement on headers received, the fork that
is getting the most hashing will naturally gain most of the headers, so
ties will be broken quickly.
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development