Re: [bitcoin-dev] block size - pay with difficulty

[Gregory Maxwell via bitcoin-dev]

On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
 wrote:
> (b) requiring miners to have idle
> hashpower on hand to change block size are both unrealistic and potentially

I really cannot figure out how you could characterize pay with
difficty has in any way involving idle hashpower.

Can you walk me through this?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Excellent - thank you.

Jeff Garzik via bitcoin-dev:
> Oops, link paste fail.
> 
> The repo: https://github.com/jgarzik/bip100
> 
> 
> On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik 
> wrote:
> 
>> Opened a repo containing the full text of BIP 100 discussion
>> document, in markdown format.
>> 
>> The BIP 100 formal spec will be checked in here as well, before
>> submitting to upstream bips.git repo.
>> 
>> 
>> 
> 
> 
> 
> ___ 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-

iQEbBAEBCgAGBQJV5+uQAAoJEGxwq/inSG8CVBUH9A5GtIj3pLxZRlX0oDxSbIWJ
2830HURoeb40ShBlhbzO1nHiJtPhRPWqByZETQcuElBagMPreSKI5VZxJ1xaNOI3
o6yo9ujeLNlge1j53TOq8uQCXKnwrVsjS3yQkXlo+IX+Vihin5c/D4Xn9y97OqwQ
CixVswCJrrRrGHj6YaFsfAx+epaJ/aT4djoB0XjH9PKJI5b0cPGSBDipHbuVn3nd
FZidPAS/hHI0Sw3k0EHtYudjBXBbMi2hCad37asrg2cIF/sFbCA/BSkpuIi5agzY
50Wp8xm3gd4WWjEn/svhw2AIgH7R/1Yk2/qFImob5iXMm7sU1OUMHD325kN2dg==
=7a0Z
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[Benjamin via bitcoin-dev]

I would be helpful to describe what is meant by "votes". As far as I
understand this would be a semi-automatic process - nodes encode values
which in turn are hardcoded in software, or is this completely automated
without any intervention at all? Is there the possibility that nodes decide
by encode votes, but somehow this decision is not adhered to? Is 4. a 51%
rule?

Under 2. it might make sense to specify values in the range (1MB steps
e.g.). The number of options could have an effect. For example if the vote
has 4 possible values or 32 possible values can make a difference in
outcomes.

With regards to 1. Bitcoin does not have a fee market, although I agree
that might be a good goal. There is no price-determination of fees and no
definition of quality of service. A fee market would entail some matching
of demand and supply to establish a price. Users would adjust fee to win a
transaction slow in a deterministic way. However currently the user has no
way of knowing what effect a fee might have. So this would necessarily
include some kind pricing-mechanism with actual commitments. Bitcoin as a
system is quite far away from such a capability. It would mean Bitcoin is
capable of adapting to how it is used. For example that would allow to
shift transactions from high demand period to low demand period. I'm not
aware of any proposal to make an actual functioning fee market in Bitcoin
(or even the conceptual primitives).



On Thu, Sep 3, 2015 at 5:09 AM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Oh, and answering your question about the 1M:  It is a safety rail.  It
> can perform no worse on the low end than the current system.  Eliminates
> unlikely scenarios that squeeze users.
>
>
> On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr  wrote:
>
>> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
>> wrote:
>> > The repo: https://github.com/jgarzik/bip100
>>
>> What is the purpose of the newly added 1 MB floor? It seems clear from the
>> current information available that 1 MB is presently too high for the
>> limit,
>> and it is entirely one-sided to only allow increases when decreases are
>> much
>> more likely to be needed in the short term.
>>
>> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
>> numeric value pushed after height? Since this is a hardfork, I suggest
>> increasing the coinbase length to allow for 100 bytes *in addition* to the
>> pushed height and size-vote.
>>
>> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
>> MB
>> (or whatever value is deemed appropriate) to make it clear that the limit
>> remains a part of the consensus protocol and p2p protocol limits are not
>> to
>> have an effect on consensus rules.
>>
>> Furthermore, I suggest modifying the voting to require 50% to set the
>> limit
>> floor. This has the effect of merely coordinating what miners can already
>> effectively do today by rejecting blocks larger than some collusion-
>> determined limit.
>>
>> Thoughts?
>>
>> Luke
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] block size - pay with difficulty

[jl2012 via bitcoin-dev]

Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:

Schemes proposing to pay with difficulty / hashpower to change block
size should be avoided.  The miners incentive has always been fairly
straightforward - it is rational to deploy new hashpower as soon as
you can get it online.  Introducing the concepts of (a) requiring
out-of-band collusion to change block size and/or (b) requiring miners
to have idle hashpower on hand to change block size are both
unrealistic and potentially corrosive.  That potentially makes the
block size - and therefore fee market - too close, too sensitive to
the wild vagaries of the mining chip market.

Pay-to-future-miner has neutral, forward looking incentives worth
researching.


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


Ref: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html


I explained here why pay with difficulty is bad for everyone: miners and 
users, and described the use of OP_CLTV for pay-to-future-miner


However, a general problem of pay-to-increase-block-size scheme is it 
indirectly sets a minimal tx fee, which could be difficult and 
arbitrary, and is against competition



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

Re: [bitcoin-dev] BIP 100 specification

[Dave Scotese via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I suggest revising these items for clarity (and I'm guessing on the first
one)

Calculate hardLimit by examining the coinbase scriptSig votes of the
previous 12,000 blocks, and taking the 20th percentile.
A new hardLimit may not increase or decrease by more than 1.2x beyond
the prior hardLimit.

to:

The new hardLimit is calculated by sorting the coinbase scriptSig votes
of the last 12,000 blocks from lowest to highest and using the vote of the
2400th block.
If the vote of the 2400th block is a change of less than 20%, use it as
the new hardLimit.  Otherwise, change the hardLimit to be closer to that
vote, to either 120% or 80% of the current hardLimit.

I don't understand #5, 75% rule.  Shouldn't invalid version 4 blocks always
be rejected?

notplato
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJV58/5AAoJEL8dSijmIbHt16IH/0jAr3v1HjWW7N1awNxeAABs
GIvOFYuZAcPkZvWZQc4JRAppglqeBfYqWl2gpyywSBK1SXjsY8zdo3t7xAK/IJfB
05hnv1GGutG3dLTzJBEXaPx62SLukepC1pzEH7rlwWvVuE9zcRqVE1eGbBEUjA9c
sGPr0z9BNeLoTbllyl3Jndz9N2Vnd6bBTxRgBlfkm/Y5ovc+GhyKZyX3Pdmj5Pga
E6foOsvqNXQJqPl8WCODsnfPSshyb7YRNFrBB9A+tpjvj4UMc8PxOpL6IX/nJpOt
jlfRoKVw2YBEodvda+9P6S54GlGFazyHhwJ11F5YCNnWW1bKoQrqJU6ofgmyxMM=
=QWra
-END PGP SIGNATURE-


On Wed, Sep 2, 2015 at 8:33 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> BIP 100 initial public draft:
> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>
> Emphasis on "initial"  This is a starting point for the usual open source
> feedback/iteration cycle, not an endpoint that Must Be This Way.
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Oh, and answering your question about the 1M:  It is a safety rail.  It can
perform no worse on the low end than the current system.  Eliminates
unlikely scenarios that squeeze users.


On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr  wrote:

> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It seems clear from the
> current information available that 1 MB is presently too high for the
> limit,
> and it is entirely one-sided to only allow increases when decreases are
> much
> more likely to be needed in the short term.
>
> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
> numeric value pushed after height? Since this is a hardfork, I suggest
> increasing the coinbase length to allow for 100 bytes *in addition* to the
> pushed height and size-vote.
>
> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
> MB
> (or whatever value is deemed appropriate) to make it clear that the limit
> remains a part of the consensus protocol and p2p protocol limits are not to
> have an effect on consensus rules.
>
> Furthermore, I suggest modifying the voting to require 50% to set the limit
> floor. This has the effect of merely coordinating what miners can already
> effectively do today by rejecting blocks larger than some collusion-
> determined limit.
>
> Thoughts?
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] block size - pay with difficulty

[Jeff Garzik via bitcoin-dev]

Schemes proposing to pay with difficulty / hashpower to change block size
should be avoided.  The miners incentive has always been fairly
straightforward - it is rational to deploy new hashpower as soon as you can
get it online.  Introducing the concepts of (a) requiring out-of-band
collusion to change block size and/or (b) requiring miners to have idle
hashpower on hand to change block size are both unrealistic and potentially
corrosive.  That potentially makes the block size - and therefore fee
market - too close, too sensitive to the wild vagaries of the mining chip
market.

Pay-to-future-miner has neutral, forward looking incentives worth
researching.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Luke,

- Definitely agree with most of your suggestions on the practical side;
several clarification could be made.
- The power to decrease the hard limit appears riskier long term in my
analysis.  This is mitigated somewhat by the ease at which miners may
locally or collectively lower the block size at any time, without a vote.


On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr  wrote:

> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It seems clear from the
> current information available that 1 MB is presently too high for the
> limit,
> and it is entirely one-sided to only allow increases when decreases are
> much
> more likely to be needed in the short term.
>
> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
> numeric value pushed after height? Since this is a hardfork, I suggest
> increasing the coinbase length to allow for 100 bytes *in addition* to the
> pushed height and size-vote.
>
> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
> MB
> (or whatever value is deemed appropriate) to make it clear that the limit
> remains a part of the consensus protocol and p2p protocol limits are not to
> have an effect on consensus rules.
>
> Furthermore, I suggest modifying the voting to require 50% to set the limit
> floor. This has the effect of merely coordinating what miners can already
> effectively do today by rejecting blocks larger than some collusion-
> determined limit.
>
> Thoughts?
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP 100 specification

[Jeff Garzik via bitcoin-dev]

BIP 100 initial public draft:
https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki

Emphasis on "initial"  This is a starting point for the usual open source
feedback/iteration cycle, not an endpoint that Must Be This Way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[Luke Dashjr via bitcoin-dev]

On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev 
wrote:
> The repo: https://github.com/jgarzik/bip100

What is the purpose of the newly added 1 MB floor? It seems clear from the 
current information available that 1 MB is presently too high for the limit, 
and it is entirely one-sided to only allow increases when decreases are much 
more likely to be needed in the short term.

Must the new size limit votes use 11 bytes of coinbase? Why not just use a 
numeric value pushed after height? Since this is a hardfork, I suggest 
increasing the coinbase length to allow for 100 bytes *in addition* to the 
pushed height and size-vote.

I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 MB 
(or whatever value is deemed appropriate) to make it clear that the limit 
remains a part of the consensus protocol and p2p protocol limits are not to 
have an effect on consensus rules.

Furthermore, I suggest modifying the voting to require 50% to set the limit 
floor. This has the effect of merely coordinating what miners can already 
effectively do today by rejecting blocks larger than some collusion-
determined limit.

Thoughts?

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

Re: [bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Oops, link paste fail.

The repo: https://github.com/jgarzik/bip100


On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik  wrote:

> Opened a repo containing the full text of BIP 100 discussion document, in
> markdown format.
>
> The BIP 100 formal spec will be checked in here as well, before submitting
> to upstream bips.git repo.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Opened a repo containing the full text of BIP 100 discussion document, in
markdown format.

The BIP 100 formal spec will be checked in here as well, before submitting
to upstream bips.git repo.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Milly Bitcoin via bitcoin-dev]

We don't want to play at being
lawyer, but our review does point towards this being something worth
coming back to.

In terms of citation, we did reference a case called /Feist/.


I don't see how you can possibly conclude this effort is worth any 
additional time.  The legal reference is:  Feist Publications, Inc., v. 
Rural Telephone Service Co., 499 U.S. 340 (1991).  The court ruled that 
Rural's directory was nothing more than an alphabetic list of all 
subscribers to its service, which it was required to compile under law, 
and that no creative expression was involved. The fact that Rural spent 
considerable time and money collecting the data was irrelevant to 
copyright law, and Rural's copyright claim was dismissed.


If some entity puts a copyright notice, demands a license, signs 
software with a certificate, claims developers or miners are some legal 
entity, etc. then those entities are setting themselves up to be sued or 
prosecuted (whether legitimately or not).  There is no benefit to 
claiming such ownership or authority or issuing any license because 
nobody is going to enforce anything and they don't even have that 
authority anyway.  A 5-minute talk with an IP lawyer should confirm that 
... but you sound like you are not going to do that.  Bitcoin certainly 
attracts quite a number of completely irrational people.


Russ



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

Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

[Zach G via bitcoin-dev]

When you assume you make an ass out of you and me. That page doesn't even exist 
in my router, I don't have 2wire. The router I have is the one everyone is 
getting from uverse.

Literally everything you said is incorrect. It is completely on topic as it 
pertains to Bitcoin Core functionality, 42 connections is nothing, and that's 
not how you fix it. If you're gonna call me out for being wrong at least be 
correct! I spent a lot of time fixing this and the info is useful cause this 
problem happens to a lot of people, so why obfuscate it with this nonsense. 

AT&T u-verse as it is now is near impossible for bitcoin nodes, 42 in the world 
is absolutely pathetic considering they are among the top 2 ISPs in the USA. 
Thanks for proving my point.

 

 

-Original Message-
From: Matt Whitlock 
To: hurricanewarn1 
Cc: bitcoin-dev 
Sent: Wed, Sep 2, 2015 3:21 pm
Subject: Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via 
utilizing private subnets.


I've been trying to keep our discussion off-list because it is off-topic, but
you keep adding the list back on in your
replies.

http://steamforge.net/wiki/images/2/29/Settings-Firewall-Advanced.png

Settings
> Firewall > Advanced Configuration > Outbound Protocol Control > All Other
Protocols

That's all you had to do.


On Wednesday, 2 September 2015, at
9:44 am, Zach G via bitcoin-dev wrote:
> 42 in the whole world, and I'm one of
them. Clearly that is a problem, do you even know about AT&T or are you in
another country? Cause that statement is utterly ridiculous given the fact there
are hundreds of millions of people using AT&T. I was simply sharing my knowledge
on this issue since it poses a threat to the health of the bitcoin network, no
need for personal attacks. 
> 
> None of my accusations were false, there is a
firewall in the DVR that is uncontrolled and all ports are blocked via private
subnets and no fixed public IP allowed unless you pay. I confirmed every one of
these details with AT&T technicians or I wouldn't be saying them.
> 
>  
>

>  
> 
>  
> 
> -Original Message-
> From: Matt Whitlock

> To: hurricanewarn1 
> Sent:
Wed, Sep 2, 2015 5:34 am
> Subject: Re: [bitcoin-dev] AT&T has effectively
banned Bitcoin nodes via utilizing private subnets.
> 
> 
> According to
BitNodes, 42 Bitcoin nodes are running on AT&T's
> network:
> 
>
https://getaddr.bitnodes.io/nodes/?q=AT%26T
> 
> So I'm thinking
> there's
nothing wrong with AT&T's default network configuration.
> 
> Frankly, the
>
things you've been writing strongly suggest that you aren't very
knowledgeable
> about computer networking. Instead of jumping right into making
wild accusations
> about AT&T, you probably should find someone knowledgeable
to verify your
> claims.
> 
> 
> On Wednesday, 2 September 2015, at 5:20 am,
Zach G via bitcoin-dev
> wrote:
> > First off I couldn't synch the wallet, it
said no block source
> available and there was zero connections. Bitcoin was
literally getting thottled
> every second. It would not even allow the
connection to get block source. EVERY
> port was blocked, making exceptions in
the router firewall did nothing. I was
> forced to use Blockchain.info which is
a major security risk.
> > 
> > Secondly, I
> am developing a program using
Bitcoin Python modules, so I login to my computer
> like it's a server and it
was flat out rejecting the connection. I could not run
> any code until this
got fixed, and of course needed the block source to even do
> anything. 
> >

> > If Bitcoin Core worked but 8333 was blocked I would not be
> emailing the
list. Bitcoin Core was crippled and unusable due to the AT&T
> settings, and
they tried hard to get me to buy monthly subscriptions to get the
> answer.
This makes it likely that Bitcoin Core is unusable for most AT&T
> customers
and other ISPs, hence the massive node decline. I'm sure this disrupts
> alot
of other people besides Bitcoiners too, hence the monthly subscriptions
>
geared towards people who can't figure out their connection situation.
> > 
>
>
> AT&T literally blocked access to static IP if you don't buy one, so it
wasn't a
> normal network setup. Unfortunately the same security used to stop
hackers and
> viruses stops Bitcoin too, so this is probably the settings for
almost every
> router in the country. Nodes are in fact declining worldwide,
down 15% in the
> past year alone. Community needs to speak up and also educate
before this gets
> completely out of control.
https://getaddr.bitnodes.io/dashboard/?days=365 6,000
> nodes is pathetic as it
is and it's constantly declining.

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

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

[Ahmed Zsales via bitcoin-dev]

Thanks Warren, very good feedback.

To avoid taking up too much of everyone's time at this point, I
think Wladimir's suggestion of placing this in a BIP advisory box for a
while is a good one. We did indicate that this might take a while to
gestate.

It is probably for us to do some further investigations and possibly engage
some input from a few miners.  We don't want to play at being lawyer, but
our review does point towards this being something worth coming back to.

In terms of citation, we did reference a case called *Feist*. We also found
some general database protection details which are relevant to the USA, if
you need any bed time reading:

http://copyright.gov/reports/dbase.html

For now, thanks to everyone for feedback and comments.

Regards,

Ahmed

On Wed, Sep 2, 2015 at 9:56 AM, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I am skeptical that any license for the blockchain itself is needed
> because of the possibility that the blockchain is not entitled to copyright
> protection.  While I am not a lawyer, I have stared hard at the copyright
> doctrine of the U.S. in multiple law school Intellectual Property courses
> and during my previous career in Open Source Software where copyright
> matters a great deal.
>
> As each owner of a
>> coin makes a transfer by digitally signing a hash of the previous
>> transaction along with the
>> new owner’s public key, the block chain is a perpetual compilation of
>> unique data.
>> *It is therefore compiled in a creative and non-obvious way.* In the
>> USA, for example, these
>> attributes confer legal protections for databases which have been ruled
>> upon by the courts.
>
>
> This portion of your paper I believe is not true and requires citations if
> you want to be convincing.  Is it truly "creative and non-obvious"?  My
> understanding under at least U.S. law, the blockchain may not be entitled
> to copyright protection because a compilation created in a mechanical
> manner is not a creative work of a human.
>
> I suppose a transaction could contain a "creative" element if it contains
> arbitrary bytes of a message or clever script.  For the most part though
> most of what you call "digitally signing a hash of the previous transaction
> along with the new owner’s public key" is purely the result of a mechanical
> process and really is not creative.  Furthermore, even if that output were
> "non-obvious", obviousness has nothing to do with copyrightability.
>
> Your license is correct in intent in attempting to exclude from the
> royalty free grant works within the blockchain that themselves may be
> subject to copyright of third parties.  The elements within the blockchain
> may be entitled individually to copyright if they are in any way a creative
> work of a human, but as a compilation I am doubtful the blockchain itself
> is entitled to copyright.
>
> I understand copyright with respect to databases can be different under
> other jurisdictions.  Your paper mentions the European database law that is
> indeed different from the U.S.  Your paper is incomplete in scholarly and
> legal citations.  I myself and we as a community don't know enough.  I
> suppose this topic merits further study.
>
> Warren Togami
>
> On Tue, Sep 1, 2015 at 6:30 AM, Ahmed Zsales via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> We believe the network requires a block chain licence to supplement the
>> existing MIT Licence which we believe only covers the core reference client
>> software.
>>
>> Replacing or amending the existing MIT Licence is beyond the scope of
>> this draft BIP.
>>
>> Rationale and details of our draft BIP for discussion and evaluation are
>> here:
>>
>>
>> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>>
>> Regards,
>>
>> Ahmed
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

[Matt Whitlock via bitcoin-dev]

I've been trying to keep our discussion off-list because it is off-topic, but 
you keep adding the list back on in your replies.

http://steamforge.net/wiki/images/2/29/Settings-Firewall-Advanced.png

Settings > Firewall > Advanced Configuration > Outbound Protocol Control > All 
Other Protocols

That's all you had to do.


On Wednesday, 2 September 2015, at 9:44 am, Zach G via bitcoin-dev wrote:
> 42 in the whole world, and I'm one of them. Clearly that is a problem, do you 
> even know about AT&T or are you in another country? Cause that statement is 
> utterly ridiculous given the fact there are hundreds of millions of people 
> using AT&T. I was simply sharing my knowledge on this issue since it poses a 
> threat to the health of the bitcoin network, no need for personal attacks. 
> 
> None of my accusations were false, there is a firewall in the DVR that is 
> uncontrolled and all ports are blocked via private subnets and no fixed 
> public IP allowed unless you pay. I confirmed every one of these details with 
> AT&T technicians or I wouldn't be saying them.
> 
>  
> 
>  
> 
>  
> 
> -Original Message-
> From: Matt Whitlock 
> To: hurricanewarn1 
> Sent: Wed, Sep 2, 2015 5:34 am
> Subject: Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via 
> utilizing private subnets.
> 
> 
> According to BitNodes, 42 Bitcoin nodes are running on AT&T's
> network:
> 
> https://getaddr.bitnodes.io/nodes/?q=AT%26T
> 
> So I'm thinking
> there's nothing wrong with AT&T's default network configuration.
> 
> Frankly, the
> things you've been writing strongly suggest that you aren't very knowledgeable
> about computer networking. Instead of jumping right into making wild 
> accusations
> about AT&T, you probably should find someone knowledgeable to verify your
> claims.
> 
> 
> On Wednesday, 2 September 2015, at 5:20 am, Zach G via bitcoin-dev
> wrote:
> > First off I couldn't synch the wallet, it said no block source
> available and there was zero connections. Bitcoin was literally getting 
> thottled
> every second. It would not even allow the connection to get block source. 
> EVERY
> port was blocked, making exceptions in the router firewall did nothing. I was
> forced to use Blockchain.info which is a major security risk.
> > 
> > Secondly, I
> am developing a program using Bitcoin Python modules, so I login to my 
> computer
> like it's a server and it was flat out rejecting the connection. I could not 
> run
> any code until this got fixed, and of course needed the block source to even 
> do
> anything. 
> > 
> > If Bitcoin Core worked but 8333 was blocked I would not be
> emailing the list. Bitcoin Core was crippled and unusable due to the AT&T
> settings, and they tried hard to get me to buy monthly subscriptions to get 
> the
> answer. This makes it likely that Bitcoin Core is unusable for most AT&T
> customers and other ISPs, hence the massive node decline. I'm sure this 
> disrupts
> alot of other people besides Bitcoiners too, hence the monthly subscriptions
> geared towards people who can't figure out their connection situation.
> > 
> >
> AT&T literally blocked access to static IP if you don't buy one, so it wasn't 
> a
> normal network setup. Unfortunately the same security used to stop hackers and
> viruses stops Bitcoin too, so this is probably the settings for almost every
> router in the country. Nodes are in fact declining worldwide, down 15% in the
> past year alone. Community needs to speak up and also educate before this gets
> completely out of control. https://getaddr.bitnodes.io/dashboard/?days=365 
> 6,000
> nodes is pathetic as it is and it's constantly declining.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Your Gmaxwell exchange

[Justus Ranvier via bitcoin-dev]

On 09/01/2015 03:29 PM, Wladimir J. van der Laan wrote:
> On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev 
> wrote:
> 
>> * They should own their bitcoins, meaning that they retain exclusive
>> control over their balances. Even more precisely, the network must
>> always honour the conditions of the scripts associated with unspent outputs.
>>
>> * Their fraction of the Bitcoin ledger must not be diluted.
>>
>> * When they decide to spend their coins, they will be able to do so
>> without requiring permission from a third party.
> 
> All of these properties are contingent on the system being decentralized.

That is not true, unless you are using a definition of the word
"decentralized" which is so broad as to convey no information whatsoever.

Saying that Bitcoin's security depends on decentralization is like
saying that a bridge's structural integrity depends on good materials.

Statements like that convey zero relevant information. Potential users
of a bridge want to know about the maximum working load of the bridge,
and under which conditions it is safe to use. At what wind speed should
the bridge be closed? Is it ok to keep using it after a magnitude 4
earthquake, or should it be closed for inspection?

Repeatedly asserting that bridges need to be made of good materials as
an alternative to answering those kinds of questions would be easily
recognized as useless in that context, but for some reason people seem
to accept it in this one.


-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
jus...@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623


0xEAD9E623.asc
Description: application/pgp-keys


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

Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

[Zach G via bitcoin-dev]

42 in the whole world, and I'm one of them. Clearly that is a problem, do you 
even know about AT&T or are you in another country? Cause that statement is 
utterly ridiculous given the fact there are hundreds of millions of people 
using AT&T. I was simply sharing my knowledge on this issue since it poses a 
threat to the health of the bitcoin network, no need for personal attacks. 

None of my accusations were false, there is a firewall in the DVR that is 
uncontrolled and all ports are blocked via private subnets and no fixed public 
IP allowed unless you pay. I confirmed every one of these details with AT&T 
technicians or I wouldn't be saying them.

 

 

 

-Original Message-
From: Matt Whitlock 
To: hurricanewarn1 
Sent: Wed, Sep 2, 2015 5:34 am
Subject: Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via 
utilizing private subnets.


According to BitNodes, 42 Bitcoin nodes are running on AT&T's
network:

https://getaddr.bitnodes.io/nodes/?q=AT%26T

So I'm thinking
there's nothing wrong with AT&T's default network configuration.

Frankly, the
things you've been writing strongly suggest that you aren't very knowledgeable
about computer networking. Instead of jumping right into making wild accusations
about AT&T, you probably should find someone knowledgeable to verify your
claims.


On Wednesday, 2 September 2015, at 5:20 am, Zach G via bitcoin-dev
wrote:
> First off I couldn't synch the wallet, it said no block source
available and there was zero connections. Bitcoin was literally getting thottled
every second. It would not even allow the connection to get block source. EVERY
port was blocked, making exceptions in the router firewall did nothing. I was
forced to use Blockchain.info which is a major security risk.
> 
> Secondly, I
am developing a program using Bitcoin Python modules, so I login to my computer
like it's a server and it was flat out rejecting the connection. I could not run
any code until this got fixed, and of course needed the block source to even do
anything. 
> 
> If Bitcoin Core worked but 8333 was blocked I would not be
emailing the list. Bitcoin Core was crippled and unusable due to the AT&T
settings, and they tried hard to get me to buy monthly subscriptions to get the
answer. This makes it likely that Bitcoin Core is unusable for most AT&T
customers and other ISPs, hence the massive node decline. I'm sure this disrupts
alot of other people besides Bitcoiners too, hence the monthly subscriptions
geared towards people who can't figure out their connection situation.
> 
>
AT&T literally blocked access to static IP if you don't buy one, so it wasn't a
normal network setup. Unfortunately the same security used to stop hackers and
viruses stops Bitcoin too, so this is probably the settings for almost every
router in the country. Nodes are in fact declining worldwide, down 15% in the
past year alone. Community needs to speak up and also educate before this gets
completely out of control. https://getaddr.bitnodes.io/dashboard/?days=365 6,000
nodes is pathetic as it is and it's constantly declining.
>  
> 
>  
> 
>
-Original Message-
> From: Matt Whitlock 
> To:
hurricanewarn1 
> Sent: Wed, Sep 2, 2015 4:32 am
>
Subject: Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via
utilizing private subnets.
> 
> 
> Respectfully, what the heck are you
talking about? Practically every home LAN
> runs on a private subnet. My own
desktop computer has the IP address
> 192.168.1.34, which is in a private
subnet. This doesn't prevent my Bitcoin Core
> node from making outbound
connections to other nodes. Moreover, almost all home
> Internet connections in
the world run on dynamically assigned IP addresses.
> Again, this does not
cause any problems for connecting outbound to other Bitcoin
> nodes. It's true
that your node can't accept incoming connections unless you
> forward port 8333
on your router to your computer, but you don't need to be able
> to accept
incoming connections to participate in the Bitcoin network.
> 
> 
> On
>
Wednesday, 2 September 2015, at 3:20 am, Zach G via bitcoin-dev wrote:
> > 
>
>  I
> was about to buy a VPS for Bitcoin, but I really do need Bitcoin Core
for
> business reasons so I didn't give up. I once again thoroughly went
through my
> computer and made sure there was nothing blocking 8333, a couple
useful tools
> are CurrPorts and TCPView. I went through the router to make
sure there was no
> block of port 8333. I researched everything thoroughly and
was sure these were
> the right settings, but Bitcoin was still getting
throttled every second and
> stuck in sys_sent, and python kept saying the
target was rejecting the
> connection.
> > 
> > I finally stumbled upon
subnet settings, and saw that I had a
> private subnet, one of the few IPs that
are private on earth (
> https://www.arin.net/knowledge/address_filters.html ).
Uverse put all their
> customers on a private subnet by default. This made my
computer not only hidden
> but un

Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

[Zach G via bitcoin-dev]

First off I couldn't synch the wallet, it said no block source available and 
there was zero connections. Bitcoin was literally getting thottled every 
second. It would not even allow the connection to get block source. EVERY port 
was blocked, making exceptions in the router firewall did nothing. I was forced 
to use Blockchain.info which is a major security risk.

Secondly, I am developing a program using Bitcoin Python modules, so I login to 
my computer like it's a server and it was flat out rejecting the connection. I 
could not run any code until this got fixed, and of course needed the block 
source to even do anything. 

If Bitcoin Core worked but 8333 was blocked I would not be emailing the list. 
Bitcoin Core was crippled and unusable due to the AT&T settings, and they tried 
hard to get me to buy monthly subscriptions to get the answer. This makes it 
likely that Bitcoin Core is unusable for most AT&T customers and other ISPs, 
hence the massive node decline. I'm sure this disrupts alot of other people 
besides Bitcoiners too, hence the monthly subscriptions geared towards people 
who can't figure out their connection situation.

AT&T literally blocked access to static IP if you don't buy one, so it wasn't a 
normal network setup. Unfortunately the same security used to stop hackers and 
viruses stops Bitcoin too, so this is probably the settings for almost every 
router in the country. Nodes are in fact declining worldwide, down 15% in the 
past year alone. Community needs to speak up and also educate before this gets 
completely out of control. https://getaddr.bitnodes.io/dashboard/?days=365 
6,000 nodes is pathetic as it is and it's constantly declining.
 

 

-Original Message-
From: Matt Whitlock 
To: hurricanewarn1 
Sent: Wed, Sep 2, 2015 4:32 am
Subject: Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via 
utilizing private subnets.


Respectfully, what the heck are you talking about? Practically every home LAN
runs on a private subnet. My own desktop computer has the IP address
192.168.1.34, which is in a private subnet. This doesn't prevent my Bitcoin Core
node from making outbound connections to other nodes. Moreover, almost all home
Internet connections in the world run on dynamically assigned IP addresses.
Again, this does not cause any problems for connecting outbound to other Bitcoin
nodes. It's true that your node can't accept incoming connections unless you
forward port 8333 on your router to your computer, but you don't need to be able
to accept incoming connections to participate in the Bitcoin network.


On
Wednesday, 2 September 2015, at 3:20 am, Zach G via bitcoin-dev wrote:
> 
>  I
was about to buy a VPS for Bitcoin, but I really do need Bitcoin Core for
business reasons so I didn't give up. I once again thoroughly went through my
computer and made sure there was nothing blocking 8333, a couple useful tools
are CurrPorts and TCPView. I went through the router to make sure there was no
block of port 8333. I researched everything thoroughly and was sure these were
the right settings, but Bitcoin was still getting throttled every second and
stuck in sys_sent, and python kept saying the target was rejecting the
connection.
> 
> I finally stumbled upon subnet settings, and saw that I had a
private subnet, one of the few IPs that are private on earth (
https://www.arin.net/knowledge/address_filters.html ). Uverse put all their
customers on a private subnet by default. This made my computer not only hidden
but unroutable for any computer on the Bitcoin network. That alone is enough to
totally stop Bitcoin connections on any port, but they made it even crazier by
generating a dynamic IP that changes all the time, so public IP was meaningless
for my computer. 
> 
> I switched over to a public subnet, and right there was
a checkbox to allow incoming connections. My static IP showed for a minute then
became dynamic/hidden again without me even touching anything. The final
roadblock was AT&T charges $15-30/month for a public static IP, which is
obviously insane and actually one could argue that violates their own terms of
service. So the router was still ignoring my public IP settings simply because I
wasn't paying for a public IP, and intentionally changing the settings back. I
asked for a free public IP and there was no response for awhile.
> 
> I found
this article on cryptocoinnews while working out:
https://www.cryptocoinsnews.com/isps-intentionally-blocking-bitcoin/ It's based
on the first email I sent, and was displayed prominently on their front page. I
posted a tweet publicly about it which referenced AT&T (
https://twitter.com/turtlehurricane/status/638930065980551168 ) and believe it
or not I had a static public IP and port 8333 was open about 1 minute later. I
don't know if it was a coincidence cause I already messaged them to please do
that an hour before, or if that article and tweet spurred them to action. The
timing was so ridiculous I think it's the

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

[Warren Togami Jr. via bitcoin-dev]

I am skeptical that any license for the blockchain itself is needed because
of the possibility that the blockchain is not entitled to copyright
protection.  While I am not a lawyer, I have stared hard at the copyright
doctrine of the U.S. in multiple law school Intellectual Property courses
and during my previous career in Open Source Software where copyright
matters a great deal.

As each owner of a
> coin makes a transfer by digitally signing a hash of the previous
> transaction along with the
> new owner’s public key, the block chain is a perpetual compilation of
> unique data.
> *It is therefore compiled in a creative and non-obvious way.* In the USA,
> for example, these
> attributes confer legal protections for databases which have been ruled
> upon by the courts.


This portion of your paper I believe is not true and requires citations if
you want to be convincing.  Is it truly "creative and non-obvious"?  My
understanding under at least U.S. law, the blockchain may not be entitled
to copyright protection because a compilation created in a mechanical
manner is not a creative work of a human.

I suppose a transaction could contain a "creative" element if it contains
arbitrary bytes of a message or clever script.  For the most part though
most of what you call "digitally signing a hash of the previous transaction
along with the new owner’s public key" is purely the result of a mechanical
process and really is not creative.  Furthermore, even if that output were
"non-obvious", obviousness has nothing to do with copyrightability.

Your license is correct in intent in attempting to exclude from the royalty
free grant works within the blockchain that themselves may be subject to
copyright of third parties.  The elements within the blockchain may be
entitled individually to copyright if they are in any way a creative work
of a human, but as a compilation I am doubtful the blockchain itself is
entitled to copyright.

I understand copyright with respect to databases can be different under
other jurisdictions.  Your paper mentions the European database law that is
indeed different from the U.S.  Your paper is incomplete in scholarly and
legal citations.  I myself and we as a community don't know enough.  I
suppose this topic merits further study.

Warren Togami

On Tue, Sep 1, 2015 at 6:30 AM, Ahmed Zsales via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello,
>
> We believe the network requires a block chain licence to supplement the
> existing MIT Licence which we believe only covers the core reference client
> software.
>
> Replacing or amending the existing MIT Licence is beyond the scope of this
> draft BIP.
>
> Rationale and details of our draft BIP for discussion and evaluation are
> here:
>
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

[Zach G via bitcoin-dev]

 I was about to buy a VPS for Bitcoin, but I really do need Bitcoin Core for 
business reasons so I didn't give up. I once again thoroughly went through my 
computer and made sure there was nothing blocking 8333, a couple useful tools 
are CurrPorts and TCPView. I went through the router to make sure there was no 
block of port 8333. I researched everything thoroughly and was sure these were 
the right settings, but Bitcoin was still getting throttled every second and 
stuck in sys_sent, and python kept saying the target was rejecting the 
connection.

I finally stumbled upon subnet settings, and saw that I had a private subnet, 
one of the few IPs that are private on earth ( 
https://www.arin.net/knowledge/address_filters.html ). Uverse put all their 
customers on a private subnet by default. This made my computer not only hidden 
but unroutable for any computer on the Bitcoin network. That alone is enough to 
totally stop Bitcoin connections on any port, but they made it even crazier by 
generating a dynamic IP that changes all the time, so public IP was meaningless 
for my computer. 

I switched over to a public subnet, and right there was a checkbox to allow 
incoming connections. My static IP showed for a minute then became 
dynamic/hidden again without me even touching anything. The final roadblock was 
AT&T charges $15-30/month for a public static IP, which is obviously insane and 
actually one could argue that violates their own terms of service. So the 
router was still ignoring my public IP settings simply because I wasn't paying 
for a public IP, and intentionally changing the settings back. I asked for a 
free public IP and there was no response for awhile.

I found this article on cryptocoinnews while working out: 
https://www.cryptocoinsnews.com/isps-intentionally-blocking-bitcoin/ It's based 
on the first email I sent, and was displayed prominently on their front page. I 
posted a tweet publicly about it which referenced AT&T ( 
https://twitter.com/turtlehurricane/status/638930065980551168 ) and believe it 
or not I had a static public IP and port 8333 was open about 1 minute later. I 
don't know if it was a coincidence cause I already messaged them to please do 
that an hour before, or if that article and tweet spurred them to action. The 
timing was so ridiculous I think it's the latter. Without twitter I probably 
wouldn't have succeeded, the technicians on twitter actually answered all my 
questions 24/7 unlike phone technicians which were clueless and trying to sell 
me a subscription for connection services help. And shout out to cryptocoinnews 
for making this public. 

So to clarify, it appears AT&T has not blocked port 8333 itself, but rather 
effectively blocked all ports via the private subnet, which makes the computer 
hidden and unroutable for incoming peers. Although this severely limits 
functionality and cripples the ability to run a full node and many other 
programs it is understandable, since it just about 100% prevents hackers from 
getting in, since they can't even see your computer. What isn't understandable 
is that AT&T technicians did not inform me about this until I changed the 
settings myself, despite the fact it is a very obvious cause of ports being 
blocked. It's probably just ignorance since AT&T has so many complex network 
settings it's hard to keep track of, although I have a suspicion that someone 
in their command chain is withholding information in an attempt to make them 
buy a $15/month connection service, and once they buy that another $15-30/month 
is needed to get the static IP.

As far as I know there is no easy to find info on the internet about private 
subnets crippling the ability to use Bitcoin. I believe this needs to be 
explicitly said in instructions for running a full node, maybe it wasn't a 
problem in 2009 but now it is a major issue. On default settings Bitcoin is 
100% blocked, and most people do not have the time or motivation to fix this. I 
talked to at least 10 AT&T technicians and worked on it 2-3 days straight, did 
not receive the right answer until I found it myself, although they certainly 
gave me some useful clues about how the network works.

I am very happy that AT&T fixed it, since other ISPs like Comcast appeared even 
worse. I openly talked with them about Bitcoin and they showed no prejudice, 
might've actually made them more willing to help me cause otherwise they would 
think I'm a hacker.

tl;dr The good news is anyone with AT&T can be a full node by getting a public 
static IP, the bad news is almost no one will figure this out unless we as a 
community make it well known. I guarantee node numbers will improve if this 
information is spread to everyone. Database size and computing expenditures is 
simply not the reason people don't run full nodes, it's because their ISP has 
made it just about impossible without shelling out nearly 100% more money per 
month. If you don't pay the fee AT&T would never tell you abo