Re: [bitcoin-dev] Horizontal scaling of blockchain

[Tom Zander via bitcoin-dev]

On Friday, 1 September 2017 20:15:53 CEST Cserveny Tamas wrote:
> The usage growth seems to be more of exponential rather than linear.
> Sooner or later the block size will need to be 4 mb then 40 mb, then what
> is the real limit? Otherwise waiting times and thus the fees will just
> grow rapidly. I don't think that it is desirable.

The real limit is set by the technology. Just like in 1990 we could not 
fathom having something like YouTube and high-res video streaming (Netflix), 
the limits of what is possible continually shifts.

This is basically how any successful product has ever grown, I think that it 
is not just desirable, it is inevitable.
-- 
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

Re: [bitcoin-dev] Horizontal scaling of blockchain

[Tom Zander via bitcoin-dev]

On Friday, 1 September 2017 14:47:08 CEST Cserveny Tamas via bitcoin-dev 
wrote:
> The fundamental problem is that if the miners add capacity it will only
> increase (protect) their share of block reward, but does not increase the
> speed of transactions.

Adding more space in blocks has no effect on the block-reward. It does 
actually increase the throughput speed of transactions.

> This will only raise the fee in the long run with
> the block reward decreasing.

Also this is exactly the opposite of what actually happened.

> The current chain is effectively single threaded. 

This is not true, since xthin/compactblocks have been introduced we 
completely removed this bottle-neck.
The transactions will be validated continuously, in parallel and not just 
when a block is found.

-- 
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

Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions

[Tom Zander via bitcoin-dev]

On Friday, 14 July 2017 20:43:37 CEST Clark Moody via bitcoin-dev wrote:
> I can understand the desire to keep all reference strings to the nice
> 14-character version by keeping the data payload to 40 bits

I’m not so clear on this, to be honest.

What is the point of having a user-readable tx-reference?

In the actual blockchain you will still be using txid, and if you want to 
change that then a less readable but more compact format is useful because 
we want to optimize for space, not for human comprehention.

Another usecase I can come up with is you wanting to spend a specific output, 
or you reporting a specific tx as proof to a merchant (or tax office).

For any such usecases you sill need to actually provide a proof of holding 
the private keys and using a human-readable format just doesn’t seem to make 
much sense because a cryptographic proof of ownership is not going to be 
readable however hard you try.

Apologies for missing the point,
can you list one or two usecases that you can see this being used for?
-- 
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

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tom Zander via bitcoin-dev]

On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev 
wrote:
> Bitcoin development differs from Linux kernel development in a number
> of obvious ways, such as the fact Bitcoin is being "patched in
> flight".

I've heard this before and it doesn't make any sense to me. Just like your 
Linux box needs a reboot to get a kernel upgrade, your node needs a restart 
to upgrade. Neither the (entire) internet will go down nor the (entire) 
Bitcoin network will go down as a result.

> Having *something* like a roadmap that gives the average user some
> insights into what exactly is being planned for Bitcoin is very
> desirable, arguably even necessary,

This is fine, and groups that do development should do this more structured 
than something like https://bitcoinhardforkresearch.github.io/

It just would not make any sense to have a roadmap for the *entire* industry 
as this would require you to decide what technical solution is better than 
another before either of them are fully researched.

Individual groups can have solutions that they believe is the best. And then 
we can let the market decide which one is to be actually activated.
-- 
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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Tuesday, 20 June 2017 00:41:49 CEST Gregory Maxwell via bitcoin-dev 
wrote:
> Can someone make a case why saving no more than those figures would
> justify the near total loss of privacy that filtering gives?

First, your figures are wrong and also fall out of the sky with no 
justification. Can’t debunk something that is pure garbage.

Second, stating that a bloom filter is a "total loss of privacy" is equally 
baseless and doesn’t need debunking.

> "Because they already do it" isn't a good argument when talking about
> a new protocol feature; things which already do BIP37 will presumably
> continue to already do BIP37.

I think you just made the case for completely rejecting this proposal based 
on the fact that nobody will use it, BIP37 already exists.

Not sure if I agree with that, improvements are always useful and we should 
be able to come up with replacements.
But arguing against a feature you don’t like, especiallyh one used by 
millions every day, is a sad way to stiffle innovation, Greg.
-- 
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

Re: [bitcoin-dev] BIP148 temporary service bit (1 << 27)

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote:
> To ease the transition to BIP148 and to minimise risks in the event miners
> choose to perform a chain split attack, at least Bitcoin Knots will be
> using the temporary service bit (1 << 27) to indicate BIP148 support.
> 
> Once the transition is complete, this will no longer be necessary, and the
> bit will be (manually) returned for reuse.
> 
> I encourage other software implementing BIP148 (both full and light nodes)
> to set and use this service bit to avoid network partitioning risks.

I'm curious what you action on the finding (or not) of a peer with this bit 
set (or not).
Can you link to the github commit where you implemented this?
-- 
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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 18:30:18 CEST Jonas Schnelli wrote:
> I personally would ALWAYS [snip]

I mentioned that it was a usability point for a reason, and your personal 
behavior makes me want to quote one of the main UX guidelines; 
  “You are not your user”

http://uxmyths.com/post/715988395/myth-you-are-like-your-users
older;
http://52weeksofux.com/post/385981879/you-are-not-your-user

I think we should defer to actual real numbers and user reseach, as has been 
quoted by Andreas. You disagreeing based on your own experience and behavior 
is worse than useless. As the above links show.

Don’t fall in that trap :)
-- 
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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote:
> Hi
> 
> > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
> >> It's been debated if [filtering of] unconfirmed transactions are
> >> necessary,
> > 
> > Why would it not be needed? Any SPV client (when used as a
> > payment-receiver) requires this from a simple usability point of view.
> 
> I think many users would be willing ...
> a) … to trade higher privacy (using client side filtering) for not having
> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
> all inved transactions

You seem to misunderstand the usecase.
If you send me a transaction, both of use are using our phones, then I need 
to be able to have immediate feedback on the transaction being broadcast on 
the network.
This is not about zero-conf, this is simple seeing what is happening while 
it is happening.

Additionally, when the transaction that is meant for my wallet is broadcast, 
I want my SPV wallet to parse and check the actual transaction.
It is not just to see that *something* was actually send, but also to be 
able to see how much is being paid to me. Maybe If the transaction is marked 
as RBF-able, etc.

Really basic usability: provide information to your users when you can, 
should they want to, and by default on.
-- 
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

Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients

[Tom Zander via bitcoin-dev]

On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
>  It's been debated if [filtering of] unconfirmed transactions are
> necessary,

Why would it not be needed? Any SPV client (when used as a payment-receiver) 
requires this from a simple usability point of view.

-- 
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

Re: [bitcoin-dev] Barry Silbert segwit agreement

[Tom Zander via bitcoin-dev]

On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
> > why?
> 
> the main
> issue is due to 0.13.1+ having many segwit related features active
> already, including all the P2P components, the new network service
> flag, the witness-tx and block messages, compact blocks v2 and
> preferential peering. 

Hmm, the flags are identical in 0.13 and 0.14 clients.

Either way, this is rather trivial to solve. If bugs in older clients mean 
they can’t operate properly when SW is activated (via bit 4) but they don’t 
know its activated (since they only look at bit1), then just ban them when 
they misbehave.
And tell people to upgrade to a version where SegWit is less buggy.

> You would have to then have multiple activation
> codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF
> etc. By doing BIP141 first you then only have the BIP141(active)->HF
> activation codepath to test for, and you also can't be sure you can
> rely on BIP141(inactive)->HF activation codepath being the only one
> until segwit activation expires.

Heh, well, this is rather simple to solve by not having all those activation 
codepaths and just picking **one**.

You can safely replace the bit1 activation code with a bit4 activation 
logic, which is based on 80% and has no end-date.
We both know that the bip9 (bit1) based activation will not trigger before 
the expiration date anyway.

These worries are rather trivial to solve if you do a little bit of proper 
architecture of the solution.  This honestly can’t be a reason for saying NO 
to the majority of the mining hash power giving you a break and offering a 
better SegWit activation.

-- 
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

Re: [bitcoin-dev] Barry Silbert segwit agreement

[Tom Zander via bitcoin-dev]

On Friday, 26 May 2017 23:30:37 CEST James Hilliard via bitcoin-dev wrote:
> It would not be feasible to schedule any HF until one can be
> completely sure BIP141 is active

why?

> Since it is likely a HF will take months of development and testing I
> see this or something similar as the fastest safe path forward

This should not be an issue, it started 2 years ago. Its tested.
-- 
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

Re: [bitcoin-dev] Barry Silbert segwit agreement

[Tom Zander via bitcoin-dev]

On Friday, 26 May 2017 19:47:11 CEST Jacob Eliosoff via bitcoin-dev wrote:
> Forgive me if this is a dumb question.

Sorry for picking your email.

I understand people want something different for the agreement, I know I do 
too.
We have a specific agreement on the table, signed by a huge subsection of the 
industry.

Maybe the time for changing things is not to be *after* the signatures are 
set. I know I’d change some detials. But do we really want to go through 
another conference where all the important people are present to agree on a 
compromise? Or can we use the one we have?

The compromise is pretty simple;
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

*  Activate Segregated Witness at an 80% threshold, signaling at bit 4
*  Activate a 2 MB hard fork within six months

-- 
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

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

[Tom Zander via bitcoin-dev]

On Friday, 26 May 2017 16:39:30 CEST Erik Aronesty wrote:
> Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is
> something that will simply never happen for basic engineering reasons.

The modifications to Bitcoin Core would take at most a day to do, plus a week 
to test.
I’m not very happy with the full compromise myself, but can we please not 
stomp on actual progress with nebulous problems?
I mean, you want SegWit, right?

> Claiming that miners support segwit is disingenuous ... considering that
> if they supported it, they would be signaling for it today... instead of
> distracting the community with fake proposals that have no peer-reviewed
> code.

The nature of a compromise like the one that happened in New York is that 
both parties do something they are not the most happy with in exchange for 
the thing they want.
Miners have agreed to the SegWit part of this compromise. Calling that 
disingenuous is not helpful...
-- 
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

Re: [bitcoin-dev] Emergency Deployment of SegWit as a partial mitigation of CVE-2017-9230

[Tom Zander via bitcoin-dev]

On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote:
> So, I started searching for the motivations of such a large amount of the
> mining hash-rate holding a position that isn’t at-all represented in the
> wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’ moment: 
> If one assumes that the 67% of the hash rate that refuse to signal for
> SegWit are using ASICBOOST. The entire picture of this political
> stalemate became much more understandable.

I’m uncomfortable with your “bingo” moment, and your huge assumption to get 
to make it fit.
The reality is that we have seen repeatedly that the miners are stating they 
are Ok with an ASICBOOST disabling change.
The larger mining industry has just this week come to consensus about a 
better way to activate SegWit! Referring to the New York consensus meeting!!
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

I question your conclusions of miners not supporting SegWit because of 
ASICBOOST, the evidence shows this accusation to be false.

You openly admitting here that you use ASICBOOST as a tool to push SegWit is 
further making me uncomfortable. Your intention may be pure, but the methods 
are not.
And on that I agree with Andreas, that taints this proposal.

-- 
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

Re: [bitcoin-dev] Full node "tip" function

[Tom Zander via bitcoin-dev]

I agree with you here, Erik. Greg's standard answer doesn’t apply to your 
suggestion.
I think he was a bit too trigger happy because we have seen a lot of similar 
suggestions that have the Sybill issue he mentioned.


On Thursday, 4 May 2017 15:15:02 CEST Erik Aronesty via bitcoin-dev wrote:
> > Greg
> > The primary result would be paying people to sybil attack the network.
> 
> I cannot imagine the benefit to replicating an ip address in this case,
> except maybe you think that you would be more likely to be selected as a
> peer?   But there would be no actual advantage since download peers are
> selected based on throughput and actual blocks served.

-- 
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

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

[Tom Zander via bitcoin-dev]

On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev 
wrote:
> > I suggested something similar which is a much simpler version;
> > https://zander.github.io/scaling/Pruning/

> Your proposal has a significant disadvantage: If every peer is dropping
> 75% of all blocks randomly, then you need to connect to a large number of
> peers to download the whole blockchain.
...
> If you are downloading 450,000 blocks, you will need to
> connect to an expected 46 peers to download the whole blockchain.

I don’t really see the problem here, even if your math is a off. (Statistics 
is difficult, I know). Connecting to many nodes to download faster is really 
not an issue and already happens.

> Your proposal is also a lot less able to handle active adversaries: if
> nodes are randomly dropping blocks, the probability that one block in
> particular is dropped by everyone goes up significantly. 

You make the assumption that this new mode of pruning will be used by 100% 
of the network, this is not how distributed systems work.

-- 
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

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

[Tom Zander via bitcoin-dev]

On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote:
> The best alternative today to storing the full blockchain is to run a
> pruned node

The idea looks a little overly complex to me.

I suggested something similar which is a much simpler version;
https://zander.github.io/scaling/Pruning/

> # Random pruning mode
> 
> There is a large gap between the two current modes of everything
> (currently 75GB) and only what we need (2GB or so).
> 
> This mode would have two areas, it would keep a days worth of blocks to
> make sure that any reorgs etc would not cause a re-download, but it would
> have additionally have an area that can be used to store historical data
> to be shared on the network. Maybe 20 or 50GB.
> 
> One main feature of Bitcoin is that we have massive replication. Each node
> currently holds all the same data that every other node holds. But this
> doesn't have to be the case with pruned nodes. A node itself has no need
> for historic data at all.
> 
> The suggestion is that a node stores a random set of blocks. Dropping
> random blocks as the node runs out of disk-space. Additionally, we would
> introduce a new way to download blocks from other nodes which allows the
> node to say it doesn't actually have the block requested.
> 
> The effect of this setup is that many different nodes together end up
> having the total amount of blocks, even though each node only has a
> fraction of the total amount.

-- 
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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander via bitcoin-dev]

On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote:
> This doesn't remove the need for consensus rule enforcement of course.

Thanks for confirming my point.

This means that Gregory was incorrect saying that there is no risk to a non-
upgraded node on a SegWit network mining a new invalid block. That risk is 
most definitely there for any miners "left behind" operating on a different 
set of consensus rules than the majority.

Kind of obvious, when you think about it.

-- 
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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander via bitcoin-dev]

On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote:
> This is false,
> 
> Those "everyone can spend" transactions are prohibited from being
> mined due to policy rules.

I expected you to know this, but ok, I'll explain.

A policy rule is not a protocol rule, a mining node is certainly not 
guarenteet to have it, and those that do typically make it configurable.

If you depend on one implementation and user configuration for the avoidance 
of chain forks, you are going to have a hard time.

Thanks for your thoughtful reply, though.
-- 
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

Re: [bitcoin-dev] BIP proposal draft: BIP43 "purpose" allocation for Ethereum

[Tom Zander via bitcoin-dev]

Thinking about this a bit, I support this proposal for a BIP.
This is not Bitcoin, but address types are bound to meet in meat-space and 
it would be good to have a central place where this is defined.

I would very much appreciate someone that worked on BIP32/BIP43 itself to 
comment on the details.

Quoting bip 43;


"We encourage different schemes to apply for assigning a separate BIP
number and use the same number for purpose field, so addresses won't be
generated from overlapping BIP32 spaces."



On Wednesday, 12 April 2017 12:02:37 CEST Nick Johnson via bitcoin-dev 
wrote:
> 
>   BIP: bip-nickjohnson-ethereum-purpose
>   Layer: Applications
>   Title: Ethereum purpose allocation for Deterministic Wallets
>   Author: Nick Johnson 
>   Status: Proposed
>   Type: Standards Track
>   Created: 2017-04-12
> 
> 
> ==Abstract==
> 
> This BIP defines a logical hierarchy for deterministic wallets on the
> Ethereum blockchain based on an algorithm described in BIP-0032 (BIP32
> from now on) and purpose scheme described in BIP-0043 (BIP43 from now
> on).
> 
> This BIP is a particular application of BIP43.
> 
> ==Motivation==
> 
> Because Ethereum is based on account balances rather than UTXO, the
> hierarchy defined by BIP44 is poorly suited. As a result, several
> competing derivation path strategies have sprung up for deterministic
> wallets, resulting in inter-client incompatibility. This BIP seeks to
> provide a path to standardise this in a fashion better suited to
> Ethereum's unique requirements.
> 
> ==Path levels==
> 
> We define the following 2 levels in BIP32 path:
> 
> 
> m / purpose' / subpurpose' / *
> 
> 
> Apostrophe in the path indicates that BIP32 hardened derivation is used.
> 
> Each level has a special meaning, described in the chapters below.
> 
> ===Purpose===
> 
> Purpose is a constant set to the hardened value of the BIP number assigned
> to this BIP (equivalently, the BIP number, bitwise ORed with 0x8000)
> following the BIP43 recommendation.
> It indicates that the subtree of this node is used according to this
> specification.
> 
> Hardened derivation is used at this level.
> 
> ===Subpurpose===
> Subpurpose is set to the EIP number specifying the remainder of the BIP32
> derivation path. This permits new Ethereum-focused applications of
> deterministic wallets without needing to interface with the BIP process.
> 
> Hardened derivation is used at this level.
> 
> ==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic
> Wallets]] * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic
> Wallets]]


-- 
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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander via bitcoin-dev]

On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev 
wrote:
> Segwit was carefully engineered so that older unmodified miners could
> continue operating _completely_ without interruption after segwit
> activates.


> They [Older nodes] can
> upgrade to it [segwit] on their own schedule. The only risk 
> non-participating
> miners take after segwit activation is that if someone else mines an
> invalid block they would extend it,

This is false,

a segwit transaction to the miner you describe is an "everyone can spend" 
transaction, and as such a miner that does not validate the segregated area 
in a post-segwit world will be able to create blocks that will not validate 
for segwit miners by including a transaction that spends a SW tx.

This would then lead to a chain-fork as the SW miners reject it and the non-
SW miners continue to mine on it.


-- 
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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

[Tom Zander via bitcoin-dev]

On Friday, 14 April 2017 18:50:47 CEST praxeology_guy via bitcoin-dev wrote:
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.

Here is a list of clear alternatives;

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

See the BIPs with number 010[1-8].

-- 
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

Re: [bitcoin-dev] A Small Modification to Segwit

[Tom Zander via bitcoin-dev]

The version field is still needed to actually allow future block version 
upgrades. We would cut off our road forward if that were to be blocked.


On Friday, 7 April 2017 22:06:39 CEST Jimmy Song via bitcoin-dev wrote:
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> are used for BIP9 signaling. We change the version bits to a nonce-space
> so the miners can use it for overt ASICBoost. The 32-bits are now moved
> over to the Coinbase transaction as part of the witness commitment. The
> witness commitment goes from 38 bytes to 42 bytes, with the last 4 bytes
> being used as the version bits in the block header previously. The
> witness commitment becomes required as per Gregory Maxwell’s proposal.
> Reasoning


-- 
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

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

[Tom Zander via bitcoin-dev]

On Tuesday, 4 April 2017 20:01:51 CEST Luke Dashjr via bitcoin-dev wrote:
> BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process
> smoother this way. But the same is not true of hardforks: miners are
> essentially irrelevant to them, and cannot make the process any smoother.

Can you explain how miners are irrelevant if the upgrade is not a soft fork?

-- 
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

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

[Tom Zander via bitcoin-dev]

Can you tell me where it is enforced?

The only place I found was here;
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1793

which doesn’t enforce it, all that code does is check that the txid is 
unknown or fully spent.
And since the below idea from Russel would change the txid, it would seem no 
full client would reject this.

Maybe its in a BIP, but I can’t find it in the code.

On Tuesday, 4 April 2017 16:59:12 CEST James Hilliard wrote:
> It is a consensus rule
> https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
> 
> On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
> 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
> > 
> > wrote:
> >>  Someone told me a while back that it would be more natural if we move
> >>  the
> >> 
> >> nHeight from the coinbase script to the coinbase locktime.  Have you
> >> considered doing this?
> > 
> > That change would not be a consensus change and thus free to make any
> > day.


-- 
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

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

[Tom Zander via bitcoin-dev]

On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev 
wrote:
>  Someone told me a while back that it would be more natural if we move the
> nHeight from the coinbase script to the coinbase locktime.  Have you
> considered doing this?

That change would not be a consensus change and thus free to make any day.

-- 
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

Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

[Tom Zander via bitcoin-dev]

On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote:
> ==Specification==
> 
> To be elaborated.

Please do elaborate :)

The meat of the proposal is missing.
 
> It is thought that only cosmetic changes are needed to generalize from
> only soft forks to 'soft or hard forks', and to add the additional
> per-bit parameters 'threshold' and 'windowsize'

I agree that the type of forks are rather irrelevant to the voting 
mechanism. As we remember that BIP109 used a voting bit too.

The per-bit (lets call that per-proposal) parameter threshold and windowsize 
are a different matter though, based on the next paragraph you wrote;

> The design of the state machine is envisioned to remain unchanged.

The entire point of BIP9 is to allow nodes that do not know about an upgrade 
to still have a functional state machine. But I don’t see how you can have a 
state machine if the two basic variables that drive it are not specified.

Now, to be clear, I am a big fan of making the window size and the threshold 
more flexible.
But in my opinion we would not be able to have a state machine without those 
variables in the actual BIP because old nodes would miss the data to 
transition to certain states.

Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse 
the CSV one). Maybe we can come up with 3 default sets of properties and 
when a proposal starts to use bit 11 it behaves differently than if it uses 
22.
-- 
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

Re: [bitcoin-dev] Inquiry: Transaction Tiering

[Tom Zander via bitcoin-dev]

On Wednesday, 29 March 2017 14:48:42 CEST Martin Stolze wrote:
> Your
> conception holds under the presupposition that all action of
> hash-power is motivated by 'rational' economic interest.

This shows you didn't think this through,

instead, the concept holds true when there is even a small section of hash 
power motivated by rational economic interest.

Your claim that it has to be 100% of the miners that need to be honest is 
something I already addressed in the previous email when I wrote its a 
distributed system.

Since this is an open market, the requirement of a secton of miners being 
honest is pretty trivial to fulful, especially since Bitcoins are worth 
quite a lot which makes greed be the main cause of honest miners.

This is the best part, greedy miners are the ones that end up working inside 
the system.

This is very quickly going off-topic. I suggest you to take it to a 
different forum where more people can explain Bitcoin without spamming the 
dev list.
-- 
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

Re: [bitcoin-dev] Inquiry: Transaction Tiering

[Tom Zander via bitcoin-dev]

On Monday, 20 March 2017 21:12:36 CEST Martin Stolze via bitcoin-dev wrote:
> Background: The current protocol enables two parties to transact
> freely, however, transaction processors (block generators) have the
> authority to discriminate participants arbitrarily.

Nag; they don’t have any authority.

> This is well known
> and it is widely accepted that transaction processors may take
> advantage of this with little recourse. It is the current consensus
> that the economic incentives in form of transaction fees are
> sufficient because the transaction processing authorities are assumed
> to be guided by the growth of Bitcoin and the pursuit of profit.

This is not the case, it misunderstands Bitcoin and specifically is 
misunderstands that Bitcoin is distributed and decentralized.

What you call “block generators” or “transaction processors” are in reality 
called miners and they don’t have any authority to mine or not mine certain 
transactions. All they have is a business incentive to mine or not mine a 
certain transaction.
This is a crucial distinction as that makes it a economical decision, not a 
political.

The massive distribution of miners creating blocks means that one miner is 
free to add his political agenda. They can choose to not mine any satoshi-
dice transactions, should they want. But they can’t stop other miners from 
mining those transactions anyway, and as such this is not a political move 
that has any effect whatsoever, at the end of the day it is just an 
economcal decision.

The rest of your email is based on this misconception as well, and therefore 
the above answers your question.
-- 
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

Re: [bitcoin-dev] Requirement for pseudonymous BIP submissions

[Tom Zander via bitcoin-dev]

On Saturday, 18 March 2017 16:23:16 CEST Chris Stewart via bitcoin-dev 
wrote:
> As everyone in the Bitcoin space knows, there is a massive scaling debate
> going on. One side wants to increase the block size via segwit, while the
> other side wants to increase via hard fork. I have strong opinions on the
> topic but I won’t discuss them here. The point of the matter is we are
> seeing the politicization of protocol level changes.

I agree with your assessment, the sides are political and picking sides 
makes people a target.
For that reason I know that many companies are not picking sides, we’ve seen 
some bad stuff happen to companies that did.

I’m not convnced it makes sense to use anonymous, but provable, identities 
is the way to solve this. Though.

I also don’t believe people are rejecting proposals purely based on the 
name. What I see is that pratically all proposals are ignored for the time 
being becaues we can’t make any changes anyway until we have made a protocol 
upgrade and came out stronger.
I do agree that bips are seen politically, but not based on the person that 
suggests them, but more based on the content being useful for their 
political side.

I am not entirely against pseudonymous submissions, but in that case I think 
it should be carried by a well known member of the Bitcoin community.

This raises the bar somewhat to a point where you have to convince someone 
that is already publicly known to propose it with you.
-- 
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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Tom Zander via bitcoin-dev]

On Tuesday, 28 March 2017 19:34:23 CEST Johnson Lau via bitcoin-dev wrote:
> So if we really want to get prepared for a potential HF with unknown
> parameters,

That was not suggested.

Maybe you can comment on the very specific suggestion instead?

-- 
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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

[Tom Zander via bitcoin-dev]

On Tuesday, 28 March 2017 18:59:32 CEST Wang Chun via bitcoin-dev wrote:
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
...
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork.

I think that is a very smart idea, thank you for making it.
-- 
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

Re: [bitcoin-dev] Encouraging good miners

[Tom Zander via bitcoin-dev]

For some time now the relation between block size and propagation speed has 
been decoupled. Using xthin/compact blocks miners only send a tiny version 
of a block which then causes the receiving node to re-create it using the 
memory pool.  Immediately getting double benefits by including pre-verified 
transactions from the memory pool you avoid the old problem of having to 
validate them again when a block was mined.

As such there is no downside to a miner creating a bigger block, as long as 
all the transactions they include are actually in the mempool.

As such I'm personally convinced that the problem you are trying to solve 
has already been solved.

Cheers!


On Monday, 27 March 2017 18:12:19 CEST Btc Ideas via bitcoin-dev wrote:
> Add a preference for mined blocks to be the one with more transactions.
> This comes into play when 2 blocks of the same height are found. The
> first good block mined would be orphaned if it had less transactions than
> another. Optionally, have this rule apply to the current block and the
> previous one.
> 
> This increases incentive for full blocks because a miner thinking the
> faster propagation of a smaller block will win him the reward, but that
> would no longer be a good assumption.


-- 
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

Re: [bitcoin-dev] Unique node identifiers (and BIP150)

[Tom Zander via bitcoin-dev]

On Wednesday, 8 March 2017 20:47:54 CET Jonas Schnelli via bitcoin-dev 
wrote:
> Please Eric. Stop spreading FUD.
> BIP150 has a fingerprint-free **OPTIONAL** authentication. It’s designed
> to not reveal any node identifier/identity without first get a
> crypto.-proof from other peer that he already knows your identity.
> **Peers can’t be identified without having the identity-keys pre shared
> by the node operators.**

Do you know the trick of having an open wifi basestation in a public street 
and how that can lead to tracking? Especially if you have a network of them.
The trick is this; you set up an open wifi base station with a hidden ssid 
and phones try to connect to it by saying “Are you ssid=xyz?”
This leads the basestation to know that the phone has known credentials with 
another wifi that has a specific ssid. (the trick is slightly more elaborate, 
but the basics are relevant here).

Your BIP is vulnarable to the same issue, as a node wants to connect using 
the AUTHCHALLENGE which has as an argument the hash of the person I’m trying 
to connect with.

Your BIP says "Fingerprinting the requesting peer is not possible”.
Unfortunately, this is wrong. Yes the peer is trivial to fingerprint. Your 
hash never changes and as you connect to a node anyone listening can see you 
sending the same hash on every connect to that peer, whereever you are or 
connect from.

Just like the wifi hack.

I think you want to use industry standards instead, and a good start may be 
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
-- 
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

Re: [bitcoin-dev] BIP150/151 concerns and some comments

[Tom Zander via bitcoin-dev]

On Tuesday, 14 February 2017 22:01:51 CET Jonas Schnelli via bitcoin-dev 
wrote:
> >> - If you use one of the todays available SPV clients, you will reveal
> >> your complete wallet content („~all your addresses") to every network
> >> observer between you and the node you have connected to. This means, if
> >> you pay for a coffee (while being on the owners WIFI), the coffee owner
> >> and all the involved ISPs can correlate your wallet with your other
> >> internet behavior. Same is true for your cellphone provider if you use
> >> cellular.
> > 
> > What about allowing trusted users connecting on a different connection.
> > Much like the RPC one.
> > Make that one encrypted. Different usecase, different connection.
> 
> - What protocol would you use?

The RPC one. Which I think is JSON.

Your usecase is essentially just calling sendRawTransaction. Don’t 
overcomplicate things.

-- 
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

Re: [bitcoin-dev] BIP150/151 concerns and some comments

[Tom Zander via bitcoin-dev]

On Tuesday, 14 February 2017 17:10:15 CET Jonas Schnelli via bitcoin-dev 
wrote:
> - If you use one of the todays available SPV clients, you will reveal
> your complete wallet content („~all your addresses") to every network
> observer between you and the node you have connected to. This means, if
> you pay for a coffee (while being on the owners WIFI), the coffee owner
> and all the involved ISPs can correlate your wallet with your other
> internet behavior. Same is true for your cellphone provider if you use
> cellular.

What about allowing trusted users connecting on a different connection. Much 
like the RPC one.
Make that one encrypted. Different usecase, different connection.

-- 
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] Changing the transaction version number to be varint

[Tom Zander via bitcoin-dev]

Hi all,

In the transaction today we have a version field which is always 4 bytes.
The rest of the integer encoding in a transaction is variable-size because 
it saves on bytes.

Specifically, in practice this means that almost all of the transaction have 
bytes 2, 3 & 4 set to zero[1].

The question that I was pondering is that when we accept a new version of 
transaction format (flextrans uses 4), what would the impact be of also 
changing the way that the version number is actually serialized to be var 
int.

The benefit would be that each and every transaction looses 3 bytes. These 
can be used differently in v1 transactions and are not needed at all to be 
there for newer transaction formats.
The secondairy benefit is that, at least for FlexTrans[2], 100% of all the 
integers in the transaction are following exactly the same encoding, the
var-int encoding.

There is currently no consensus rule that rejects transactions which lie 
about their version, so obviously this rule should not and can not be 
introduced retro-actively. It will be from a certain block-height.

The way to do this is that from a certain block-height the current 
transaction format labels bytes 2, 3 & 4 to be unused.
>From that same block height the interpretation of the first byte is as 
varint.
Last, we add the rule from that block-height that only transactions that do 
not lie about their version number are valid. Which means version 1.

Do people see any problems with this?
This could be done as a soft fork.

1) It should be 100% because there is no transaction version defined that 
sets them to non-zero, but there is no consensus rule that rejects 
transactions that lie about their version number.
2) https://bitcoinclassic.com/devel/Flexible%20Transactions.html

-- 
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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Tom Zander via bitcoin-dev]

On Saturday, 7 January 2017 21:15:11 CET Btc Drak via bitcoin-dev wrote:
> There actually isn't an activation threshold in Bitcoin Classic.

Thats partly correct.
There is just not a formal one, there very much is an informal and practical 
threshold.

I, and I'm not alone in this, think that a formal vote or an algorithm to 
decide something will happen or not reeks too much like central planning and 
more importantly that it is too inflexible for real world use.
Its fine for simple upgrades, and we have seen lots of success there.

It would be a mistake to think that miners can just start mining with 
Classic and make something that Core doesn't understand. That would have 
negative effects and thus won't happen. Less social people will ask why and 
maybe ask how we avoid this. They misunderstand the social and economic 
parts of Bitcoin.

The block size is an ongoing debate. 
I find it very hard to believe that all the people replying in outrage to my 
release announcement completely missed this.

I see no point in bringing it up in a BIP or on this list as some central 
cabal that can make decisions for or against.  It is in actual fact being 
decided in the real world, out of yours and my control.

Classic is a tool to that end. No more. No less.
-- 
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

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[Tom Zander via bitcoin-dev]

On Saturday, 7 January 2017 00:55:19 CET Eric Lombrozo wrote:
> Your release announcement does not make it clear that Bitcoin Classic is
> incompatible with the current Bitcoin network and its consensus rules.

To explain why I didn't write that;

Bitcoin Classic is not incompatible with the current Bitcoin network and its 
consensus rules.

-- 
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] Bitcoin Classic 1.2.0 released

[Tom Zander via bitcoin-dev]

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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander via bitcoin-dev]

On Monday, 2 January 2017 16:05:58 CET t. khan wrote:
> On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander  wrote:
> > If the input of your math is completely free and human created, how does
> > it follow that it was math that created it ?
> > Why do you want it math created anyway?
> 
> The beauty of math is that everyone on the planet agrees how it works.
> Everything in Bitcoin is math, with the exception of the blocksize limit
> (1MB) which was a stop-gap solution at the time.

In actual fact the block size *is* set by miners, not math. And always has 
been.
In your proposal the max blocksize continues to be set by miners as a 
secondary effect of them choosing the block size.

Saying the max is actually math is painting an illusion that is rather thin 
and easy to see through because every single usecase for your suggestion 
starts with the choice of blocksize that a human makes. There is not really 
any other input except some rather simple algorithm.

> > A maximum is needed, yes. But does it have to be part of the protocol?
> > A simple policy which is set by node operators (reject block if greater
> > than
> > X bytes) will solve this just fine, no?
> 
> No. That would be an epic disaster. There's no such thing as a "simple
> policy" when humans are involved.

This is ignoring history where miners have successfully set policy on block 
size for years now.

> Obviously no one would agree on what X
> bytes would be and you'd have some nodes rejecting blocks that others
> already accepted.

Not sure about your "obviously". I don't agree. In fact, there is plenty of 
reason to think it does work.

Miners have always been the ones to decide on the block size, and they have 
always done this in a coordinated fashion. This is a natural consequence of 
the rather elegant (economic) design of Bitcoin.

*  Miners earn more fee-based income when they produce bigger blocks.
*  Miners take more risk of their blocks being orphaned with bigger blocks.
*  Miners want to avoid emptying the memory pool every block as that removes 
a total need for users to pay fees.
*  Miners want to make sure the mempool does not become backlogged because 
users that do not see their transactions confirmed will get disappointed and 
find other means to do payments. Which hurts the price and in effect hurts 
the miners income.

This behaviour in block size means blocks will not get huge and they will 
not stay small either, because there are reasons for both. And so the size 
will be something in the middle.

-- 
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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander via bitcoin-dev]

On Monday, 2 January 2017 21:19:10 CET Luke Dashjr wrote:
> On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote:
> > A maximum is needed, yes. But does it have to be part of the protocol?
> > A simple policy which is set by node operators (reject block if greater
> > than X bytes) will solve this just fine, no?
> 
> If you reject a block based on a particular condition, that is BY
> DEFINITION part of the consensus protocol, and NOT a policy. The protocol
> is literally the set of rules by which blocks are determined to be valid
> or invalid.
> 
> Policies are things that can vary node-to-node without affecting the
> validity judgement of blocks.

Policy is thus expanded to allow an individual node to reject blocks that 
are technically speaking valid, just unacceptable to them.

It would be fun to ponder of the effect of that when applied to many nodes. 
Many people already have pondered that question and find it intriguing. So 
don't reject it out of hand :)
-- 
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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander via bitcoin-dev]

On Monday, 2 January 2017 14:32:24 CET t. khan wrote:
> Math should decide the max block size, not humans (miners in this
> case). The goal of Block75 is to manage the max block size without any
> human intervention.

If the input of your math is completely free and human created, how does it 
follow that it was math that created it ?

Why do you want it math created anyway?

> A maximum block size is necessary to prevent a single nefarious miner from
> creating a ridiculously large block which would break the network.

A maximum is needed, yes. But does it have to be part of the protocol?
A simple policy which is set by node operators (reject block if greater than 
X bytes) will solve this just fine, no?

-- 
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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander via bitcoin-dev]

On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote:
> Thoughts? 

This proposal doesn't change the block size, it only changes the maximum 
block size. Which is expected, nothing bad there.

The direct consequence of this, though is that the miners set the maximum 
block size. Because they decide on the actual created block size.

This leads me to the simple question why we can't just give the miners full 
control of the maximum block size directly?

The fact of the matter is that miners have for the full history of Bitcoin 
been able to set the block size, until they hit the 1MB limit.
And your proposal keeps that property, but why have a maximum in the 
protocol?
-- 
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

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

[Tom Zander via bitcoin-dev]

On Sunday, 4 December 2016 21:37:39 CET Hampus Sjöberg via bitcoin-dev 
wrote:
> > Also how about making timestamp 8 bytes?  2106 is coming up soon 
> 
> AFAICT this was fixed in this commit:
> https://github.com/jl2012/bitcoin/commit/
fa80b48bb4237b110ceffe11edc14c813
> 0672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200

That commit hacks around it, a new block header fixes it. Subtle difference.

-- 
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

Re: [bitcoin-dev] New BIP: Hardfork warning system

[Tom Zander via bitcoin-dev]

I am failing to see how you actually will detect a hard fork with this 
system.

Maybe its because of this sentence not being very clear to me;
 «If a generalized block header chain with non-trivial total proof-of-work
   is emerging»

Also, can you explain what you are actually trying to accomplish?

I want to point out that the following part from your motivation is 
incorrect. A full node would reject a hard forked chain (by definition), 
there is no risk of them transacting on it.

«When such features are implemented with a hardfork, existing full node 
implementations would consider such blocks as invalid, and may even ban a 
peer for relaying such blocks. They are effectively blind to such hardfork 
rule changes, leaving users to unknowingly transact on a system with 
potentially different token value. »



On Friday, 2 December 2016 01:20:31 CET Johnson Lau via bitcoin-dev wrote:
> This BIP defines a change in consensus rules regarding to block nVersion,
> and define a concept of generalized block header to implement a hardfork
> warning system for full nodes and light nodes.
> 
> For better formatting, visit github
> https://github.com/jl2012/bips/blob/hfwarning/bip-hfwarning.mediawiki
> 
> 
> 
> BIP: ?
> Title: Hardfork warning system
> Author: Johnson Lau 
> Status: Draft
> Type: Standard
> Created: 2016-12-01
> 
> Abstract
> 
> This BIP defines a change in consensus rules regarding to block nVersion,
> and define a concept of generalized block header to implement a hardfork
> warning system for full nodes and light nodes.
> 
> Motivation
> 
> Softfork and hardfork are the 2 majors categories of consensus rules
> change. Generally, softforks make some previously valid blocks invalid,
> while hardforks make some previously invalid blocks valid. Bitcoin has
> successfully introduced a number of new functions through softforks. A
> built-in warning system is also available in many implementations to warn
> users for the activation of any unknown softforks.
> 
> Some features, however, may not be easily introduced with a softfork.
> Examples include expanding maximum block resources limits, and changing
> the average block time interval. When such features are implemented with
> a hardfork, existing full node implementations would consider such blocks
> as invalid, and may even ban a peer for relaying such blocks. They are
> effectively blind to such hardfork rule changes, leaving users to
> unknowingly transact on a system with potentially different token value.
> On the other hand, light nodes may blindly follow a hardfork with unknown
> rule changes and lose the right to choose the previous system.
> 
> This BIP defines a change in consensus rules regarding to block nVersion,
> and define a concept of generalized block header to implement a hardfork
> warning system for full nodes and light nodes.
> 
> Definitions
> 
> Valid block
> A block that satisfies all the consensus rules being enforced by a bitcoin
> protocol implementation. An implementation may intentionally (e.g. a
> light node) or unintentionally (e.g. unaware of a softfork) not enforcing
> any part of the current netwrok rules.
> 
> Valid blockchain
> A blockchain constituting of only valid blocks.
> 
> Best valid blockchain
> The valid blockchain with highest total proof-of-work.
> 
> Valid blockchain fork
> A valid blockchain sharing a common ancestral block with the best valid
> blockchain, but with less total proof-of-work
> 
> Generalized block header
> Any serialized hexadecimal data with exactly 80 bytes (byte 0 to byte 79).
> The bytes 4 to 35 are the double-SHA256 hash of another generalized block
> header. The bytes 72 to 75 are nBits, the target of this generalized
> block header encoded in the same way as normal bitcoin block header. The
> 2 most significant bits of the byte 3 are the hardfork notification bits.
> The semantics of other data in a generalized block header is not defined
> in any general way. It should be noted that a normal bitcoin block header
> is a special case of generalized block header.
> 
> Generalized block header chain
> A chain of generalized block header. A header chain of valid blocks is a
> special case of a generalized block header chain.
> 
> 
> Specifications
> 
> 
> Block nVersion softfork
> 
> A softfork is deployed to restrict the valid value of block nVersion. Upon
> activation, any block with the second highest nVersion bit set becomes
> invalid (nVersion & 0x4000)
> 
> This softfork will be deployed by "version bits" BIP9 with the name
> "hfbit" and using bit 2.
> 
> For Bitcoin mainnet, the BIP9 starttime will be midnight TBC UTC (Epoch
> timestamp TBC) and BIP9 timeout will be midnight TBC UTC (Epoch timestamp
> TBC).
> 
> For Bitcoin testnet, the BIP9 starttime will be midnight TBC UTC (Epoch
> timestamp TBC) and BIP9 timeout will be midnight TBC UTC (Epoch timestamp
> TBC).
> 
> Any bitcoin implementation (full nodes and light nodes) supporting this
> softfork 

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Tom Zander via bitcoin-dev]

On Saturday, 26 November 2016 15:35:49 CET Peter R via bitcoin-dev wrote:
> Therefore, it is in the best interest of miners to all set the same block
> size limit (and reliably signal in their coinbase TX what that limit is,
> as done by Bitcoin Unlimited miners).

As a point of interest, last week I merged into Classic the same concept. 
Classic will now respect the EB limit and put it in the coinbase.

>  (This actually surprised me because the only way they could lose money is
>  if some _other_ miner wasted even more money by purposely mining a
>  destined-to-be-orphaned block.)

Your surprise may come from the difference in cost vs. expected earnings of 
creating a block, which is quite significant.
-- 
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

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Tom Zander via bitcoin-dev]

On Friday, 25 November 2016 20:45:20 CET Sergio Demian Lerner wrote:
> I now think my reasoning and conclusions are based on a false premise:
> that BU block size policies for miners can be heterogeneous.

Agreed.
 
> There can't be short forks because forks are not in the best interest of
> the honest miner majority. All miners need to announce and follow the same
> block size policy to prevent short forks.

What you appear to want to say is that it is in everyones best interest to 
avoid short forks.
Its impossible to guarentee they can't happen, but very possible to minimize 
them.
 
> If block size negotiations are meant to be open and carried on on-chain,
> then it's much better to let miners increase or decrease the block size
> limit by 1% per block (such as what Ethereum does with the gas limit).

No, there are no block-size-negotiations on chain.

The blockchain is used here for one purpose, to state the position of 
individual miners. But what may not be clear is that you can use this as a 
time-stamped way to hold them to it. Which means that if they lie (by 
rejecting a block), everyone in the world will be able to individually 
verify that fact and their credibility will be affected.

Which will not help their case next time any block size negotiations will 
happen.
-- 
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

Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Tom Zander via bitcoin-dev]

On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via bitcoin-
dev wrote:
> Without a detailed analysis, unlimited block size seems a risky change to
> Bitcoin, to me.

What exactly do you think is a ‘change’ in bitcoin here?

The concept of proof-of-work is that the longer a chain, the higher 
probability that that one will be extended for the simple reason that 
another chain will have to show a higher amount of proof of work to ‘win’.

As far as I understand the document from Peter, there is no change there at 
all. Only chains with more POW will win.
Or, to answer your example, miners will prefer to extend the chain with the 
most POW.

The other fact stays the same as well, if you protect from reorgs by 
expecting more confirmations. Nothing changes here either. The common-sense 6 
confirmations for things like exchange-deposits keep having the same 
security.

The basic idea that we have a 3 or 4 deep fork is a huge problem in Bitcoin. 
It hasn’t happened for ages, and we like it that way. The miners like it 
that way too. Its disruptive.
The is a problem that is not created by the ‘excessive block’ concept. It 
does, however, provide a possible solution to this very far-fetched problem.

You should also realize that the policy of a miner is stored in the 
coinbase.

That said, I’m sure there are improvements to be made to the policy that BU 
uses. But since this is a node-local policy, the consensus rules are not 
affected by it.
-- 
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

Re: [bitcoin-dev] Flexible Transactions.

[Tom Zander via bitcoin-dev]

On Monday, 21 November 2016 10:54:19 CET Russell O'Connor wrote:
> Hi Tom,
> 
> On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev  
> linuxfoundation.org> wrote:
> > The OP_CHECKSIG is the most well known and, as its name implies, it
> > validates a signature.
> > In the new version of 'script' (version 2) the data that is signed is
> > changed to be equivalent to the transaction-id. This is a massive
> > simplification and also the only change between version 1 and version 2
> > of script.
> 
> I'm a fan of simplicity too; Unfortunately, your proposal above to change
> the semantics of OP_CHECKSIG is too naive.

Thanks for your email, Russell.

Unfortunately you waited 6 weeks with writing this and the problem you are 
seeing has been fixed quite some time ago.

Thanks again for reviewing, though!
-- 
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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

[Tom Zander via bitcoin-dev]

Here is my thinking.

The BIP process is about changes to a living project which is the bitcoin 
prptocol.
This specific BIP got accepted and we know in the blockchain that
this event (the acceptance) is recorded.
Before a certain block the rules were one way, after they were changed.

I have no problem with changing the *code* to be less complex because it 
already knows the past. A checkpoint is the same, it is the registeration of 
a past event.
This makes software less complex and still capable of checking the entire 
blockchain from genesis.

I don’t see any harm in this change. I see prudent software engineering 
practices.


On Monday, 14 November 2016 10:47:35 CET 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).


-- 
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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote:
> On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> > Lets get back to the topic. Having a longer fallow period is a simple
> > way to be safe.  Your comments make me even more scared that safety is
> > not taken into account the way it would.
> 
> Can you please explain how having a longer grace period makes it any
> safer? Once the fork reaches the LOCKED_IN status, the fork will become
> active after the period is over. How does having a longer grace period
> make this any safer besides just adding more waiting before it goes
> active? 

As Marek wrote just minutes before your email came in; companies will not 
roll out their updates until it locks in. Peter Todd says the same thing.
So your assumption that the lock-in time is the END of the upgrading is 
false. Thats only the case for miners.

The entire point here is that SegWit is much bigger than just full nodes 
(including miner).
An entire ecosystem of Bitconin will have a need to upgrade.

I understand people saying that non-miners don't *need* to upgrade in order 
to avoid being kicked of the network, but truely, thats a bogus argument.

People want to actually participate in Bitcoin and that means they need to 
understand all of it. Not just see anyone-can-spend transactions.
I think its rather odd to think that developers on this list can decide
the risk profile that Bitcoin using companies or individuals should have.


> You said something about rolling back the changes. There is no
> mechanism for roll backs, and the whole point of the soft fork
> signalling is such that there is no need to roll back anything because
> miners have signaled that they are supporting the fork.

There are a bunch of really large assumptions in there that I disagree with.
First of all, miners running the latest software doesn't mean the software 
is free from flaws. Everyone makes mistakes. People that see a way to abuse 
the system may have found things and are not reporting it because they want 
to abuse the flaw for their own gains. Which is exactly what happened with 
Etherium.

The amount of code and the amount of changes in SegWit makes this a very 
dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin 
being changed with it. We don't yet know how they will interact. We can’t.

You are asking people to create everyone-can-spend transactions that would 
mean a loss of funds to everyone that used it if we do find a major flaw and 
need to rollback.

The gamble is rather uncomforable to many...
-- 
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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev 
wrote:
> It's not the website's fault if wallet devs aren't updating their
> statuses. Besides, "WIP" can mean an awful lot of things.

As I said, it would be nice to get an updated version so we can see more 
than 20% readyness of wallets.
The wallet devs not caring enough to update the status should be a worrying 
sign, though.

> A lot of devs have already worked on SegWit support. This has been
> covered. Even if they don't support SegWit, the wallets will probably
> work just fine. (For awhile, Armory did crash when trying to read SegWit

SegWit is probably the most disruptive and most invasive change ever made to 
Bitcoin. We have miners actively saying they don't like it and this makes it 
a contriversial upgrade which means the network may split and other issues.

Your "wallets will probably work just fine" comment is honestly not the 
answer to make people put faith in the way that this is being vetted and 
checked...

> Also, once again, FlexTrans is off-topic. 

Its an alternative and brought up in that vain. Nothing more. Feel free to 
respond to the BIP discussion (134) right on this list if you have any 
opinions on it. They will be on-topic there. No problems have been found so 
far.

Lets get back to the topic. Having a longer fallow period is a simple way to 
be safe.  Your comments make me even more scared that safety is not taken 
into account the way it would.

People are not even acknowledging the damage a contriversial soft fork of 
the scope and magnitude of SegWit can have, and a simple request to extend 
the fallow time for safety is really not a big deal.
SegWit has been in development for 18 months or so, what is a couple of 
extra week??

I would just like to ask people to take the safety of Bitcoin serious. This 
discussion and refusal to extend the safety period is not a good sign.
-- 
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

Re: [bitcoin-dev] (no subject)

[Tom Zander via bitcoin-dev]

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote:
> > Honestly, if the reason for the too-short-for-safety timespan is that
> > you
> > want to use BIP9, then please take a step back and realize that SegWit
> > is a contriversial soft-fork that needs to be deployed in a way that is
> > extra safe because you can't roll the feature back a week after
> > deployment. All transactions that were made in the mean time turn into
> > everyone-can- spent transactions.
> 
> No one should use, nor anyone is advised to use, segwit transactions
> before it is fully activated. 

Naturally, I fully agree.

It seems I choose the wrong words, let me rephrase;

You can't roll the SegWit back a week after people are allowed to send 
segwit transactions (lock-in + fallow period). All transactions that were 
made in the mean time turn into everyone-can- spent transactions.

Because the network as a whole and any implementation is unable to roll back 
in an environment where SegWit is a contriversial soft-fork, it is super 
important to make sure that it is properly supported by all miners. This 
takes time and the risk you take by pushing this is that actual real people 
loose actual real money because of the issue I outlined inthe previous 
paragraph.


> Having 2 months or 2 weeks of grace period
> makes totally no difference in this regard. If anyone tried to use segwit
> tx during your proposed 2 months grace period, all those txs were still
> everyone-can-spent.
> 
> All you are advocating is just stalling the process with no improvement in
> security.

I hope the above explains the actual security issue better.

-- 
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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

On Sunday, 16 October 2016 20:41:34 CEST Jorge Timón wrote:
> You keep insisting on "2 months after activation", but that's not how
> BIP9 works. We could at most change BIP9's initial date, but if those
> who haven't started to work on supporting segwit will keep waiting for
> activation, then changing the initial date won't be of any help to
> them can only delay those who are ready and waiting.

Then don't use BIP9...

Honestly, if the reason for the too-short-for-safety timespan is that you 
want to use BIP9, then please take a step back and realize that SegWit is a 
contriversial soft-fork that needs to be deployed in a way that is extra 
safe because you can't roll the feature back a week after deployment.
All transactions that were made in the mean time turn into everyone-can-
spent transactions.

I stand by the minimum of 2 months. There is no reason to use BIP9 as it was 
coded in an older client. That is an excuse that I don't buy.
-- 
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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

On Sunday, 16 October 2016 12:35:58 CEST Gavin Andresen wrote:
> On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
> 
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The fallow period sounds wy to short. I suggest 2 months at minimum
> > since anyone that wants to be safe needs to upgrade.
> 
> I asked a lot of businesses and individuals how long it would take them to
> upgrade to a new release over the last year or two.
> 
> Nobody said it would take them more than two weeks.

The question you asked them was likely about the block size. The main 
difference is that SPV users do not need to update after BIP109, but they do 
need to have a new wallet when SegWit transactions are being sent to them.

This upgrade affects also end users, not just businesses etc.

Personally, I'd say that 2 months is even too fast.
 
-- 
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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander via bitcoin-dev]

The fallow period sounds wy to short. I suggest 2 months at minimum 
since anyone that wants to be safe needs to upgrade.

Also, please comment on why you won't use the much more safe and much 
smaller Flexible Transactions.

On Sunday, 16 October 2016 16:31:55 CEST Pieter Wuille via bitcoin-dev 
wrote:
> Hello all,
> 
> We're getting ready for Bitcoin Core's 0.13.1 release - the first one
> to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin
> mainnet, after being extensively tested on testnet and in other
> software. Following the BIP9 recommendation [1] to set the versionbits
> start time a month in the future and discussion in the last IRC
> meeting [2], I propose we set BIP 141's start time to November 15,
> 2016, 0:00 UTC (unix time 1479168000).
> 
> Note that this is just a lower bound on the time when the versionbits
> signalling can begin. Activation on the network requires:
> (1) This date to pass
> (2) A full retarget window of 2016 blocks with 95% signalling the
> version bit (bit 1 for BIP141)
> (3) A fallow period consisting of another 2016 blocks.
> 
>   [1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
>   [2]
> http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.
> 2016-10-13-19.04.log.html
> 
> Cheers,


-- 
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

Re: [bitcoin-dev] BIP 2 revival and rework

[Tom Zander via bitcoin-dev]

On Saturday, 15 October 2016 17:02:30 CEST Marco Falke wrote:
> >> BIP 2 does not forbid you to release your work under PD in
> >> legislations where this is possible
> > 
> > It does, actually.
> 
> Huh, I can't find it in the text I read. The text mentions "not
> acceptable", but I don't read that as "forbidden".

You suggest that a person can dual license something under both CC-BY-SA as 
well as under public domain.
That means you don't understand copyright,

See, all licenses are based on you having copyright. In contrast; public 
domain is not a license, it means a certain text does not have copyright. 
Public domain is the lack of copyright.

One text can not at the same time have copyright and not have copyright, 
making your assumption impossible.

Hence, with PD not explicitly being allowed, you can't use PD.

Personally I prefer copyleft licenses, so the lack of PD is fine with me. The 
lack of a good copyleft we can use in BIPs is what got me involved in this 
discussion in the first place.
-- 
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

Re: [bitcoin-dev] BIP 2 revival and rework

[Tom Zander via bitcoin-dev]

On Saturday, 15 October 2016 14:12:09 CEST Marco Falke wrote:
> On Sat, Oct 15, 2016 at 1:00 PM, Tom Zander via bitcoin-dev
> 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > My suggestion (sorry for not explaining it better) was that for BIPS to
> > be a public domain (aka CC0) and a CC-BY option and nothing else.
> 
> Indeed, we agree that BIPs should be licensed as permissive as
> possible. Still, I wonder why you chose otherwise with BIP 134.
> (Currently OPL and CC-BY-SA)

OPL was the only allowed option apart from CC0.

I dual licensed it so future acceptance of the CC-BY-SA one may mean someone 
can just remove the OPL from the BIP and no futher action or permission is 
needed from all the authors.

> BIP 2 does not forbid you to release your work under PD in
> legislations where this is possible

It does, actually.

> One
> of the goals of BIP 2 is to no longer allow PD as the only copyright
> option.

That's odd as PD was never the only copyright option.

-- 
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

Re: [bitcoin-dev] BIP 2 revival and rework

[Tom Zander via bitcoin-dev]

On Saturday, 15 October 2016 12:11:02 CEST Marco Falke wrote:
> On Sat, Sep 24, 2016 at 11:41 AM, Tom via bitcoin-dev
>  wrote:
> > I'd suggest saying that "Share alike" is required and "Attribution" is
> > optional.
> 
> Please note there is no CC license that requires SA and at the same
> time has BY as an option.
> 
> Generally, I think CC0 is best suited as license for BIPs. If authors
> are scared that they won't get proper attribution, they can choose
> MIT/BSD or CC-BY.

My suggestion (sorry for not explaining it better) was that for BIPS to be a 
public domain (aka CC0) and a CC-BY option and nothing else.

I like you agree with that part, but I see you added two licenses.
Do you have a good reason to add MIT/BSD to that list? Otherwise I think we 
agree.
Using code-specific licenses (including the GPL) for documentation and 
specifically a specification is a really poor fit and doens't make much sense.

> Other than that I don't think that more restrictive
> licenses are suitable for BIPs. The BIP repo seems like the wrong
> place to promote Open Access (e.g. by choosing a CC-BY-SA license).
> BIP 2 allows such licenses, but does not recommend them, which is
> fine.
> 
> I think that BIP 2 in its current form (
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
> @6e47447b ) 
Well, it has this sentence;

> This BIP is dual-licensed under the Open Publication License and
> BSD 2-clause license. 

Which is a bit odd in light of the initial email from Luke that suggested we 
drop the Open Publication License and we use the CC ones instead in addition 
to the public domain one.

Marco:
> looks good and addressed the feedback which was
> accumulated last year. If there are no objections I'd suggest to move
> forward with BIP 2 in the next couple of days/weeks.

Thats odd, you just stated you like the public domain (aka CC0) license, yet 
you encourage the BIP2 that states we can no longer use public domain for 
BIPs... Did you read it?
It says;
 «Public domain is not universally recognised as a legitimate action, thus
  it is inadvisable.» [1]


Also;
This list has not seen a lot of traffic, if you want to make sure people keep 
using the BIP process, I think you need to reach out to the rest of the 
community and make sure this has been heard and discussed.
Moving forward the way it is now will likely deminish the importance of the 
BIP process.

I strongly suggest people make very clear any and all changes that are 
proposed and defend each of them with reasons why you want to change things.


1) if you write as a rationale "In some jurisdictions, public domain is not 
recognised as a legitimate legal action" then you can at least name those 
jurisdictions and explain how they *do* support things like GPL. Burden of 
proof is on the man who wants to change things.
It looks fishy when lawyers disagree. See the CC wikipedia page;
 "public domain: cc0 Freeing content globally without restrictions"

-- 
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

Re: [bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users

[Tom Zander via bitcoin-dev]

On Friday, 14 October 2016 04:51:01 CEST Daniel Robinson via bitcoin-dev 
wrote:
> > Because if not, the DPL is still better than the status quo.
> 
> Agreed. Also worth noting that it has a potential advantage over
> unilateral patent disarmament, analogous to the advantage of copyleft
> licenses over MIT/BSD: it provides an incentive (at least a theoretical
> one) for other companies to adopt it too.

This is a very important point and a huge step forward in my opinion.

The downside of MIT/BSD licenses is that companies can take and not give 
back. It doesn't build a community and commonly-shared property. Copyleft 
allows people to take and embrace, but if they extend they have to give 
back. Which is fair, you build it on their stuff...

-- 
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

Re: [bitcoin-dev] Compact Block Relay BIP

[Tom Zander via bitcoin-dev]

On Sunday, May 08, 2016 03:24:22 AM Matt Corallo wrote:
> >> ===Intended Protocol Flow===
> > 
> > I'm not a fan of the solution that a CNode should keep state and talk to
> > its remote nodes differently while announcing new blocks.
> > Its too complicated and ultimately counter-productive.
> > 
> > The problem is that an individual node needs to predict network behaviour
> > in advance. With the downside that if it guesses wrong that both nodes
> > end up paying for the wrong guess.
> > This is not a good way to design a p2p layer.
> 
> Nodes don't need to predict much in advance, and the cost for predicting
> wrong is 0 if your peers receive blocks with a few hundred ms between
> them (as we should expect) and you haven't set the announce bit on more
> than a few peers (as the spec requires for this reason).

You misunderstand the networking effects.
The fact that your node is required to choose which one to set the announce 
bit on implies that it needs to predict which node will have the best data in 
the future.
It needs to predict which nodes will not start being incommunicado and it 
requires them to predict all the things that are not possible to predict in a 
network.
In networking it is even more true than in stocks; results of the past are no 
guarantee for the future.

This means you are creating a fragile system. Your system will only work in 
laboratory situations.  It will fail spectacularly when the network or the 
internet is under stress or some parts fall away.


Another problem with your solution is that nodes send a much larger amount of 
unsolicited data to peers in the form of the thin-block compared to the normal 
inv or header-first data.

Saying this is mitigated by only subscribing on this data from a small 
subsection of nodes means you position yourself in a situation that I 
displayed above. A tradeoff of fragile and fast.  With no possible way to make 
a node automatically decide on a good equilibrium.


> It seems I forgot to add a suggested peer-preforwarding-selection
> algorithm in the text, but the intended use-case is to set the bit on
> peers which recently provided you blocks faster than other peers, up to
> only one or three peers. This is both simple and should be incredibly
> effective.

Network autorepair systems have been researched for decades, no real solution 
has as of yet appeared. 
PHDs are written on the subject and you want to make this a design for Bitcoin 
based on "[it] should be incredibly effective", I think you are underestimating 
the subject matter you are dealing with.


> > I would suggest that a new block is announced to all nodes equally and
> > then
> > individual nodes can respond with a request of either a 'compact' or a
> > normal block.
> > This is much more in line with the current design as well.
> > 
> > Detection if remote nodes support compact blocks, for the purpose of
> > requesting a compact-block, can be done either via a network-bit or just a
> > protocol version. Or something else entirely, if you have better
> > suggestions.
> 
> In line with recent trends, neither service bits nor protocol versions
> are particularly well-suited for this purpose.

Am I to understand that you choose the solution based on the fact that service 
bits are too expensive to extend? (if not, please respond to my previous 
question actually answering the suggestion)

That sounds like a rather bad way of doing design. Maybe you can add a second 
service bits field of message instead and then do the compact blocks correctly.


> >> Variable-length integers: bytes are a MSB base-128 encoding of the
> >> number.
> >> The high bit in each byte signifies whether another digit follows.
> >> [snip bitwise spec]
> > 
> > I suggest just referring to UTF-8 which describes this just fine.
> > it is good practice to refer to existing specs when possible and not copy
> > the details.
> 
> Hmm? There is no UTF anywhere in this protocol. Indeed this section
> needs to be rewritten, as indicated. I'd recommend you read the code
> until I update the section with better text if you're confused.

Wait, you didn't steal the variable length encoding from an existing standard 
and you programmed a new one?
I strongly suggest you don't reinvent this kind of protocol level encodings 
but instead steal from something like UTF8. Which has been around for decades.

Please base your standard on other standards where possible.

Look at UTF-8 on wikipedia, you may have "invented" the same encoding that IBM 
published in 1992.


> >> Short transaction IDs
> >> Short transaction IDs are used to represent a transaction without
> >> sending a full 256-bit hash. They are calculated by:
> >> # single-SHA256 hashing the block header with the nonce appended (in
> >> little-endian)
> >> # XORing each 8-byte chunk of the double-SHA256 transaction hash with
> >> each corresponding 8-byte chunk of the hash from the previous step
> >> # Adding each of the XORed 8-byte chunks together 

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Tom Zander via bitcoin-dev]

On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev wrote:
> None of the reasons you list say anything about the fact that "being lost"
> (kicked out of the network) is a problem for those node's users.

That's because its not.

If you have a node that is "old" your node will stop getting new blocks. 
The node will essentially just say "x-hours behind" with "x" getting larger 
every hour. Funds don't get confirmed. etc.

After upgrading the software they will see the new reality of the network.

Nobody said its a problem, because its not.

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

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

[Tom Zander via bitcoin-dev]

On Monday 26 Oct 2015 11:06:56 Douglas Roark via bitcoin-dev wrote:
> While not exactly the most rigorous link,
> https://en.wikipedia.org/wiki/LevelDB#Bugs_and_Reliability seems like an
> okay place to start.

Thanks for that link!

Another Google open source product I'll avoid like the plague ;)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

[Tom Zander via bitcoin-dev]

On Thursday 22 Oct 2015 17:26:42 Jeff Garzik via bitcoin-dev wrote:
> It was noted that leveldb is unmaintained, and this is part of researching
> alternatives that are maintained and reliable.

Apart from it being unmaintained, any links to what are problems with levelDB?

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

Re: [bitcoin-dev] Memory leaks?

[Tom Zander via bitcoin-dev]

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"


signature.asc
Description: This is a digitally signed message part.
___
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

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 18.03.05 Btc Drak via bitcoin-dev wrote:
> However, I would like to challenge your assumption of point 1 that that by
> Mike making a rabble, it somehow makes CLTV deployment controversial. His
> arguments have  been refuted.

Unsuccessfully.

> Simply making a noise does not make something controversial. When it is
> controversial, it is obvious and plain to see.

I think its plain to see the soft fork is controversial.

But that’s not the point.

The point is that Bitcoin Core claims to have a consensus mechanism and sticks 
to "no change" on not reaching a consensus. And that rule is the reason why 
bigger blocks were blocked for years.

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.

I think today is the day that everyone should agree that the past is the past 
and we all learned our lesson and Bitcoin Core will make decisions a different 
way.
___
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

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 20.33.04 s7r via bitcoin-dev wrote:
> For example, I don't see this controversial nor a violation of the BIP
> requirements. Mike had some fair objections, they were explained by
> gmaxwell and Jorge, everybody understood. The explanation is clear,
> with plausible practical examples, so from my point of view the
> objections have no arguments to sustain the claim.

I enjoyed reading them, but I have to admit I'm not convinced and for me the 
objections stand.

Softforks are unnecessarily dangerous and I feel entirely avoidable. It is a 
risk that not worth taking.
___
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

[Tom Zander via bitcoin-dev]

Gregory,

you are good at language and its easy to write eloquent words.

Looking at this little dialog, for instance;

On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner wrote:
> > 1) ignores him, which is against the established criteria that all
> > technical objections coming from anyone must be addressed until that
> > person agrees, so that a change can be uncontroversial.
[snip]
On Monday 5. October 2015 18.35.13 Gregory Maxwell via bitcoin-dev wrote:
> I am aware of no instance where an active contributor to core has made
> the claim that no change to consensus can happen without 100% support

This *seems* to read like the same thing. But it is not.  Your version is more 
polarizing and changes the intent quite dramatically.

It is an eloquent change, but not really the topic we were discussing. It also 
makes you attack Mike (calling him out as having a strawman) without basis.
For the second time in this thread. 
I would suggest arguing on the topic, not on the man.

___
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

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 18.04.48 Gregory Maxwell wrote:
> > Unsuccessfully.
> 
> I think rather successfully.

Arguing that BIP66 rollout was a full success is in the same park of 
"successful" ?
Where for weeks people were told not to trust the longest chain until it was 
30 blocks.
Lets put that in perspective. The main functionality of Bitcoin  
Frankly, if that fiasco happened in a company, people would get fired for 
gross misconduct.

Bottom line is that there is a horrible track record of doing soft forks in 
the past, there are some really good technical reasons why this should not 
happen again. 

And the defence against this argument is to do character assassination because 
you think he has ulterior motives?  Like you say in this part;

> That Mike himself continues to misexplain
> things is not surprising since he has all but outright said that his
> motivation here is to disrupt Bitcoin in order to try to force his
> blocksize hardfork on people. 

"all but outright said" is still not said. Is still just a suspicion you have. 
And you are accusing a man of something he didn't do.
That’s just not right.

> > The point is that Bitcoin Core claims to have a consensus mechanism and
> > sticks to "no change" on not reaching a consensus. And that rule is the
> > reason why bigger blocks were blocked for years.
> 
> You're repeating Mike's claims there-- not anyone elses. Take your
> complaint up with him-- not the list.

There is no complaint. Why do you think there is?
Are you claiming that not reaching consensus is NOT the reason that bigger 
blocks are not in Bitcoin Core?


Reaching consensus is an admirable goal. But its exactly that, a goal.
And anyone that is a perfectionist will know that in the real world goals are 
often not reached. That doesn't make them less useful. That makes them goals.
This specific goal is in conflict of building a good product and a well 
functioning community.

A good product and a well functioning community needs rules and needs timely 
decisions and conflict resolution.
It does not need muting of valuable voices, it does not need character 
assassinations and it really doesn't need egos.

I suggest reading this book;
http://www.artofcommunityonline.org/


___
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

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 20.56.34 Gregory Maxwell wrote:
>  (In this case, I don't even believe we have any regulator
> contributors that disagree).

Regular contributor?

Please explain how for a fork in the protocol should you only listen to 
regular Bitcoin Core contributors?

___
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

[Tom Zander via bitcoin-dev]

On Monday 5. October 2015 19.41.30 Gregory Maxwell wrote:
> On Mon, Oct 5, 2015 at 7:13 PM, Tom Zander via bitcoin-dev
> 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > It is an eloquent change, but not really the topic we were discussing. It
> > also makes you attack Mike (calling him out as having a strawman) without
> > basis. For the second time in this thread.
> > I would suggest arguing on the topic, not on the man.
> 
> Such a shame you appear to reserve that wisdom for those you disagree
> with, biting your tongue when others emit all forms of ad hominem--

You are special only in your eloquent use of the language. Consider yourself 
lucky :)

> In this case, I think, however your correction is also misplaced at
> least on this message; though I would otherwise welcome it.

I would not expect anything less.

> I'm not complaining about the man;
> but pointing out the behavior of stating an
> opinion no one has held as theirs and attacking it is not a productive
> way to hold a discussion. It's an argument or a behavior, not a
> person, and beyond calling it bad I attempted to explaining (perhaps
> poorly) why its bad.

Thanks for explaining your thinking.

Fortunately I can say that while we certainly value your opinion, when peoples 
opinions are hard to read, as you indicated they can be, we should look at 
their actions. The group has followed the consensus rule quite rigorously, 
which I applaud.
But next to that people like Black and Laan have given strong verbal 
indications confirming the practice you personally keep explaining is not 
real.


When I was a little boy of maybe 12 years, I remember reading a short story, 
that stuck with me.  It was about a man that had vowed to never lie. He was 
invited to a dinner party and asked to assist with another man's accusation of 
a crime he claimed to not have committed.
The end result was that the accused man was indeed guilty, but he minced his 
words so well that every sentence uttered was true. To the layman he seemed 
truthful and pleasant. Certainly innocent.
But to the man that never lied, his stories quickly fell apart as he himself 
had had years of practice with the same. And the guilty man was jailed.


I really enjoy reading your emails and github posts too, they have an 
eloquence and a brashness.

>  If there is continued
> misunderstanding, I do not doubt its my fault; but it's probably not a
> good use of hundreds/thousands of people's time for you to help me
> interactively improve my explanation on list.

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