Proposal to add the bitcoin symbol to Unicode

Use of the bitcoin symbol in text is inconvenient, because the bitcoin symbol isn't in the Unicode standard. To fix this, I've written a proposal to have the common B-with-vertical-bars bitcoin symbol added to Unicode. I've successfully proposed a new character for Unicode before, so I'm familiar with the process and think this has a good chance of succeeding. The proposal is at http://righto.com/bitcoin-unicode.pdf

I received a suggestion to run this proposal by the bitcoin-dev group, so I hope this email is appropriate here. Endorsement by Bitcoin developers will help the Unicode Committee realize the importance of adding this symbol, so please let me know if you support this proposal. 

Thanks,
Ken


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Andy Chase via bitcoin-dev | 4 Sep 02:30 2015

[BIP/Draft] BIP Acceptance Process

Here’s a BIP. I wrote the BIP mostly to stir the pot on ideas of governance, but I’m moderately serious about it. This is set in Markdown for readability, but here’s the BIP-0001 Medawiki version: https://gist.github.com/andychase/dddb83c294295879308b


  Title: BIP Acceptance Process
  Author: Andy Chase
  Status: Draft
  Type: Process
  Created: 2015-08-31

Abstract
========

The current process for accepting a BIP is not clearly defined. While
BIP-0001 defines the process for writing and submitting a Bitcoin
improvement proposal to the community it does not specify the precise
method for which BIPs are considered accepted or rejected.

This proposal sets up a method for determining BIP acceptance.

This BIP has two parts:

-   It sets up a process which a BIP goes through for comments
  and acceptance.
  -   The Process is:
      -   BIP Draft
      -   Submitted for comments (2 weeks)
      -   Waiting on opinion (two weeks)
      -   Accepted or Deferred
-   It sets up committees for reviewing comments and indicating
  acceptance under precise conditions.
  -   Committees are authorized groups that represent client authors,
      miners, merchants, and users (each as a segment). Each one must
      represent at least 1% stake in the Bitcoin ecosystem.

BIP acceptance is defined as at least 70% of the represented percentage
stake in 3 out of the 4 Bitcoin segments.

Copyright
=========

This document is placed into the public domain.

Motivation
==========

BIPs represent important improvements to Bitcoin infrastructure, and in
order to foster continued innovation, the BIP process must have clearly
defined stages and acceptance acknowledgement.

Rationale
=========

A committee system is used to organize the essential concerns of each
segment of the Bitcoin ecosystem. Although each segment may have many
different viewpoints on each BIP, in order to seek a decisive yes/no on
a BIP, a representational authoritative structure is sought. This
structure should be fluid, allowing people to move away from committees
that do not reflect their views and should be re-validated on each BIP
evaluation.

Weaknesses
==========

Each committee submits a declaration including their claim to represent
a certain percentage of the Bitcoin ecosystem in some way. Though
guidelines are given, it's up to each committee to prove their stake,
and it's up to the reader of the opinions to decide if a BIP was truly
accepted or rejected.

The author doesn't believe this is a problem because a BIP cannot be
forced on client authors, miners, merchants, or users. Ultimately this
BIP is a tool for determining whether a BIP is overwhelmingly accepted.
If one committee's validity claim becomes the factor that decides
whether the BIP will succeed or fail, this process simply didn't return
a clear answer and the BIP should be considered deferred.

Process
=======

-   **Submit for Comments.** The first BIP champion named in the
  proposal can call a "submit for comments" at any time by posting to
  the [Dev Mailing
  List](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)
  mailling with the BIP number and a statement that the champion
  intends to immediately submit the BIP for comments.
  -   The BIP must have been assigned BIP-number (i.e. been approved
      by the BIP editor) to be submitted for comments.
-   **Comments.**
  -   After a BIP has been submitted for comments, a two-week waiting
      period begins in which the community should transition from
      making suggestions about a proposal to publishing their opinions
      or concerns on the proposal.
-   **Reported Opinions.**
  -   After the waiting period has past, committees must submit a
      summary of the comments which they have received from their
      represented communities.
  -   The deadline for this opinion is four weeks after the BIP was
      submitted for comments.
  -   Committees cannot reverse their decision after the deadline, but
      at their request may flag their decision as "likely to change if
      another submit for comments is called". Committees can change
      their decision if a resubmit is called.
  -   Opinions must include:
      -   One of the following statements: "Intend to accept", "Intent
          to implement", "Decline to accept", "Intend to accept, but
          decline to implement".
      -   If rejected, the opinion must cite clear and specific
          reasons for rejecting including a checklist for what must
          happen or be change for their committee to accept
          the proposal.
      -   If accepted, the committee must list why they accepted the
          proposal and also include concerns they have or what about
          the BIP that, if things changed, would cause the committee
          to likely reverse their decision if another submit for
          comments was called.
-   **Accepted.**
  -   If at least 70% of the represented percentage stake in 3 out of
      4 segments accept a proposal, a BIP is considered accepted.
      -   If a committee fails to submit an opinion, consider the
          opinion "Decline to accept".
  -   The BIP cannot be substantially changed at this point, but can
      be replaced. Minor changes or clarifications are allowed but
      must be recorded in the document.
-   **Deferred.**
  -   The acceptance test above is not met, a BIP is sent back
      into suggestions.
  -   BIP can be modified and re-submitted for a comments no sooner
      than two months after the date of the previous submit for
      comments is called.
  -   A BIP is marked rejected after two failed submission attempts. A
      rejected BIP can still be modified and re-submitted.

Committees
==========

**BIP Committees.**

-   BIP Committees are representational structures that represent
  critical segments of the Bitcoin ecosystem.
-   Each committee must prove and maintain a clear claim that they
  represent at least 1% of the Bitcoin ecosystem in some form.
  -   If an organization or community does not meet that requirement,
      it should conglomerate itself with other communities and
      organizations so that it does.
-   The segments that committees can be based around are:
  -   Bitcoin software
  -   Merchants/services/payment processors
  -   Mining operators
  -   User communities
-   A person may be represented by any number of segments, but a
  committee cannot re-use the same resource as another committee in
  the same segment.

-   **Committee Declarations.** At any point, a Committee Declaration
  can be posted.
-   This Declaration contain details about:
  -   The segment the Committee is representing
  -   Who the committee claim to represent and it's compositional
      makeup (if made up of multiple miner orgs, user orgs, companies,
      clients, etc).
  -   Proof of claim and minimum 1% stake via:
      -   Software: proof of ownership and user base (Min 1% of
          Bitcoin userbase)
      -   Merchant: proof of economic activity (Min 1% of Bitcoin
          economic activity)
      -   Mining: proof of work (Min 1% of Hashpower)
      -   For a user organization, auditable signatures qualifies for
          a valid committee (Min 1% of Bitcoin userbase)
  -   Who is running the committee, their names and roles
  -   How represented members can submit comments to the committee
  -   A code of conduct and code of ethics which the committee
      promises to abide by
-   A committee declaration is accepted if:
  -   The declaration includes all of the required elements
  -   The stake is considered valid
-   Committee validation is considered when considering the results of
  opinions submitted by committee on a BIP. A committee must have met
  the required stake percentage before a BIP is submitted for
  comments, and have maintained that stake until a valid opinion
  is submitted.
  -   Committees can dissolve at any time or submit a declaration at
      any time
  -   Declaration must have been submitted no later than the third day
      following a BIP's request for comments to be eligible for
      inclusion in a BIP

BIP Process Management Role
===========================

BIPs, Opinions, and Committee Declaration must be public at all times.

A BIP Process Manager should be chosen who is in charge of:

-   Declaring where and how BIPs, Opinions, and Committee Declaration
  should be posted and updated officially.
-   Maintaining the security and authenticity of BIPs, Opinions, and
  Committee Declarations
-   Publishing advisory documents about what kinds of proof of stakes
  are valid and what kinds should be rejected.
-   Naming a series of successors for the roles of the BIP Process
  Manager and BIP Editor (BIP-001) as needed.

Conditions for activation
=========================

In order for this process BIP to become active, it must succeed by its
own rules. At least a 4% sample of the Bitcoin community must be
represented, with at least one committee in each segment included. Once
at least one committee has submitted a declaration, a request for
comments will be called and the process should be completed from there.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Alpha release of METAmarket available for download NOW for Windows and Linux. Come help us test a new standard in P2P e-commerce!

I'm pleased to announce the newest contender in the field of decentralized
e-commerce. 100% P2P and 100% customize-able. Using METAmarket, you can
create your own market where you make the rules. Open to all or Private?
Wholesale or retail? Moderated or unmoderated? Clearnet or Darknet? You
are in complete control of your local market. There are always people
looking for cheap and easy ways to trade and METAmarket uses a zero-fee
approach. All funds are secure from theft or exit scams using a P2P
Bitcoin multisig escrow between buyer and seller ONLY. (NO third parties!)
METAmarket is built directly on top of the Bitcoin and Bitmessage
reference clients, keeping security as priority #1. The future of
e-commerce under your control. The future of e-commerce is METAmarket.

http://www.notbeinggoverned.com/metamarket-whitepaper/

https://bitcointalk.org/index.php?topic=1044827.0

http://metamarket.biz/

Multi-chain payment channel nodes

Here is a brief overview of a way to use something like the lightning
network, or another multi-hop payment channel network, to handle more
transactions per second.

These ideas were mentioned yesterday in #bitcoin-wizards and my email
does not significantly elaborate on any of it (search for
"cross-chain"):
http://gnusha.org/bitcoin-wizards/2015-09-01.log
http://gnusha.org/bitcoin-wizards/2015-09-02.log

Mailing list discussion of this can be found at [6] and on the forum at [7].

Summary
=======

Payment channel network nodes could operate on multiple chains or
ledgers, especially if those ledgers are 2-way-peg compatible with
BTC. Payment network users may have a variety of different preferences
about security models or fees or any other number of system
properties, and this method can be more accomodating than only
offering mainnet UTXOs.

Terminology
===========

During the IRC monologue I was using the word "hub" and "cross-chain
hubs" to describe a payment channel network node. Rusty Russell later
brought to my attention a good argument from Joseph Poon to prefer to
call them nodes, namely that "hub" implies centralization which isn't
really necessary to implicate in these designs. So I'll stick with
"node".

Vague requirements and scenario speculation
===========================================

- bip70-like payment-channel-compatible wallet-to-wallet communication
protocol; useful for sender and receiver to negotiate how payment
should be routed over the payment channel network.

- assume existence of other ledgers with working 2-way-peg.

- lightning network[1], amiko pay[2], or some other payment channel
network with multi-hop payment routing

- (at least some) payment channel nodes which access more than one
blockchain or ledger system

- can be more than two chains or ledgers that the node opens channels
on or operate on (octoledger nodes?)

- node can eventually setup 2-way-pegs through moxiebox code embedded
in some opcode for a specification of an alternative federated ledger
(just kidding, there be dragons here)

Implication: Chain or ledger UTXO ambivalence
=============================================

The sender (receiver) doesn't need to be concerned with which chain
the receiver (sender) wishes to transact with, as long as both parties
have wallets that can communicate with each other for fee negotiation
while payment channel routing happens.

Implication: UTXO preferences informed by fee pressures
=======================================================

An earlier identified implication by others has been that transaction
fee trends may influence when payment channel users choose to settle
on the main chain, because fees may be too high to make the tradeoffs
worthwhile for the user.

Transaction fee pressure on the bitcoin mainnet chain may influence
receivers, otherwise busy negotiating their payment channel payments,
to negotiate receipt of their UTXOs on alternative chains which might
be charging lower fees. Users that wish to settle to a ledger for a
lower fee can do so without paying for main chain transaction
prioritization.

(Concerns about market exchange rate of BTC even with the presence of
2-way-pegs could be alleviated by multi-chain nodes that practice
arbitrage. However, perhaps the financial markets will not bother
assigning different values to BTC-compatible UTXOs on different
sidechains? High mainnet fees may be reflected in market price
differences, maybe....)

Minor lightning network protocol change
=======================================

Add chain parameter to onion routing protocol message. Receipt of this
message was acknowledged by Rusty Russell yesterday. However, this
change alone may be insufficient to enable this described usage. Also
while I hope that onion routing continues to be the direction there's
no guarantee of course.

Other: Centralized ledgers
==========================

Centralized ledger operators, such as companies running spot
exchanges, could run payment channel nodes, allowing their users to
deposit and withdraw funds "immediately" subject to whether the
service provider is operating anything resembling a hot wallet. A
centralized ledger operator could be considered a valid multi-chain
destination in the above-mentioned imaginary lightning-compatible
payment protocol. Payment channel network programmers should not be
burdened with a thousand different standards for this ability, and
instead there should be an attempt at general compatibility, although
trustless implementations should be preferred if available.

Luke-Jr mentions that the same (currently imaginary) payment protocol
could also provide for user-to-user transfers on the same centralized
services, skipping the payment channels entirely.

Other
=====

Here are some things that I have been meaning to look at, but haven't looked at:

- can we do probabilistic payments[3][4] over payment channels? does
it require all payments to be probabilistic payments?

- is lightning network + multi-chain compatible with terminating on a
chain like zerocash? or inside coinjoin/coinshuffle schemes? mixing
implications?

- are payment channel networks compatible with confidential
transactions[5], and what about in the multi-chain regime?

- should work if 2-way-peg between multiple assets on same chain, like
in elements alpha?

References
==========

[1] http://lightning.network/lightning-network-paper.pdf

[2] https://github.com/cornwarecjp/amiko-pay

[3] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-May/002564.html

[4] https://bitcointalk.org/index.php?topic=62558.0

[5] https://bitcointalk.org/index.php?topic=1085273.0

[6] http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010797.html

[7] https://bitcointalk.org/index.php?topic=1170303.0

- Bryan
http://heybryan.org/
1 512 203 0507

Proposed minor change to BIP 01 to use a PR for request assignment

The process in BIP01 was written when we used a different solution for
storing and presenting BIPs.

I'm thinking of suggesting that the number request process be changed
to opening a pull req with BIP text with no number (e.g. just using
the authors name and an index as the number) as the mechenism to
request number assignment.

Is there any reason that anyone would find this objectionable?

(Please do not respond to this message with anything but a strictly
directed answer to that question, start a new thread for a different
subject. Thanks!)
jimsmit--- via bitcoin-dev | 3 Sep 22:16 2015

Adhoc Bitcoin Network

Hi,

Is there a feature in Bitcoin that supports adhoc networks, that merge their work into the main Blockchain
at some point?

Thanks,
Jim

block size - pay with difficulty

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 <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

BIP 100 specification

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 <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

BIP 100 repo

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 <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Zach G via bitcoin-dev | 2 Sep 15:44 2015

Re: AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

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 <bip <at> mattwhitlock.name>
To: hurricanewarn1 <hurricanewarn1 <at> aol.com>
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 <bip <at> mattwhitlock.name> > To: hurricanewarn1 <hurricanewarn1 <at> aol.com> > 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 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 about the private subnet, at least based on my > experience. > > > > > > -----Original Message----- > > From: odinn > <odinn.cyberguerrilla <at> riseup.net> > > To: hurricanewarn1 > <hurricanewarn1 <at> aol.com>; bitcoin-dev <bitcoin-dev <at> lists.linuxfoundation.org> > > > Sent: Tue, Sep 1, 2015 3:16 am > > Subject: Re: [bitcoin-dev] AT&T has > effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in > the cable box > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > Another note on this subject > > to add to the stuff people have already > > > mentioned... > > > > If you have the AT&T > > landline but don't use AT&T's > standard internet / > > tv (what they call Uverse) > > offering - that is, if you > prefer to use > > some local internet provider - you are > > probably better off > (in terms > > of avoiding not only this sort of > > blockage/censorship but as > well, > > potentially getting a better privacy policy > > that isn't going to > be > > like AT&T's long-term data retention). You can check > > directly with > > > the various local small ISPs to see what their policies > > are > > specifically > on ports and whatnot. > > > > Ideally your ISP should let > > you: > > > > port > forward to SOMEPORTNUMBER for tcp and udp > > > > (above may or may not > > be > helpful for some if you are using > > decentralized markets) > > > > have port > 8333 > > open > > > > (above is for bitcoin of course) > > > > Supposing you have > FTTN because you > > are paying a local ISP for > > internet service, and that > local ISP has contracted > > with AT&T to be > > able to provide service in an > area where old-style DSL has been > > phased > > out, thus your local ISP is > essentially providing you AT&T FTTN. > > (FTTN > > is Fiber to the Node, FTTN-BP > is FTTN Bonded Pair). Even if a > > local ISP has > > its own privacy policy > posted which is different from > > AT&T, everything is > > subject to AT&T data > retention because the FTTN. > > So get yourself a VPN (or set > > up your own) for > your connection. Tor > > will run through the VPN. > > > > General > > observations > - TWC stores your IP and other stuffs for 6 > > months or longer. > > Same for > Comcast. Verizon retains your stuffs for > > 18 month minimum, probably > > > longer though. Qwest/Century, 1 year. > > Cox, 6 months. AT&T retains for > longer > > than a year. This is just > > what they are telling you, the reality > is it's > > probably longer due to > > stuff like > > this: > > > https://www.lawfareblog.com/odni-and-doj-release-last-section-215-collec > > > tion-order > > > > > > > > > > > > > > > > > > > > Zach > > G via bitcoin-dev: > > > > I have been struggling to get port 8333 open all year, I > > gave up > > > and > was using blockchain for months despite a strong desire to > > stay > > > on > Bitcoin Core, but now the issue has reached critical mass since > > > > > I'm > using the python Bitcoin server module. I have literally spent > > > my entire > > > day trying to open 8333, I thoroughly made sure it was > > > open on the router > and > > computer and it's still closed. Strangely > > > enough I got it open for > 30 seconds > > once today but something closed > > > it immediately. > > > > > > > After hours of phone > > calls and messaging AT&T finally told me the > > > truth > of what was going on, and > > only because I noticed it myself > > > and demanded > an answer. The internet is > > being routed through a > > > DVR/cable box, and > they confirmed the DVR also has a > > firewall. To > > > make this even more > absurd they refused to turn the firewall > > off > > > because it is their > equipment. So effectively they can firewall any > > > > > port they want even if > the customer asks them not to, in the > > > unlikely event > > the customer > figures it out. > > > > > > Perhaps this is the driving force behind the > > > inexplicable and > > > massive decline in Bitcoin nodes. Bitcoin is being > censored > > by the > > > ISPs themselves, and they won't even tell you that. I > had to get in > > > > > touch with headquarters and threaten to rip it out of the > wall to > > > get a > > proper answer. > > > > > > > > > > > > > _______________________________________________ > > bitcoin-dev mailing > > > list > bitcoin-dev <at> 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----- > > > > > iQEcBAEBCgAGBQJV5VDeAAoJEGxwq/inSG8CvkIH/jy4Vo+My3xeBdvFQmxkJWyQ > > > U5mv2zWEvBYw71Xy1EDzQY1AhEBmatUU1eu2AbOqXdUR4511FxCNzFmTxy6roEiz > > > EehBkvXNbBCbEzLRisjxuQw34OKM+xfieCqE1mzJok2uSdLMMQLcbWL1/k3/OmS5 > > > 9O9z/wMXqU1Jc19MTK+vF1Lz5ilnRn3hEbTaCN3ivYnYFa0DpBH9r0Y07UcoJ6Wr > > > ui/x0sSSuupAGzOkZ75HQ8yeQXckeAu6TB3/jE8QEqNUmAJkmR8eK4ofXZWFrIjy > > > mOKeQL4c+jRQnTR8pt+y89g2QIpzFoHaV5T+WvQuC1t8xNOrxLgYFXWgl0dhoYE= > > =UCLC > > > -----END > > PGP SIGNATURE----- > > > > > >
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Zach G via bitcoin-dev | 2 Sep 11:20 2015

Re: AT&T has effectively banned Bitcoin nodes via utilizing private subnets.

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 <bip <at> mattwhitlock.name>
To: hurricanewarn1 <hurricanewarn1 <at> aol.com>
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 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 about the private subnet, at least based on my experience. > > > -----Original Message----- > From: odinn <odinn.cyberguerrilla <at> riseup.net> > To: hurricanewarn1 <hurricanewarn1 <at> aol.com>; bitcoin-dev <bitcoin-dev <at> lists.linuxfoundation.org> > Sent: Tue, Sep 1, 2015 3:16 am > Subject: Re: [bitcoin-dev] AT&T has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Another note on this subject > to add to the stuff people have already > mentioned... > > If you have the AT&T > landline but don't use AT&T's standard internet / > tv (what they call Uverse) > offering - that is, if you prefer to use > some local internet provider - you are > probably better off (in terms > of avoiding not only this sort of > blockage/censorship but as well, > potentially getting a better privacy policy > that isn't going to be > like AT&T's long-term data retention). You can check > directly with > the various local small ISPs to see what their policies > are > specifically on ports and whatnot. > > Ideally your ISP should let > you: > > port forward to SOMEPORTNUMBER for tcp and udp > > (above may or may not > be helpful for some if you are using > decentralized markets) > > have port 8333 > open > > (above is for bitcoin of course) > > Supposing you have FTTN because you > are paying a local ISP for > internet service, and that local ISP has contracted > with AT&T to be > able to provide service in an area where old-style DSL has been > phased > out, thus your local ISP is essentially providing you AT&T FTTN. > (FTTN > is Fiber to the Node, FTTN-BP is FTTN Bonded Pair). Even if a > local ISP has > its own privacy policy posted which is different from > AT&T, everything is > subject to AT&T data retention because the FTTN. > So get yourself a VPN (or set > up your own) for your connection. Tor > will run through the VPN. > > General > observations - TWC stores your IP and other stuffs for 6 > months or longer. > Same for Comcast. Verizon retains your stuffs for > 18 month minimum, probably > longer though. Qwest/Century, 1 year. > Cox, 6 months. AT&T retains for longer > than a year. This is just > what they are telling you, the reality is it's > probably longer due to > stuff like > this: > https://www.lawfareblog.com/odni-and-doj-release-last-section-215-collec > tion-order > > > > > > > > > > Zach > G via bitcoin-dev: > > I have been struggling to get port 8333 open all year, I > gave up > > and was using blockchain for months despite a strong desire to > stay > > on Bitcoin Core, but now the issue has reached critical mass since > > > I'm using the python Bitcoin server module. I have literally spent > > my entire > day trying to open 8333, I thoroughly made sure it was > > open on the router and > computer and it's still closed. Strangely > > enough I got it open for 30 seconds > once today but something closed > > it immediately. > > > > After hours of phone > calls and messaging AT&T finally told me the > > truth of what was going on, and > only because I noticed it myself > > and demanded an answer. The internet is > being routed through a > > DVR/cable box, and they confirmed the DVR also has a > firewall. To > > make this even more absurd they refused to turn the firewall > off > > because it is their equipment. So effectively they can firewall any > > > port they want even if the customer asks them not to, in the > > unlikely event > the customer figures it out. > > > > Perhaps this is the driving force behind the > inexplicable and > > massive decline in Bitcoin nodes. Bitcoin is being censored > by the > > ISPs themselves, and they won't even tell you that. I had to get in > > > touch with headquarters and threaten to rip it out of the wall to > > get a > proper answer. > > > > > > > > _______________________________________________ > bitcoin-dev mailing > > list bitcoin-dev <at> 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----- > > iQEcBAEBCgAGBQJV5VDeAAoJEGxwq/inSG8CvkIH/jy4Vo+My3xeBdvFQmxkJWyQ > U5mv2zWEvBYw71Xy1EDzQY1AhEBmatUU1eu2AbOqXdUR4511FxCNzFmTxy6roEiz > EehBkvXNbBCbEzLRisjxuQw34OKM+xfieCqE1mzJok2uSdLMMQLcbWL1/k3/OmS5 > 9O9z/wMXqU1Jc19MTK+vF1Lz5ilnRn3hEbTaCN3ivYnYFa0DpBH9r0Y07UcoJ6Wr > ui/x0sSSuupAGzOkZ75HQ8yeQXckeAu6TB3/jE8QEqNUmAJkmR8eK4ofXZWFrIjy > mOKeQL4c+jRQnTR8pt+y89g2QIpzFoHaV5T+WvQuC1t8xNOrxLgYFXWgl0dhoYE= > =UCLC > -----END > PGP SIGNATURE----- > >
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Gmane