[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak via bitcoin-dev]

I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.

https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki

pre
  BIP: XX
  Title: CHECKSEQUENCEVERIFY
  Authors: BtcDrak btcd...@gmail.com
   Mark Friedenbach m...@friedenbach.org
  Status: Draft
  Type: Standards Track
  Created: 2015-08-10
/pre

==Abstract==

This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that in combination with BIP 68 allows execution
pathways of a script to be restricted based on the age of the output
being spent.


==Summary==

CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
it compares the top item on the stack to the inverse of the nSequence
field of the transaction input containing the scriptSig. If the
inverse of nSequence is less than the sequence threshold (1  31),
the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.

BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.


==Motivation==

BIP 68 repurposes the transaction nSequence field meaning by giving
sequence numbers new consensus-enforced semantics as a relative
lock-time. However, there is no way to build Bitcoin scripts to make
decisions based on this field.

By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.


==Specification==

Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.


case OP_NOP3:
{
if (!(flags  SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
// not enabled; treat as a NOP3
if (flags  SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
}
break;
}

if (stack.size()  1)
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

// Note that unlike CHECKLOCKTIMEVERIFY we do not need to
// accept 5-byte bignums since any value greater than or
// equal to SEQUENCE_THRESHOLD (= 1  31) will be rejected
// anyway. This limitation just happens to coincide with
// CScriptNum's default 4-byte limit with an explicit sign
// bit.
//
// This means there is a maximum relative lock time of 52
// years, even though the nSequence field in transactions
// themselves is uint32_t and could allow a relative lock
// time of up to 120 years.
const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);

// In the rare event that the argument may be  0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKSEQUENCEVERIFY.
if (nInvSequence  0)
return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);

// Actually compare the specified inverse sequence number
// with the input.
if (!CheckSequence(nInvSequence))
return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);

break;
}

bool CheckSequence(const CScriptNum nInvSequence) const
{
int64_t txToInvSequence;

// Fail under all circumstances if the transaction's version
// number is not set high enough to enable enforced sequence
// number rules.
if (txTo-nVersion  2)
return false;

// Sequence number must be inverted to convert it into a
// relative lock-time.
txToInvSequence = (int64_t)~txTo-vin[nIn].nSequence;

// Sequence numbers under SEQUENCE_THRESHOLD are not consensus
// constrained.
if (txToInvSequence = SEQUENCE_THRESHOLD)
return false;

// There are two types of relative lock-time: lock-by-
// blockheight and lock-by-blocktime, distinguished by
// whether txToInvSequence  LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of lock-time being 

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Btc Drak via bitcoin-dev]

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:
 Nobody is going to click that...

I guess I am nobody. Here's a copy of the text:-

*Dynamically Controlled Bitcoin Block Size Max Cap
http://upalc.com/maxblocksize.php*

*Assumption*: This article is for those, who already understand the bitcoin
protocol and aware of the block size controversy. Details of the problem
statement can be found in BIP 100
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf.
Satoshi's opinion regarding block size can be found here
https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366. I will be
directly going into the solution without explaining the problem in details.


*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do
just another calculation here. Nodes will also calculate what % of blocks
in the last difficulty period is higher than 90% of the maximum block size,
which is 1 MB for now. If it is found that more than 90% blocks in the last
difficulty period is higher than 90% of the maximum block size, then double
the maximum block size. If not, then calculate what % of blocks in the last
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.

Please note that, while calculating the % of blocks, it is better to take
into account the first 2000 of the 2016, than the whole of 2016. This helps
to avoid the calculation mistake if some of the last few blocks get
orphaned.


*Reasoning*: This solution is derived directly from the indication of the
problem. If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume, but
maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.


*Other Solutions of this Problem*:-

Making Decentralized Economic Policy
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf - by
Jeff Garzik

Elastic block cap with rollover penalties
https://bitcointalk.org/index.php?topic=1078521 – by Meni Rosenfeld

Increase maximum block size
https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki - by Gavin
Andresen

Block size following technological growth
https://gist.github.com/sipa/c65665fc360ca7a176a6 - by Pieter Wuille

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
https://lightning.network/lightning-network-paper.pdf - by Joseph Poon 
Thaddeus Dryja


Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.


 On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:

 I have tried to solve the maximum block size debate, depending on the
 previous block size calculation.

 Requesting for comment - http://upalc.com/maxblocksize.php


 ___
 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 XTs Tor IP blacklist downloading system has significant privacy leaks.

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 4:45 PM, Mike Hearn via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 The code was peer reviewed, in the XT project. I didn't bother submitting
 other revisions to Core, obviously, as it was already rejected.

 The quantity of incorrect statements in this thread is quite ridiculous.

Would you kindly link to said peer review as I was unable to find it
other than a couple of comments between you and Gavin which hardly
amounts to peer review.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd p...@petertodd.org wrote:
 Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
 other users' comments on their own pull-reqs...

 IMO that's an abuse of the pull-req process, and in turn, Gavin
 Andresens's commit access rights for the Bitcoin Core repo.

For the avoidance of doubt here's the archive link of my comment
https://archive.is/omvSY#40% (call me paranoid)
and here's where he tells me he's censored my posts https://archive.is/vym6N#40%

 I think this should weigh in favor of Gavin Andresen not having commit
 privileges for the Bitcoin Core repository.

It's time.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik jgar...@gmail.com wrote:
 bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
 discussion?

Well -dev or both, I dont particularly see a difference at the moment,
and establishing two lists isnt really going to make a difference so
long as Bitcoin Core is the reference client, which it is by defacto.
The risk of having too many lists is interested stakeholders will miss
a discussions. Normal protocol and core discussions are usually pretty
low volume in any case.

 As Jorge notes, a general discussion list has existed for a long time with
 little use.

I would suggest it's only because there havent been any rules for -dev
that would force general discussion over to the bitcoin list. On IRC
we regularly tell people in #bitcoin-dev they are OT and ask them to
move to #bitcoin and as a result, -dev remains quite clear of chit
chat, #bitcoin has a steady stream of general chatter.

We could reduce the OT/noise of bitcoin-dev list considerably by
offloading the non-technical/academic debate to the bitcoin list. It
just needs a bit of shepherding. I am more than happy to help out.
Especially if the list already exists, we should consider making a
decision now.

Who are the moderators for that list? Do we really want to use
sourceforge or are there alternatives, like another list on
linuxfoundation?

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

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 11:25 PM, Gary Mulder via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 So guys, do we need a BIP to address the existence of XT and its possible
 impact to the block chain?

I believe there is BIP99 that addresses hard forks.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

[Btc Drak via bitcoin-dev]

On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 I like the intend of this attempt to bring more clarity to the blocksize
 debate, however it would be more help to make this a information site about
 the current outstanding BIPs and summarize their differences rather than
 voting mechanism.
  (ofcourse the author of the BIPs would vote for their own proposals.)

 It would be good to include supporting and counter statements regards to
 these BIPs on the site.
 in addition to highlight certain things like pools in china have voiced
 their opinion that increase should happen, and 8mb is something they are
 comfortable with, which is not directly related to a single BIP, but never
 the less relevant in this discussion.

I was rather surprised by the tweet from AntPool[1] today saying that
they support big blocks and would be prepared to upgrade to XT. Pools
have stated that they are willing to increase to a maximum of 8MB, but
upgrading to XT puts them on a schedule towards 8GB which is clearly
not what they have agreed to.

Do you have any insights into what's going on there?

Also do you have any insight into what Chinese pools would accept as a
compromise in terms of raising the blocksize limit?

Drak

[1] https://twitter.com/JihanWu/status/633288343338381314
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via bitcoin-dev]

I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based determination.

The living document is currently a gist available at
https://gist.github.com/btcdrak/1c3a323100a912b605b5


pre
  BIP: XX
  Title: Consensus based block size retargeting algorithm
  Author: BtcDrak btcd...@gmail.com
  Status: Draft
  Type: Standards Track
  Created: 2015-08-21
/pre

==Abstract==

A method of altering the maximum allowed block size of the Bitcoin
protocol using a consensus based approach.

==Motivation==

There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase due to a
mass adoption curve, because co-ordinating a hard fork takes
considerable time, and being unable to respond in a timely manner
would irreparably harm the credibility of bitcoin.

Additionally, predetermined block size increases are problematic
because they attempt to predict the future, and if too large could
have unintended consequences like damaging the possibility for a fee
market to develop as block subsidy decreases substantially over the
next 9 years; introducing or exacerbating mining attack vectors; or
somehow affect the network in unknown or unpredicted ways. Since fixed
changes are hard to deploy, the damage could be extensive.

Dynamic block size adjustments also suffer from the potential to be
gamed by the larger hash power.


==Rationale==

By introducing a cost to increase the block size ensures the mining
community will collude to increase it only when there is a clear
necessity, and reduce it when it is unnecessary. Rogue miners cannot
force their wishes so easily because not only will they have to pay
extra a difficulty target, then can be downvoted at no cost by the
objecting hash power.


==Specification==

The initial base block size limit shall be 1MB.

Miners can vote for a block size increase by signalling the proposed
percentage increase of the base block size limit in the coinbase
field. For the vote to be considered valid the block they mine must
meets a difficulty target which is proportionally larger than the
standard difficulty target based on the percentage increase they voted
for. If a miner does not vote, or the vote is invalid, it shall be
counted as a vote for no change.

Miners may vote the size down by signalling in the coinbase field
without paying a difficulty penalty.

Every 2016 blocks, the maximum allowed block size will be recalculated
by the average of all votes in the last 2016 blocks, i.e. sum each
vote from each block and divide by 2016 then multiply by the base
block size limit. This will redefine the base block size limit for the
next 2016 blocks.

Blocks that are larger than the calculated base block size limit are
invalid and MUST be rejected.

The maximum change up or down each retargeting period shall be limited
to 10% of the base block size limit.

The maximum block size may not increase above 8MB.

Votes shall be cast by adding the following human readable multiplier
to the coinbase string “/BXn.nnn/” where valid votes would exist
between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
increase). “/BX1.000/” would be a vote for no change. Invalid votes
will be counted as a vote for no change: “/BX1.000/”.


==Acknowledgements==

This proposal is based on ideas and concepts derived from the writings
of Meni Rosenfeld and Gregory Maxwell.


==Copyright==

This work is placed in the public domain.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

[Btc Drak via bitcoin-dev]

On Fri, Aug 21, 2015 at 6:10 AM, Nicolas Dorier via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 Decision making is not the goal of this site, it is only a way to see
 various pros and cons of various devs on various proposals in a single
 place.
 This is for the community to have a coherent view about what you are talking
 about now spread into reddit/mailing/forums.

 If you did not analyzed a proposal yet, you don't have to fill out your
 opinion veto or approval.
 It is only to show what you would you approve and what you would veto,
 after your analysis.
 Then point out all the discussions in the opinion section that lead you to
 your conclusion.

 You can change edit your position as you progress into your analysis and as
 new BIP get redacted.
 I'm eager to include the new proposals.

The most important part that developers should complete is the
Technical Opinion column section where they can explain their
general worldview, what their concerns are, how those concerns would
be alleviated. If one is undecided or does not have enough information
regarding each BIP then dont fill it out. That also helps signal the
level of consensus for a proposal.

As it stands at the moment, it's almost impossible to direct someone
at the opinion of a specific developer other than hunting down a few
gems scattered to the four corners of the universe. I tried recently
and it was simply impossible. At least with this system, specific BIPs
aside, we can easily see the view of each developer. I think most of
us can comment on BIP101 since the BIP appears non-negotiable.

The XT faction are easily winning the media war by obscuring rational
debate by high signal to noise ratio. Nicolas' solution means the most
important views expressed by each heavyweight will not get lost and
serve as a good reference point for everyone, including the media.

The site could be extended to include major stakeholders too like
major service providers (think exchanges, wallet providers etc) and
mining pools.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

[Btc Drak via bitcoin-dev]

On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 What might be valuable is to ask devs to explain what their threat models 
 are, what should be at the root of their thinking about the blocksize.

That's exactly what the Technical Opinion column is for.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ?

[Btc Drak via bitcoin-dev]

I was looking at this site recently and it's not very clear that by
clicking the name you get their opinion. I would make that a separate
column stated, Technical Opinion.

I think you need to include more of the developers/technical people,
Adam Back, Mark Friedenback, Jorge Timons, (all of who are core
developers). You need
Peter Todd is a core dev btw, as is thebluematt.

You need other experts, I would include Nick Szabo, Meni Rosenfeld,
Charlie Lee might be a good one. You should get the pools on there
too.

You're missing Mike Hearn of course.

My key is 0xE5D138F5E73A1AF2


On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 I created a small website which show a chart of your approvals about various
 BIPs (which you must fill by yourself with a signed pgp message)

 For each BIP, you can fill if you approve or not, and give comments. (HTML
 accepted, so you can link stuff you your posts)

 It would help the community a lot, so I hope you will do it !
 I'm open to add other important devs, big miners, or other proposal that I
 missed.

 Please, respond on BTC Talk or github. (I don't read the mailing anymore
 because of the spam :( )

 Link : http://bipsxdevs.azurewebsites.net/
 BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164
 Github : https://github.com/NicolasDorier/BIPxDevs

 ___
 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] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón jti...@jtimon.cc wrote:

 Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
 But technical people run away from noise while non-technical people
 chase them wherever their voices sounds more loud.


Regarding disruptors, if there are clear rules about what is acceptable on
-dev, one can simply moderate out offenders. It's absolutely necessary we
have a forum where we can share and discuss purely academic and technical
matters. No-one can accuse censorship because all moderation would say
would be to take it to the other list. It's essential for all people who
are developing and maintaining Bitcoin protocol software, or services that
rely on it. The mailing list used to be very low volume.

While we are at it, we should also think about a bitcoin-announce read only
list which consumers of Bitcoin Core can subscribe for announcements about
new versions of Bitcoin Core, and any critical warnings. Miners and service
providers would particularly benefit from this. The list is moderated so
only say Bitcoin Core commit engineers are allowed to post.


 One thing that I would like though, is separating Bitcoin
 Core-specific development from general bips and consensus discussions.


The potential downside is too much separation becomes confusing although I
would not oppose such a change. My own suggestion would be try just a -dev
and -discuss list and see how that goes first. It used to work well.
Whatever the case I am very confident we need a general discussion mailing
list.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak via bitcoin-dev]

Please note there is now a PR for this BIP[1] and also a pull request for
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].

[1] https://github.com/bitcoin/bips/pull/179
[2] https://github.com/bitcoin/bitcoin/pull/6564
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Btc Drak via bitcoin-dev]

I thought it's worth mentioning there is a specific Lightning Network
development mailing list at
http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
some pretty interesting explanations in the archives.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Memory leaks?

[Btc Drak via bitcoin-dev]

I think this thread has gotten to the stage where it should be moved
to an issue on Github and not continue to CC the bitcoin-dev list (or
any other list tbh).

On Thu, Oct 22, 2015 at 5:27 PM, Jonathan Toomim via bitcoin-dev
 wrote:
> You may want to add a cron job to restart bitcoind every day or two as a
> damage control mechanism until we figure this out.
>
> On Oct 22, 2015, at 9:06 AM, Multipool Admin  wrote:
>
> This is a real issue.  The bitcoind process is getting killed every few days
> when it reaches around 55gb of usage on my server.
>
> On Oct 21, 2015 12:29 AM, "Tom Zander via bitcoin-dev"
>  wrote:
>>
>> On Tuesday 20 Oct 2015 20:01:16 Jonathan Toomim wrote:
>> >  claimed that he had this memory usage issue on Linux, but not on Mac OS
>> > X,
>> > under a GBT workload in both situations. If this is true, that would
>> > suggest this might be a fragmentation issue due to poor memory
>> > allocation.
>>
>> Please make sure you measure your memory usage correctly on Linux, it is
>> notoriously easy to get misleading info from tools like top.
>>
>> I use this one on Linux.
>>
>> $cat ~/bin/showmemusage
>> #!/bin/sh
>> if test -z "$1"; then
>> echo "need a pid"
>> exit
>> fi
>>
>> mem=`echo 0 $(cat /proc/$1/smaps | grep Pss | awk '{print $2}' | \
>> sed 's#^#+#' ) | bc`
>> echo "$mem KB"
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "bitcoin-xt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoin-xt+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> ___
> 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

[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] This thread is not about the soft/hard fork technical debate

[Btc Drak via bitcoin-dev]

On Mon, Oct 5, 2015 at 6:26 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> History has shown that for many decision making processes this doesn't
> work,
> and this argument has been made to Core.
> Until today this was essentially a rule that hurt the things that Mike was
> really passionate about.
> Today this hurts the things that some other devs are passionate about.
>

If you are referring to some of Mike's PRs that were either refused or
reverted, it was because they where substantial technical objections to
them. This isn't even in the same ballpark.

Surely you see the absurdity of arguing against soft forks after we
successfully used them already for BIP34 and BIP66?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Btc Drak via bitcoin-dev]

On Mon, Oct 5, 2015 at 5:56 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> CLTV deployment is clearly controversial. Many developers other than me
> have noted that hard forks are cleaner, and have other desirable
> properties. I'm not the only one who sees a big question mark over soft
> forks.
>

No, that is not correct and you are distorting facts to fit your argument.
We have discussed the tradeoffs of each method in general, but that does
not make hard forks or soft forks controversial in an of itself.

There is technical consensus to roll out CLTV by ISM, and if somehow you
are right, it will come out during deployment in much the same way as your
recent attempt at rolling out a controversial hardfork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

[Btc Drak via bitcoin-dev]

This BIP was assigned number 113.

I have updated the text accordingly and added credits to Gregory Maxwell.

Please see the changes in the pull request:
https://github.com/bitcoin/bips/pull/182

On Sat, Aug 22, 2015 at 1:57 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote:

 I submitted the pull-request for the median-past timelock BIP just now

 https://github.com/bitcoin/bips/pull/182

 Any luck finding the link to this discussion? It would be nice to
 include this for posterity.

 Found it! From #bitcoin-wizards, 2013-07-16:

 23:57  petertodd See, it'd be possible for nLockTime w/ time-based locks to 
 create some really ugly incentives for miners to mine blocks at thelimit of 
 the 2hr window - a timestamping chain could provide a way for nodes to at 
 least detect that their clocks are off, especially given how peers can mess 
 with them.
 23:58  petertodd It's still dodgy though... I was thinking if 
 nLockTime-by-time inclusion was based on the previous block timestamp it'd be 
 ok, but that still leaves large miners with incentives to screw with the 2hr 
 window, never mind how it can reduce competition if there exists clock skew 
 in the mining nodes.
 --- Log closed Wed Jul 17 00:00:57 2013
 --- Log opened Wed Jul 17 00:00:57 2013
 00:01  petertodd (remember that if this is a timestamping facility any node 
 wanting to know the current time simply gets a nonce timestamped, and then 
 they know what time it is!)
 00:11  Luke-Jr I don't see how nLockTime can discourage forward-dating 
 blocks
 00:11  Luke-Jr and there is no 2hr window backward..
 00:12  Luke-Jr well, I guess if miners are behaving there is .
 00:19  petertodd The problem is a block being created with nTime  actual 
 time, and the incentive is to get a head start on other miners to put, say, a 
 high-fee nLockTime in the block you are creating.
 00:21  Luke-Jr petertodd: but nLockTime only sets a minimum time, it cannot 
 set a maximum
 00:22  petertodd but that's it, if I have a 1BTC fee tx, with nLockTime 
 expiring in two hours, why not take the increased orphan chance and set nTime 
 on my block to two hours ahead/
 00:22  petertodd ?
 00:22  petertodd yet if we allow that incentive, it's very bad for consensus
 00:23  gmaxwell ha. We can fix.
 00:23  gmaxwell it's a soft forking fix.
 00:23  gmaxwell use the last blocks ntime, not this one.
 00:23  Luke-Jr is sipa's secp256k1 branch reasonably stable?
 00:23  petertodd gmaxwell: that's what I said...
 00:24  gmaxwell petertodd: sorry I just read the last couple lines.
 00:24  Luke-Jr petertodd: AFAIK we already don't relay transactions with 
 time in the future?
 00:24  gmaxwell petertodd: well I agree. (or not even the last block— it 
 could use the minimum time)
 00:24  petertodd gmaxwell: The problem is, that's only a fix if mining 
 power is well distributed, it actually makes things worse because if there is 
 a lot of profit to be gained the miners with a lot of hashing power still 
 have the incentive, and it's to a much greater degree. (their orphan rate is 
 less)
 00:24  Luke-Jr gmaxwell: the minimum time will be earlier than the last 
 block's :p
 00:25  gmaxwell Luke-Jr: sure, but that doesn't change it really. 
 Presumably if people start locking in the future miners will run nodes that 
 take what they get and selfishly horde them, creating incentives for all 
 miners to run good collection networks.
 00:25  petertodd Luke-Jr: sure, but there are lots of ways to learn that a 
 tx exists
 00:26  gmaxwell petertodd: one of the reasons that the min is important 
 there is because (1) it's hard to advance, and (2) when you advance it you 
 raise the difficulty.
 00:26  petertodd gmaxwell: I was working on figuring out the expected 
 return - the math is really ugly
 00:27  gmaxwell petertodd: a worst case expected return may be easier.
 00:27  petertodd gmaxwell: Worst case is easy - your block is orphaned.
 00:28  petertodd gmaxwell: See the issue is that once I find a block, the 
 other side needs to find two blocks to beat me. As time goes on more of the 
 other sides hashing power will accept my from the future block as valid, so 
 then you get the next level where the remainder needs three blocks and so on.
 00:28  petertodd gmaxwell: Pretty sure it can't be done as a closed-form 
 equation.
 00:30  petertodd gmaxwell: I don't think minimum time works either, because 
 you still get to manipulate it by creating blocks in the future, although the 
 ability too is definitely less. If I could show you'd need 50% hashing power 
 to do anything interesting I'd be set.
 00:31  Luke-Jr petertodd: hmm, is block-uneconomic-utxo-creation basically 
 just an older revision of what Gavin did in 0.8.2?
 00:31  gmaxwell petertodd: moving the minimum time forward needs the 
 coperation of 50% of the hashpower over the small median window.
 00:32  petertodd Luke-Jr: It's what Gavin did 

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Btc Drak via bitcoin-dev]

I have changed BIPS 112 and 113 to reflect this amended deployment
strategy. I'm beginning to think the issues created by Bitcoin XT are
so serious it probably deserves converting OPs text into an
informational BIP.

On Thu, Aug 20, 2015 at 6:42 PM, Mark Friedenbach via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 No, the nVersion would be = 4, so that we don't waste any version values.

 On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:

 Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:



 2) nVersion mask, with IsSuperMajority()

 In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
 be masked away, prior to applying standard IsSuperMajority() logic:

 block.nVersion  ~0x2007

 This means that CLTV/CSV/etc. miners running Bitcoin Core would create
 blocks with nVersion=8, 0b1000. From the perspective of the
 CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be
 advertising blocks that do not trigger the soft-fork.

 For the perpose of soft-fork warnings, the highest known version can
 remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
 as well as a future nVersion bits implementation. Equally,
 XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
 unknown bit set.

 When nVersion bits is implemented by the Bitcoin protocol, the plan of
 setting the high bits to 0b001 still works. The three lowest bits will
 be unusable for some time, but will be eventually recoverable as
 XT/Not-Bitcoin-XT mining ceases.

 Equally, further IsSuperMajority() softforks can be accomplished with
 the same masking technique.

 This option does complicate the XT-coin protocol implementation in the
 future. But that's their problem, and anyway, the maintainers
 (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks
 and/or appear to be in favor of a more centralized mandatory update
 schedule.(6)


 If you are going to mask bits, would you consider to mask all bits except
 the 4th bit? So other fork proposals may use other bits for voting
 concurrently.

 And as I understand, the masking is applied only during the voting stage?
 After the softfork is fully enforced with 95% support, the nVersion will be
 simply =8, without any masking?

 ___
 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] RFC - BIP: URI scheme for Blockchain exploration

[Btc Drak via bitcoin-dev]

What about supporting different networks? What if I want to look up
testnet for example?

blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

or

blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet

On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
 I like the idea of having a standard for this, that all explorers (and even
 core, eventually) would understand.

 I would recommend 2 changes though. First, using a real URI scheme,
 blockchain:// so that we can just use normal URL parsing libraries. The
 bitcoin: thing leads to additional code to mutate it into a proper URI
 before passing it to URL parsing. And I think it would be fine to include
 the type looking up. For example:

 blockchain://blockhash/1003e880d500968d51157f210c632e08a652af3576600198
 blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
 blockchain://block/189000
 blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn

 I think this would help the URI be more human understandable as well as give
 the explorers the ability to optimize a bit what they are looking for when
 hitting various databases.

 A possible future path could also include blockchain://tx/123000/4 for block
 height, tx index... Another possibility could be blockchain://version which
 would return a list of supported paths, version of the BIP supported, etc.

 The BIP should also specify little endian searching. I'm not sure, but would
 it also make sense for this BIP to include what the return results should
 look like? Maybe another, related BIP.

 RicMoo

 Sent from my self-aware iPhone

 .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º

 Richard Moore ~ Founder
 Genetic Mistakes Software Inc.
 phone: (778) 882-6125
 email: ric...@geneticmistakes.com
 www: http://GeneticMistakes.com

 On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:

 Hi!
 My first post here, hope I'm following the right conventions.
 I had this humble idea for a while, so I thought to go ahead and propose
 it.

 BIP: XX
 Title: URI scheme for Blockchain exploration
 Author: Marco Pontello
 Status: Draft
 Type: Standards Track
 Created: 29 August 2015

 Abstract
 
 This BIP propose a simple URI scheme for looking up blocks, transactions,
 addresses on a Blockchain explorer.

 Motivation
 ==
 The purpose of this URI scheme is to enable users to handle all the
 requests for details about blocks, transactions, etc. with their preferred
 tool (being that a web service or a local application).

 Currently a Bitcoin client usually point to an arbitrary blockchain
 explorer when the user look for the details of a transaction (es. Bitcoin
 Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
 Other times resorting to cutpaste is needed.
 The same happens with posts and messages that reference some particular
 txs or blocks, if they provide links at all.

 Specification
 =
 The URI follow this simple form:

 blockchain: hash/string

 Examples:

 blockchain:1003e880d500968d51157f210c632e08a652af3576600198
 blockchain:001949
 blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a

 Rationale
 =
 I thought about using some more complex scheme, or adding qualifiers to
 distinguish blocks from txs, but in the end I think that keeping it simple
 should be practical enough. Blockchain explorers can apply the same
 disambiguation rules they are already using to process the usual search
 box.

 From the point of view of a wallet developer (or other tool that need to
 show any kind of Blockchain references), using this scheme mean that he
 can simply make it a blockchain: link and be done with it, without having
 to worry about any specific Blockchain explorer or provide a means for the
 user to select one.

 Blockchain explorers in turn will simply offer to handle the blockchain:
 URI, the first time the user visit their website, or launch/install the
 application, or even set themselves if there isn't already one.

 Users get the convenience of using always their preferred explorer, which
 can be especially handy on mobile devices, where juggling with cutpaste
 is far from ideal.


 ___
 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

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak via bitcoin-dev]

This BIP has been assigned BIP112 by the BIP repository maintainer. I
have updated the pull request accordingly.

Regarding the suggestion to cannibalise version, by your own
disadvantage list, we would lose fine grained control over txins which
neuters the usefulness considerably. Also using version is also ugly
because there isn't a semantic association with what we are trying to
do, whereas, sequence is associated with transaction finality and is
thus the more appropriate and logical field to use.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Censorship

[Btc Drak via bitcoin-dev]

On Mon, Aug 31, 2015 at 10:49 AM, NxtChg  wrote:
>>While this topic is very interesting, I do not see how it is
>>relevant to a mailing list dedicated to technical and academic debate.
>>Please can you take this discussion elsewhere.
>
> Wow. I have Deja Vu. Where have I heard recently that discussing Bitcoin 
> split is off topic and must be stopped?.. Hm...
>
> This is the biggest issue with Bitcoin right now and you want us to move to 
> some obscure place?
>
> Where? Reddit?  Where we can't be heard? Create another list with top XT 
> people then.

This is a technical list dedicated to technical discussions revolving
around the bitcoin protocol and related technologies. What I am saying
is your discussion topic is not relevant to the long established theme
of this list. Please have a bit of decorum and respect for people who
joined this list so they could participate in and review
technical/academic topics.

Clearly there *should* be a general bitcoin discussion list somewhere,
I don't disagree (and I have repeatedly asked for one to be created),
but regardless, this list isn't it. The flood of off topic and
non-technical posts make it almost impossible to follow any technical
proposals.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Censorship

[Btc Drak via bitcoin-dev]

While this topic is very interesting, I do not see how it is relevant
to a mailing list dedicated to technical and academic debate. Please
can you take this discussion elsewhere.

On Mon, Aug 31, 2015 at 10:35 AM, Zach G via bitcoin-dev
 wrote:
> When I say de-centralized I mean it, all the things you listed are
> centralized. Reddit is actually a purely centralized system and just as
> unhealthy as the current bitcoin forum. We have the technology, I'm simply
> putting together the pieces that other people have already built. This forum
> will literally be uncontrollable in raw form, once it's unleashed it can't
> be stopped. It will exist on thousands of computers so it cannot be
> destroyed, it will not be centrally hosted.
>
> I expect users to create their own external software to parse the data, so
> people can centralize as much or as little as they want in their own
> 'sub-forums' built on this system. I will be releasing some very rudimentary
> external software/website to go along with this de-centralized system just
> so people can post and read what's posted, and will worry about the finer
> details at a later time.
>
> There will be various leaders who utilize this program and organize quality
> forums, but fundamentally the raw de-centralized system cannot be
> controlled, so people posting to it will always have a venue to speak
> without being censored.
>
> I actually started this project to create a journal of uncensored scientific
> research, but it didn't take long to realize this sort've thing is useful
> for pretty much everyone, so I'm rushing the basic release out. Then I will
> work on making my science journal 'sub-forum' software and everyone else can
> do whatever they want.
>
>
> -Original Message-
> From: NxtChg 
> To: hurricanewarn1 ; bitcoin-dev
> 
> Sent: Mon, Aug 31, 2015 4:45 am
> Subject: Re: [bitcoin-dev] Censorship
>
>
>>I am creating a de-centralized forum, and I mean truly decentralized as I
>> nor
> anyone else will be able to control it.
>
> Zander is working on the same thing:
> https://www.reddit.com/r/AetheralResearch/
>
> But it's actually quite difficult
> to make it truly censorship-resistant: both in solving the theymos factor
> and
> spam/abuse/overloading as an attack.
>
>
>>There is no doubt that the
> centralization and censorship of the Bitcoin community is massively
> inhibiting
> the advance of Bitcoin
>>and also the growth of the Bitcoin economy. We are
> scaring away intellectuals, businessman, and newbies that are just getting
> started.
>
> We have /r/bitcoinxt and so far it has been great. But we also need
> a regular forum.
>
> Roger Ver controls bitcoin.com, as I understand?
> https://bitcoin.com/forum/ would be nice.
>
> And it must be a real community,
> not "say whatever you want because free speech". We've seen how that turned
> out
> to be.
>
> Something like battle.net or Steam forums: heavily moderated, not for
> opinions, but for spam/noise/insults.
>
> Again, this needs leadership. Anyone
> can install a forum software, what is needed is an "official seal of
> approval"
> and regular presence of top XT people there.
>
> And a will to setup proper
> moderation. Then people will move.
>
>
> ___
> 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] Open Block Chain Licence, BIP[xxxx] Draft

[Btc Drak via bitcoin-dev]

Without commenting on your proposal at all, the general problem with
licensing after the fact is you require the permission of every
copyright holder in order to make the change.



On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
 wrote:
> Hello,
>
> We believe the network requires a block chain licence to supplement the
> existing MIT Licence which we believe only covers the core reference client
> software.
>
> Replacing or amending the existing MIT Licence is beyond the scope of this
> draft BIP.
>
> Rationale and details of our draft BIP for discussion and evaluation are
> here:
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> ___
> 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] Open Block Chain Licence, BIP[xxxx] Draft

[Btc Drak via bitcoin-dev]

I have read the proposal. I think you missed my point: every existing
transaction author would be required to agree to your proposals for
them to be legal, and that's clearly impossible. You'd also need every
single miner who published a block. You're much better taking the line
that actually, the data is public domain and unrestricted based on
various assumptions.

You make some assumptions that transaction authors use Bitcoin Core to
"contract with the network", but in fact transactions are written and
broadcast by a number of means, arguably very few are created by
Bitcoin Core these days. How exactly do you expect to get a legally
binding agreement from all future transaction authors agreeing to your
terms? How would you prove Alice agreed 10 years later? If it was a
proprietary system like Paypal who can force you to agree or close
your account, the Bitcoin protocol is permissionless and anyone can
author a transaction using any means they like, not just Bitcoin Core.
So again I come back to the point your proposal would have to get
permission from all existing authors, and all future authors to work.

Overall I think the proposal is trying to fix something that doesn't
need fixing and get into a quagmire in the process. In fact, I see it
as an impossible task.

On Tue, Sep 1, 2015 at 11:11 PM, Ahmed Zsales  wrote:
> To avoid repetition, we have actually covered the general points and
> questions you have raised in the draft BIP, which includes a draft licence
> to assist discussions:
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> On Tue, Sep 1, 2015 at 11:02 PM, Btc Drak  wrote:
>>
>> I think it gets worse. Who are the copyright owners (if this actually
>> applies). You've got people publishing transaction messages, you've
>> got miners reproducing them and publishing blocks. Who are all the
>> parties involved? Then to take pedantry to the next level, does a
>> miner have permission to republish messages? How do you know? What if
>> the messages are reproducing others copyright/licensed material? It's
>> not possible to license someone else's work. There are plenty rabbit
>> holes to go down with this train of thought.
>>
>> On Tue, Sep 1, 2015 at 8:36 PM, Ahmed Zsales via bitcoin-dev
>>  wrote:
>> > That is a very good point.
>> >
>> > We considered whether data existing before a licence change would be
>> > covered, but we hadn't factored the potential need for gaining
>> > permissions
>> > for a change to be considered effective.
>> >
>> > We have proposed that miners be the main beneficiaries of licensing and
>> > there is a consideration on whether they should vote to adopt the new
>> > terms.
>> > While not the preferred route, that would overcome any issues to what is
>> > an
>> > otherwise honest 'error and omission.' There doesn't seem to be anyone
>> > who
>> > could claim to have suffered any economic losses so this may not be an
>> > issue. It merits further investigation.
>> >
>> > The block chain is in perpetual change, so the sooner a change is agreed
>> > upon, if at all, the more data it will cover without any reservations.
>> > At
>> > any rate, we believe the changes would be considered effective on a
>> > retrospective basis.
>> >
>> >
>> > On Tue, Sep 1, 2015 at 7:12 PM, Btc Drak  wrote:
>> >>
>> >> Without commenting on your proposal at all, the general problem with
>> >> licensing after the fact is you require the permission of every
>> >> copyright holder in order to make the change.
>> >>
>> >>
>> >>
>> >> On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
>> >>  wrote:
>> >> > Hello,
>> >> >
>> >> > We believe the network requires a block chain licence to supplement
>> >> > the
>> >> > existing MIT Licence which we believe only covers the core reference
>> >> > client
>> >> > software.
>> >> >
>> >> > Replacing or amending the existing MIT Licence is beyond the scope of
>> >> > this
>> >> > draft BIP.
>> >> >
>> >> > Rationale and details of our draft BIP for discussion and evaluation
>> >> > are
>> >> > here:
>> >> >
>> >> >
>> >> >
>> >> > https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>> >> >
>> >> > Regards,
>> >> >
>> >> > Ahmed
>> >> >
>> >> > ___
>> >> > 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

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Btc Drak via bitcoin-dev]

On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón
 wrote:
>> Some altcoins (LTC and FTC for example) have the same genesis block hash.
>
> That's obviously a design mistake in FTC, but it's not unsolvable. FTC could
> move their genesis block to the next block (or the first one that is not
> identical to LTC's).
>
> Bitcoin and all its test chains have different genesis blocks, so I'm not
> sure FTC should be a concern for a BIP anyway...

That's a very sweeping generalisation indeed. Why should two chains
have to have a separate genesis? It's cleaner, but it's certainly not
a necessity. You cant exclude this case just because it doesn't fit
your concept of neat and tidy. Other BIP proposals that account for
alternative chains do not rely on the genesis hash, but instead an
identifier. Why should it be any different here? How would you account
for a world with XTCoin and Bitcoin which would also share the same
genesis hash, but clearly not be the same coin.

When I brought up the issue originally, I deliberately steered away
from altchains choosing to focus on networks like mainnet, testnet
because I think it's easier to repurpose a protocol for an altcoin
than it is to make the proposal work for all cases. Take the payment
protocol for example. The BIP specifies a URI with bitcoin: well it's
just as easy to repurpose that for litecoin: etc than adding something
like ?cointype=litecoin, so that was my reason for not mentioning
altcoins at all.

If the proposal is made to account for altcoins, genesis hash is
definitely not desirable, or at least not genesis hash in isolation,
and if that's the case, better to have an identifier.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

[Btc Drak via bitcoin-dev]

On Tue, Sep 1, 2015 at 5:12 PM, Danny Thorpe via bitcoin-dev
 wrote:
> Rather than using an inhumanly long hex string from the genesis hash to
> distinguish between mainnet and testnet, why not use the network magic bytes
> instead? Much shorter, just as distinct.

There's nothing stopping two coins having the same magic bytes, but
communicating on separate ports.

> I'd still prefer a common network name mapping for the sake of humanity. Few
> bitcoin library implementations use the same string names for mainnet and
> testnet. This BIP could simply define one string name alias for each
> supported network and leave mapping to local lingo to the implementors.

The only sane way to me see to have cointype like BIP44.
See https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#coin-type
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

[Btc Drak via bitcoin-dev]

I think it gets worse. Who are the copyright owners (if this actually
applies). You've got people publishing transaction messages, you've
got miners reproducing them and publishing blocks. Who are all the
parties involved? Then to take pedantry to the next level, does a
miner have permission to republish messages? How do you know? What if
the messages are reproducing others copyright/licensed material? It's
not possible to license someone else's work. There are plenty rabbit
holes to go down with this train of thought.

On Tue, Sep 1, 2015 at 8:36 PM, Ahmed Zsales via bitcoin-dev
 wrote:
> That is a very good point.
>
> We considered whether data existing before a licence change would be
> covered, but we hadn't factored the potential need for gaining permissions
> for a change to be considered effective.
>
> We have proposed that miners be the main beneficiaries of licensing and
> there is a consideration on whether they should vote to adopt the new terms.
> While not the preferred route, that would overcome any issues to what is an
> otherwise honest 'error and omission.' There doesn't seem to be anyone who
> could claim to have suffered any economic losses so this may not be an
> issue. It merits further investigation.
>
> The block chain is in perpetual change, so the sooner a change is agreed
> upon, if at all, the more data it will cover without any reservations. At
> any rate, we believe the changes would be considered effective on a
> retrospective basis.
>
>
> On Tue, Sep 1, 2015 at 7:12 PM, Btc Drak  wrote:
>>
>> Without commenting on your proposal at all, the general problem with
>> licensing after the fact is you require the permission of every
>> copyright holder in order to make the change.
>>
>>
>>
>> On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
>>  wrote:
>> > Hello,
>> >
>> > We believe the network requires a block chain licence to supplement the
>> > existing MIT Licence which we believe only covers the core reference
>> > client
>> > software.
>> >
>> > Replacing or amending the existing MIT Licence is beyond the scope of
>> > this
>> > draft BIP.
>> >
>> > Rationale and details of our draft BIP for discussion and evaluation are
>> > here:
>> >
>> >
>> > https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>> >
>> > Regards,
>> >
>> > Ahmed
>> >
>> > ___
>> > 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] block size - pay with difficulty

[Btc Drak via bitcoin-dev]

Maybe Jeff can clarify but my communications with him seemed to imply
he didn't think any kind of difficulty penalty scheme is workable. I
strongly dispute that assertion.

On Thu, Sep 3, 2015 at 7:23 PM, Jorge Timón
 wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
> increased nBits are used to vote for the block size to raise
> permanently ( or until it gets voted down).
> His arguments don't seem to apply to your original proposal (where the
> size is only increased for that block).
>
>
> On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
>  wrote:
>> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik  wrote:
>>> Expanding on pay-with-diff and volatility (closing comment),
>>>
>>> Users and miners will have significant difficulty creating and/or predicting
>>> a stable block size (and fee environment) with pay-with-diff across the
>>> months.  The ability of businesses to plan is low.  Chaos and
>>> unpredictability are bad in general for markets and systems.  Thus the
>>> binary conclusion of "not get used" or "volatility"
>>
>> Sorry, I'm still not following.  I agree that predictability is important.
>>
>> I don't follow where unpredictability is coming from here. Most (all?)
>> of the difficulty based adjustments had small limits on the difficulty
>> change that wouldn't have substantially changed the interblock times
>> relative to orphaning.
>>
>>> It's written as 'a' and/or 'b'.  If you don't have idle hashpower, then 
>>> paying with difficulty requires some amount of collusion ('a')
>>> Any miner paying with a higher difficulty either needs idle hashpower, or 
>>> self-increase their own difficulty at the possible opportunity cost of 
>>> losing an entire block's income to another miner who doesn't care about 
>>> changing the block size.  The potential loss does not economically 
>>> compensate for size increase gains in most cases, when you consider the 
>>> variability of blocks (they come in bursts and pauses) and the fee income 
>>> that would be associated
>>
>> What the schemes propose is blocksize that increases fast with
>> difficulty over a narrow window. The result is that your odds of
>> producing a block are slightly reduced but the block you produce if
>> you do is more profitable: but only if there is a good supply of
>> transactions which pay real fees compariable to the ones you're
>> already taking.  The same trade-off exists at the moment with respect
>> to orphaning risk and miners still produce large blocks, producing a
>> larger block means a greater chance you're not successful (due to
>> orphaning) but you have a greater utility.  The orphing mediated risk
>> is fragile and can be traded off for centeralization advantage or by
>> miners bypassing validation, issues which at least so far we have no
>> reason to believe exist for size mediated schemes.
>>
>> As you know, mining is not a race (ignoring edge effects with
>> orphaning/propagation time). Increasing difficulty does not put you at
>> an expected return disavantage compared to other miners so long as the
>> income increases at least proportionally (otherwise pooling with low
>> diff shares would be an astronomically losing proposition :)!).
>>
>> Pay-for-size schemes have been successfully used in some altcoins
>> without the effects you're suggesting.
>> ___
>> 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] BIP 100 specification

[Btc Drak via bitcoin-dev]

If you read between the lines of what was recently changed and why
(reducing to 2MB), it seems reasonable to assume BIP101's allowance
opens up some of the attack vector again.

On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev
 wrote:
> Maybe grab some code from BIP101 ?  It permits block messages > 2MB,
> while retaining the current limit of 2 MB imposed on other network
> messages.  The 32 MB limit was patched a few months ago.
>
> Links to code:
>
> https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
>
>
>
> On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
>> The 32Mb limit is
>> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>>
>> It's to keep the message size small enough that messages can be
>> serialized in memory.
>>
>> Jeff if you decide to lift the 32MB limit (you really should, unless
>> your plan is to potentially hard force another Blocksize discussion
>> again which might be okay). I suggest having the 32MB ceiling auto-raise
>> according to a exponential factor (1.5?) starting 1 year from now.
>>
>> Basically hard limit ceiling 2016-2017: 32 MB
>> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>>
>> The factor could be 2 like BIP-101 but I imagine you will want to be
>> more conservative. The delay time could also be longer if you think it
>> will take longer to fix the message size issue across all implementations.
>>
> ___
> 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] BIP 100 specification

[Btc Drak via bitcoin-dev]

On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik  wrote:
> A discussion of rolling out BIP 100 will not be avoided :)
>
> It is a hard fork; it would be silly to elide discussion of these key
> issues.
>
> I don't get the community's recent interest in avoiding certain topics.

It's not a matter of avoiding the subject, it's a whole separate
discussion and in the interests of efficient discussion, it is best
done separately. There's a whole BIP dedicated to the discussion of
consensus forks which you should probably give some input in also,
BIP99 [1]

Once we come to an agreement and can say "here's what we're doing
about blocksize, it will be X, or we'll raise by this algo", then we
can discuss the best way to implement the hard fork.

[1] https://github.com/bitcoin/bips/pull/181


>
>
>
> On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak  wrote:
>>
>> We should avoid discussing actual hard fork/softfork deployment
>> methodologies when discussing blocksize proposals because deployment
>> is a separate issue. As a recent case in point, look at how BIP65
>> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
>> That lead to a focused discussion of the functionality and relatively
>> quick inclusion.
>>
>> Deployment really is a separate issue than the mechanics of how BIP100
>> will function after activation.
>>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>>  wrote:
>> > Some comments:
>> >
>> > The 75% rule is meaningless here. Since this is a pure relaxation of
>> > rules,
>> > there is no such thing as "invalid version 4 blocks"
>> >
>> > The implication threshold is unclear. Is it 95% or 80%?
>> >
>> > Softfork requires a very high threshold (95%) to "attack" the original
>> > fork.
>> > This makes sure that unupgraded client will only see the new fork.
>> > In the case of hardfork, however, the new fork is unable to attack the
>> > original fork, and unupgraded client will never see the new fork. The
>> > initiation of a hardfork should be based on its acceptance by the
>> > economic
>> > majority, not miner support. 95% is an overkill and may probably never
>> > accomplished. I strongly prefer a 80% threshold rather than 95%.
>> >
>> > As I've pointed out, using 20-percentile rather than median creates an
>> > incentive to 51% attack the uncooperative minority.
>> >
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>> >
>> > Having said that, I don't have a strong feeling about the use of
>> > 20-percentile as threshold to increase the block size. That means the
>> > block
>> > size is increased only when most miners agree, which sounds ok to me.
>> >
>> > However, using 20-percentile as threshold to DECREASE the block size
>> > could
>> > be very dangerous. Consider that the block size has been stable at 8MB
>> > for a
>> > few years. Everyone are happy with that. An attacker would just need to
>> > acquire 21% of mining power to break the status quo and send us all the
>> > way
>> > to 1MB. The only way to stop such attempt is to 51% attack the attacker.
>> > That'd be really ugly.
>> >
>> > For technical and ethical reasons, I believe the thresholds for increase
>> > and
>> > decrease must be symmetrical: increase the block size when the
>> > x-percentile
>> > is bigger than the current size, decrease the block size when the
>> > (100-x)-percentile is smaller than the current size. The overall effect
>> > is:
>> > the block size remains unchanged unless 80% of miners agree to.
>> >
>> > Please consider the use of "hardfork bit" to signify the hardfork:
>> >
>> >
>> > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>> >
>> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>> >
>> > Or, alternatively, please combine the hardfork with a softfork. I'm
>> > rewriting the specification as follow (changes underlined):
>> >
>> > Replace static 1M block size hard limit with a floating limit
>> > ("hardLimit").
>> >
>> > hardLimit floats within the range 1-32M, inclusive.
>> >
>> > Initial value of hardLimit is 1M, preserving current system.
>> >
>> > Changing hardLimit is accomplished by encoding a proposed value within a
>> > block's coinbase scriptSig.
>> >
>> > Votes refer to a byte value, encoded within the pattern "/BV\d+/"
>> > Example:
>> > /BV800/ votes for 8,000,000 byte hardLimit. If there is more than
>> > one
>> > match with with pattern, the first match is counted.
>> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
>> > votes. Votes above the maximum cap (32M) are counted as 32M votes.
>> > A new hardLimit is calculated at each difficult adjustment period (2016
>> > blocks), and applies to the next 2016 blocks.
>> > Calculate hardLimit by examining the coinbase scriptSig votes of the
>> > previous 12,000 blocks, and taking the 20th percentile and 80th
>> > 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Btc Drak via bitcoin-dev]

I'm rather perplexed about this proposal. What exactly is wrong with
the existing BIPs process? I mean, it seems to me anyone can publish a
BIP pretty easily in the BIPs repository. There doesnt seems to be any
real barrier to entry whatsoever. I know there have been all manner of
aspersions, but having just written two BIPs there was no friction at
all.

Whether the ecosystem adopts a BIP is another question of course, but
that's out of scope of the BIPs project anyhow. Take BIP101
controversial as it gets, but it's there. Whether Bitcoin implementers
implement it is another kettle of fish and a matter for each project
to decide. It's absolutely NOT the realm of the BIPs project itself.
Bitcoin Core does not make any consensus critical changes with a BIP.
Where one seeks to establish certain standards, say for privacy, a BIP
would be appropriate so the ecosystem can harmonise methodology across
the board.

The status of a BIP is not really determined by anyone, it's by
adoption - that's where consensus happens. There's a little legroom
around this but I'm not entirely sure what you are trying to solve.
Yes the process is loose, but is it broken? There have been a flood of
BIPs added recently with zero bureaucracy or friction.

BIP0001 is the BIP that defines the BIP process. Interestingly enough
the only BIP that might be controversial is in fact a BIP to change
the way BIPs are handled!

So I'd really prefer to start this conversation with a breakdown of
what you think is broken first before tackling what may or may not
need fixing. I would be very cautious bringing "administrative"
burdens to the process or evicting common sense from the proceedings.
Much of the debates around consensus building seem to negate the
importance of common sense and the simple fact that "it's obvious when
you see it".

I'm sure there can be improvements, but for me personally, I need to
see what is broken before I can make any judgement on a potential way
forward, and if it's not broken, we should leave it alone.


On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
 wrote:
> As posted:
>
> **Enforcement/Organization** I agree with your comments. I don't believe in
> setting up an organization to manage this process (would be too much power
> and not really needed because the internet is pretty good at information
> sharing). Therefore, I designed it around the assumption that participation
> is voluntary. This means that it's hard to enforce rules like forcing groups
> to see the other side. Groupthink/Echo chambers is real and is bad but it's
> hard to change human nature.
>
> In regards to enforcement, I believe that the best approach would be to
> motivate committees to produce the best opinion they can (and also proof of
> stake, another weak point in this proposal), as the better they can do this
> the more likely the community will accept their opinion as valid and
> important.
>
> Indeed, I believe that without an organization managing the process, it's up
> to each individual reader of each BIP/Opinions set to make the decision on
> whether or not there is clear and true community acceptance.
>
> 
>
> **Committee versus another approach**
>
> Pros of using Committees:
>
> * Committees are used today in many fields with a range of success. Lots of
> previous work to work off of here, history is established.
> * Many segments already have committee-like structures (Merchants produce
> shared signed documents, miners often represent themselves, User groups have
> representatives like voting on subreddit moderators, Core Devs have Core
> Devs)
> * Committees can filter a range of opinions down to a yes/no
> * Committees have real people that can be talked to, contacted, etc.
> * Much easier to proof stake in a range (People generally accept the Bitcoin
> Core has 70-90% of the market share) vs someone trying to proof they make up
> (.01% of the Bitcoin user-base)
> * Committees have some stability, encourages experience and expertise
> (Committee members can be knowledgeable in their area and adequately
> understand BIPs)
>
> Cons:
>
> * Fear of committees working in the dark, censoring opinions (i.e. "Dark
> smokey room of fat cats") (Possible solution: make committee power fluid
> i.e. easily abandon-able: miners can change pools, users can change client
> forks, change merchants, users can re-group, encourage transparency)
> * More centralized, centralization of power (generally bad) (Possible
> solution: encourage smaller committees)
> * Centralization pressure (groups may seek to consolidate to gain power)
> (Possible solution: Segmentation)
> * Encourages groupthink, political maneuvers, turns good people into
> politicians, mud-tossing
>
> **Another possible approach: micro votes**
>
> Pros:
>
> * Each user can represent themselves, no censorship
> * People feel more involved and empowered
>
> Cons:
>
> * How to prove and prevent manipulation?
> * Only 

Re: [bitcoin-dev] Problem compiling bitcoin-core

[Btc Drak via bitcoin-dev]

I mailed the solution privately, but for the record he was using the
wrong build option which should have been --with-gui=no

On Mon, Sep 7, 2015 at 9:58 AM, Sriram Karra via bitcoin-dev
 wrote:
> Your problem is it cannot find your Boost libs. Why exactly are you trying
> to build with a custom lib directory?
>
>
>
> On Sat, Sep 5, 2015 at 11:24 PM, LinuXperia via bitcoin-dev
>  wrote:
>>
>> Hi.
>>
>> I am trying to compile bitcoin core on my ubuntu Linux machine as follow:
>>
>> ./autogen.sh
>>
>> ./configure
>> CPPFLAGS="-I/media/linuxperia/mydata/Projects/bitcoi/depends/x86_64-unknown-linux-gnu/include/
>> -O2"
>> LDFLAGS="-L/media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/lib/"
>> --without-gui
>>
>> make
>>
>> but i am getting always this Build Error message here!
>> What i am doing wrong ?
>> How can i fix this build problem so i am able to run the Bitcoin-core Node
>> on my Machine ?
>>
>> Thanks in advance for your helpful solution tips!
>>
>>CXXLDbitcoind
>> libbitcoin_server.a(libbitcoin_server_a-init.o): In function
>> `boost::filesystem::path::path(boost::filesystem::directory_entry
>> const&,
>> boost::enable_if,
>> void>::type*)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/filesystem/path.hpp:140:
>> undefined reference to
>> `boost::filesystem::path_traits::dispatch(boost::filesystem::directory_entry
>> const&, std::__cxx11::basic_string> std::allocator >&)'
>> libbitcoin_util.a(libbitcoin_util_a-util.o): In function `GetNumCores()':
>> /media/linuxperia/mydata/Projects/bitcoin/src/util.cpp:825: undefined
>> reference to `boost::thread::physical_concurrency()'
>> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
>> `boost::program_options::detail::basic_config_file_iterator::getline(std::__cxx11::basic_string> std::char_traits, std::allocator >&)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/program_options/detail/config_file.hpp:161:
>> undefined reference to
>> `boost::program_options::to_internal(std::__cxx11::basic_string> std::char_traits, std::allocator > const&)'
>> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
>> `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
>> std::set> std::allocator >, std::less> std::char_traits, std::allocator > >,
>> std::allocator> std::allocator > > > const&, bool)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/program_options/detail/config_file.hpp:145:
>> undefined reference to
>> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set> std::char_traits, std::allocator >,
>> std::less> std::allocator > >, std::allocator> std::char_traits, std::allocator > > > const&, bool)'
>> libbitcoin_wallet.a(libbitcoin_wallet_a-walletdb.o): In function
>> `boost::filesystem::copy_file(boost::filesystem::path const&,
>> boost::filesystem::path const&, boost::filesystem::copy_option::enum_type)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/filesystem/operations.hpp:497:
>> undefined reference to
>> `boost::filesystem::detail::copy_file(boost::filesystem::path const&,
>> boost::filesystem::path const&, boost::filesystem::detail::copy_option,
>> boost::system::error_code*)'
>> collect2: error: ld returned 1 exit status
>> Makefile:2620: recipe for target 'bitcoind' failed
>> make[2]: *** [bitcoind] Error 1
>> make[2]: Leaving directory '/media/linuxperia/mydata/Projects/bitcoin/src'
>> Makefile:6559: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory '/media/linuxperia/mydata/Projects/bitcoin/src'
>> Makefile:626: recipe for target 'all-recursive' failed
>> make: *** [all-recursive] Error 1
>>
>> ___
>> 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] Dynamic limit to the block size - BIP draft discussion

[Btc Drak via bitcoin-dev]

> but allow meaningful relief to transaction volume pressure in response to 
> true market demand

If blocksize can only increase then it's like a market that only goes
up which is unrealistic. Transaction will volume ebb and flow
significantly. Some people have been looking at transaction volume
charts over time and all they can see is an exponential curve which
they think will go on forever, yet nothing goes up forever and it will
go through significant trend cycles (like everything does). If you
dont want to hurt the fee market, the blocksize has to be elastic and
allow contraction as well as expansion.

On Tue, Sep 8, 2015 at 8:45 AM, Washington Sanchez via bitcoin-dev
 wrote:
> Hi everyone,
>
> I know many of us feel that the last thing the Bitcoin community needs is
> another BIP related to the block size, but after a lot of reading and
> commenting, I'd like to throw this idea out there.
>
> I've already written it up as a BIP and would like some constructive
> feedback/suggestions/alternatives related to some of the variables in my
> specification:
>
>
> Dynamic limit to the block size
> ===
>
> The goal is to dynamically increase the maximum block size conservatively,
> but allow meaningful relief to transaction volume pressure in response to
> true market demand. The specification follows:
>
> - Every 4032 blocks (~4 weeks), the maximum block size will be increased by
> 10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
> size at that time
>   + This calculates to theoretically 13 increases per year
> - The maximum block size can only ever be increased, not decreased
>
> For example, if this rule were to be instituted January 1st 2016, with a
> present maximum block size 1 MB, the limit would be increased to 1.1 MB on
> January 29th 2016. The theoretical maximum block size at the end of 2016
> would be ~3.45 MB, assuming all 13 increases are triggered.
>
> As the maximum block size rises, so the cost of artificially triggering an
> increase in the maximum block size.
>
>
> Regards,
> Wash
>
>
> ---
> Dr Washington Y. Sanchez
> Co-founder, OB1
> Core developer of OpenBazaar
> @drwasho
>
>
> ___
> 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] BIP 100 specification

[Btc Drak via bitcoin-dev]

We should avoid discussing actual hard fork/softfork deployment
methodologies when discussing blocksize proposals because deployment
is a separate issue. As a recent case in point, look at how BIP65
(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
That lead to a focused discussion of the functionality and relatively
quick inclusion.

Deployment really is a separate issue than the mechanics of how BIP100
will function after activation.

On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
 wrote:
> Some comments:
>
> The 75% rule is meaningless here. Since this is a pure relaxation of rules,
> there is no such thing as "invalid version 4 blocks"
>
> The implication threshold is unclear. Is it 95% or 80%?
>
> Softfork requires a very high threshold (95%) to "attack" the original fork.
> This makes sure that unupgraded client will only see the new fork.
> In the case of hardfork, however, the new fork is unable to attack the
> original fork, and unupgraded client will never see the new fork. The
> initiation of a hardfork should be based on its acceptance by the economic
> majority, not miner support. 95% is an overkill and may probably never
> accomplished. I strongly prefer a 80% threshold rather than 95%.
>
> As I've pointed out, using 20-percentile rather than median creates an
> incentive to 51% attack the uncooperative minority.
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the block
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size could
> be very dangerous. Consider that the block size has been stable at 8MB for a
> few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the way
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase and
> decrease must be symmetrical: increase the block size when the x-percentile
> is bigger than the current size, decrease the block size when the
> (100-x)-percentile is smaller than the current size. The overall effect is:
> the block size remains unchanged unless 80% of miners agree to.
>
> Please consider the use of "hardfork bit" to signify the hardfork:
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
> Or, alternatively, please combine the hardfork with a softfork. I'm
> rewriting the specification as follow (changes underlined):
>
> Replace static 1M block size hard limit with a floating limit ("hardLimit").
>
> hardLimit floats within the range 1-32M, inclusive.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> Changing hardLimit is accomplished by encoding a proposed value within a
> block's coinbase scriptSig.
>
> Votes refer to a byte value, encoded within the pattern "/BV\d+/" Example:
> /BV800/ votes for 8,000,000 byte hardLimit. If there is more than one
> match with with pattern, the first match is counted.
> Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
> votes. Votes above the maximum cap (32M) are counted as 32M votes.
> A new hardLimit is calculated at each difficult adjustment period (2016
> blocks), and applies to the next 2016 blocks.
> Calculate hardLimit by examining the coinbase scriptSig votes of the
> previous 12,000 blocks, and taking the 20th percentile and 80th percentile.
> New hardLimit is the median of the followings:
>
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
>
> version 4 block: the coinbase of a version 4 block must match this pattern:
> "/BV\d+/"
> 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
> reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
> version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last
> 1000)
> Block version number is calculated after masking out high 16 bits (final bit
> count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
>> BIP 100 initial public draft:
>> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>>
>> Emphasis on "initial"  This is a starting point for the usual open
>> source feedback/iteration cycle, not an endpoint that Must Be This
>> Way.
>>
>>
>>
>> Links:
>> --
>> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>>
>> ___
>> bitcoin-dev mailing list
>> 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Btc Drak via bitcoin-dev]

Sorry not to reply earlier. I have a rather long post. I've split it
into two sections, one explaining the background and secondly talking
very specifically about your proposal and possible areas to look at.

I think there's a key misunderstanding about BIPs and "who decides
what in Bitcoin". A BIP usually defines some problem and a solutions
or helps communicate proposals to the technical community. They are
sort of mini white papers on specific topics often with reference
implementations attached. They may be consensus critical, or not. The
process for getting a BIP published is fairly loose in that it really
just requires some discussion and relevance to Bitcoin regardless of
whether the proposal is something that would be accepted or used by
others in the ecosystem. The BIP editor is obviously going to filter
out obvious nonesense and that shouldn't be controversial but obvious
when you see it.

You need to separate out the idea of BIPs as is, and implementations
of BIPs in Bitcoin software (like Bitcoin Core).

Take BIP64 for example. It's a proposal that adds a service to nodes
allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
as a project has not implemented it but was instead implemented in XT
and is utilised by Lighthouse. So the BIP specification is there in
the BIPs repository. As far as the bitcoin ecosystem goes, only
Bitcoin XT and lighthouse utilise it so far.

BIP101 is another example, but one of a consensus critical proposal
that would change the Bitcoin protocol (i.e. requires a hard fork). It
was adopted by only the XT project and so far no other software. At
the time of writing miners have chosen not to run implementations of
BIP101.

You can see the BIPs authoring and publishing process is a separate
issue entirely to the implementation and acceptance by the Bitcoin
ecosystem.

For non-consensus critical proposals like BIP64, or maybe one relating
to privacy (how to order transaction output for example), you could
judge acceptance of the proposal by the number of software projects
that implement the proposal, and the number of users it impacts. If a
proposal is utilised by many projects, but not the few projects that
have the majority of users, one could not claim wide acceptance.

For consensus critical proposals like BIP66 (Strict DER encoding) this
BIP was implemented in at least two bitcoin software implementations.
Over 95% of miners adopted the proposal over a 4.5 month period. The
BIP became de facto accepted, and in fact, once 95% lock-in was
achieved, the BIP became Final by rights that the consensus rules for
the Bitcoin network had changed.

In the case of consensus critical proposals like that, you can only
write proposals, implement it in software and hope they are adopted.

Now where does the confusion arise? Well, Bitcoin Core is the de facto
reference implementation by virtue of having the largest technical
contributor base and the widest userbase of any Bitcoin full node
implementation. This is where I believe, the community get stuck in
their assumptions and is so obvious it may have been overlooked.

Consensus rule changes to Bitcoin Core are always documented as BIPs
so the exact details can be picked up by other software implementers
(if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
opcode. The proposal implemented in Bitcoin Core and eventually
merged. Peter also authored BIP65 (required because without it, his
proposal could not be considered for Bitcoin Core).

It is not that BIP65 was somehow "accepted", in fact, as it stands,
BIP65 is still just a draft because while there is a BIP and a
reference implementation in Bitcoin Core, the consensus changes to the
Bitcoin protocol have not been proposed to the community (through a
soft fork), and thus acceptance is still only a possibility (although
acceptance is extremely likely because service providers are literally
chomping at the bit waiting for deployment).

Also I would like to note that it's only an internal rule of Bitcoin
Core that consensus rule changes require a formal BIP. It is not a
requirement laid down from the BIP gods. BIPs simply serve as a way to
communicate ideas and proposals. The community at large will decide if
a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
major influence on this because they have the largest user base. It is
relevant to say the large userbase is not just a historical artefact
by virtue of being the first Bitcoin implementation. Bitcoin Core is
widely trusted by commercial users because of the high developer
count, wide technical expertise and relative security given knowing
that they will be supported with security and maintenance releases.

YOUR PROPOSAL

Getting back to your specific proposal. It seems to focus more on
getting BIPs accepted in the sense of published and missed the wider
picture. As I have detailed, getting published isnt a problem. Anyone
can make a proposal, so long as it's not obviously 

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

[Btc Drak via bitcoin-dev]

Rusty,

I think you've covered all the issues discussed now. +1 for submitting to
BIPs repo to get an official number.

Are you planning to write the implementation?



On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Those who've seen the original versionbits bip, this adds:
>1) Percentage checking only on retarget period boundaries.
>2) 1 retarget period between 95% and activation.
>3) A stronger suggestion for timeout value selection.
>
> https://gist.github.com/rustyrussell/47eb08093373f71f87de
>
> And pasted below, de-formatted a little.
>
> Thanks,
> Rusty.
>
>   BIP: ??
>   Title: Version bits with timeout and delay
>   Author: Pieter Wuille , Peter Todd <
> p...@petertodd.org>, Greg Maxwell , Rusty Russell <
> ru...@rustcorp.com.au>
>   Status: Draft
>   Type: Informational Track
>   Created: 2015-10-04
>
> ==Abstract==
>
> This document specifies a proposed change to the semantics of the
> 'version' field in Bitcoin blocks, allowing multiple backward-compatible
> changes (further called called "soft forks") being deployed in parallel. It
> relies on interpreting the version field as a bit vector, where each bit
> can be used to track an independent change. These are tallied each retarget
> period. Once the consensus change succeeds or times out, there is a
> "fallow" pause after which the bit can be reused for later changes.
>
> ==Motivation==
>
> BIP 34 introduced a mechanism for doing soft-forking changes without
> predefined flag timestamp (or flag block height), instead relying on
> measuring miner support indicated by a higher version number in block
> headers. As it relies on comparing version numbers as integers however, it
> only supports one single change being rolled out at once, requiring
> coordination between proposals, and does not allow for permanent rejection:
> as long as one soft fork is not fully rolled out, no future one can be
> scheduled.
>
> In addition, BIP 34 made the integer comparison (nVersion >= 2) a
> consensus rule after its 95% threshold was reached, removing 2^31 +2 values
> from the set of valid version numbers (all negative numbers, as nVersion is
> interpreted as a signed integer, as well as 0 and 1). This indicates
> another downside this approach: every upgrade permanently restricts the set
> of allowed nVersion field values. This approach was later reused in BIP 66,
> which further removed nVersion = 2 as valid option. As will be shown
> further, this is unnecessary.
>
> ==Specification==
>
> ===Mechanism===
>
> '''Bit flags'''
> We are permitting several independent soft forks to be deployed in
> parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is
> not currently in use for any other ongoing soft fork. Miners signal intent
> to enforce the new rules associated with the proposed soft fork by setting
> bit 1B in nVersion to 1 in their blocks.
>
> '''High bits'''
> The highest 3 bits are set to 001, so the range of actually possible
> nVersion values is [0x2000...0x3FFF], inclusive. This leaves two
> future upgrades for different mechanisms (top bits 010 and 011), while
> complying to the constraints set by BIP34 and BIP66. Having more than 29
> available bits for parallel soft forks does not add anything anyway, as the
> (nVersion >= 3) requirement already makes that impossible.
>
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''.  Transitions are considered after each
> retarget period.
>
> '''Soft Fork Support'''
> Software which supports the change should begin by setting B in all blocks
> mined until it is resolved.
>
>  if (BState == defined) {
>  SetBInBlock();
>  }
>
> '''Success: Lock-in Threshold'''
> If bit B is set in 1916 (1512 on testnet) or more of the 2016 blocks
> within a retarget period, it is considered ''locked-in''.  Miners should
> stop setting bit B.
>
>  if (NextBlockHeight % 2016 == 0) {
> if (BState == defined && Previous2016BlocksCountB() >= 1916) {
> BState = locked-in;
> BActiveHeight = NextBlockHeight + 2016;
> }
>  }
>
> '''Success: Activation Delay'''
> The consensus rules related to ''locked-in'' soft fork will be enforced in
> the second retarget period; ie. there is a one retarget period in
> which the remaining 5% can upgrade.  At the that activation block and
> after, the bit B may be reused for a different soft fork.
>
>  if (BState == locked-in && NextBlockHeight == BActiveHeight) {
> BState = activated;
> ApplyRulesForBFromNextBlock();
> /* B can be reused, immediately */
>  }
>
> '''Failure: Timeout'''
> A soft fork proposal should include a ''timeout''.  This is measured
> as the beginning of a calendar year as per this table (suggested
> three years from drafting the soft fork proposal):
>
> Timeout Year

Re: [bitcoin-dev] libconsensus and bitcoin development process

[Btc Drak via bitcoin-dev]

On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik  wrote:

> The problem comes with the impact of an unfocused stream of refactors to
> key code.
>
> For example, there is much less long term developer impact if refactoring
> were _accelerated_, scheduled to be performed in a one-week sprint.  There
> is a lot of breakage, yes, but after that week the average level of
> downstream patch breakage is significantly lower.  A "rip the band-aid off
> quickly rather than slowly" approach.
>

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

Re: [bitcoin-dev] libconsensus and bitcoin development process

[Btc Drak via bitcoin-dev]

I also share a lot of Jeff's concerns about refactoring and have voiced
them several times on IRC and in private to Jorge, Wladamir and Greg. I
meant to do a write up but never got around to it. Jeff has quite
eloquently stated the various problems. I would like to share my thoughts
on the matter because we really do need to come up with a plan on how this
issue is dealt with.

Obviously, Bitcoin Core is quite tightly coupled at the moment and
definitely needs extensive modularisation. Such work will inevitably
require lots of bulk code moves and then finer refactoring. However, it
requires proper planning because there are lots of effects and consequences
for other people contributing to Core and also downstream projects relying
on Core:

1. Refactoring often causes other pull requests to diverge and require
rebasing. Continual refactoring can put PRs in "rebase hell" and puts a big
stress on contributors (many of whom are part time).

2. Version to version, Bitcoin Core changes significantly in structure. 0.9
to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This makes makes
it hard to follow release to release and the net result is less people
upgrade (especially think of miners trying to keep their patch sets working
while trying not to disrupt or risk their mining operations).

3. Continual refactoring increases risk: we're human, and mistakes will
slip through peer review. This is especially concerning with consensus
critical code and this makes it difficult to merge such refactoring often,
which of course exacerbates the problem.

The net negative consequence is it is harder to contribute to Core, harder
for the Core maintainers to merge and harder for downstream/dependent
projects/implementations to keep up.

Suggested Way Forward
-

With the understanding that refactored code by definition must not change
behaviour. There are three major kinds of refactoring:

1. code moves (e.g. separating concerns into different files);
2. code style;
3. structural optimisation and consolidation (reducing LOC, separating
concerns, encapsulation etc).

Code moves(1) and CS(2) are easy to peer review and merge quickly. The
third kind(3) requires deeper analysis to ensure that while the code
changed, the behaviour (including any bugs) did not.

We must resist all temptation to fix bugs or tack on minor fixes and tweaks
during refactoring: pull requests should only be refactoring only, with no
net change to behaviour. Keeping discipline makes it much easier to verify
and peer review and this faster to merge.

With respect to Code moves and CS, I believe we should have a "refactoring
fortnight" where we so the bulk of code move-only refactoring plus CS where
necessary. This is by fat the most disruptive kind of change because it
widely affects other PRs mergeability. We should aim to get most of this
done in one go, so that it's not happening in dribs and drabs over months
and many releases. Once done, it gives everyone a good idea to the overall
new structure and where one can expect to find things in the future. The
idea here is to help orientation and not have to continuously hunt for
where things have moved to.

To be clear, I am strongly suggesting code move-only refactoring PRs not be
mixed with anything else. Same for CS changes. This makes the PRs extremely
easy to vet and thus quick to merge.

Towards this end, maybe there should be an IRC meeting to agree the initial
moves, then someone who has the stomach for it can get on and do it -
during that time, we do not merge anything else. We need to bite the bullet
and break the back out of code moves.

With regards to CS, I think we do need to get CS right, because a continual
dribble of CS changes also makes diffs between releases less easy to
follow. Much of CS checking can be automated by the continuous integration
so authors can get it right easily. It can be just like a Travis check.

With respect to the 3rd kind of refactoring, we need to set some standards
and goals and aim for some kind of consistency. Refactoring needs to fulfil
certain goals and criterion otherwise contributors will always find a
reason to fiddle over and over forever. Obvious targets here can be things
like proper encapsulation and separation of concerns.

Overall, refactoring should be merged quickly, but only on a schedule so it
doesn't cause major disruption to others.

Obviously the third kind of refactoring more complex and time consuming and
will need to occur over time, but it should happen in defined steps. As
Jeff said, one week a month, or maybe one month a release. In any case,
refactoring changes should be quickly accepted or rejected by the project
maintainer and not left hanging.

Finally, refactoring should *always* be uncontroversial because essentially
functionality is not changing. If functionality changes (e.g. you try to
sneak in a big fix or feature tweak "because it's small") the PR should be
rejected outright. 

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Btc Drak via bitcoin-dev]

Where do we stand now on which sequencenumbers variation to use? We really
should make a decision now.

On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> So I've created 2 new repositories with changed rules regarding
> sequencenumbers:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers2
>
> This repository inverts (un-inverts?) the sequence number. nSequence=1
> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1
> second relative lock-height. nSequence>=0x8000 (most significant bit
> set) is not interpreted as a relative lock-time.
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers3
>
> This repository not only inverts the sequence number, but also interprets
> it as a fixed-point number. This allows up to 5 year relative lock times
> using blocks as units, and saves 12 low-order bits for future use. Or, up
> to about 2 year relative lock times using seconds as units, and saves 4
> bits for future use without second-level granularity. More bits could be
> recovered from time-based locktimes by choosing a higher granularity (a
> soft-fork change if done correctly).
>
> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach 
> wrote:
>
>> To follow up on this, let's say that you want to be able to have up to 1
>> year relative lock-times. This choice is somewhat arbitrary and what I
>> would like some input on, but I'll come back to this point.
>>
>>  * 1 bit is necessary to enable/disable relative lock-time.
>>
>>  * 1 bit is necessary to indicate whether seconds vs blocks as the unit
>> of measurement.
>>
>>  * 1 year of time with 1-second granularity requires 25 bits. However
>> since blocks occur at approximately 10 minute intervals on average, having
>> a relative lock-time significantly less than this interval doesn't make
>> much sense. A granularity of 256 seconds would be greater than the Nyquist
>> frequency and requires only 17 bits.
>>
>>  * 1 year of blocks with 1-block granularity requires 16 bits.
>>
>> So time-based relative lock time requires about 19 bits, and block-based
>> relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
>> other uses.
>>
>> Assuming a maximum of 1-year relative lock-times. But what is an
>> appropriate maximum to choose? The use cases I have considered have only
>> had lock times on the order of a few days to a month or so. However I would
>> feel uncomfortable going less than a year for a hard maximum, and am having
>> trouble thinking of any use case that would require more than a year of
>> lock-time. Can anyone else think of a use case that requires >1yr relative
>> lock-time?
>>
>> TL;DR
>>
>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach 
>> wrote:
>>
>>> A power of 2 would be far more efficient here. The key question is how
>>> long of a relative block time do you need? Figure out what the maximum
>>> should be ( I don't know what that would be, any ideas?) and then see how
>>> many bits you have left over.
>>> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
  wrote:
 > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
 > discussion has any thought been given to represent one block with more
 > than one increment?  This would leave additional space for future
 > signaling, or allow, for example, higher resolution numbers for a
 > sharechain commitement.

 No, I don't think anybody thought about this. I just explained this to
 Pieter using "for example, 10 instead of 1".
 He suggested 600 increments so that it is more similar to timestamps.
 ___
 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] Fill-or-kill transaction

[Btc Drak via bitcoin-dev]

On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Btc Drak 於 2015-09-17 15:12 寫到:
>
>> Forgive me if I have missed the exact use-case, but this seems overly
>> complex. Surely fill-or-kill refers to getting a transaction confirmed
>> within a few confirms or to drop the tx from the mempool so it wont be
>> considered for inclusion anymore. As such, you could just repurpose a
>> small range of nLocktime such that a TX will be accepted into mempool
>> for a specific period before expiring.
>>
>
> What I'm describing is to implement fill-or-kill as consensus rule.
> Certainly, we could implement it at the P2P network level: everything is
> the same as I described, but the nLockTime2 and nKillTime are for reference
> only and tx validity depends only on the nLockTime. Benevolent miners
> should drop the tx after the suggested kill time but there is no guarantee
>

Sure, you can make the scheme I describe consensus based by adding the rule
tx is not valid to mine after expiry: this still keeps the simplicity I
described.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Btc Drak via bitcoin-dev]

On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Any particular reason bitcoin versioning doesn't follow the SemVer spec?
>

We do: a.b.c, the next major version is, 0.12.0, and maintenance releases
are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Btc Drak via bitcoin-dev]

On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-fork with CSV using the nVersion bits mechanism.
>
> nVersion bits doesn't even have an implementation yet, nor has solid
> consensus been reached on the exact semantics of how nVersion bits
> should work.


Small correction, the suggestion is to aim to roll out CLTV+CSV together by
0.12 release, using IsSuperMajority() (or versionbits if it is ready by
then). If CSV is not ready by then, we'd just roll out CLTV.

However, the CSV related pull requests are ready for final review and if
that can happen soon I don't see why we wouldn't roll CLTV+CSV out together
before 0.12. A considerable amount of time, discussion and iterations have
occurred for the related PRs and I believe they are at the point of
consensus modulo final review before merging.

References:

Mempool-only sequence number constraint verification
https://github.com/bitcoin/bitcoin/pull/6312

Mempool-only CHECKSEQUENCEVERIFY
https://github.com/bitcoin/bitcoin/pull/6564

Mempool-only Median time-past as endpoint for lock-time calculations
https://github.com/bitcoin/bitcoin/pull/6566
___
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

[Btc Drak via bitcoin-dev]

Regarding the keeping nSequence for future expansion I believe this has
been covered in the specification section of BIP68[1]: For transaction
version >= 2, if the MSB of nSequence is unset, the field is interpreted as
relative locktime, otherwise no special consensus meaning is attached (and
thus free for repurposing in the future). Effectively if the MSB is set,
the remaining 31 bits (out of 32) are free.

Also please note the BIP112 text has been updated with several more
usecases.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

[Btc Drak via bitcoin-dev]

On Mon, Oct 5, 2015 at 6:33 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I also agree with Mike that Core's requirement for unanimous consensus
> results in development grid lock and should be revisited.
>

There is no development gridlock. Look at the IRC logs for core-dev; look
at the pull requests; look a the merge history: Development is vibrant.
Developers are very active. You are manufacturing a crisis convenient to
your narrative, but it is far from the actual reality on the ground.

Please desist from this intellectual dishonesty and toxicity.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Weekly development meetings on IRC

[Btc Drak via bitcoin-dev]

Urgh... Can we hardfork time? It's clearly in need of an upgrade...

On Fri, Sep 18, 2015 at 9:31 PM, Gregory Maxwell  wrote:

> On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
>  wrote:
> > Google Calendar is localized, but has an option to change the timezone
> > of an event, it just doesnt have UTC in its options. So, yes, we should
> > use something that observes DST in roughly the same way as everyone else
> > - CEST/PDT/EST/etc.
>
> uh. There is fairly little global consistency in DST usage. Lots of
> places do dst on different dates.
>
> So if it's in some DST timezone it's likely to move twice each change
> for some subset of the people who do it.
>
> E.g. europe and US end DST one week apart.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via bitcoin-dev]

On Fri, Aug 28, 2015 at 11:24 PM, Gavin gavinandre...@gmail.com wrote:
 With this proposal, how much would it cost a miner to include an 'extra' 
 500-byte transaction if the average block size is 900K and it costs the miner 
 20BTC in electricity/capital/etc to mine a block?

 If my understanding of the proposal is correct, it is:

 500/90 * 20 = 0.1 BTC

Typo, 0.0

 ... Or $2.50 at today's exchange rate.

 That seems excessive.

I am not sure how it is relevant to this proposal because miners are
not paying to include an extra transaction. The BIP details how miners
can vote for a larger block size limit during a window of 2016 blocks.
The block size limit does not increase during this phase. The block
size limit is adjusted at the end of the sample window and the new
size is valid until the next retargetting.

If this wasn't clear, please let me know if I need to clarify any
specifics in the wording of the proposal.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via bitcoin-dev]

I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.

I also request the BIP maintainer for a BIP number assignment

[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2] 
https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/

Pull request: https://github.com/bitcoin/bips/pull/187

pre
  BIP: XX
  Title: Consensus based block size retargeting algorithm
  Author: BtcDrak btcd...@gmail.com
  Status: Draft
  Type: Standards Track
  Created: 2015-08-21
/pre

==Abstract==

A method of altering the maximum allowed block size of the Bitcoin protocol
using a consensus based approach.

==Motivation==

There is a belief that Bitcoin cannot easily respond to raising the
blocksize limit if popularity was to suddenly increase due to a mass adoption
curve, because co-ordinating a hard fork takes considerable time, and being
unable to respond in a timely manner would irreparably harm the credibility of
bitcoin.

Additionally, predetermined block size increases are problematic because they
attempt to predict the future, and if too large could have unintended
consequences like damaging the possibility for a fee market to develop
as block subsidy decreases substantially over the next 9 years; introducing
or exacerbating mining attack vectors; or somehow affect the network in unknown
or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
extensive.

Dynamic block size adjustments also suffer from the potential to be gamed by the
larger hash power.

Free voting as suggested by BIP100 allows miners to sell their votes out of band
at no risk, and enable the sponsor the ability to manipulate the blocksize.
It also provides a cost free method or the larger pools to vote in ways to
manipulate the blocksize such to disadvantage or attack smaller pools.


==Rationale==

By introducing a cost to increase the block size ensures the mining community
will collude to increase it only when there is a clear necessity, and reduce it
when it is unnecessary. Larger miners cannot force their wishes so easily
because not only will they have to pay extra a difficulty target, then can be
downvoted at no cost by the objecting hash power.

Using difficulty as a penalty is better than a fixed cost in bitcoins because it
is less predictable.


==Specification==

The initial block size limit shall be 1MB.

Each time a miner creates a block, they may vote to increase or decrease the
blocksize by a maximum of 10% of the current block size limit. These votes will
be used to recalculate the new block size limit every 2016 blocks.

Votes are cast using the block's coinbase field.

The first 4 bytes of the coinbase field shall be repurposed for voting as an
unsigned long integer which will be the block size in bytes.

If a miner votes for an increase, the block hash must meet a difficulty target
which is proportionally larger than the standard difficulty target based on the
percentage increase they voted for.

Votes proposing decreasing the block size limit do not need to meet a higher
difficulty target.

Miners can vote for no change by voting for the current block size.

For blocks to be valid the blockhash must meet the required difficulty target
for the vote otherwise the block is invalid and will be rejected.

Every 2016 blocks, the block size limit will be recalculated by the median of
all votes in the last 2016 blocks. This will redefine the block size limit for
the next 2016 blocks.

Blocks that are larger than the calculated base block size limit are invalid and
will be rejected.

The base block size limit may not reduce below 1MB.


==Acknowledgements==

This proposal is based on ideas and concepts derived from the writings of
Meni Rosenfeld and Gregory Maxwell.


==Copyright==

This work is placed in the public domain.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Btc Drak via bitcoin-dev]

On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> > On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via
> bitcoin-dev wrote:
> >> TL;DR: I propose we work immediately towards the segwit 4MB block
> >> soft-fork which increases capacity and scalability, and recent speedups
> >> and incoming relay improvements make segwit a reasonable risk. BIP9
> >> and segwit will also make further improvements easier and faster to
> >> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
> >> scaling, while building additional tools that would make bandwidth
> >> increases safer long term. Further work will prepare Bitcoin for further
> >> increases, which will become possible when justified, while also
> providing
> >> the groundwork to make them justifiable.
> >
> > Sounds good to me.
>
> Better late than never, let me comment on why I believe pursuing this plan
> is important.
>
> For months, the block size debate, and the apparent need for agreement on
> a hardfork has distracted from needed engineering work, fed the external
> impression that nothing is being done, and generally created a toxic
> environment to work in. It has affected my own productivity and health, and
> I do not think I am alone.
>
> I believe that soft-fork segwit can help us out of this deadlock and get
> us going again. It does not require the pervasive assumption that the
> entire world will simultaneously switch to new consensus rules like a
> hardfork does, while at the same time:
> * Give a short-term capacity bump
> * Show the world that scalability is being worked on
> * Actually improve scalability (as opposed to just scale) by reducing
> bandwidth/storage and indirectly improving the effectiveness of systems
> like Lightning.
> * Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
>
> So I'd like to ask the community that we work towards this plan, as it
> allows to make progress without being forced to make a possibly divisive
> choice for one hardfork or another yet.
>
Thank you for saying this. I also think the plan is solid and delivers
multiple benefits without being contentious. The number of wins are so
numerous, it's frankly a no-brainer.

I guess the next step for segwit is a BIP and deployment on a testnet?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP68: Relative lock-time through consensus-enforced sequence numbers (update)

[Btc Drak via bitcoin-dev]

As I am sure you are aware, for the last 5 months work has been on-going to
create a relative lock-time proposal using sequence numbers. The
implementation can be found at https://github.com/bitcoin/bitcoin/pull/6312.
The current implementation is "mempool-only" and the soft-fork would be
deployed at a later stage.

Over these months there has been various discussion back and forth to
refine the details.

I have updated the BIP text now according to the details that were
discussed in mid-October[1][2] and have extensively clarified the text.

To recap, the overall picture for relative lock-time is that BIP68
introduces consensus rules using some of the nSequence field, while BIP112
creates a new opcode OP_CHECKSEQUENCEVERIFY (PR #6564) so relative
lock-time can be verified from the Bitcoin scripting language. Ideally we
would soft-fork BIP68, BIP112 (CSV) and 113 (MTP) together. BIP113 has been
deployed in 0.11.2 as mempool policy so miners should be applying this
policy as they deploy version 4 blocks for the ongoing CLTV soft-fork
(currently at 42% at the time of writing).

I am writing this mail to draw your attention to the BIP68 pull-requests
and to request final review at:

BIP68 text - https://github.com/bitcoin/bips/pull/245
BIP68 implementation - https://github.com/bitcoin/bitcoin/pull/6312

Discussion references:
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011357.html
[2] http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444928045.0
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP68: Second-level granularity doesn't make sense

[Btc Drak via bitcoin-dev]

On Tue, Nov 24, 2015 at 4:36 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The downside of BIP68 as written is users of by-height locktimes have 14
> bits unused in nSequence, but by-time locktimes have just 5 bits unused.
> This presents an awkward situation if we add new meanings to nSequence
> if we ever need more than 5 bits. Yet as shown above, the extra
> granularity doesn't have a practical benefit.
>
>
> Recommendation: Change BIP68 to make by-time locks have the same number
> of bits as by-height locks, and multiply the by-time lock field by the
> block interval.
>

I think you might be referring to the old specification. I believe this was
brought up before and the specification was changed so the same number of
bits were used for by-time and by-height. Please see
https://github.com/bitcoin/bips/pull/245

However, I am glad you came to the came conclusions independently because
"re-invention" often confirms good ideas :)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 2 promotion to Final

[Btc Drak via bitcoin-dev]

On Wed, Mar 16, 2016 at 10:24 PM, Luke Dashjr  wrote:

> BIP Comments are not a part of the BIP itself, merely post-completion notes
> from various external parties. So having them external does not make the
> BIP
> any less self-contained. Right now, this information takes the form of
> reddit/forum comments, IRC chats, etc.
>

BIP2 does not state the comments section is where discussion happens for
the BIP, but for a sort of final summary.


> It is important that the forum for comments have a low barrier of use. The
> Bitcoin Wiki requires only a request for editing privileges, whereas GitHub
> wiki would require reading and agreeing to a lengthy Terms of Service
> contract.
>

Seems weak, it's much easier to sign up for a Github account and most have
one already. It's certainly easier than either paying to get edit
privileges on the Bitcoin Wiki find someone to convince you're genuine an
obscure IRC channel.


> In terms of staleness, the Wiki has been shown to stand the test of time,
> and
> is frankly less likely to move than the GitHub repository.
>
> The BIP process originated on the Wiki, and was only moved to GitHub
> because
> stronger moderation was needed (eg, to prevent random other people from
> editing someone else's BIP; number self-assignments; etc). Such moderation
> is
> not only unnecessary for BIP Comments, but would be an outright nuisance.
>

I'm not sure that is the reason why, but in any case, Github is a more
sensible place because of the collaborative features which is why they
became the centre of OSS software development for hundreds of thousands of
projects.


> I hope this addresses all your concerns and we can move forward with BIP 2
> unmodified?
>

I am sorry but it has not. I still strongly object to using the Bitcoin
Wiki or any external source source for the commentary part of BIP2. I
believe it should be done on using the Wiki feature at bitcoin/bips. If
that is not acceptable, then I would suggest a separate page in the bip
assets folder, called bip/comments.md. On a side note, more complex
reference implementation code should be stored in that folder too.


> (On another note, I wonder if we should recommend non-reference
> implementation
> lists/links be moved to BIP Comments rather than constantly revising the
> BIPs
> with them...)
>

Certainly those could be on the comments page.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

[Btc Drak via bitcoin-dev]

Agreed, this thread is venturing somewhat out of scope for the list. Please
can we redirect philosophical discussion to another forum/list such as
bitcoin-discuss, which can be found at
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss

Repost of the bitcoin-dev posting guidelines are:

- Posts must concern development of bitcoin protocol.
- Posts should be technical or academic in nature.
- Generally encouraged: patches, notification of pull requests, BIP
proposals, academic paper announcements. And discussions that follow.
- Generally discouraged: shower thoughts, wild speculation, jokes, +1s,
non-technical bitcoin issues, rehashing settled topics without new data,
moderation concerns.
- Detailed patch discussion generally better on a GitHub PR.
- Meta-discussion is better on bitcoin-discuss.

On Wed, Feb 8, 2017 at 8:13 PM, alp alp via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >Only the majority needs to consent, though what is considered a majority
> varies depending on the context (95%, 75%, 51%). Nowhere does it say
> "everyone needs to agree".
>
> There's a pretty huge gap between 90% and nearly 100%.  90% excluding 10%
> only 7 times results in only 48% of the original base.
>
> >If a small dissenting minority can block all forward progress then
> bitcoin is no longer interesting.
>
> Your definition of forward may be different than other users.
>
> >Is that really the bitcoin that you want to be a part of?
>
> Yes, I chose Bitcoin because it relies on a strictly held consensus
> mechanism and not one that changes on the whims of the majority.  We have
> tens of dozens of political currencies for that.
>
> >When the 1MB cap was implemented it was stated specifically that we
> could increase it when we needed it.  The white paper even talks about
> scaling to huge capacity.  Not sure where you got the idea that we all
> agreed to stay at 1MB forever, I certainly didn't.  It was never stated or
> implied that we could change the coin cap later(please cite if I'm
> mistaken).
>
> The community has not agreed that it is needed at this time.  Perhaps they
> will change their mind at some point in the future.  We have also learned a
> great deal since the publication of the initial whitepaper, such as the
> unstable state without a backlog or subsidy.  Fortunately, participation in
> this system is voluntary, and you are free to leave at any time.
>
> This seems to be venturing quite off topic, and perhaps would be better
> suited for the bitcoin-discuss list.
>
> On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson  > wrote:
>
>> If a small dissenting minority can block all forward progress then
>> bitcoin is no longer interesting.  What an incredibly simple attack
>> vector...
>>
>> No need to break any cryptography, find a bug to exploit, build tens of
>> millions of dollars in mining hardware, spend lots of bitcoin on fees to
>> flood the network, or be clever or expend any valuable resources in any
>> way, shape, or form.
>>
>> Just convince(or pay, if you do want to expend some resources) a few
>> people(or make up a few online personas) to staunchly refuse to accept
>> anything at all and the entire system is stuck in 2013(when we first
>> started widely discussing a blocksize increase seriously).
>>
>> Is that really the bitcoin that you want to be a part of?
>>
>> When the 1MB cap was implemented it was stated specifically that we could
>> increase it when we needed it.  The white paper even talks about scaling to
>> huge capacity.  Not sure where you got the idea that we all agreed to stay
>> at 1MB forever, I certainly didn't.  It was never stated or implied that we
>> could change the coin cap later(please cite if I'm mistaken).
>>
>>
>> On Feb 8, 2017 12:16 PM, "alp alp"  wrote:
>>
>> Doing nothing is the rules we all agreed to.  If those rules are to be
>> changed,nearly everyone will need to consent.  The same rule applies to the
>> cap, we all agreed to 21m, and if someone wants to change that, nearly
>> everyone would need to agree.
>>
>>
>> On Feb 8, 2017 10:28 AM, "Andrew Johnson" 
>> wrote:
>>
>> It is when you're talking about making a choice and 6.3x more people
>> prefer something else. Doing nothing is a choice as well.
>>
>> Put another way, if 10% supported increasing the 21M coin cap and 63%
>> were against, would you seriously consider doing it?
>>
>> On Feb 8, 2017 9:57 AM, "alp alp"  wrote:
>>
>>> 10% is not a tiny minority.
>>>
>>> On Feb 8, 2017 9:51 AM, "Andrew Johnson" 
>>> wrote:
>>>
 You're never going to reach 100% agreement, and stifling the network
 literally forever to please a tiny minority is daft.

 On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

 10% say literally never.  That seems like a significant
 

Re: [bitcoin-dev] Status updates for BIP 9, 68, 112, and 113

[Btc Drak via bitcoin-dev]

Fine by me to update BIP68 and BIP112 to Final status. The forks have
activated.

On Fri, Jul 15, 2016 at 4:30 PM, Luke Dashjr  wrote:

> Daniel Cousens opened the issue a few weeks ago, that BIP 9 should
> progress to
> Accepted stage. However, as an informational BIP, it is not entirely clear
> on
> whether it falls in the Draft/Accepted/Final classification of proposals
> requiring implementation, or the Draft/Active classification like process
> BIPs. Background of this discussion is at:
> https://github.com/bitcoin/bips/pull/413
> (Discussion on the GitHub BIPs repo is *NOT* recommended, hence bringing
> this
> topic to the mailing list)
>
> Reviewing the criteria for status changes, my opinion is that:
> - BIPs 68, 112, 113, and 141 are themselves implementations of BIP 9
> -- therefore, BIP 9 falls under the Draft/Accepted/Final class
> - BIPs 68, 112, and 113 have been deployed to the network successfully
> -- therefore, BIP 9 has satisfied the conditions of not only Accepted
> status,
>but also Final status
> -- therefore, BIPs 68, 112, and 113 also ought to be Final status
>
> If there are no objections, I plan to update the status to Final for BIPs
> 9,
> 68, 112, and 113 in one month. Since all four BIPs are currently Draft, I
> also
> need at least one author from each BIP to sign-off on promoting them to
> (and
> beyond) Accepted.
>
> BIP   9: Pieter Wuille 
>  Peter Todd 
>  Greg Maxwell 
>  Rusty Russell 
>
> BIP  68: Mark Friedenbach 
>  BtcDrak 
>  Nicolas Dorier 
>  kinoshitajona 
>
> BIP 112: BtcDrak 
>  Mark Friedenbach 
>  Eric Lombrozo 
>
> BIP 113: Thomas Kerin 
>  Mark Friedenbach 
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] About ASICBoost

[Btc Drak via bitcoin-dev]

Sergio,

It is critically important to the future of Bitcoin that consensus
code avoid any unnecessary entanglements with patents because "the
free market" allows you and anyone else to make consensus change
proposals that rely on (unknown) patents - but this is something we
should all be working to avoid, as it unnecessarily hinders Bitcoin
development and everyone's ability to deploy. Consensus code must not
be hindered by patents and Bitcoin should retain its permissionless
qualities.

When you proposed the extra nonce space BIP [1], you had already
applied for your ASICBOOST patent [2] without disclosure in the BIP
[1] nor in your Bitcoin Core pull request #5102 [2].

The ASICBOOST patent [2] describes the same process as in the BIP [1]
and proposed code [3] "As we explained in our Provisional Application,
it has been proposed to partition the 4-byte Version field in the
block header (see, Fig. 6) and use, e.g., the high 2-byte portion as
additional nonce range."

Today when you proposed a new sidechain BIP [4], Peter Todd was
(rightly) concerned about the prior lack of disclosure of your patents
related to your prior consensus modification proposal. Hence the
concern is that this might be happening this time as well.

There is no evidence that any of the other filers for the
ASICBOOST-like patents by mining companies other than your own were
going to be using it offensively as those other companies appeared to
understand the decentralization risk of having an advantage enforced
by legal and not technical means.

It's great that you have now committed to looking into the Defensive
Patent License. This seems likely to mitigate some of the patent
concerns. Although it would be a show of good faith if you also agreed
to license ASICBOOST under the DPL.

[1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
[2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
[3]: Extra nonce pull request: https://github.com/bitcoin/bitcoin/pull/5102
[4]: COUNT_ACKS
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013174.html

On Sun, Oct 2, 2016 at 6:13 PM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> Please Peter Todd explain here all what you want to say about a patent of a
> hardware design for an ASIC.
>
> Remember that ASICBoost is not the only patent out there, there are at least
> three similar patents, filed by major Bitcoin ASIC manufacturers in three
> different countries, on similar technologies.
>
> That suggest that the problem is not ASICBoot's: you cannot blame any
> company from doing lawful commerce in a FREE MARKET.
>
> It is a flaw in Bitcoin design that could be corrected if the guidelines I
> posted in [1] had been followed.
>
> [1]
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
>
>
>
>
> ___
> 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] [BIP Proposal] Buried Deployments

[Btc Drak via bitcoin-dev]

I think this is already covered in the BIP text:-

"As of November 2016, the most recent of these changes (BIP 65,
enforced since December 2015) has nearly 50,000 blocks built on top of
it. The occurrence of such a reorg that would cause the activating
block to be disconnected would raise fundamental concerns about the
security assumptions of Bitcoin, a far bigger issue than any
non-backwards compatible change.

So while this proposal could theoretically result in a consensus
split, it is extremely unlikely, and in particular any such
circumstances would be sufficiently damaging to the Bitcoin network to
dwarf any concerns about the effects of this proposed change."


On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
 wrote:
> NACK
>
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material performance
> optimization (the checks are avoidable once activated until a sufficiently
> deep reorg deactivates them).
>
> e
>
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
>  wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules
> surrounding deployment of BIPs 34, 66, and 65
> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
> minor one, I thought it was worth documenting the rationale in a BIP for
> posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> signaling in block version numbers. Now that the chain has long since passed
> the blocks at which those consensus rules have triggered, we can (as a
> simplification and optimization) replace the trigger mechanism by caching
> the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
>
> ___
> 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] Start time for BIP141 (segwit)

[Btc Drak via bitcoin-dev]

I can see how it looks but actually most of the underlying libraries have
already been adapted or are almost finished being adapted for segwit. Since
segwit is not live on mainnet, most are not released (either still in PR
form or merged to a development branch). As a software developer, I think
you can appreciate that libraries cant actually release a segwit supported
versions until segwit is released as final in 0.13.1. Obviously consumers
of the libraries cant update for segwit until the libraries are released -
you get the idea. I wouldn't be too concerned about the adoption chart,
it's just very difficult to reflect the actual state of affairs. For
example Trezor is marked as wip, but they have had an updated, but
unreleased firmware version for many months[1]. We are in the process of
planning a migration guide and updating the existing development notes[2].
Additionally, many companies are already planning to update their services
for segwit.

Regarding BIP9, it's purpose is to co-ordinate *miner upgrade* and
activation. The starttime delay is simply designed to avoid miners
signalling before the soft fork has been made available for general
release; so the starttime prevents unreleased software from setting the
version bit prematurely. The whole BIP9 state machine allows predictable
activation. Non mining full nodes are under no constraints to upgrade on a
specific schedule, which is by design of soft forks. Signalling will not
begin until the first diff retarget period after the starttime of 15th Nov.
Practically it means there will be a minimum of 4-6 weeks at the very least
before activation can happen.

[1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issu
ecomment-217329474
[2] https://bitcoincore.org/en/segwit_wallet_dev/

On Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
> wrote:
> > Would I want anyone to lose money due to faulty wallets? Of course not.
> > By the same token, devs have had almost a year to tinker with SegWit and
> > make sure the wallet isn't so poorly written that it'll flame out when
> > SegWit comes along. It's not like this is some untested, mostly unknown
> > feature that's being slipped out at the last minute
>
> There have been objections to the way that SegWit has been implemented for
> a
> long time, some wallets are taking a "wait and see" approach.  If you look
> at the page you linked[1], that is a very very sad state of affairs. The
> vast majority is not ready.  Would be interesting to get a more up-to-date
> view.
> Wallets probably won't want to invest resources adding support for a
> feature
> that will never be activated. The fact that we have a much safer
> alternative
> in the form of Flexible Transactions may mean it will not get activated. We
> won't know until its actually locked in.
> Wallets may not act until its actually locked in either. And I think we
> should respect that.
>
> Even if all wallets support it (and thats a big if), they need to be rolled
> out and people need to actually download those updates.
> This takes time, 2 months after the lock-in of SegWit would be the minimum
> safe time for people to actually upgrade.
>
> 1) https://bitcoincore.org/en/segwit_adoption/
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] (no subject)

[Btc Drak via bitcoin-dev]

For continuity, Matt took the discussion to the bitcoin-discuss lists here
https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-October/000104.html

On Sun, Oct 16, 2016 at 9:45 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sunday, 16 October 2016 19:35:52 CEST Matt Corallo wrote:
> > You keep calling flexible transactions "safer", and yet you haven't
> > mentioned that the current codebase is riddled with blatant and massive
> > security holes.
>
> I am not afraid of people finding issues with my code, I'm only human.
> Would
> appreciate you reporting actual issues instead of hinting at things here.
> Can't fix things otherwise :)
>
> But, glad you brought it up, the reason that FT is safer is because of the
> amount of conceps that SegWit changes in a way that anyone doing
> development
> on Bitcoin later will need to know about them in order to do proper
> development.
> I counted 10 in my latest vlog entry.  FT only changes 2.
>
> Its safer because its simpler.
>
> > For example, you seem to have misunderstood C++'s memory
> > model - you would have no less than three out-of-bound, probably
> > exploitable memory accesses in your 80-LoC deserialize method at
> > https://github.com/bitcoinclassic/bitcoinclassic/
> blob/develop/src/primitiv
> > es/transaction.cpp#L119 if you were to turn on flexible transactions (and
> > I only reviewed that method for 2 minutes).
>
> The unit test doesn't hit any of them. Valgrind only reports such possibly
> exploitable issues in secp256k and CKey::MakeNewKey. The same as in Core.
>
> I don't doubt that your 2 minute look shows stuff that others missed, and
> that valgrind doesn't find either, but I'd be really grateful if you can
> report them specifically to me in an email off list (or github, you know
> the
> drill).
> More feedback will only help to make the proposal stronger and even better.
> Thanks!
>
> > If you want to propose an
> > alternative to a community which has been in desperate need of fixes to
> > many problems for several years, please do so with something which would
> > not take at least a year to complete given a large team of qualified
> > developers.
>
> I think FT fits the bill just fine :)  After your 2 minute look, take a bit
> longer and check the rest of the code. You may be surprised with the
> simplicity of the approach.
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] Start time for BIP141 (segwit)

[Btc Drak via bitcoin-dev]

This thread has strayed extensively off topic from the OP which asked a
simple question about BIP141 signalling start params.

Please move to another thread, or take more general discussion to
bitcoin-discuss.

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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Btc Drak via bitcoin-dev]

There actually isn't an activation threshold in Bitcoin Classic. The hard
fork rules are active the moment you install the software. As was noted,
there aren't any release notes, so you can be forgiven for not knowing that
BIP109 support was removed and the proposal rejected. Classic recently
adopted a new set of hard fork rules for which there is no written
specification.

Bitcoin software vendors should take great pains to document software
features and changes from version to version. Bitcoin Core for example,
always has extensive release notes, and a full changelog extracted from the
source code for each version. In the case of consensus rule change
proposals, we follow the BIPs process which exists to help ecosystem-wide
co-ordination. A detailed and complete specification allows others to
re-implement the BIP in their own software and also acts as part of the
consensus building process and peer review process.

There's nothing wrong with hard forks per se, and this list is certain a
good place to discuss proposals, but releasing hard fork software without
establishing community wide consensus and without clearly labelling your
product as such is just not cricket. If I may cast your attention back a
few weeks ago, Johnson Lau released a hard fork client _testnet_ as part of
his research project which was announced on this list. It was clearly
labelled. This Bitcoin Classic announcement was not clearly labelled (and
released on mainnet).


On Sat, Jan 7, 2017 at 8:12 PM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin Classic only activates if 75% of the network adopts it. That
> is not irresponsible or dangerous. It would only be dangerous if it
> activates at 50%, because that would create a situation where its not
> clear which side of the fork has the most proof of work.
>
> On 1/7/17, Eric Lombrozo via bitcoin-dev
>  wrote:
> > Your release announcement does not make it clear that Bitcoin Classic is
> > incompatible with the current Bitcoin network and its consensus rules. It
> > is a hard fork on mainnet with no safe activation as well as including
> > other unsafe changes. There is also no BIP for the hard fork. There is
> also
> > no evidence of community wide consensus for such a hard fork. This is
> > dangerous and irresponsible.
> >
> >
> > It's wrong to announce software without correctly informing people about
> > the contents or risks. Furthermore, there are no release notes in
> > https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
> > changelog. Without those, it is almost impossible for average users to
> know
> > what is under the hood or what has changed and time consuming for
> > developers to assess.
> >
> > On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> Bitcoin Classic version 1.2.0 is now available from;
> >>
> >>  
> >>
> >> This is a new major version release, including new features, various
> >> bugfixes and performance improvements.
> >>
> >> This release marks a change in strategy for Bitcoin Classic, moving from
> >> the
> >> very conservative block size proposal based on compromise to one where
> >> Classic truly innovates and provides a long term solution for the market
> >> to
> >> choose and leave behind the restrictions of the old.
> >>
> >> The most visible change in this version is the decentralised block size
> >> solution where node operators decide on the maximum size.
> >>
> >> Bitcoin Classic is focused on providing users a way to get onto the
> >> Bitcoin
> >> network using a high quality validating node for a large set of use
> >> cases.
> >> Classic presents top notch quality processes in this release, to help
> >> anyone
> >> running Bitcoin.
> >>
> >> We include in this release various projects with the beta label. People
> >> who
> >> want to use the Classic node as an on-ramp to Bitcoin will find them
> >> interesting. These projects will need to be enabled in the config by
> >> those
> >> that want to test them.
> >>
> >> More background information on this release and Classic can be seen in
> >> this
> >> video: https://vimeo.com/192789752
> >> The full release notes are on github at
> >> https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
> >>
> >> --
> >> Tom Zander
> >> Blog: https://zander.github.io
> >> Vlog: https://vimeo.com/channels/tomscryptochannel
> >> ___
> >> 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] Announcements on bitcoin-dev

[Btc Drak via bitcoin-dev]

The purpose of this list is Bitcoin protocol discussion of all kinds,
including consensus rules that require hard and soft forks and there
have been many discussions about both. There is also a clear technical
process for proposing, discussing and peer reviewing consensus rule
changes via the BIPs process which this list has traditionally played
a large role. BIP specifications allow community wide coordination
across multiple implementations.

Since the recent thread announcing a new version of Bitcoin Classic,
many people have complained on and off-list that is should not be
allowed on the bitcoin-dev mailing list because it is not consensus
compatible nor is it a change which has been arrived at through wide
community consensus. There isn't even a formal specification that
other implementations could follow if they wanted to. The general
feeling seems to be that announcements for consensus compatible
implementations is ok on this list. If there is ever community wide
consensus for a hard fork, then that too would be ok since there would
be consensus.

This list does strive to be somewhat high signal to noise ratio where
possible and we need to be clear about the list remit. So let's be
clear, announcing/advertising software that is consensus incompatible
is off-topic, however, discussion of hard forks, peer review etc has
always been, and remains, on topic.

I've copied the current list remit below for completeness. General
discussions should be directed at bitcoin-discuss, where as actual
protocol development discussion belongs on bitcoin-dev.

Bitcoin development and protocol discussion.

This list is lightly moderated.

- No offensive posts, no personal attacks.
- Posts must concern development of bitcoin protocol.
- Posts should be technical or academic in nature.
- Generally encouraged: patches, notification of pull requests, BIP
proposals, academic paper announcements. And discussions that follow.
- Generally discouraged: shower thoughts, wild speculation, jokes,
+1s, non-technical bitcoin issues, rehashing settled topics without
new data, moderation concerns.
- Detailed patch discussion generally better on a GitHub PR.
- Meta-discussion is better on bitcoin-discuss
(https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss)

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

Re: [bitcoin-dev] Unique node identifiers

[Btc Drak via bitcoin-dev]

Nodes are by design not supposed to be identifiable in any way, including
persisting identities across IPs changes or when connecting over different
networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a
step backwards. Also absolute node count is pretty meaningless since only
fully validating nodes that participate in economic activity really matter.

As a side note, this should probably have started out as a bitcoin-discuss
post.

On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The discussion of UASF got me thinking about whether such a method might
> lead to sybil attacks, with new nodes created purely to inflate the node
> count for a particular implementation in an attempt at social engineering.
>
> I had an idea for an anonymous, opt-in, unique node identification
> mechanism to help counter this.
>
> This would give every node the opportunity to create a node
> ‘address’/unique identifier. This could even come in the form of a Bitcoin
> address.
>
> The node on first installation generates and backs up a private key. The
> corresponding public key becomes that node’s unique identifier. If the node
> switches to a new software version or a new IP, the identifier can remain
> constant if the node operator chooses.
>
> Asking a node for its identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond with its
> unique identifier and a signature for the challenge to prove it. The node
> can also include what software it is running and sign this information so
> it can be verified as legitimate by third parties.
>
> Why would we do this?
>
> Well, it adds a small but very useful piece of data when compiling lists
> of active nodes.
>
> Any register of active nodes can have a record of when a node identifier
> was “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software the node operator has been seen
> running historically.
>
> This information would make it easy to identify patterns. For example if a
> huge new group of nodes appeared on the network with no history for their
> identifier they could likely be dismissed as sybil attacks. If a huge
> number of nodes that had been reporting as Bitcoin Core for an extended
> period of time started switching to a rival implementation, this would add
> credibility but not certainty (keys could be traded), that the shift was
> more organic.
>
> This would be trivial to implement, is (to me?) non-controversial, and
> would give a way for a node to link itself to a pseudo-anonymous identity,
> but with the freedom to opt-out at any time.
>
> Keen to hear any thoughts?
>
> Thanks,
>
> John Hardy
>
> j...@seebitcoin.com
>
>
> ___
> 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] A Segwit2x BIP

[Btc Drak via bitcoin-dev]

I am utterly appalled by this proposal both technically, ethically, and by
the process which it has adopted. Hard forks require consensus from the
entire ecosystem in order to prevent a fork, funds loss, confusion and harm
to the robust guarantees of the Bitcoin system has thus far displayed.

I know this is a draft, but you are seeking reviews of a proposal that has
just a few weeks remaining before deployment (where "technical review" is
pointless because the is not actually open
 unless
you are an approved member
),
making it totally unworkable and irresponsible. For example, exactly how
are other implementations supposed to adopt the BIP in such a short
timeframe? For all the talk of how important "alternative implementations"
are, how does this rash and rushed action promote an ecosystem of multiple
implementors? By encouraging fast upgrades, you are actually centralizing
the ecosystem even further.

The linked coded doesn't uniquely identify itself on the network by
user-agent, something all distinct implementations have done to date.

The draft BIP text looks like an afterthought and doesn't actually specify
the proposal in enough detail to implement from the text. By contrast for
example, BIP141 has a level of detail which allowed others to implement
segwit without looking at any reference code (which consequently results to
more confidence and testing of the specification all round). The Bitcoin
system has a market cap of over $40bn supported by a robust and reliable
network and your proposal is an offence to all Bitcoin has achieved because
due to it's the strong foundations.

I cannot not support this proposal in the current form and timeline, nor do
I support the coercion that has been used behind closed doors to try and
gain more support (not limited to, but including approaching company
investors to twist arms and veiled threats of blacklisting companies from
further funding/collaboration).

I think the best you can hope for this hard fork proposal is for it to be
quietly ignored.



On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
>
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
>
> You can find the BIP draft in the following link:
>
> https://github.com/SergioDemianLerner/BIPs/blob/
> master/BIP-draft-sergiolerner-segwit2x.mediawiki
>
> Reference source was kindly provided by the Segwit2x group.
>
> Best regards,
>  Sergio.
>
> ___
> 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] BIP proposal: Reserved nversion bits in blockheader

[Btc Drak via bitcoin-dev]

Hi,

The following proposal reduces the number of version-bits that can be used
for parallel soft-fork signalling, reserving 16 bits for non-specific use.
This would reduce the number of parallel soft-fork activations using
versionbits to from 29 to 13 and prevent node software from emitting false
warnings about unknown signalling bits under the versionbits signalling
system (BIP8/9). I chose the upper bits of the nVersion, because looking at
the versionbits implementation in the most widely deployed node software,
it is easier to implement than say annexing the lower 2 bytes of the field.

The scope of the BIP is deliberately limited to reserving bits for general
use without specifying specific uses for each bit, although there have
previously been various discussions of some use-cases of nVersion bits
including version-rolling AsicBoost[1], and nonce rolling to reduce CPU
load on mining controllers because ntime-rolling can only be done for short
periods otherwise it could have negative side effects distorting time.
However, specific use cases are not important for this BIP.

I am reviving discussion on this topic now, specifically, because the new
DragonMint miner uses version-rolling AsicBoost on mainnet[2]. It is
important to bring up so node software can adapt the versionbits warning
system to prevent false positives. This BIP has the added advantage that
when a new use for bits is found, mining manufacturers can play in the
designated area without causing disruption or inconvenience (as
unfortuntely, the use of version-rolling will cause until BIP8/9 warning
systems are adapted). I appologise for the inconvenience in advance, but
this is the unfortunate result of restraints while negotiating to get the
patent opened[3] and licensed defensively[4] in the first place.

I believe there was a similar proposal[5] made some years ago, before the
advent of BIP9. This proposal differs in that it's primary purpose is to
remove bits from the versionbits soft-fork activation system and earmark 16
bits for general use without allocating fixed uses for each bit. The BIP
cites a couple of usecases for good measure, but they are just
informational examples, not part of a specification laid down. For this
reason, there no is mention of the version-rolling Stratum extension[6]
specifics within the BIP text other than a reference to the specification
itself.

Refs:

[1] https://arxiv.org/pdf/1604.00575.pdf
[2]
https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-version-rolling-asicboost/
[3]
https://www.asicboost.com/single-post/2018/03/01/opening-asicboost-for-defensive-use/
[4] https://blockchaindpl.org/
[5] https://github.com/BlockheaderNonce2/bitcoin/wiki
[6] http://stratumprotocol.org/stratum-extensions


  BIP: ?
  Title: Reserved nversion bits in blockheader
  Author: BtcDrak 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
  Status: Draft
  Type: Informational
  Created: 2018-03-01
  License: BSD-3-Clause
   CC0-1.0


==Abstract==

This BIP reserves 16 bits of the block header nVersion field for
general purpose use and removes their meaning for the purpose of
version bits soft-fork signalling.

==Motivation==

There are a variety of things that miners may desire to use some of
the nVersion field bits for. However, due to their use to coordinate
miner activated soft-forks, full node software will generate false
warnings about unknown soft forks if those bits are used for non soft
fork signalling purposes. By reserving bits from the nVersion field
for general use, node software can be updated to ignore those bits and
therefore will not emit false warnings. Reserving 16 bits for general
use leaves enough for 13 parallel soft-forks using version bits.

==Example Uses==

The following are example cases that would benefit from using some of
the bits from the nVersion field. This list is not exhaustive.

Bitcoin mining hardware currently can exhaust the 32 bit nonce field
in less than 200ms requiring the controller to distribute new jobs
very frequently to each mining chip consuming a lot of bandwidth and
CPU time. This can be greatly reduced by rolling more bits. Rolling
too many bits from nTime is not ideal because it may distort the
timestamps over a longer period.

Version-rolling AsicBoost requires two bits from the nVersion field to
calculate 4-way collisions. Any two bits can be used and mining
equipment can negotiate which bits are to be used with mining pools
via the Stratum "version-rolling" extension.

==Specification==

Sixteen bits from the block header nVersion field, starting from 13
and ending at 28 inclusive (0x1fffe000), are reserved for general use
and removed from BIP8 and BIP9 specifications. A mask of 0xe0001fff
should be applied to nVersion bits so bits 13-28 inclusive will be
ignored for soft-fork signalling and unknown soft-fork warnings.

This specification does not reserve specific bits