Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Rusty Russell via bitcoin-dev]

Rusty Russell via bitcoin-dev  writes:
>>From a practical perspective: yuck.  There's currently no way to play
> with bitcoind's perception of time, so that's a very long sleep to
> blackbox test (which is what my lightning test script does).
>
> So consider this YA feature request :)
 
... Gavin just told me about setmocktime.  That's fast service!

Thanks,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Rusty Russell via bitcoin-dev]

Btc Drak  writes:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed your
> concerns from the last meeting and he made the change. The BIP text still
> needs to be updated, but the discussed change was added to the PR, albeit
> squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with
> a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK
> and SEQUENCE_LOCKTIME_GRANULARITY in the PR
> https://github.com/bitcoin/bitcoin/pull/6312.

I like it from a technical perspective.

>From a practical perspective: yuck.  There's currently no way to play
with bitcoind's perception of time, so that's a very long sleep to
blackbox test (which is what my lightning test script does).

So consider this YA feature request :)

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello, and thanks for the reply.  I don't think you are missing
anything, I'll continue to observe this thread for further details and
developments on NG generally, security, & privacy.

Ittay:
> Hi Odinn,
> 
> I guess to answer we should separate pure-NG from the hypothetical
> overlay-NG that runs on top of Bitcoin. For pure NG one still has
> to set a transaction bandwidth limit due to bandwidth and storage
> limitations of the individual clients. This rate can be arbitrarily
> high with NG without compromising protocol security.
> 
> With overlay NG you cannot run above Bitcoin's bandwidth because
> all clients must agree on the ledger, so different clients cannot
> run at different rates. You could do two things: 1. Significantly
> reduce observed latency (time to first confirmation). Users get
> better confidence as more miners adopt NG. 2. Increase the
> bandwidth once everyone is on board.
> 
> As for privacy - I don't see why NG would change things. Such
> privacy schemes are only concerned with the transaction DAG. NG
> does not touch this structure. Am I missing something?
> 
> Thanks, Ittay
> 
> 
> On Thu, Oct 15, 2015 at 4:48 AM, odinn
>  wrote:
> 
> So, there could not be, for example, a user decision to activate
> it? (versus not activate it)?  I'm wondering if something about
> this can be boiled down to allowing the user to make a choice on
> the matter (turn it on and off).  In Bitcoin-NG, the protocol as
> follows (as described in a general overview of it): every 10
> minutes, NG elects a 'leader,' who then vets future transactions as
> soon as they happen. NG approach supposedly can run as fast as the
> network will allow.
> 
> If this is the case, and if NG functions without major hiccup, 
> shouldn't a user (of Core, for example) be able to be given the
> option to choose between:
> 
> (a) being limited by the blocksize and block interval, or (b)
> running out as fast as the network will allow (NG)?
> 
> The other questions I had pertained to privacy.  How would this
> scheme affect users who would be trying to do things like stealth
> or confidential transactions?
> 
> Matt Corallo:
 Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin 
 protocol one and should be discussed here, not on github. I
 really appreciate Ittay and Emin's efforts in this space and
 their willingness to work with the Bitcoin community on it!
 It seems it still needs some tuning, but seems like if the
 pool-mining issues were resolved it could make block relay
 times irrelevant, at least.
 
 Matt
 
 On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev 
  wrote: This
 (Bitcoin-NG in concept) could be done as a (issue and pull
 request process) to Bitcoin Core itself, amirite?  It seems
 like it would provide an interesting issue to open and have
 healthy discussion on both mailing list and github, adding
 the caveat that it would be at the user's option.  Thus if
 something like Bitcoin-NG did come to be it would be
 something more like a feature that the user could activate /
 deactivate from within Core.  I assume it would be default
 off, but with the option to utilize.  Code would thus be 
 available to others as well.  I am not saying yea or nay on
 it, just that it seems like this could be done.
 
 Some notes:
 
 Once a node generates a key block it becomes the leader.  As
 a leader, the node is allowed to generate  microblocks  at  a
 set rate smaller  than  a  prede >ned  maximum.  A
 microblock in Bitcoin-NG contains  ledger  entries  and  a
 header.   The  header contains the  reference  to the
 previous  block,  the  current GMT  time,  a cryptographic
 hash  of  its  ledger  entries,  and a cryptographic
 signature  of  the  header.   The  signature  uses the
 private  key that  matches  the public key in the latest key 
 block in the chain. For a microblock to be valid, all its
 entries must be valid according to the specification of the
 state machine, and the signature has to be valid.  However,
 the microblocks, it is said, don't affect the weight of the
 chain, because they do not contain proof of work.  It is
 assumed by the authors of this model that this situation is
 critical for maintaining incentives here.
 
 The questions that then begin to emerge to me are how is
 this information managed and protected?  The headers, thus
 containing reference(s) to previous block(s), current GMT
 time(s), cryptographic hash(es) of ledger entries, and
 cryptographic signature(s) of the headers, so forth, and
 other information.  Can the Bitcoin-NG scheme be designed or
 implemented in a manner which supports Stealth sends,
 Confidential Transactions, or similar privacy measures?  Or
 is this something which cannot be answered at this tim

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Mark Friedenbach via bitcoin-dev]

Adam, there is really no justification I can see to lower the interblock
interval on the Bitcoin blockchain, primarily due to the effects of network
latency. Lowering the interblock interval and raising the block size are
not equal alternatives - you can always get more throughput in bitcoin by
raising the block size than by lowering the interblock time. And that's
without considering the effect shorter intervals would have on e.g. SPV
client bandwidth or sidechain connectivity proofs. So I find it very
unlikely that such granularity would ever be needed on the Bitcoin block
chain, although if were to happen then extra bits from nSequence could be
used in a soft-fork compatible way.

However it is true that various sidechains such as Liquid will have a much
shorter interblock interval than 10min, as well as customer demand for
protocols with shorter timeouts. It would be nice if such systems did not
HAVE to resort to complex bit shifting to support more precision, and if
protocols written for bitcoin could be reused on such systems with minimal
or no modification.

To that end, it might be preferable to move the flag bit indicating use of
seconds from bit 16 to bit 23 and (by convention only) reserve bits 17..22
to provide higher granularity in a sidechain environment. This keeps the
size of a stack push to 3 bytes while also keeping sufficient room for
high-order bits of relative lock-time in a sidechain that supports shorter
block intervals.

Another alternative is to put the units flag in the least significant bit,
which has the advantage of allowing both units of lock-time to make use of
1-2 byte pushes, but the disadvantage of making lock times of 64..127
2-bytes instead of 1-byte.

Thoughts?

On Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Does that pre-judge that block interval would never change from
> 10mins?  Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
>  wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> > /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> >  * applied to extract that lock-time from the sequence field. */
> > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x;
> >
> > /* In order to use the same number of bits to encode roughly the
> >  * same wall-clock duration, and because blocks are naturally
> >  * limited to occur every 600s on average, the minimum granularity
> >  * for time-based relative lock-time is fixed at 512 seconds.
> >  * Converting from CTxIn::nSequence to seconds is performed by
> >  * multiplying by 512 = 2^9, or equivalently shifting up by
> >  * 9 bits. */
> > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> >  wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >>  wrote:
> >>>
> >>> Peter Todd  writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev 
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> 

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Alex Morcos via bitcoin-dev]

Adam,

The remaining 14 bits can be used to soft fork in finer granularity in the
future.

Alex


On Thu, Oct 15, 2015 at 12:37 PM, Adam Back  wrote:

> Does that pre-judge that block interval would never change from
> 10mins?  Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
>  wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> > /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> >  * applied to extract that lock-time from the sequence field. */
> > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x;
> >
> > /* In order to use the same number of bits to encode roughly the
> >  * same wall-clock duration, and because blocks are naturally
> >  * limited to occur every 600s on average, the minimum granularity
> >  * for time-based relative lock-time is fixed at 512 seconds.
> >  * Converting from CTxIn::nSequence to seconds is performed by
> >  * multiplying by 512 = 2^9, or equivalently shifting up by
> >  * 9 bits. */
> > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> >  wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >>  wrote:
> >>>
> >>> Peter Todd  writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev 
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> >>> >> > implement this feature via nSequence.
> >>> >>
> >>> >> It could be implemented in other ways, but nSequence is the neatest
> >>> >> and
> >>> >> most straightforward I've seen.
> >>> >>
> >>> >> - I'm not aware of any other (even vague) proposal for its use?
> >>> >> Enlighten?
> >>> >
> >>> > There's three that immediately come to mind:
> >>> >
> >>> > Gregory Maxwell has proposed it as a way of discouraging miners from
> >>> > reorging chains, by including some of the low-order bits of a
> previous
> >>> > block header in nSequence.
> >>> >
> >>> > A few people have proposed implementing proof-of-stake blocksize
> voting
> >>> > with nSequence.
> >>>
> >>> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
> >>> voting seems like it won't be a problem in 5 bits.
> >>>
> >>> The "prevbits" idea would want more bits; naively 64 would be good, but
> >>> I think there are some tricks we can use to make 32 work OK.  We would
> >>> have to then split between nLocktime (if available) and multiple
> >>> nSequence fields, and it would weaken it for some txs.
> >>>
> >>> There is one easy solution: change the BIP wording from:
> >>>
> >>> -For transactions with an nVersion of 2 or greater,
> >>> +For transactions with an nVersion of 2,
> >>>
> >>> And on every tx bump, we decide whether to keep this scheme (mempool
> >>> would enforce it always).
> >>>
> >>> Cheers,
> >>> Rusty.
> >>> ___
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >>
> >> __

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Adam Back via bitcoin-dev]

Does that pre-judge that block interval would never change from
10mins?  Eg say with IBLT or fountain codes etc and security arguments
for the current limitations of them are found, such that orphan rates
can remain low in a decentralised way with 1min blocks, then the
locktime granularity would be coarse relative to the block interval
(with 512s locktime granularity.

Adam

On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
 wrote:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed your
> concerns from the last meeting and he made the change. The BIP text still
> needs to be updated, but the discussed change was added to the PR, albeit
> squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with
> a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> SEQUENCE_LOCKTIME_GRANULARITY in the PR
> https://github.com/bitcoin/bitcoin/pull/6312.
>
> /* If CTxIn::nSequence encodes a relative lock-time, this mask is
>  * applied to extract that lock-time from the sequence field. */
> static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x;
>
> /* In order to use the same number of bits to encode roughly the
>  * same wall-clock duration, and because blocks are naturally
>  * limited to occur every 600s on average, the minimum granularity
>  * for time-based relative lock-time is fixed at 512 seconds.
>  * Converting from CTxIn::nSequence to seconds is performed by
>  * multiplying by 512 = 2^9, or equivalently shifting up by
>  * 9 bits. */
> static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
>
> I am also much happier with this last tightening up of the specification
> because it removes ambiguity. 512s granularity makes sense within the
> context of the 10 minute block target.
>
> Thank you for spending so much time carefully considering this BIP and
> reference implementation and please let me know if there there are any
> remaining nits so we can get those addressed.
>
>
>
>
>
> On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
>  wrote:
>>
>> Mark,
>>
>> You seemed interested in changing BIP 68 to use 16 bits for sequence
>> number in both the block and time versions, making time based sequence
>> numbers have a resolution of 512 seconds.
>>
>> I'm in favor of this approach because it leaves aside 14 bits for further
>> soft forks within the semantics of BIP 68.
>>
>> It would be nice to know if you're planning this change, and perhaps
>> people can hold off on review until things are finalized.
>>
>> I'd cast my "vote" against BIP 68 without this change, but am also open to
>> being convinced otherwise.
>>
>> What are other peoples opinions on this?
>>
>> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
>>  wrote:
>>>
>>> Peter Todd  writes:
>>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>>> >> Peter Todd via bitcoin-dev 
>>> >> writes:
>>> >> > However I don't think we've done a good job showing why we need to
>>> >> > implement this feature via nSequence.
>>> >>
>>> >> It could be implemented in other ways, but nSequence is the neatest
>>> >> and
>>> >> most straightforward I've seen.
>>> >>
>>> >> - I'm not aware of any other (even vague) proposal for its use?
>>> >> Enlighten?
>>> >
>>> > There's three that immediately come to mind:
>>> >
>>> > Gregory Maxwell has proposed it as a way of discouraging miners from
>>> > reorging chains, by including some of the low-order bits of a previous
>>> > block header in nSequence.
>>> >
>>> > A few people have proposed implementing proof-of-stake blocksize voting
>>> > with nSequence.
>>>
>>> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
>>> voting seems like it won't be a problem in 5 bits.
>>>
>>> The "prevbits" idea would want more bits; naively 64 would be good, but
>>> I think there are some tricks we can use to make 32 work OK.  We would
>>> have to then split between nLocktime (if available) and multiple
>>> nSequence fields, and it would weaken it for some txs.
>>>
>>> There is one easy solution: change the BIP wording from:
>>>
>>> -For transactions with an nVersion of 2 or greater,
>>> +For transactions with an nVersion of 2,
>>>
>>> And on every tx bump, we decide whether to keep this scheme (mempool
>>> would enforce it always).
>>>
>>> Cheers,
>>> Rusty.
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Btc Drak via bitcoin-dev]

Alex,

I am sorry for not communicating more clearly. Mark and I discussed your
concerns from the last meeting and he made the change. The BIP text still
needs to be updated, but the discussed change was added to the PR, albeit
squashed making it more non-obvious. BIP68 now explicitly uses 16 bits with
a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK
and SEQUENCE_LOCKTIME_GRANULARITY in the PR
https://github.com/bitcoin/bitcoin/pull/6312.

/* If CTxIn::nSequence encodes a relative lock-time, this mask is
 * applied to extract that lock-time from the sequence field. */
static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x;

/* In order to use the same number of bits to encode roughly the
 * same wall-clock duration, and because blocks are naturally
 * limited to occur every 600s on average, the minimum granularity
 * for time-based relative lock-time is fixed at 512 seconds.
 * Converting from CTxIn::nSequence to seconds is performed by
 * multiplying by 512 = 2^9, or equivalently shifting up by
 * 9 bits. */
static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;

I am also much happier with this last tightening up of the specification
because it removes ambiguity. 512s granularity makes sense within the
context of the 10 minute block target.

Thank you for spending so much time carefully considering this BIP and
reference implementation and please let me know if there there are any
remaining nits so we can get those addressed.





On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Mark,
>
> You seemed interested in changing BIP 68 to use 16 bits for sequence
> number in both the block and time versions, making time based sequence
> numbers have a resolution of 512 seconds.
>
> I'm in favor of this approach because it leaves aside 14 bits for further
> soft forks within the semantics of BIP 68.
>
> It would be nice to know if you're planning this change, and perhaps
> people can hold off on review until things are finalized.
>
> I'd cast my "vote" against BIP 68 without this change, but am also open to
> being convinced otherwise.
>
> What are other peoples opinions on this?
>
> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Peter Todd  writes:
>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
>> >> Peter Todd via bitcoin-dev 
>> >> writes:
>> >> > However I don't think we've done a good job showing why we need to
>> >> > implement this feature via nSequence.
>> >>
>> >> It could be implemented in other ways, but nSequence is the neatest and
>> >> most straightforward I've seen.
>> >>
>> >> - I'm not aware of any other (even vague) proposal for its use?
>> Enlighten?
>> >
>> > There's three that immediately come to mind:
>> >
>> > Gregory Maxwell has proposed it as a way of discouraging miners from
>> > reorging chains, by including some of the low-order bits of a previous
>> > block header in nSequence.
>> >
>> > A few people have proposed implementing proof-of-stake blocksize voting
>> > with nSequence.
>>
>> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
>> voting seems like it won't be a problem in 5 bits.
>>
>> The "prevbits" idea would want more bits; naively 64 would be good, but
>> I think there are some tricks we can use to make 32 work OK.  We would
>> have to then split between nLocktime (if available) and multiple
>> nSequence fields, and it would weaken it for some txs.
>>
>> There is one easy solution: change the BIP wording from:
>>
>> -For transactions with an nVersion of 2 or greater,
>> +For transactions with an nVersion of 2,
>>
>> And on every tx bump, we decide whether to keep this scheme (mempool
>> would enforce it always).
>>
>> Cheers,
>> Rusty.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[Ittay via bitcoin-dev]

Hi Odinn,

I guess to answer we should separate pure-NG from
the hypothetical overlay-NG that runs on top of Bitcoin.
For pure NG one still has to set a transaction bandwidth
limit due to bandwidth and storage limitations of
the individual clients. This rate can be arbitrarily high
with NG without compromising protocol security.

With overlay NG you cannot run above Bitcoin's
bandwidth because all clients must agree on the ledger,
so different clients cannot run at different rates. You
could do two things:
1. Significantly reduce observed latency (time to first
confirmation). Users get better confidence as more
miners adopt NG.
2. Increase the bandwidth once everyone is on
board.

As for privacy - I don't see why NG would change things.
Such privacy schemes are only concerned with the
transaction DAG. NG does not touch this structure. Am
I missing something?

Thanks,
Ittay


On Thu, Oct 15, 2015 at 4:48 AM, odinn 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> So, there could not be, for example, a user decision to activate it?
> (versus not activate it)?  I'm wondering if something about this can
> be boiled down to allowing the user to make a choice on the matter
> (turn it on and off).  In Bitcoin-NG, the protocol as follows (as
> described in a general overview of it): every 10 minutes, NG elects a
> 'leader,' who then vets future transactions as soon as they happen. NG
> approach supposedly can run as fast as the network will allow.
>
> If this is the case, and if NG functions without major hiccup,
> shouldn't a user (of Core, for example) be able to be given the option
> to choose between:
>
> (a) being limited by the blocksize and block interval, or
> (b) running out as fast as the network will allow (NG)?
>
> The other questions I had pertained to privacy.  How would this scheme
> affect users who would be trying to do things like stealth or
> confidential transactions?
>
> Matt Corallo:
> > Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin
> > protocol one and should be discussed here, not on github. I really
> > appreciate Ittay and Emin's efforts in this space and their
> > willingness to work with the Bitcoin community on it! It seems it
> > still needs some tuning, but seems like if the pool-mining issues
> > were resolved it could make block relay times irrelevant, at
> > least.
> >
> > Matt
> >
> > On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev
> >  wrote: This (Bitcoin-NG in
> > concept) could be done as a (issue and pull request process) to
> > Bitcoin Core itself, amirite?  It seems like it would provide an
> > interesting issue to open and have healthy discussion on both
> > mailing list and github, adding the caveat that it would be at the
> > user's option.  Thus if something like Bitcoin-NG did come to be it
> > would be something more like a feature that the user could
> > activate / deactivate from within Core.  I assume it would be
> > default off, but with the option to utilize.  Code would thus be
> > available to others as well.  I am not saying yea or nay on it,
> > just that it seems like this could be done.
> >
> > Some notes:
> >
> > Once a node generates a key block it becomes the leader.  As a
> > leader, the node is allowed to generate  microblocks  at  a  set
> > rate smaller  than  a  prede >ned  maximum.  A  microblock in
> > Bitcoin-NG contains  ledger  entries  and  a  header.   The  header
> > contains the  reference  to the  previous  block,  the  current
> > GMT  time,  a cryptographic  hash  of  its  ledger  entries,  and
> > a cryptographic signature  of  the  header.   The  signature  uses
> > the  private  key that  matches  the public key in the latest key
> > block in the chain. For a microblock to be valid, all its entries
> > must be valid according to the specification of the state machine,
> > and the signature has to be valid.  However, the microblocks, it is
> > said, don't affect the weight of the chain, because they do not
> > contain proof of work.  It is assumed by the authors of this model
> > that this situation is critical for maintaining incentives here.
> >
> > The questions that then begin to emerge to me are how is this
> > information managed and protected?  The headers, thus containing
> > reference(s) to previous block(s), current GMT time(s),
> > cryptographic hash(es) of ledger entries, and cryptographic
> > signature(s) of the headers, so forth, and other information.  Can
> > the Bitcoin-NG scheme be designed or implemented in a manner which
> > supports Stealth sends, Confidential Transactions, or similar
> > privacy measures?  Or is this something which cannot be answered at
> > this time?
> >
> > Emin Gün Sirer via bitcoin-dev:
> > So it seems to me that all I need to do is figure out who
> > the current
>  leader is,
> > and DDoS him off the network to shut Bitcoin-NG down.
> 
>  Good point. If NG is layered on top of Bitcoin, we'd retain
>  all of Bitcoin as is. T

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[Ittay via bitcoin-dev]

Thanks, Matt. Response inline.

On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo 
wrote:

> That conversation missed a second issue. Namely that there is no way to
> punish people if there is a double spend in a micro block that happens in
> key block which reorg'd away the first transaction. eg one miner mines a
> transaction in a micro block, another miner (either by not having seen the
> first yet, or being malicious - potentially the same miner) mines a key
> block which reorgs away the first micro block and then, in their first
> micro block, mines a double spend. This can happen at any time, so you end
> up having to fall back to regular full blocks for confirmation times :(.
>

If NG is to be used efficiently, microblocks are going to be very frequent,
and so such forks should occur at almost every key-block publication. Short
reorgs as you described are the norm. A user should wait before accepting a
transaction to make sure there was no key-block she missed. The wait time
is chosen according to the network propagation delay (+as much slack as the
user feels necessary). This is similar to the situation in Bitcoin when you
receive a block. To be confident that you have one confirmation you should
wait for the propagation time of the network to make sure there is no
branch you missed.

As for the malicious case: the attacker has to win the key-block, have the
to-be-inverted transaction in the previous epoch, and withhold his
key-block for a while. That being said, indeed our fraud proof scheme
doesn't catch such an event, as it is indistinguishable from benign
behavior.


> Also, Greg Slepak brought up a good point on twitter at
> https://twitter.com/taoeffect/status/654358023138209792. Noting that this
> model means users could no longer pick transactions in a mining pool which
> was set up in such a way (it could be tweaked to do so with separate
> rewards and pubkeys, but now the user can commit fraud at a much lower cost
> - their own pool reward, not the block's total reward).
>

Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
Do you perceive this as a significant practical issue?


>
> On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop  wrote:
>>
>>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>>>  wrote:
>>> > while the whitepaper has all the nitty gritty details:
>>> >  http://arxiv.org/abs/1510.02037
>>>
>>> Taking reward compensation back by fraud proofs is not enough to fix
>>> the problems associated with double spending (such as, everyone has to
>>> wait for the "real" confirmations instead of the "possibly
>>> double-spend" confirmations). Some of this was discussed in -wizards
>>> recently:
>>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>>
>>
>> Fraud proof removes all the attacker's revenue. It's like the attacker
>> sacrifices an entire block for double spending in the current system. I
>> think Luke-Jr got it right at that discussion.
>>
>> Best,
>> Ittay
>>
>> --
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

[Alex Morcos via bitcoin-dev]

Mark,

You seemed interested in changing BIP 68 to use 16 bits for sequence number
in both the block and time versions, making time based sequence numbers
have a resolution of 512 seconds.

I'm in favor of this approach because it leaves aside 14 bits for further
soft forks within the semantics of BIP 68.

It would be nice to know if you're planning this change, and perhaps people
can hold off on review until things are finalized.

I'd cast my "vote" against BIP 68 without this change, but am also open to
being convinced otherwise.

What are other peoples opinions on this?

On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Peter Todd  writes:
> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >> Peter Todd via bitcoin-dev 
> >> writes:
> >> > However I don't think we've done a good job showing why we need to
> >> > implement this feature via nSequence.
> >>
> >> It could be implemented in other ways, but nSequence is the neatest and
> >> most straightforward I've seen.
> >>
> >> - I'm not aware of any other (even vague) proposal for its use?
> Enlighten?
> >
> > There's three that immediately come to mind:
> >
> > Gregory Maxwell has proposed it as a way of discouraging miners from
> > reorging chains, by including some of the low-order bits of a previous
> > block header in nSequence.
> >
> > A few people have proposed implementing proof-of-stake blocksize voting
> > with nSequence.
>
> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
> voting seems like it won't be a problem in 5 bits.
>
> The "prevbits" idea would want more bits; naively 64 would be good, but
> I think there are some tricks we can use to make 32 work OK.  We would
> have to then split between nLocktime (if available) and multiple
> nSequence fields, and it would weaken it for some txs.
>
> There is one easy solution: change the BIP wording from:
>
> -For transactions with an nVersion of 2 or greater,
> +For transactions with an nVersion of 2,
>
> And on every tx bump, we decide whether to keep this scheme (mempool
> would enforce it always).
>
> Cheers,
> Rusty.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So, there could not be, for example, a user decision to activate it?
(versus not activate it)?  I'm wondering if something about this can
be boiled down to allowing the user to make a choice on the matter
(turn it on and off).  In Bitcoin-NG, the protocol as follows (as
described in a general overview of it): every 10 minutes, NG elects a
'leader,' who then vets future transactions as soon as they happen. NG
approach supposedly can run as fast as the network will allow.

If this is the case, and if NG functions without major hiccup,
shouldn't a user (of Core, for example) be able to be given the option
to choose between:

(a) being limited by the blocksize and block interval, or
(b) running out as fast as the network will allow (NG)?

The other questions I had pertained to privacy.  How would this scheme
affect users who would be trying to do things like stealth or
confidential transactions?

Matt Corallo:
> Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin
> protocol one and should be discussed here, not on github. I really
> appreciate Ittay and Emin's efforts in this space and their
> willingness to work with the Bitcoin community on it! It seems it
> still needs some tuning, but seems like if the pool-mining issues
> were resolved it could make block relay times irrelevant, at
> least.
> 
> Matt
> 
> On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev
>  wrote: This (Bitcoin-NG in
> concept) could be done as a (issue and pull request process) to
> Bitcoin Core itself, amirite?  It seems like it would provide an
> interesting issue to open and have healthy discussion on both
> mailing list and github, adding the caveat that it would be at the
> user's option.  Thus if something like Bitcoin-NG did come to be it
> would be something more like a feature that the user could
> activate / deactivate from within Core.  I assume it would be
> default off, but with the option to utilize.  Code would thus be
> available to others as well.  I am not saying yea or nay on it,
> just that it seems like this could be done.
> 
> Some notes:
> 
> Once a node generates a key block it becomes the leader.  As a
> leader, the node is allowed to generate  microblocks  at  a  set
> rate smaller  than  a  prede>ned  maximum.  A  microblock in
> Bitcoin-NG contains  ledger  entries  and  a  header.   The  header
> contains the  reference  to the  previous  block,  the  current
> GMT  time,  a cryptographic  hash  of  its  ledger  entries,  and
> a cryptographic signature  of  the  header.   The  signature  uses
> the  private  key that  matches  the public key in the latest key
> block in the chain. For a microblock to be valid, all its entries
> must be valid according to the specification of the state machine,
> and the signature has to be valid.  However, the microblocks, it is
> said, don't affect the weight of the chain, because they do not
> contain proof of work.  It is assumed by the authors of this model
> that this situation is critical for maintaining incentives here.
> 
> The questions that then begin to emerge to me are how is this 
> information managed and protected?  The headers, thus containing 
> reference(s) to previous block(s), current GMT time(s),
> cryptographic hash(es) of ledger entries, and cryptographic
> signature(s) of the headers, so forth, and other information.  Can
> the Bitcoin-NG scheme be designed or implemented in a manner which
> supports Stealth sends, Confidential Transactions, or similar
> privacy measures?  Or is this something which cannot be answered at
> this time?
> 
> Emin Gün Sirer via bitcoin-dev:
> So it seems to me that all I need to do is figure out who
> the current
 leader is,
> and DDoS him off the network to shut Bitcoin-NG down.
 
 Good point. If NG is layered on top of Bitcoin, we'd retain
 all of Bitcoin as is. This would confer all the benefits of
 Bitcoin's retrospective blocks, as well as add the ability to
 mint microblocks with low latency in between. And despite the
 phrase "the leader," the actual leader in NG is a key, not a
 specific node. That makes it possible to deter DDoS attacks
 by dynamically migrating where in the network the leader is
 operating in response to an attack. Finally, DDoS attacks
 against miners are already possible, but they seem rare, and
 I suspect it's at least partly because of the success of Matt
 Corallo's high speed bitcoin relay network. Similar defenses
 can apply here.
 
 - egs
 
 
 
 On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath
  wrote:
 
> So it seems to me that all I need to do is figure out who
> the current leader is, and DDoS him off the network to
> shut Bitcoin-NG down.
> 
> This is a significant advantage to bitcoin's ex-post-facto 
> blocks: no one knows where the next one will come from.
> The only way to shut the network do

Re: [bitcoin-dev] Proposed list moderation policy and conduct

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Another point building on Justus's remarks that I'll make (below)

Justus Ranvier via bitcoin-dev:
> On 14/10/15 19:02, Jeff Garzik via bitcoin-dev wrote:
>> *Disclose potential conflicts*
>> 
>> 1. List discussions often involve interested parties. We expect 
>> participants to be aware when they are conflicted due to
>> employment or other projects they are involved in, and disclose
>> those interests to other project members. 2. When in doubt,
>> over-disclose. Perceived conflicts of interest are important to
>> address, so that the lists’ decisions are credible even when 
>> unpopular, difficult or favorable to the interests of one group
>> over another.
> 
> Even if we assume everybody will try to approach that topic in
> good faith, I don't think it's that simple.
> 
> A term that's become popular recently is "Bitcoin maximalist", and
> it's frequently used as a slur or insult.
> 
> I honestly find that to be incomprehensible. If somebody at a Ford
> board meeting started talking about how Ford needed to make sure
> Toyota was able to sell enough cars, they wouldn't get very far by
> labelling their critics as "Ford maximalists".
> 
> Anyone who works at Ford and who isn't a Ford maximalist is in the
> wrong job.
> 
> And yet in Bitcoin, a much development is funded by companies who
> offer products which compete with Bitcoin, or at least would be in
> competition if Bitcoin were to achieve unlimited success.


One example that came to mind as I was reading this was, when I
presented an idea that I thought would be good for integration into
Bitcoin Core, explaining in various ways why I felt it would be
worthwhile to explore, I eventually had someone tell me I should go
and develop the idea first as either some sort of independent wallet,
or to demonstrate it would work via an alt.  (This has now occurred,
as a successful implementation of my micro-donations idea has been
demonstrated in an alt.)  I have to wonder, however, when I eventually
bring the micro-donation ideas back in such a form that they could
again be considered in bitcoin-dev, whether or not they would
seriously be considered, in part due to this effect which Justus
Ranvier has described in part ~ that is to say, the effect of people
engaging in the use of "maximalist" or some other label (or labels) as
limiting the extent of discourse which people can engage in.  (I
realize that wasn't exactly where you were going with this Justus, but
I'm just expanding upon the notion of how some labels and categories
can be used to suppress real discussion.)  Or, for example, if people
see me as "conflicted," and someone else doesn't, and I'm confused
about why someone would see me as "conflicted," where does that leave
one?  Quite possibly, stuck in a morass of unproductive commentary (or
maybe just being ignored by moderators who might see quite a few
people as "conflicted").

> 
> I expect this is a minority view on this list, but my position is
> that anyone who is not a Bitcoin maximalists has a potential
> conflict of interest if they're also involved in Bitcoin
> development.
> 
> I also suspect this issue is a cause of much user dissatisfaction
> with Bitcoin development. If Bitcoin users and investors don't
> trust that the developers are working toward the unlimited success
> case, they can and will revolt.
> 

Another thing to consider, although the person(s) proposing the list
moderation policy and conduct document will certainly not want to hear
it, is that the list might be better off without a policy document
that is enforced by moderators.  (An "about" section for what the list
is about, its purpose, and how people are supposed to treat each
other, is probably good... but the enforcement angle that I'm seeing
is probably a bad idea.)  What we stand for here is more than making
people comfortable while technical issues are discussed on a list.
The idea of keeping a protocol free of financial censorship, in
concept, extends to language as well, and thus people should be able
to be free in how they write and speak, even when their peers on the
list don't like what they see in others' expressions.

I recommend removal of the enforcement and moderator sections.
(Technically, there are mods for it already... I suppose... the
question is how you disclose in a "Purpose" or "About" section that
refers to this list who the mods are, or rather, what the roles are of
each person involved in a way that is minimally invasive and lets the
list flow.)

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

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWH2YLAAoJEGxwq/inSG8C0aAH/AqYWgZEyRM5d1rAwjt6jNrf
Vqkd+kBCu0+

[bitcoin-dev] Bitcoin Core 0.10.3 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.10.3 is now available from:

  

This is a new minor version release, bringing security fixes and translation 
updates.

Please report bugs using the issue tracker at github:

  

Upgrading and downgrading
=

How to Upgrade
- --

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- --

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.

Notable changes
===

Fix buffer overflow in bundled upnp
- 

Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
the XML parser during initial network discovery.

Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/

This applies to the distributed executables only, not when building from source 
or
using distribution provided packages.

Additionally, upnp has been disabled by default. This may result in a lower
number of reachable nodes on IPv4, however this prevents future libupnpc
vulnerabilities from being a structural risk to the network
(see https://github.com/bitcoin/bitcoin/pull/6795).

Test for LowS signatures before relaying
- -

Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector.

Consensus behavior is unchanged.

If widely deployed this change would eliminate the last remaining known vector
for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
it will block most transactions made by sufficiently out of date software.

Unlike the other avenues to change txids on transactions this
one was randomly violated by all deployed bitcoin software prior to
its discovery. So, while other malleability vectors where made
non-standard as soon as they were discovered, this one has remained
permitted. Even BIP62 did not propose applying this rule to
old version transactions, but conforming implementations have become
much more common since BIP62 was initially written.

Bitcoin Core has produced compatible signatures since a28fb70e in
September 2013, but this didn't make it into a release until 0.9
in March 2014; Bitcoinj has done so for a similar span of time.
Bitcoinjs and electrum have been more recently updated.

This does not replace the need for BIP62 or similar, as miners can
still cooperate to break transactions.  Nor does it replace the
need for wallet software to handle malleability sanely[1]. This
only eliminates the cheap and irritating DOS attack.

[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf

Minimum relay fee default increase
- ---

The default for the `-minrelaytxfee` setting has been increased from `0.1`
to `0.5`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11.0
release notes, in which this value was suggested)

0.10.3 Change log
=

Detailed release notes follow. This overview includes changes that affect 
external
behavior, not code moves, refactors or string updates.

- - #6186 `e4a7d51` Fix two problems in CSubnet parsing
- - #6153 `ebd7d8d` Parameter interaction: disable upnp if -proxy set
- - #6203 `ecc96f5` Remove P2SH coinbase

[bitcoin-dev] Bitcoin Core 0.11.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version 0.11.1 is now available from:

  

This is a new minor version release, bringing security fixes. It is recommended
to upgrade to this version as soon as possible.

Torrent magnet link:


magnet:?xt=urn:btih:c6dd5f10efd99d9129869bb5fbf9cc53fc07cefa&dn=bitcoin-core-0.11.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F

Please report bugs using the issue tracker at github:

  

Upgrading and downgrading
=

How to Upgrade
- --

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- --

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.

Notable changes
===

Fix buffer overflow in bundled upnp
- 

Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
the XML parser during initial network discovery.

Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/

This applies to the distributed executables only, not when building from source 
or
using distribution provided packages.

Additionally, upnp has been disabled by default. This may result in a lower
number of reachable nodes on IPv4, however this prevents future libupnpc
vulnerabilities from being a structural risk to the network
(see https://github.com/bitcoin/bitcoin/pull/6795).

Test for LowS signatures before relaying
- -

Make the node require the canonical 'low-s' encoding for ECDSA signatures when
relaying or mining.  This removes a nuisance malleability vector.

Consensus behavior is unchanged.

If widely deployed this change would eliminate the last remaining known vector
for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
it will block most transactions made by sufficiently out of date software.

Unlike the other avenues to change txids on transactions this
one was randomly violated by all deployed bitcoin software prior to
its discovery. So, while other malleability vectors where made
non-standard as soon as they were discovered, this one has remained
permitted. Even BIP62 did not propose applying this rule to
old version transactions, but conforming implementations have become
much more common since BIP62 was initially written.

Bitcoin Core has produced compatible signatures since a28fb70e in
September 2013, but this didn't make it into a release until 0.9
in March 2014; Bitcoinj has done so for a similar span of time.
Bitcoinjs and electrum have been more recently updated.

This does not replace the need for BIP62 or similar, as miners can
still cooperate to break transactions.  Nor does it replace the
need for wallet software to handle malleability sanely[1]. This
only eliminates the cheap and irritating DOS attack.

[1] On the Malleability of Bitcoin Transactions
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf

Minimum relay fee default increase
- ---

The default for the `-minrelaytxfee` setting has been increased from `0.1`
to `0.5`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is