date:20150821

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 21 August 2015 20:21:22 GMT-07:00, "Jorge Timón"  wrote:
>Don't you mean profits instead of revenue?

Actually no. I thought revenue would be a less subjective question to ask, with 
more focus on the underlying orphan rate question; part of the answer might 
include an assumed profit margin.
-BEGIN PGP SIGNATURE-

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV2BYO
AAoJEMCF8hzn9Lncz4MH/3Z+n1sWPIBSjRebDdZdiFZvJhOYknpE9fzHo2zv6euY
qDkQS5uAXbFroF2jrm41H3hjtDXcy0mBIgxhhYMesia8ck9jXb2mXuUlnltBNzgK
XeNEWgie1Y2kvXkeq1pXgPLtWWi9W54kQQ9IrpoMpasBMmP8UHh5WuzSqrWFP8Ha
HD8smRbByhc6ydEHbVE8FaYxg9ijBIM1e0sh3W+QPgRG8ATAaH6UVJu01YkKHtwS
V7PLW0m8WAEH+DAMV54Wgzm6prreQGy3KmldHDF58iMLzescdDIc0Pvotw613rvz
06KgQkQ20ba75XeJQOqXBygGoYS3qHOa9XwVyYq1S7g=
=elAX
-END PGP SIGNATURE-

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

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

Don't you mean profits instead of revenue?

On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
> > On 8/21/2015 3:21 PM, Peter Todd wrote:
> > > To use a car analogy, Pieter Wuille has shown that the brake cylinders
> > > have a fatigue problem, and if used in stop-and-go traffic regularly
> > > they'll fail during heavy braking, potentially killing someone. You've
> > > countered with a study of highway driving, showing that if the car is
> > > only used on the highway the brakes have no issues, claiming that the
> > > car design is perfectly safe.
> >
> > No.  If we must play the analogy game, it was found that the car crashes
> > when the brakes are bad (minority hash power partitioned) the radio is
> > on (partitioned miners had small individual hashrate).
> >
> > I checked the scenario where only the radio is on, and found the car
> > does not crash.
>
> Incidentally, what's your acceptable revenue difference between a small
> (1% hashing power) and large (%30 hashing power) miner, all else being
> equal? (remember that we shouldn't preclude variance reduction
> techniques such as p2pool and pooled-solo mode)
>
> Equally, what kind of attacks on miners do you think we need to be able to
> resist? E.g. DoS attacks, hacking, etc.
>
> That would let me know if you're definition of "the brakes are bad"
> corresponds to normal usage, or something that's not reasonable to
> design for.
>
> --
> 'peter'[:-1]@petertodd.org
> 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RE : Visualizations of Votes

2015-08-21 Thread odinn via bitcoin-dev

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is great!! Thank you.

On 08/21/2015 06:24 AM, Christian Decker wrote:
> I hacked together a simple tracking page for the 'block votes', it 
> currently includes the 8MB vote and XT, as well as the /BV\d+/ vote
> for generic size: http://bitcoinstats.com/network/votes/
> 
> On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev 
>  > wrote:
> 
> Hello Nicolas,
> 
> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>>> A visualization I would like to see would include:
> 
>>> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB,
>>> BIP sipa
>> etc) based on what's published in blocks.
> 
>> If such a vote existed, I would gladly show the pie on BIPxDevs. 
>> However there is no standard way for miners to vote informally
>> BIP they support.
> 
> What about formal votes? Is there a way to visually have them
> appear in a pie chart as the votes become apparent in blocks?
> 
> I appreciate good visualizations and am trying to get a (visual) 
> comparison of the votes on these competing proposals.
> 
> 
> 
> 
>> ___ bitcoin-dev
>> mailing list bitcoin-dev@lists.linuxfoundation.org
> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
>  
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

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

iQEcBAEBAgAGBQJV1+kXAAoJEGxwq/inSG8Ctg4H/0zOfXEO/b+yxgGjnrIiiAi5
04Un/C9ZuPCn/dMQ5rZ0e8jIOclNER3NGtKbPBmLweyeN84HlrUUQ0ctRQocY1md
XwGJIMpjpwQCSf52XrH3IC0J8X45DQj3295sDNnmgAkOxIyPABKdDR7RJ8LfQU/B
BmJu0JAIBJmpAkz1ZJ2wYe2T0sUFk8WmvH40BzoIKqu0A9vMcR8IqfKMBI9Qczbw
ZJyWFTsgovS/p/8tSxeI458DsY1WjivdQe7nJNXit6eA5Yle3Cs3nvsA2+6xy5L9
uedX38+8s3XNXrXY1CCR7ptowjzCI+U6yiFluK+xx1oPPhtdRJYwo4vyTmaCaK8=
=uh68
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread odinn via bitcoin-dev

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bitcoin will be neutered and die if the big Chinese mining pools
utilize XT.

Specifically the text of @JihanWu's tweet was,

"I support increasing the block size. @BITMAINtech 's AntPool will be
prepared to switch to XT, IF we see majority has switched."

Since there are many people who are supportive of increasing the block
size, but have spend much time calling attention to the many problems
of XT (which I need not repeat again here), it is odd that Jihan Wu
would see a need to suggest that AntPool will be prepared to switch to
XT at a time when there has not yet been time for fully assessing
other proposals; not all proposals have gone through a voting process,
nor have even people had a chance yet to attend upcoming workshops on
the subject which are partially or wholly intended for development of
consensus ( one example being the upcoming one in Montreal, but I
think this is not the only one https://scalingbitcoin.org/montreal2015/
).
See also Pindar Wong's post on this list regarding the Montreal workshop
:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0101
35.html

This is also a good time to remember again some of the pressures being
placed by the state on Chinese internet-based businesses.  These
pressures have increased, as has been recently discussed on this list,
here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0098
61.html

Take a good read of these issues (linked to above) relating to Chinese
mining and the influence of the Chinese state, and it becomes clear
how the state pressures might cause Chinese miners to adopt XT in
light of:

Hearn's disabling Tor in XT
https://lists.torproject.org/pipermail/tor-dev/2014-July/007167.html
http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-e
xits-may-reveal-users-ip-addresses
Hearn's move to support blacklisting
https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the
_bitcoin_foundations_law/

A recent post that sums it up pretty well:
http://qntra.net/2015/08/collected-notes-on-the-xt-client-and-xtcoin-for
k/

I encourage people still reading this list to:

- - Not use XT
- - Work to develop consensus on an alternative that increases block
size (e.g. BIP 100)
- - Attend a conference if you can such as the one which is coming up in
Montreal https://scalingbitcoin.org/montreal2015/ and if you go there
as a developer / engineer / miner, AGREE ON SOMETHING (other than XT)
- - Visualize different proposals and votes on them so people can see
what is happening
- - Please see also (how end users can deal with this situation) at:
https://bitcointalk.org/index.php?topic=1157545.msg12189776
and contribute to the discussion if you like

Thank you.



On 08/21/2015 04:28 AM, Btc Drak via bitcoin-dev wrote:
> On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev 
>  wrote:
>> I like the intend of this attempt to bring more clarity to the
>> blocksize debate, however it would be more help to make this a
>> information site about the current outstanding BIPs and summarize
>> their differences rather than voting mechanism. (ofcourse the
>> author of the BIPs would "vote" for their own proposals.)
>> 
>> It would be good to include supporting and counter statements
>> regards to these BIPs on the site. in addition to highlight
>> certain things like pools in china have voiced their opinion that
>> increase should happen, and 8mb is something they are comfortable
>> with, which is not directly related to a single BIP, but never 
>> the less relevant in this discussion.
> 
> I was rather surprised by the tweet from AntPool[1] today saying
> that they support big blocks and would be prepared to upgrade to
> XT. Pools have stated that they are willing to increase to a
> maximum of 8MB, but upgrading to XT puts them on a schedule towards
> 8GB which is clearly not what they have agreed to.
> 
> Do you have any insights into what's going on there?
> 
> Also do you have any insight into what Chinese pools would accept
> as a compromise in terms of raising the blocksize limit?
> 
> Drak
> 
> [1] https://twitter.com/JihanWu/status/633288343338381314 
> ___ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

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

iQEcBAEBAgAGBQJV1+ZRAAoJEGxwq/inSG8CzIEH/jQQzFHz2IUxh8CIDIyBEMFA
FxVqgcTcs2gdL0R4Nprj+PoKUYSDbanDSr+5QVt6Qp8l4jbQEC/QlFWlmwRL9AlC
tUxd5VAubWCuAcg2xADD4lEFedJlxZcDZ8VHp/TMUgPuWWLP0lvnXtef/FlgmPik
xAZzsHfujD1u0trwwvVSF4pjpbV1mKQcI5lkA9nGZI5yg7+bQDDEMjmCSh2xhyCe
5Tc0b7xQqJiamPgjbauKmZFfLpCM6UdHFiT19syJ1YB9F1JmpXWz3Kpxy1w6uFNH
HSseqGIUHjQDCq3rRwoXOYPf8aVfACXPxc00HH1SbUA5dgQs4lo+i6z71dcMgs4=
=4d+B
-END PGP SIGNATURE-

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

On Sat, Aug 22, 2015 at 01:08:13AM +, Matt Corallo wrote:
> > Well actually, we can reference the DoS attacks that Bitcoin XT nodes
> > are undergoing right now - part of the attack is repeated Bloom filter
> > requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far
> > as I know they haven't published details of those attacks - a write-up
> > would be very helpful.
> > 
> > While so far those are being directed only at XT nodes, obviously this
> > is a potential issue for Core nodes as well. Like I mentioned last time
> > around, it's critical that miners aren't affected by these attacks -
> > nodes simply serving SPV wallet clients are much less latency sensitive,
> > so a good DoS attack mitigation strategy would be to have the two
> > classes of nodes out there "in the wild"
> 
> Ehh, I was going more for the oldest mention.

One of the oldest mentions is the to-be-published-later portion of my
Litecoin Audit report; attached.

(see 
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html
for the original report/timestamping/verification)

-- 
'peter'[:-1]@petertodd.org
0939524874a2896a46ea96bf59776ed869ccff95679cb087
Security vulnerabilities related to the Litecoin v0.8.3.6 release
=

Nonce: c0854ae01b1ed8526af3bb6fb82550ff
Date:  Jul 29 2013

To be released in full on January 29, 2014 to the public.

LevelDB
===

Something not well appreciated outside of the Bitcoin developers is that the
temporary limits on block size and complexity introduced in response to the
fork, automatically removed on May 15th, were simply voluntary measures to
protect against accidental triggering of the fork. The measures did not protect
against malicious attempts to trigger the the fork.

Litecoin is no different. Because of that I strongly recomend that miners be
encouraged to transition to v0.8.3.6 as soon as possible to ensure as much
hashing power as possible is consolidated on one version. Transitioning for
users/merchants is also important, however with sufficient mining power on the
new version it would be difficult to pull off a double-spend attack against an
older version simply because it would take so long to get the required number
of confirmations.

The development team may want to clarify this point to the Litecoin community
and encourage users to be suspicious if it takes an especially long time to get
confirmations. Merchants with automatic systems should use fail-safes triggered
by unusually long confirmation times, and as always ensure that total possible
losses are limited. It would be good if popular "blockchain information" sites
upgraded to v0.8.3.6 along with miners to give users accurate information on
the state of the blockchain. In any case users and merchants should take this
advice in general regardless of specific threats.

I would not be surprised to see someone deliberately attempt to fork Litecoin
by exploiting the issue; there is a lot of hostility torwards and within the
alt-coins.

SPV and network-wide DoS attacks

Bitcoin is quite vulnerable currently to network-wide DoS attacks due to the
maximum connections limits; we do not have any form of filtering on incoming
connections so an attack can be made simply by making sufficient connections to
all nodes that they hit that incoming connections limit. This is public
knowledge, as is the suggestion to stop the attack by having concepts of peer
"usefullness" so that "useless" peers can be dropped. Of course SPV nodes are
badly impacted by such measures.

What isn't as well-known publicly is that Litecoin will make this attack
significantly less costly to the attacker in v0.8.3.6 by adding support for
bloom filters. That support allows the attacker to reduce their bandwidth
consumption to a minimum, making the attack easier to pull off on a wide scale.

The Bitcoin team is aware of the issue. Our plans in the event of an attack are
to ensure that large pools and merchants connect to each other via a private
"darknet" while fixes are implemented. These plans are also useful in the event
of an attack exploiting the vulnerability discussed below.

Bloom filters and disk IO
=

However it gets worse: there is nothing limiting peers from requesting blocks.
Without bloom filters bandwidth is a natural limit, however with bloom filters
a malicious peer can simply set the filter to match almost nothing and simply
submit getdata messages to the target requesting all blocks. The target will do
an extremely large amount of disk IO at almost no cost to the attacker.

To quote one core developer in a private conversation regarding bloom filtering
"I think we didn't think hard enough before implementing this"

A good first measure would be to assign a service bit to advertise bloom filter
support:

 /** nServices flags */
 enum
 {
 NODE_NETWORK = (1 << 0),
+NODE_BLO

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

BIP Editor: Can I get a BIP # for this?

On 08/21/15 17:55, Matt Corallo via bitcoin-dev wrote:
> Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
> sure we want to encourage more people aside from bitcoinj to use
> that...I thought about adding a DNS seed section to this bip, but
> decided against it...still, I think we should add the option to select
> service bits to DNS seeds ASAP.
> 
> Re: need to "shard" the blockchain: not sure what you're referring to
> here. The bloom filter stuff requires you to download the chain
> in-order, sure, but you have to do that for headers anyway, and
> hopefully your total data isnt too much more than headers alone.
> 
> Anyone have the best reference for the DoS issues?
> 
> BIP: ?
> Title: NODE_BLOOM service bit
> Author: Matt Corallo , Peter Todd 
> Type: Standards Track (draft)
> Created: 20-08-2015
> 
> Abstract
> 
> 
> This BIP extends BIP 37, Connection Bloom filtering, by defining a
> service bit to allow peers to advertise that they support bloom filters
> explicitly. It also bumps the protocol version to allow peers to
> identify old nodes which allow bloom filtering of the connection despite
> lacking the new service bit.
> 
> 
> Motivation
> ==
> 
> BIP 37 did not specify a service bit for the bloom filter service, thus
> implicitly assuming that all nodes that serve peers data support it.
> However, the connection filtering algorithm proposed in BIP 37, and
> implemented in several clients today, has been shown to provide little
> to no privacy[1], as well as being a large DoS risk on some nodes[2].
> Thus, allowing node operators to disable connection bloom filtering is a
> much-needed feature.
> 
> 
> Specification
> =
> 
> The following protocol bit is added:
> 
> NODE_BLOOM = (1 << 2)
> 
> Nodes which support bloom filters should set that protocol bit.
> Otherwise it should remain unset. In addition the protocol version is
> increased from 70002 to 70011 in the reference implementation. It is
> often the case that nodes which have a protocol version smaller than
> 70011, but larger than 7 support bloom filtered connections without
> the NODE_BLOOM bit set, however clients which require bloom filtered
> connections should avoid making this assumption.
> 
> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
> which, nonetheless, provide filtered access to the data which they do have).
> 
> If a node does not support bloom filters but receives a "filterload",
> "filteradd", or "filterclear" message from a peer the node should
> disconnect that peer immediately. For backwards compatibility, in
> initial implementations, nodes may choose to only disconnect nodes which
> have the new protocol version set and attempt to send a filter command.
> 
> While outside the scope of this BIP it is suggested that DNS seeds and
> other peer discovery mechanisms support the ability to specify the
> services required; current implementations simply check only that
> NODE_NETWORK is set.
> 
> 
> Design rational
> ===
> 
> A service bit was chosen as applying a bloom filter is a service.
> 
> The increase in protocol version is for backwards compatibility. In
> initial implementations, old nodes which are not yet aware of NODE_BLOOM
> and use a protocol version < 70011 may still send filter* messages to a
> node without NODE_BLOOM. This feature may be removed after there are
> sufficient NODE_BLOOM nodes available and SPV clients have upgraded,
> allowing node operators to fully close the bloom-related DoS vectors.
> 
> 
> Reference Implementation
> 
> 
> https://github.com/bitcoin/bitcoin/pull/6579
> 
> 
> Copyright
> =
> 
> This document is placed in the public domain.
> 
> 
> References
> ==
> 
> [1] http://eprint.iacr.org/2014/763
> [2]  is one example where the issues were found, though others
> independently discovered issues as well. Sample DoS exploit code
> available at https://github.com/petertodd/bloom-io-attack.
> 
> 
> 
> On 08/21/15 05:42, Peter Todd wrote:
>> On Thu, Aug 20, 2015 at 10:38:19PM -0700, Peter Todd via bitcoin-dev wrote:
 Motivation
 ==

 BIP 37 did not specify a service bit for the bloom filter service, thus
 implicitly assuming that all nodes that serve peers data support it.
 However, the connection filtering algorithm proposed in BIP 37, and
 implemented in several clients today, has been shown to provide little
 to no privacy, as well as being a large DoS risk on some nodes. Thus,
 allowing node operators to disable connection bloom filtering is a
 much-needed feature.
>>>
>>> I'd reference that paper on bloom filters re: the "little to no privacy"
>>> issue. There's also a post in the bitcoinj mailing list somewhere IIRC
>>> talking about the default settings, and how they don't provide any
>>

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP



On 08/21/15 22:06, Peter Todd wrote:
> On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
>> Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
>> sure we want to encourage more people aside from bitcoinj to use
>> that...I thought about adding a DNS seed section to this bip, but
>> decided against it...still, I think we should add the option to select
>> service bits to DNS seeds ASAP.
> 
> Well, in general relying on seeds every time you start your node is a
> really bad idea; doing so much be carefully weighed against the
> downsides and should be used only as a last resort. Nodes should be
> doing caching and proper gossip protocol participation whenever
> possible. (note how bitcoinj nodes *do* rely on centralized servers,
> implemented with an unauthenticated, unencrypted, protocol - the worst
> of all possible solutions with many possible MITM vectors and privacy
> security holes)
>
> To that end, I'd be inclined to leave the DNS seed protocol as it is and
> let others solve the centralized server use-case, for which Cartographer
> isn't all that bad of a load balancing mechanism. Also as gmaxwell noted
> on IRC, adding flag bits does have privacy implications.

Had a discussion on IRC and with Pieter, and I kinda agree that the more
optimal way is for DNS seeds to, instead of returning NODE_NETWORK
nodes, return any node which responds to getaddr, allowing clients to
connect to a few DNS seeds by name, do a getaddr, then disconnect (like
Bitcoin Core does now if you're using Tor). They can then select the
peers they want based on nServices.

>> Re: need to "shard" the blockchain: not sure what you're referring to
>> here. The bloom filter stuff requires you to download the chain
>> in-order, sure, but you have to do that for headers anyway, and
>> hopefully your total data isnt too much more than headers alone.
> 
> Any protocol change that would split blocks themselves into multiples.
> Not an easy problem to solve, but given the inherent O(n^2) scaling of
> global consensus blockchains, it's the only kind of solution that could
> in the future make the blockchain itself have reasonable scalability.

Meh, whatever, justification is already provided well enough without
having to go into "but if we did this long into the future"  arguments.

>> Anyone have the best reference for the DoS issues?
> 
> Well actually, we can reference the DoS attacks that Bitcoin XT nodes
> are undergoing right now - part of the attack is repeated Bloom filter
> requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far
> as I know they haven't published details of those attacks - a write-up
> would be very helpful.
> 
> While so far those are being directed only at XT nodes, obviously this
> is a potential issue for Core nodes as well. Like I mentioned last time
> around, it's critical that miners aren't affected by these attacks -
> nodes simply serving SPV wallet clients are much less latency sensitive,
> so a good DoS attack mitigation strategy would be to have the two
> classes of nodes out there "in the wild"

Ehh, I was going more for the oldest mention.

>> BIP: ?
>> Title: NODE_BLOOM service bit
>> Author: Matt Corallo , Peter Todd 
>> Type: Standards Track (draft)
>> Created: 20-08-2015
>>
>> Abstract
>> 
>>
>> This BIP extends BIP 37, Connection Bloom filtering, by defining a
>> service bit to allow peers to advertise that they support bloom filters
>> explicitly. It also bumps the protocol version to allow peers to
>> identify old nodes which allow bloom filtering of the connection despite
>> lacking the new service bit.
>>
>>
>> Motivation
>> ==
>>
>> BIP 37 did not specify a service bit for the bloom filter service, thus
>> implicitly assuming that all nodes that serve peers data support it.
>> However, the connection filtering algorithm proposed in BIP 37, and
>> implemented in several clients today, has been shown to provide little
>> to no privacy[1], as well as being a large DoS risk on some nodes[2].
>> Thus, allowing node operators to disable connection bloom filtering is a
>> much-needed feature.
>>
>>
>> Specification
>> =
>>
>> The following protocol bit is added:
>>
>> NODE_BLOOM = (1 << 2)
>>
>> Nodes which support bloom filters should set that protocol bit.
>> Otherwise it should remain unset. In addition the protocol version is
>> increased from 70002 to 70011 in the reference implementation. It is
>> often the case that nodes which have a protocol version smaller than
>> 70011, but larger than 7 support bloom filtered connections without
>> the NODE_BLOOM bit set, however clients which require bloom filtered
>> connections should avoid making this assumption.
>>
>> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
>> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
>> which, nonetheless, provide filtered access to the data which they do have).
>>
>> If a node does not supp

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

On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote:
> 
> I submitted the pull-request for the median-past timelock BIP just now
> 
> https://github.com/bitcoin/bips/pull/182
> 
> Any luck finding the link to this discussion? It would be nice to
> include this for posterity.

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

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

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

2015-08-21 Thread Ahmed Zsales via bitcoin-dev

Interesting.

Unless I misunderstand the proposal, you would have to factor a way to deal
with miner cartel behavior. A few emails every week and the larger miners
could collude to set prices.

With that figured, then your voting proposal could be triggered by a moving
day block average which takes into account capacity for any given period,
plus a level of headroom for unexpected spikes. The issue with this is
forward planning is more important, especially when the moving average is
longer than a week.

Credit card providers and retailers use a number of factors to plan for
capacity on a regional basis. From previous years figures, long-term
weather forecasts, annual calendar events, one off events, etc. A global
currency can't use many of these tools for forward planning.

E.g. religious holidays are among the biggest events for transactions; if
we take Christmas, your proposal could work out a capacity during a quiet
period in November leading to a downward adjustment which then sees
transactions getting maxed out during the two weeks before Christmas eve.
You could then have an upward adjustment, but people stop spending on
Christmas day.

These are human factors that need to be considered.

On Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> 
>   BIP: XX
>   Title: Consensus based block size retargeting algorithm
>   Author: BtcDrak 
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-21
> 
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> ==Motivation==
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> ==Specification==
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string “/BXn.nnn/” where valid votes would exist
> between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
> increase). “/BX1.000/” would be a vote for no change. Invalid votes
> will be counted as a vote for no change: “/BX1.000/”.
>
>
> ==Acknowledgements==
>
> This proposal is based on ide

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

On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
> On 8/21/2015 3:21 PM, Peter Todd wrote:
> > To use a car analogy, Pieter Wuille has shown that the brake cylinders
> > have a fatigue problem, and if used in stop-and-go traffic regularly
> > they'll fail during heavy braking, potentially killing someone. You've
> > countered with a study of highway driving, showing that if the car is
> > only used on the highway the brakes have no issues, claiming that the
> > car design is perfectly safe. 
> 
> No.  If we must play the analogy game, it was found that the car crashes
> when the brakes are bad (minority hash power partitioned) the radio is
> on (partitioned miners had small individual hashrate).
> 
> I checked the scenario where only the radio is on, and found the car
> does not crash.

Incidentally, what's your acceptable revenue difference between a small
(1% hashing power) and large (%30 hashing power) miner, all else being
equal? (remember that we shouldn't preclude variance reduction
techniques such as p2pool and pooled-solo mode)

Equally, what kind of attacks on miners do you think we need to be able to
resist? E.g. DoS attacks, hacking, etc.

That would let me know if you're definition of "the brakes are bad"
corresponds to normal usage, or something that's not reasonable to
design for.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

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

[bitcoin-dev] Questiosn about BIP100

2015-08-21 Thread Andrew C via bitcoin-dev

Hi all,

Is there any client or code that currently implements BIP 100? And how will
it be deployed? WIll the initial fork be deployed in the same manner that
the max block size changes are deployed described in the bip?

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

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

2015-08-21 Thread Paul Sztorc via bitcoin-dev

You said:

> There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase

From this, my understanding is that you are operating on the principle
that "the optimum blocksize" is related to "popularity/use of Bitcoin".

It seems that others on this list instead feel that "the optimum
blocksize" is a function of "technical limitations (namely bandwidth)".
Do you acknowledge this as an irreconcilable difference in approach?

Also, I'm not sure, but your principle would seem to imply that
"outsourcing the decision to Miners" is superfluous. You are concerned
(according to you) with "not reacting to 'popularity' quickly enough",
and you are only against "predetermined increases" and "hashpower
influences" (according to you), so why not measure "popularity" directly
(by using "transaction volume" or "fees paid") and use that number to
set the blocksize?

--

However, thank you very much for actually stating a principle. Unless
one knows what a person's principle is, one *can't even check if* what
they are saying makes any sense (according to *them*), so my completely
sincere congratulations on an intelligible email.


On 8/21/2015 6:22 PM, Btc Drak via bitcoin-dev wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> 
>   BIP: XX
>   Title: Consensus based block size retargeting algorithm
>   Author: BtcDrak 
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-21
> 
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> ==Motivation==
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> ==Specification==
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string “/BXn.nnn/” where valid votes would exist
> between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
> increase). “/BX1.000/” would be a vote for no change. Invalid votes
> will be counted as a vote for no change: “/BX1.000/”.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory

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

2015-08-21 Thread Tom Harding via bitcoin-dev

On 8/21/2015 3:21 PM, Peter Todd wrote:
> To use a car analogy, Pieter Wuille has shown that the brake cylinders
> have a fatigue problem, and if used in stop-and-go traffic regularly
> they'll fail during heavy braking, potentially killing someone. You've
> countered with a study of highway driving, showing that if the car is
> only used on the highway the brakes have no issues, claiming that the
> car design is perfectly safe. 

No.  If we must play the analogy game, it was found that the car crashes
when the brakes are bad (minority hash power partitioned) the radio is
on (partitioned miners had small individual hashrate).

I checked the scenario where only the radio is on, and found the car
does not crash.

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

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

2015-08-21 Thread Tom Harding via bitcoin-dev

On 8/20/2015 11:07 PM, Peter Todd via bitcoin-dev wrote:

> I run a number of high speed nodes and while I don't have historical
> logs handy over time, I've noticed a drop from about %5-%10 SPV
> clients at any one time tocloser to %1


Just checked mine and found 20.4% bitcoinj connections.


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

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

On Fri, Aug 21, 2015 at 06:15:16PM -0400, Chris Pacia wrote:
> On Aug 21, 2015 2:07 AM, "Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > Also, as I mentioned, just look at the popularity of wallets such as
> > Mycelium that are not adopting bloom filters, but going with SPV
> > verification of block headers w/ lookup servers.
> 
> Related I recently had a conversation with a Mycelium employee who told me
> they were considering moving to spv/bloom because of the server issues
> Andreas mentioned.
> 
> I don't know any more about their plans, but I wouldn't assume the above
> statement to be correct.

That'd be a foolish design decision to move exclusively over; their
wallet was safe to use during the recent fork, unlike Android Wallet,
precisely because of their existing design.

In any case, regardless of whether we're wrong about the popularity
issue, I've yet to see any issues raised with implementing NODE_BLOOM
that will adversely affect such wallets - we've certainly got no
shortage of node capacity to go around.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

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

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

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

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



  BIP: XX
  Title: Consensus based block size retargeting algorithm
  Author: BtcDrak 
  Status: Draft
  Type: Standards Track
  Created: 2015-08-21


==Abstract==

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

==Motivation==

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

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

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


==Rationale==

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


==Specification==

The initial "base block size limit" shall be 1MB.

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

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

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

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

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

The maximum block size may not increase above 8MB.

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


==Acknowledgements==

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


==Copyright==

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

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

On Fri, Aug 21, 2015 at 09:52:43AM -0700, Tom Harding wrote:
> On 8/20/2015 5:37 PM, Peter Todd wrote:
> > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev 
> > wrote: >> I found that small miners were not at all disadvantaged by large
> blocks. >> > > You used 20% as the size of the large miner, with all the
> small miners > having good connectivity with each other. > > That is
> *not* the scenario we're worried about. The math behind the > issue is
> that the a miner needs to get their blocks to at least 33% of > hashing
> power, but more than that is unnecessary and only helps their >
> competition; you simulated 20%, which is under that threshold. Equally,
> > why are you assuming the small miner group is well connected to each >
> other? > > You probably didn't get any replies because your experiment
> is obviously > wrong and misguided, and we're all busy. >
> 
> I gave the small miners collectively the same hashrate as the large
> miners in the original test.  I made them well-connected because
> everyone was well-connected intra-partition in the original test.
> 
> I just varied one thing: the size of the miners.  This is a principle of
> experiment design, in science.
> 
> Next you'll probably claim that second-order and cross-term effects
> dominate.  Maybe you can find the time to prove it.

This is a security issue: if you can find a likely scenario where the
system fails, that's a problem and we need to fix it.

You've taken the scenario where the system fails, and changed the
conditions to create a scenario where it works. That's not particularly
interesting or noteworthy.

To use a car analogy, Pieter Wuille has shown that the brake cylinders
have a fatigue problem, and if used in stop-and-go traffic regularly
they'll fail during heavy braking, potentially killing someone. You've
countered with a study of highway driving, showing that if the car is
only used on the highway the brakes have no issues, claiming that the
car design is perfectly safe.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


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

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

2015-08-21 Thread Chris Pacia via bitcoin-dev

On Aug 21, 2015 2:07 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Also, as I mentioned, just look at the popularity of wallets such as
> Mycelium that are not adopting bloom filters, but going with SPV
> verification of block headers w/ lookup servers.

Related I recently had a conversation with a Mycelium employee who told me
they were considering moving to spv/bloom because of the server issues
Andreas mentioned.

I don't know any more about their plans, but I wouldn't assume the above
statement to be correct.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
> Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
> sure we want to encourage more people aside from bitcoinj to use
> that...I thought about adding a DNS seed section to this bip, but
> decided against it...still, I think we should add the option to select
> service bits to DNS seeds ASAP.

Well, in general relying on seeds every time you start your node is a
really bad idea; doing so much be carefully weighed against the
downsides and should be used only as a last resort. Nodes should be
doing caching and proper gossip protocol participation whenever
possible. (note how bitcoinj nodes *do* rely on centralized servers,
implemented with an unauthenticated, unencrypted, protocol - the worst
of all possible solutions with many possible MITM vectors and privacy
security holes)

To that end, I'd be inclined to leave the DNS seed protocol as it is and
let others solve the centralized server use-case, for which Cartographer
isn't all that bad of a load balancing mechanism. Also as gmaxwell noted
on IRC, adding flag bits does have privacy implications.

> Re: need to "shard" the blockchain: not sure what you're referring to
> here. The bloom filter stuff requires you to download the chain
> in-order, sure, but you have to do that for headers anyway, and
> hopefully your total data isnt too much more than headers alone.

Any protocol change that would split blocks themselves into multiples.
Not an easy problem to solve, but given the inherent O(n^2) scaling of
global consensus blockchains, it's the only kind of solution that could
in the future make the blockchain itself have reasonable scalability.

> Anyone have the best reference for the DoS issues?

Well actually, we can reference the DoS attacks that Bitcoin XT nodes
are undergoing right now - part of the attack is repeated Bloom filter
requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far
as I know they haven't published details of those attacks - a write-up
would be very helpful.

While so far those are being directed only at XT nodes, obviously this
is a potential issue for Core nodes as well. Like I mentioned last time
around, it's critical that miners aren't affected by these attacks -
nodes simply serving SPV wallet clients are much less latency sensitive,
so a good DoS attack mitigation strategy would be to have the two
classes of nodes out there "in the wild"

> BIP: ?
> Title: NODE_BLOOM service bit
> Author: Matt Corallo , Peter Todd 
> Type: Standards Track (draft)
> Created: 20-08-2015
> 
> Abstract
> 
> 
> This BIP extends BIP 37, Connection Bloom filtering, by defining a
> service bit to allow peers to advertise that they support bloom filters
> explicitly. It also bumps the protocol version to allow peers to
> identify old nodes which allow bloom filtering of the connection despite
> lacking the new service bit.
> 
> 
> Motivation
> ==
> 
> BIP 37 did not specify a service bit for the bloom filter service, thus
> implicitly assuming that all nodes that serve peers data support it.
> However, the connection filtering algorithm proposed in BIP 37, and
> implemented in several clients today, has been shown to provide little
> to no privacy[1], as well as being a large DoS risk on some nodes[2].
> Thus, allowing node operators to disable connection bloom filtering is a
> much-needed feature.
> 
> 
> Specification
> =
> 
> The following protocol bit is added:
> 
> NODE_BLOOM = (1 << 2)
> 
> Nodes which support bloom filters should set that protocol bit.
> Otherwise it should remain unset. In addition the protocol version is
> increased from 70002 to 70011 in the reference implementation. It is
> often the case that nodes which have a protocol version smaller than
> 70011, but larger than 7 support bloom filtered connections without
> the NODE_BLOOM bit set, however clients which require bloom filtered
> connections should avoid making this assumption.
> 
> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
> which, nonetheless, provide filtered access to the data which they do have).
> 
> If a node does not support bloom filters but receives a "filterload",
> "filteradd", or "filterclear" message from a peer the node should
> disconnect that peer immediately. For backwards compatibility, in
> initial implementations, nodes may choose to only disconnect nodes which
> have the new protocol version set and attempt to send a filter command.
> 
> While outside the scope of this BIP it is suggested that DNS seeds and
> other peer discovery mechanisms support the ability to specify the
> services required; current implementations simply check only that
> NODE_NETWORK is set.
> 
> 
> Design rational
> ===
> 
> A service bit was chosen as applying a bloom filter is a service.
> 
> The increase in protocol version is for b

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

2015-08-21 Thread Upal Chakraborty via bitcoin-dev

I have tried to solve the maximum block size debate in two different
proposal.

i. Depending only on previous block size calculation.

ii. Depending on previous block size calculation and previous Tx fee
collected by miners.


Proposal 1: Depending only on previous block size calculation

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last
difficulty period, is less than 50% MaxBlockSize
Half MaxBlockSize
Else
Keep the same MaxBlockSize
Proposal 2: Depending on previous block size calculation and previous Tx
fee collected by miners

TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks
in last 2 difficulty period
TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in
last 2 difficulty period (This actually includes 8 blocks from last but one
difficulty)

If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 >
50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
TotalTxFeeInLastButOneDifficulty) )
MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize /
TotalTxFeeInLastButOneDifficulty
Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016
< 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
TotalTxFeeInLastButOneDifficulty) )
MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize /
TotalTxFeeInLastButOneDifficulty
Else
Keep the same MaxBlockSize
Details: http://upalc.com/maxblocksize.php

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

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

2015-08-21 Thread Daniele Pinna via bitcoin-dev

"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3% of
the blocks."

Peter_R's analysis of fee markets in the absence of blocksize limits [1]
shows that the hashrate advantage of a large miner is a side-effect of
coinbase subsidization. As the block rewards get smaller, so will large
miner advantages. An easy way to think about this is as follows:

Currently, the main critique of larger blocksizes is that we'll connected
miners can cut out smaller miners by gratuitously filling up blocks with
self-paying transactions. This only works because block subsidies exist.
The moment block rewards become comparable to block TX fees, this exploit
ceases to be functional.

Basically, large miners will still be forced to move full blocks, but it
will go against their interest to fill them with spam since their main
source of income is the fees themselves. As a result, large miners (unlike
smaller ones) will lose the incentive to mine an un full block this evening
the playing field.

In this context, large blocksizes as proposed by BIP100-101 hope to
stimulate the increase of TX fees by augmenting the network's capacity. The
sooner block rewards become comparable to block fees, the sooner we will
get rid of mine centralization.

Dpinna

[1]
http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

2015-08-21 Thread Sergio Demian Lerner via bitcoin-dev

Hector,
 I can only say 2 things in the brief time I have now:

1. There is a solution that I proposed for proving you own a copy of the
block-chain. It's using aymmetric-time functions:

https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/

2. I'm finishing a paper on a transaction system (DAGCoin) which relies on
proof-of-work per transactions, and no per blocks. Actually it has no
blocks.

This has been explored in the past, but I came up with some basic ideas
that make this work a few months ago. I will forward a draft to you while
at the same time I try to analyze your proposal. Or I may publish the draft
altogether.

Best regards,
 Sergio

On Fri, Aug 21, 2015 at 5:50 PM, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Jameson,
>
> I like your thinking about the implicit reward of full nodes. It was not
> perceived as sufficient by many, hence full node counts were falling.
>
> This might reverse now as the implicit value of validating yourself
> however becomes higher in a heterogenous environment, that is if there are
> hard forks in the wild.
>
> Actually pooled mining became an option through the homogenous nature of
> the network.
>
> Tamas Blummer
>
> On Aug 19, 2015, at 13:42, Jameson Lopp via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> The incentives for running a node may not be obvious to the average user,
> but they are there. Rather than direct monetary incentives, they are
> indirect. For one, it allows you to have a local copy of the blockchain
> that you validated yourself - trustlessness is the entire point of this
> system. Having local self-validated blockchain data is also essential for
> any enterprise that needs to quickly access large volumes of it. The other
> incentive is it supports the network. Users may feel that this is necessary
> out of altruism or they may feel incentivized to protect their investments
> in Bitcoin.
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

2015-08-21 Thread Tamas Blummer via bitcoin-dev

Jameson,

I like your thinking about the implicit reward of full nodes. It was not 
perceived as sufficient by many, hence full node counts were falling.

This might reverse now as the implicit value of validating yourself however 
becomes higher in a heterogenous environment, that is if there are hard forks 
in the wild.

Actually pooled mining became an option through the homogenous nature of the 
network.

Tamas Blummer

> On Aug 19, 2015, at 13:42, Jameson Lopp via bitcoin-dev 
>  wrote:
> 
> The incentives for running a node may not be obvious to the average user, but 
> they are there. Rather than direct monetary incentives, they are indirect. 
> For one, it allows you to have a local copy of the blockchain that you 
> validated yourself - trustlessness is the entire point of this system. Having 
> local self-validated blockchain data is also essential for any enterprise 
> that needs to quickly access large volumes of it. The other incentive is it 
> supports the network. Users may feel that this is necessary out of altruism 
> or they may feel incentivized to protect their investments in Bitcoin.

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev
 wrote:
>> For the 73th time or so this month on this list:
>>
>> The maximum block size consensus rule limits mining centralization
>> (which is currently pretty bad).
>
>
> Instead of posting all these messages with bald claims why don't you work on
> a decentralization metric which you can point to?

Please start with the centralization metrics we both agree are
necessary instead of keeping insulting me publicly and privately.

> (instead of trying to
> claim people don't understand things which is clearly not the case,  You are
> just attacking people you don't agree with).

I'm not inventing this, he recently said so himself publicly on this
mailing list:

"I don't believe that the maximum block size has much at all to do with
mining centralization"

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009960.html

It is therefore not surprising that non-developers and developers with
less experience in Bitcoin than Gavin have similar misunderstandings.

That claim seems in contradiction with his earlier analysis:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3%
of the blocks."

That's why I was surprised when he denied the relation between the
consensus maximum size and mining centralization, but hey, people
change their minds and that's completely fine. I change my mind about
many things quite often myself. For example, I will change my mind
about not touching the maximum blocksize consensus rule as soon as I
see some data that convinces that the proposed sizes are not very
risky.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

2015-08-21 Thread Eric Lombrozo via bitcoin-dev

Unfortunately we have no way of rigorously proving functional equivalence
other than code review and unit testing. The simpler the consensus code
(and the more we can write it in a style that affords provability of
correctness) the easier it will be in the future to compare implementations.

Prior to swapping out implementations, we should at the least run it
through the gauntlet and perhaps run both implementations side-by-side.

All I/O should be treated abstractly in the API.

In C++ I really like using a nearly bare-bones signal template for most
async message handling, i.e.
https://github.com/ciphrex/mSIGNA/blob/master/deps/Signals/src/Signals.h

This greatly facilitates support for async bidirectional I/O, etc...with
minimal overhead.

But others might have other stylistic preferences.

- Eric

On Fri, Aug 21, 2015, 12:46 PM Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer 
> wrote:
> > Every re-implementation, re-factoring even copy-paste introduces a risk
> of disagreement,
> > but also open the chance of doing the work better, in the sense of
> software engineering.
>
> But you don't want something better, you want something functionally
> identical.
> You may want to watch sipa's explanation on why "the implementation is
> the specification" and the reasons to separate libconsensus:
> https://youtu.be/l3O4nh79CUU?t=764
>
> >> On Aug 20, 2015, at 10:06, Jorge Timón  wrote:
> >>
> >>
> >> But the goal is not reimplementing the consensus rules but rather
> >> extract them from Bitcoin Core so that nobody needs to re-implement
> >> them again.
> >
> >
> >
> > My goal is different. Compatibility with Bitcoin is important as I also
> want to deal with Bitcoins,
> > but it is also imperative to be able to create and serve other block
> chains with other rules and for those
> > I do not want to carry on the legacy of an antique tool set and a
> spaghetti style.
> >
> > Bits of Proof uses scala (akka networking), java (api service), c++
> (leveledb and now libconsensus)
> > and I am eager to integrate secp256k1 (c) as soon as part of consensus.
> The choices were
> > made because each piece appears best in what they do.
>
> Since you already depend on libconsensus for VerifyScript, wouldn't it
> be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
> You would still have complete control over storage, concurrency,
> networking, policy...
> My plan is for the C API to interface with the external storage by
> passing a function pointer to it.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

On Fri, Aug 21, 2015 at 2:13 PM, Sriram Karra  wrote:
> On Thu, Aug 20, 2015 at 1:01 PM, Jorge Timón
>  wrote:
>>
>>
>> For the 73th time or so this month on this list:
>>
>> The maximum block size consensus rule limits mining centralization
>> (which is currently pretty bad).
>>
>> But don't worry about not being an authority on the subject: Gavin
>> (who has written extensively on the subject) doesn't seem to
>> understand this either.
>
>
> If your goal is to get the Miners (who are highly centralised today) to
> implement a change in consensus rule that will limit mining centralisation,
> guess what public position you will be taking?

The rule is already there. My goal is to make sure we understand the
potential consequences of changing that rule in the "less limitation
to mining centralization" better before changing it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

2015-08-21 Thread Danny Thorpe via bitcoin-dev

The limits Alex proposed are generous (bordering on obscene!), but dropping
that down to allowing only two levels of chained unconfirmed transactions
is too tight.

Use case: Brokered asset transfers may require sets of transactions with a
dependency tree depth of 3 to be published together. ( N seller txs, 1
broker bridge tx, M buyer txs )

If the originally proposed depth limit of 100 does not provide a sufficient
cap on memory consumption or loop/recursion depth, a depth limit of 10
would provide plenty of headroom for this 3 level use case and similar
patterns.

-Danny

On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I dont see any problem with such limits. Though, hell, if you limited
> entire tx dependency trees (ie transactions and all required unconfirmed
> transactions for them) to something like 10 txn, maximum two levels
> deep, I also wouldnt have a problem.
>
> Matt
>
> On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
> > Hi everyone,
> >
> >
> > I'd like to propose a new set of requirements as a policy on when to
> > accept new transactions into the mempool and relay them.  This policy
> > would affect transactions which have as inputs other transactions which
> > are not yet confirmed in the blockchain.
> >
> > The motivation for this policy is 6470
> >  which aims to limit the
> > size of a mempool.  As discussed in that pull
> > ,
> > once the mempool is full a new transaction must be able to pay not only
> > for the transaction it would evict, but any dependent transactions that
> > would be removed from the mempool as well.  In order to make sure this
> > is always feasible, I'm proposing 4 new policy limits.
> >
> > All limits are command line configurable.
> >
> > The first two limits are required to make sure no chain of transactions
> > will be too large for the eviction code to handle:
> >
> > Max number of descendant txs : No transaction shall be accepted if it
> > would cause another transaction in the mempool to have too many
> > descendant transactions (all of which would have to be evicted if the
> > ancestor transaction was evicted).  Default: 1000
> >
> > Max descendant size : No transaction shall be accepted if it would cause
> > another transaction in the mempool to have the total size of all its
> > descendant transactions be too great.  Default : maxmempool / 200  =
> 2.5MB
> >
> > The third limit is required to make sure calculating the state required
> > for sorting and limiting the mempool and enforcing the first 2 limits is
> > computationally feasible:
> >
> > Max number of ancestor txs:  No transaction shall be accepted if it has
> > too many ancestor transactions which are not yet confirmed (ie, in the
> > mempool). Default: 100
> >
> > The fourth limit is required to maintain the pre existing policy goal
> > that all transactions in the mempool should be mineable in the next
> block.
> >
> > Max ancestor size: No transaction shall be accepted if the total size of
> > all its unconfirmed ancestor transactions is too large.  Default: 1MB
> >
> > (All limits include the transaction itself.)
> >
> > For reference, these limits would have affected less than 2% of
> > transactions entering the mempool in April or May of this year.  During
> > the period of 7/6 through 7/14, while the network was under stress test,
> > as many as 25% of the transactions would have been affected.
> >
> > The code to implement the descendant package tracking and new policy
> > limits can be found in 6557
> >  which is built off of
> 6470.
> >
> > Thanks,
> > Alex
> >
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Aug 20, 2015 at 10:35 AM, Tamas Blummer  wrote:
> Every re-implementation, re-factoring even copy-paste introduces a risk of 
> disagreement,
> but also open the chance of doing the work better, in the sense of software 
> engineering.

But you don't want something better, you want something functionally identical.
You may want to watch sipa's explanation on why "the implementation is
the specification" and the reasons to separate libconsensus:
https://youtu.be/l3O4nh79CUU?t=764

>> On Aug 20, 2015, at 10:06, Jorge Timón  wrote:
>>
>>
>> But the goal is not reimplementing the consensus rules but rather
>> extract them from Bitcoin Core so that nobody needs to re-implement
>> them again.
>
>
>
> My goal is different. Compatibility with Bitcoin is important as I also want 
> to deal with Bitcoins,
> but it is also imperative to be able to create and serve other block chains 
> with other rules and for those
> I do not want to carry on the legacy of an antique tool set and a spaghetti 
> style.
>
> Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb 
> and now libconsensus)
> and I am eager to integrate secp256k1 (c) as soon as part of consensus. The 
> choices were
> made because each piece appears best in what they do.

Since you already depend on libconsensus for VerifyScript, wouldn't it
be nice that it also offered VerifyTx, VerifyHeader and VerifyBlock?
You would still have complete control over storage, concurrency,
networking, policy...
My plan is for the C API to interface with the external storage by
passing a function pointer to it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

I dont see any problem with such limits. Though, hell, if you limited
entire tx dependency trees (ie transactions and all required unconfirmed
transactions for them) to something like 10 txn, maximum two levels
deep, I also wouldnt have a problem.

Matt

On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:
> Hi everyone,
> 
> 
> I'd like to propose a new set of requirements as a policy on when to
> accept new transactions into the mempool and relay them.  This policy
> would affect transactions which have as inputs other transactions which
> are not yet confirmed in the blockchain.
> 
> The motivation for this policy is 6470
>  which aims to limit the
> size of a mempool.  As discussed in that pull
> ,
> once the mempool is full a new transaction must be able to pay not only
> for the transaction it would evict, but any dependent transactions that
> would be removed from the mempool as well.  In order to make sure this
> is always feasible, I'm proposing 4 new policy limits.
> 
> All limits are command line configurable.
> 
> The first two limits are required to make sure no chain of transactions
> will be too large for the eviction code to handle:
> 
> Max number of descendant txs : No transaction shall be accepted if it
> would cause another transaction in the mempool to have too many
> descendant transactions (all of which would have to be evicted if the
> ancestor transaction was evicted).  Default: 1000
> 
> Max descendant size : No transaction shall be accepted if it would cause
> another transaction in the mempool to have the total size of all its
> descendant transactions be too great.  Default : maxmempool / 200  =  2.5MB
> 
> The third limit is required to make sure calculating the state required
> for sorting and limiting the mempool and enforcing the first 2 limits is
> computationally feasible:
> 
> Max number of ancestor txs:  No transaction shall be accepted if it has
> too many ancestor transactions which are not yet confirmed (ie, in the
> mempool). Default: 100
> 
> The fourth limit is required to maintain the pre existing policy goal
> that all transactions in the mempool should be mineable in the next block.
> 
> Max ancestor size: No transaction shall be accepted if the total size of
> all its unconfirmed ancestor transactions is too large.  Default: 1MB
> 
> (All limits include the transaction itself.)
> 
> For reference, these limits would have affected less than 2% of
> transactions entering the mempool in April or May of this year.  During
> the period of 7/6 through 7/14, while the network was under stress test,
> as many as 25% of the transactions would have been affected.
> 
> The code to implement the descendant package tracking and new policy
> limits can be found in 6557
>  which is built off of 6470.
> 
> Thanks,
> Alex
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Censorship

2015-08-21 Thread sisadm101--- via bitcoin-dev


People are wondering why there is such a division in the bitcoin community
at this time. Bitcoin as a whole is only so big. The bitcoin discussion
communities are spread out, but there are only a few popular ones.
BitcoinTalk and Reddit seem to be the largest, most popular where bitcoin
discussion happens consistently and from almost everyone in the community
(devs, users, btc companies, merchants, and so on). I think we all know
where this is going. If not, here you go. BitcoinTalk and Reddit are
managed by a single person: Theymos. It's become quite clear over the past
several days/weeks, that Theymos is highly censoring bitcoin discussion,
mainly on Reddit, but also BitcoinTalk. If this single person is able to
censor content, and hush the debate, he (and whatever his agenda is), wins.
How can we as a community discuss these proposed changes, if the discussion
is from a one sided point of view? There doesn't seem to be a solution at
this time, but I find it dissapointing that many (in this very email list)
aren't discussing this important part of the issue. Maybe it's becuase
Theymos is anti-bigger blocks, which seems to coincide with the Blockstream
point of view, which many of the core devs belong to.


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!

Commercial and Bulk Mail Options!  ___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread Will Madden via bitcoin-dev

I’m replying all just because my point was changed in your response.

> As a protocol Bitcoin could support millions of full nodes. What you
> talking about is the number of shareholders. But these are poorly
> determined by the block size. The number of shareholders is determined
> by many parameter but manly by the decreasing-supply algorithm. Which
> "was chosen because it approximates the rate at which commodities like
> gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply

  I am not talking about "shareholders” who own bitcoin, or the supply of 
bitcoin at all.  I’m talking about active users of bitcoin.  I don’t care if 
they send 10,000 BTC, or .01 BTC, usage is adoption.  Putting a 1MB cap on 
block size caps transaction volume, which by definition blocks adoption and 
use.  

> While the decreasing-supply algorithm of Bitcoin has many advantage it's
> very hard to believe that the block chain will ever reach mass adoption.
> Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is
> distributed in large blocks to a few. Exceptions prove the rule. In the
> last 6 years the 1MB limit has been sufficient. I don't think that we
> will hit the 8MB limit in the next 6 years, except for stress tests and
> spam.

You can think what you like, but I find your position on this specious.  You 
don’t know if we will hit that limit in the next 6 years.  All it takes is one 
moderately successful application and we could be hitting that limit with very 
little warning.  It could be open bazaar, or something else.  Stating that 
“even after 6 years, hardly anyone owns Bitcoins.” as a justification that it 
will stay small doesn’t hold water either in terms of common sense or when 
looking at other standards evolving through history.  TCP/IP was declared as a 
standard by the US Military in 1982 and became a public standard in 1985.  
Normal people didn’t start using TCP/IP until much later, when Mark Andreessen 
created the Mosaic internet browser, the precursor to Netscape.  It was 
released in 1993.  Widespread use didn’t really kick in until the second half 
of that decade.  The reference bitcoin client was released in January 2009.  So 
it’s basically 1988 for bitcoin, if we use the internet as a proxy - one way to 
look at it.  The telephone even took 50 years to become widespread. 

> I don't think that a relative tight block size could harm Bitcoin
> middle-term. Only experienced users penetrate the block chain directly.
> They know what they are doing and deal with problems. When space for
> transactions starts to become scarce and the fees rise too much, the
> developers have enough time to make a change. It would then also not so
> controversial. A matter of a few days or weeks. Especially if all
> necessary preparations have already been taken.

This is insane.  You actually believe this?  Capping the block size at 1MB 
doesn’t just cause fees to rise.  It caps transactions that can be performed.  
This caps the number of users who can access bitcoin, directly cuts demand, 
which kills the price, which kills the mining, and BAM Rome falls.  Only 
experienced users can “penetrate’ the block chain directly?  Seriously?  You 
download a software application, or sign up for a web wallet, buy some bitcoin 
on an exchange or have a friend send you some, and send it.  Try bread wallet.  
My mom can do it.  She is in her 70’s and couldn’t program a VCR 20 years ago.

I am just going to stop here.  I really hope you change the way you are looking 
at bitcoin.  This is not what it was meant to be, and if it ever becomes this, 
I’m not going to be interested in it.

> On Aug 21, 2015, at 11:31 AM, Oliver Egginger  wrote:
> 
> Am 21.08.2015 um 15:34 schrieb Will Madden:
>> Keeping the block size at 1mb restricts the number of active users of 
>> bitcoin to around 100,000 people transacting twice a day on blockchain.  
>> BItcoin is a protocol.  Protocols are successful because of their network 
>> effect.  Capping the block size freezes bitcoin’s network effect, limits 
>> users and prevents new users from joining (which will cut demand to exchange 
>> bitcoin) and also freeze the economic incentive to mine, because it will 
>> hurt the price.  
> 
> As a protocol Bitcoin could support millions of full nodes. What you
> talking about is the number of shareholders. But these are poorly
> determined by the block size. The number of shareholders is determined
> by many parameter but manly by the decreasing-supply algorithm. Which
> "was chosen because it approximates the rate at which commodities like
> gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply
> 
> While the decreasing-supply algorithm of Bitcoin has many advantage it's
> very hard to believe that the block chain will ever reach mass adoption.
> Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is
> distributed in large blocks to a few. Exceptions prove the rule. In the
> last 6 years the 1MB l

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
decided against it...still, I think we should add the option to select
service bits to DNS seeds ASAP.

Re: need to "shard" the blockchain: not sure what you're referring to
here. The bloom filter stuff requires you to download the chain
in-order, sure, but you have to do that for headers anyway, and
hopefully your total data isnt too much more than headers alone.

Anyone have the best reference for the DoS issues?

BIP: ?
Title: NODE_BLOOM service bit
Author: Matt Corallo , Peter Todd 
Type: Standards Track (draft)
Created: 20-08-2015

Abstract

This BIP extends BIP 37, Connection Bloom filtering, by defining a
service bit to allow peers to advertise that they support bloom filters
explicitly. It also bumps the protocol version to allow peers to
identify old nodes which allow bloom filtering of the connection despite
lacking the new service bit.

Motivation
==

BIP 37 did not specify a service bit for the bloom filter service, thus
implicitly assuming that all nodes that serve peers data support it.
However, the connection filtering algorithm proposed in BIP 37, and
implemented in several clients today, has been shown to provide little
to no privacy[1], as well as being a large DoS risk on some nodes[2].
Thus, allowing node operators to disable connection bloom filtering is a
much-needed feature.

Specification
=

The following protocol bit is added:

NODE_BLOOM = (1 << 2)

Nodes which support bloom filters should set that protocol bit.
Otherwise it should remain unset. In addition the protocol version is
increased from 70002 to 70011 in the reference implementation. It is
often the case that nodes which have a protocol version smaller than
70011, but larger than 7 support bloom filtered connections without
the NODE_BLOOM bit set, however clients which require bloom filtered
connections should avoid making this assumption.

NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
which, nonetheless, provide filtered access to the data which they do have).

If a node does not support bloom filters but receives a "filterload",
"filteradd", or "filterclear" message from a peer the node should
disconnect that peer immediately. For backwards compatibility, in
initial implementations, nodes may choose to only disconnect nodes which
have the new protocol version set and attempt to send a filter command.

While outside the scope of this BIP it is suggested that DNS seeds and
other peer discovery mechanisms support the ability to specify the
services required; current implementations simply check only that
NODE_NETWORK is set.

Design rational
===

A service bit was chosen as applying a bloom filter is a service.

The increase in protocol version is for backwards compatibility. In
initial implementations, old nodes which are not yet aware of NODE_BLOOM
and use a protocol version < 70011 may still send filter* messages to a
node without NODE_BLOOM. This feature may be removed after there are
sufficient NODE_BLOOM nodes available and SPV clients have upgraded,
allowing node operators to fully close the bloom-related DoS vectors.

Reference Implementation

https://github.com/bitcoin/bitcoin/pull/6579

Copyright
=

This document is placed in the public domain.

References
==

[1] http://eprint.iacr.org/2014/763
[2]  is one example where the issues were found, though others
independently discovered issues as well. Sample DoS exploit code
available at https://github.com/petertodd/bloom-io-attack.

On 08/21/15 05:42, Peter Todd wrote:
> On Thu, Aug 20, 2015 at 10:38:19PM -0700, Peter Todd via bitcoin-dev wrote:
>>> Motivation
>>> ==
>>>
>>> BIP 37 did not specify a service bit for the bloom filter service, thus
>>> implicitly assuming that all nodes that serve peers data support it.
>>> However, the connection filtering algorithm proposed in BIP 37, and
>>> implemented in several clients today, has been shown to provide little
>>> to no privacy, as well as being a large DoS risk on some nodes. Thus,
>>> allowing node operators to disable connection bloom filtering is a
>>> much-needed feature.
>>
>> I'd reference that paper on bloom filters re: the "little to no privacy"
>> issue. There's also a post in the bitcoinj mailing list somewhere IIRC
>> talking about the default settings, and how they don't provide any
>> privacy.
> 
> Oh, and we should also point out that Bloom filters have scaling issues,
> as each application of the filter has to scan the whole blockchain -
> with future blocksize increases these issues increase, in some proposals
> quite dramatically. The underlying idea also conflicts with some
> proposals to "shard" the

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

The proposal will not break any existing clients in the first release.
After sufficient time to upgrade SPV clients, a new version will be
released which will result in older SPV clients finding themselves
disconnected from peers when they send filter* commands, so they can go
find other peers which do support bloom filtering.

On 08/21/15 05:48, Jeff Garzik wrote:
> If this is widely deployed + enabled, what is the impact to current
> wallets in use?
> 
> 
> On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo via bitcoin-dev
>  > wrote:
> 
> Peter: Since I stole most of this text from your old BIP, should I leave
> you as an author?
> 
> BIP: ?
> Title: NODE_BLOOM service bit
> Author: Matt Corallo mailto:b...@bluematt.me>>,
> Peter Todd mailto:p...@petertodd.org>>
> Type: Standards Track (draft)
> Created: 20-08-2015
> 
> Abstract
> 
> 
> This BIP extends BIP 37, Connection Bloom filtering, by defining a
> service bit to allow peers to advertise that they support bloom filters
> explicitly. It also bumps the protocol version to allow peers to
> identify old nodes which allow bloom filtering of the connection despite
> lacking the new service bit.
> 
> 
> Motivation
> ==
> 
> BIP 37 did not specify a service bit for the bloom filter service, thus
> implicitly assuming that all nodes that serve peers data support it.
> However, the connection filtering algorithm proposed in BIP 37, and
> implemented in several clients today, has been shown to provide little
> to no privacy, as well as being a large DoS risk on some nodes. Thus,
> allowing node operators to disable connection bloom filtering is a
> much-needed feature.
> 
> 
> Specification
> =
> 
> The following protocol bit is added:
> 
> NODE_BLOOM = (1 << 2)
> 
> Nodes which support bloom filters should set that protocol bit.
> Otherwise it should remain unset. In addition the protocol version is
> increased from 70002 to 70011 in the reference implementation. It is
> often the case that nodes which have a protocol version smaller than
> 70011, but larger than 7 support bloom filtered connections without
> the NODE_BLOOM bit set, however clients which require bloom filtered
> connections should avoid making this assumption.
> 
> NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
> NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
> which, nonetheless, provide filtered access to the data which they
> do have).
> 
> If a node does not support bloom filters but receives a "filterload",
> "filteradd", or "filterclear" message from a peer the node should
> disconnect that peer immediately. For backwards compatibility, in
> initial implementations, nodes may choose to only disconnect nodes which
> have the new protocol version set and attempt to send a filter command.
> 
> While outside the scope of this BIP it is suggested that DNS seeds and
> other peer discovery mechanisms support the ability to specify the
> services required; current implementations simply check only that
> NODE_NETWORK is set.
> 
> 
> Design rational
> ===
> 
> A service bit was chosen as applying a bloom filter is a service.
> 
> The increase in protocol version is for backwards compatibility. In
> initial implementations, old nodes which are not yet aware of NODE_BLOOM
> and use a protocol version < 70011 may still send filter* messages to a
> node without NODE_BLOOM. This feature may be removed after there are
> sufficient NODE_BLOOM nodes available and SPV clients have upgraded,
> allowing node operators to fully close the bloom-related DoS vectors.
> 
> 
> Reference Implementation
> 
> 
> https://github.com/bitcoin/bitcoin/pull/6579
> 
> 
> Copyright
> =
> 
> This document is placed in the public domain.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread Oliver Egginger via bitcoin-dev

Am 21.08.2015 um 15:34 schrieb Will Madden:
> Keeping the block size at 1mb restricts the number of active users of bitcoin 
> to around 100,000 people transacting twice a day on blockchain.  
> BItcoin is a protocol.  Protocols are successful because of their network 
> effect.  Capping the block size freezes bitcoin’s network effect, limits 
> users and prevents new users from joining (which will cut demand to exchange 
> bitcoin) and also freeze the economic incentive to mine, because it will hurt 
> the price.  

As a protocol Bitcoin could support millions of full nodes. What you
talking about is the number of shareholders. But these are poorly
determined by the block size. The number of shareholders is determined
by many parameter but manly by the decreasing-supply algorithm. Which
"was chosen because it approximates the rate at which commodities like
gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply

While the decreasing-supply algorithm of Bitcoin has many advantage it's
very hard to believe that the block chain will ever reach mass adoption.
Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is
distributed in large blocks to a few. Exceptions prove the rule. In the
last 6 years the 1MB limit has been sufficient. I don't think that we
will hit the 8MB limit in the next 6 years, except for stress tests and
spam.

> Freezing bitcoin’s growth for any meaningful length of time will
> threaten its position as the leading cryptocurrency.

I don't think that a relative tight block size could harm Bitcoin
middle-term. Only experienced users penetrate the block chain directly.
They know what they are doing and deal with problems. When space for
transactions starts to become scarce and the fees rise too much, the
developers have enough time to make a change. It would then also not so
controversial. A matter of a few days or weeks. Especially if all
necessary preparations have already been taken.

But I know that my opinion is very different from other claims. However,
reliable people share some more fatalism as I'm currently find in some
parts of the the Bitcoin community. Fear is a very bad adviser and can
make a genius stupid.

- oliver

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

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

2015-08-21 Thread Nicolas Dorier via bitcoin-dev

My UX skills are lacking a bit. You can edit all your thoughts about each
BIP, HTML is accepted, so you can link to other posts you made somewhere
else.
When you click on a cell in the grid, it forward you to the page that the
dev edited for this BIP.

This website is not only to say "approve", "disapprove", nor is it about a
formal process for reaching agreement.
This is a tool, a portal, which educates people, and permit you to link all
of your thoughts about the various BIP and show it to others.

With the opinions browse able from the same website, you will notice in a
gleam as soon as one of those proposal reach consensus. (I think SIPA's BIP
has a chance to do so, but nobody knows it yet)
Sadly, the most controversial is a BIP, the noisier it is, at the expense
of those which are not. (like sipa's one).

It irritates me a lot that the debate in public mind is "XT or not" /
"Bigger blocks or not", when in reality there is lots of different
proposals that might also reach consensus but are lost in the noise.
I will add any BIP that at least one voter approve and want to push forward.
I plan to add merchants/wallet providers/mining pools later.

On Fri, Aug 21, 2015 at 6:35 PM, Peter Todd  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 21 August 2015 02:31:51 GMT-07:00, Btc Drak  wrote:
> >On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
> > wrote:
> >> What might be valuable is to ask devs to explain what their threat
> >models are, what should be at the root of their thinking about the
> >blocksize.
> >
> >That's exactly what the "Technical Opinion" column is for.
>
> What if could be used for; theres value in being more explicit.
> -BEGIN PGP SIGNATURE-
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG
> AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH
> Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD
> seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl
> CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6
> JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ
> za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI=
> =Jfl+
> -END PGP SIGNATURE-
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread Tom Harding via bitcoin-dev

On 8/20/2015 5:37 PM, Peter Todd wrote:
> On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: 
> >> I found that small miners were not at all disadvantaged by large
blocks. >> > > You used 20% as the size of the large miner, with all the
small miners > having good connectivity with each other. > > That is
*not* the scenario we're worried about. The math behind the > issue is
that the a miner needs to get their blocks to at least 33% of > hashing
power, but more than that is unnecessary and only helps their >
competition; you simulated 20%, which is under that threshold. Equally,
> why are you assuming the small miner group is well connected to each >
other? > > You probably didn't get any replies because your experiment
is obviously > wrong and misguided, and we're all busy. >

I gave the small miners collectively the same hashrate as the large
miners in the original test.  I made them well-connected because
everyone was well-connected intra-partition in the original test.

I just varied one thing: the size of the miners.  This is a principle of
experiment design, in science.

Next you'll probably claim that second-order and cross-term effects
dominate.  Maybe you can find the time to prove it.

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

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

2015-08-21 Thread Will Madden via bitcoin-dev

Keeping the block size at 1mb restricts the number of active users of bitcoin 
to around 100,000 people transacting twice a day on blockchain.  

BItcoin is a protocol.  Protocols are successful because of their network 
effect.  Capping the block size freezes bitcoin’s network effect, limits users 
and prevents new users from joining (which will cut demand to exchange bitcoin) 
and also freeze the economic incentive to mine, because it will hurt the price. 

Keeping the 1MB cap in place is horrible for the health of bitcoin.  It’s good 
for competing protocols that want a chance to “catch up”. 

Freezing bitcoin’s growth for any meaningful length of time will threaten its 
position as the leading cryptocurrency.  Reasonable, controlled growth is a 
good thing.  BIP101 should be rolled into core as soon as feasible.

> On Aug 21, 2015, at 7:18 AM, Oliver Egginger via bitcoin-dev 
>  wrote:
> 
> Yifu Guo via bitcoin-dev:
>> One thing is for sure though, not increasing the blocksize is not an option.
> 
> Why not? The blocksize increase eliminates the pressure to seek durable
> solutions. But it will turn out differently. Other than we all think.
> 
> I really can not imagine that a 20-year plan will be successful. At one
> point we like to clear away the auto-increase. I think that is the only
> thing for sure at the moment.
> 
> I hope that the current protocol and blockchain will be continued.
> Perhaps with fewer people. That would settles the matter for the time
> being. ;)
> 
> - oliver
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] RE : Visualizations of Votes

2015-08-21 Thread Christian Decker via bitcoin-dev

I hacked together a simple tracking page for the 'block votes', it
currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for
generic size:
http://bitcoinstats.com/network/votes/

On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Nicolas,
>
> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
> >> A visualization I would like to see would include:
> >
> >> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
> >> sipa
> > etc) based on what's published in blocks.
> >
> > If such a vote existed, I would gladly show the pie on BIPxDevs.
> > However there is no standard way for miners to vote informally BIP
> > they support.
>
> What about formal votes? Is there a way to visually have them appear
> in a pie chart as the votes become apparent in blocks?
>
> I appreciate good visualizations and am trying to get a (visual)
> comparison of the votes on these competing proposals.
>
> >
> >
> >
> > ___ bitcoin-dev mailing
> > list bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
> MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
> P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
> oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
> HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
> Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
> =AHv3
> -END PGP SIGNATURE-
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread Oliver Egginger via bitcoin-dev

Yifu Guo via bitcoin-dev:
> One thing is for sure though, not increasing the blocksize is not an option.

Why not? The blocksize increase eliminates the pressure to seek durable
solutions. But it will turn out differently. Other than we all think.

I really can not imagine that a 20-year plan will be successful. At one
point we like to clear away the auto-increase. I think that is the only
thing for sure at the moment.

I hope that the current protocol and blockchain will be continued.
Perhaps with fewer people. That would settles the matter for the time
being. ;)

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

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

2015-08-21 Thread Yifu Guo via bitcoin-dev

accordingly to public release[1], They.

1. agreed that blocksize increase is needed.
2. opposed original 20mb, suggest 8mb instead as it is more technically
reasonable.
3. do not want blocksize to change in the "short term future" ( direct
translation. ) and in the document states.
"after discussion we are in agreement that the blocksize should be within
the ball park of 8mb for the short term future."

They have no explicitly rejected or supported the other components of
BIP101. It's my opinion that as long as the change is < 8mb. they'll take
it.

I don't believe in trying to predict the future, on adoption, technology
growth, nor geopolitics. I think it matters very little which BIP we need
up deploying, as long as all the attack vectors are covered, especially for
the dynamically adjustable ones.

One thing is for sure though, not increasing the blocksize is not an option.

we can't predict the future, in the mean time, Hardfork Responsibly™.

[1]
http://7fvhfe.com1.z0.glb.clouddn.com/@/wp-content/uploads/2015/06/%E5%8C%BA%E5%9D%97%E6%89%A9%E5%AE%B9%E8%8D%89%E6%A1%88.jpg

On Fri, Aug 21, 2015 at 7:28 AM, Btc Drak  wrote:

> On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
>  wrote:
> > I like the intend of this attempt to bring more clarity to the blocksize
> > debate, however it would be more help to make this a information site
> about
> > the current outstanding BIPs and summarize their differences rather than
> > voting mechanism.
> >  (ofcourse the author of the BIPs would "vote" for their own proposals.)
> >
> > It would be good to include supporting and counter statements regards to
> > these BIPs on the site.
> > in addition to highlight certain things like pools in china have voiced
> > their opinion that increase should happen, and 8mb is something they are
> > comfortable with, which is not directly related to a single BIP, but
> never
> > the less relevant in this discussion.
>
> I was rather surprised by the tweet from AntPool[1] today saying that
> they support big blocks and would be prepared to upgrade to XT. Pools
> have stated that they are willing to increase to a maximum of 8MB, but
> upgrading to XT puts them on a schedule towards 8GB which is clearly
> not what they have agreed to.
>
> Do you have any insights into what's going on there?
>
> Also do you have any insight into what Chinese pools would accept as a
> compromise in terms of raising the blocksize limit?
>
> Drak
>
> [1] https://twitter.com/JihanWu/status/633288343338381314
>

-- 
*Yifu Guo*
*"Life is an everlasting self-improvement."*
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread Sriram Karra via bitcoin-dev

On Thu, Aug 20, 2015 at 1:01 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> For the 73th time or so this month on this list:
>
> The maximum block size consensus rule limits mining centralization
> (which is currently pretty bad).
>
> But don't worry about not being an authority on the subject: Gavin
> (who has written extensively on the subject) doesn't seem to
> understand this either.
>

If your goal is to get the Miners (who are highly centralised today) to
implement a change in consensus rule that will limit mining centralisation,
guess what public position you will be taking?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
 wrote:
> I like the intend of this attempt to bring more clarity to the blocksize
> debate, however it would be more help to make this a information site about
> the current outstanding BIPs and summarize their differences rather than
> voting mechanism.
>  (ofcourse the author of the BIPs would "vote" for their own proposals.)
>
> It would be good to include supporting and counter statements regards to
> these BIPs on the site.
> in addition to highlight certain things like pools in china have voiced
> their opinion that increase should happen, and 8mb is something they are
> comfortable with, which is not directly related to a single BIP, but never
> the less relevant in this discussion.

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

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

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

Drak

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

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

2015-08-21 Thread Thomas Kerin via bitcoin-dev


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

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


On 19/08/15 02:08, Mark Friedenbach wrote:
> You are absolutely correct! My apologies for the oversight in editing. If you 
> could dig up the link
though that would be really helpful.
>
> On Tue, Aug 18, 2015 at 6:04 PM, Peter Todd via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas Kerin via
bitcoin-dev wrote:
> > ==Acknowledgements==
> >
> > Mark Friedenbach for designing and authoring the reference
> > implementation of this BIP.
> >
> > Thomas Kerin authored this BIP document.
>
> IIRC Gregory Maxwell came up with the actual idea in question,
during a
> discussion between myself and Luke-Jr about incentives related to
nTime
> on #bitcoin-dev or #bitcoin-wizards. He should get credit for it; I'll
> see if I can dig up a link to the discussion for historical interest.
>
> --
> 'peter'[:-1]@petertodd.org 
> 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org

> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

- -- 
My PGP key can be found here: 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJV1we8AAoJEAiDZR291eTlkdwP/Rv3wE1kUSGe62Im9VIm49ZW
hL71+9+C9BMyRWfUjizqGi/FgWzKlS5dVrKJdNnzV5g1KjZYIWF7Zy824Gnv8hrE
zW2pJc4vgu8igjtO+Qm/Wi+yy5WNjQ9qhRO+chELx4JLvD5JalagrBP2V693gNNd
g2K6fjXlogx/Rw4mK2pxYlUxgaWf2j+iJ2v09238+aWuXruTirpf/HJ70Pxwm4oq
LvJervkEUtUJLiwqsiwAQwqjesFPfuV1nYCi48G0/QfYK7tpajGD7NkO89RBNnP8
P6XGouBqulSvzc3QgtQqPIfOdEtV2Qi8Aohv+ebttaxFM8LSycvG9wxrQ+5Y/F4w
h7HDkn7ziM8MVS+KfFuuyfKxhDKdfpgu61r1YTzt7TyMSzdvQ8c9XhYCN3/AvL9S
6kwOeWTONVNpQbhI3WkzRPpTpaInLm1LkeXWuZVy9jbUtD8tlI0a6HmLzIrhcpdS
keOZiH1eV1nritrEFeToaTNL09MjyfdJk0kN9dr6fI3eOV/cPQkY52iCHWLMj+WY
X2wWwMPiNzfkgmMC+GvcQNmGSklaIr2OoUuT92q4M1pVi24vPNSvVy00W4+klXgK
UsCIMzo+n1OLRV8I1zuYkCAwOKzzJlvMw/7bggLxhuNsLubtM0HvDjq0uquE+zu6
BO12PmW8qOA2KqyeYEVn
=1Fst
-END PGP SIGNATURE-

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

Re: [bitcoin-dev] Economic majority vote by splitting coins

2015-08-21 Thread Tier Nolan via bitcoin-dev

On Fri, Aug 21, 2015 at 4:22 AM, odinn 
wrote:

> That's interesting.  But in all honesty I don't see most users being
> able to pull off what you are describing.

The idea assumes that it is a BIP + soft fork.  This means that most
wallets would support/recognise the encumbered coins.

Even if only some wallets support it, you can still move your coins
around.  Only the people who are trading between XT and Core would need to
have wallets that support it.

If you consolidate x BTC-Core and x BTC-XT into a single output, then you
can convert it back to a normal output.

> If they are convinced that it is needed its

> use will grow but they won't realize how bad they will be misled until
> later, at which point it will be...
>
> .. Too Late
>

That is the point, this gives a sneak preview.  At minimum, it shows which
choice will give the highest BTC value.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2015-08-21 Thread Yifu Guo via bitcoin-dev

I like the intend of this attempt to bring more clarity to the blocksize
debate, however it would be more help to make this a information site about
the current outstanding BIPs and summarize their differences rather than
voting mechanism.
 (ofcourse the author of the BIPs would "vote" for their own proposals.)

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

On Fri, Aug 21, 2015 at 5:35 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 21 August 2015 02:31:51 GMT-07:00, Btc Drak  wrote:
> >On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
> > wrote:
> >> What might be valuable is to ask devs to explain what their threat
> >models are, what should be at the root of their thinking about the
> >blocksize.
> >
> >That's exactly what the "Technical Opinion" column is for.
>
> What if could be used for; theres value in being more explicit.
> -BEGIN PGP SIGNATURE-
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG
> AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH
> Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD
> seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl
> CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6
> JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ
> za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI=
> =Jfl+
> -END PGP SIGNATURE-
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

-- 
*Yifu Guo*
*"Life is an everlasting self-improvement."*
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 21 August 2015 02:31:51 GMT-07:00, Btc Drak  wrote:
>On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
> wrote:
>> What might be valuable is to ask devs to explain what their threat
>models are, what should be at the root of their thinking about the
>blocksize.
>
>That's exactly what the "Technical Opinion" column is for.

What if could be used for; theres value in being more explicit.
-BEGIN PGP SIGNATURE-

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG
AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH
Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD
seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl
CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6
JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ
za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI=
=Jfl+
-END PGP SIGNATURE-

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

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 21 August 2015 02:09:06 GMT-07:00, Btc Drak via bitcoin-dev 
 wrote:
>The site could be extended to include major stakeholders too like
>major service providers (think exchanges, wallet providers etc) and
>mining pools.

Given the strong consensus that blockchains simply don't scale well - even 
Andersen describes a blocksize increase as "kicking then can down the road" - 
it'd be good to ask service providers what their long term plans for growth are.
-BEGIN PGP SIGNATURE-

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vA2
AAoJEMCF8hzn9Lncz4MH/23E4erqX1qZnXDb++hoVSXrEhj38ERVQFrMxBQ4Vpd+
VwdrYdNYLdMTdiQRYIFq1TWMQrQh18p2N6QnIo/hAskzRcWOBkc2/WyTCME6keY5
xYcruJELjmoD80zwkQRIOpfLV8483vST3aoInZ/TIYPqvgNW6Jd1ymPxSyoZD6le
hm/yQHe0gCO4hfow4Exx35YVPiNOB4RaJf6W9WRC7d5otpMz/ZVyFtYNgjBBCVRD
DSXSbISYxi7XI6E4muyDAaDylU/cVrZpJT8Tfal9bjnoZbtm44TzMDVuV7XI9/zs
yQ3ClTDY3FRTPogIskC2wbC5la2wzHogVO25FGSjKZQ=
=icqv
-END PGP SIGNATURE-

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

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

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

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

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 20 August 2015 21:45:23 GMT-07:00, Gregory Maxwell via bitcoin-dev 
 wrote:
>I think this is a bit well, sad, at the moment--  a basic principle in
>sound decision making is that one should try to withhold judgement
>until after the analysis and options are laid out to avoid prematurely
>laying down "battle lines" which then they're socially and politically
>committed to a particular answer.
>
>
>There are several other BIPs in the works right now that aren't out
>there yet, as well (as presumably) new insight from the workshop. It
>would be a shame if these things would be for naught because of being
>decided prematurely.

I'll second that, which is why I've mostly not commented on whether or not 
particular proposals are good ideas, except in the case where they're obviously 
broken due to reasons other than the blocksize itself. For instance both of 
Garzik's proposals and Andresen's BIP101 have serious flaws regardless of your 
thoughts on the blocksize, which is why I've commented on them. Wuille's OTOH 
is implemented well, which is why I have not commented about it.

What might be valuable is to ask devs to explain what their threat models are, 
what should be at the root of their thinking about the blocksize.

-BEGIN PGP SIGNATURE-

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1u9o
AAoJEMCF8hzn9Lncz4MH/0ZvaS+XK4+kVsgvdO0Mx8Axi8lesQoOSNafY1O8F4Tx
QQcIWYk+QgST0wBOooqIkivlWUhXUUc0A22VvYJ2gOt+KCWCscXkOnPrHWMA2f80
4KBEbLyFd+eaKQnCXoWX6SlDiYrNhyIySwAAvZyJ6IxTliUljuuk4Cc+K7pnVKu2
tfaRXtoal3IzyVb/rxUafgRoCaR2QdkYfr+xwkeF9AjqYFUKL+p5zENV97cbLsiF
/Rxtpe0A9RSClc+VX0yyjFAIIUfmFDWdC7+wNv8YBvHssE0lndPByxWTNVHnHmCk
44XfrsSL0LAqPIqcxyK0hnUSUgKPo0c2chd9mlXHpYE=
=eHHo
-END PGP SIGNATURE-

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

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