Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

[Odinn Cyberguerrilla]

> I completed a whitepaper for Bitcoin a proof-of-stake version which uses a
> single nomadic verifiable mint agent and distributed replication of a
> single blockchain by compensated full nodes to achieve 6-hop, sub-second
> transaction acknowledgement times. Plus it pays dividends to holders
> instead of wasting it on miners. Subsidized transaction fees are thus
> lower.


I look at this and agree of course that the nodes are decreasing, see,
https://getaddr.bitnodes.io/   But when I see stuff in the white paper
like "misbehaving nodes" in the context of an "audit agent," a "single
non-forking blockchain," the notion of "Misbehaving nodes" that would be
"banned from the network" so as to "motivat(e) honest behavior," ~ really,
all of this does sound as though a sort of morality is being formulated
rather than a mathematical solution.

This is not to say that the white paper hasn't addressed a problem that
needs to be addressed, namely... the problem of the nodes disappearing,
and a few other things.  But to take that and then layer onto that the
issues associated with proof of stake... There does seem to be a simpler
way to address this and I think first without suggesting the complex issue
of some kind of thing that would involve dividends for those in a
proof-of-stake system, consensus achieved by stake-weighted voting, and so
forth, one would be better off removing all references to voting and
stake, and determining ways simply to incentivize more substantively those
who actually run a full node.  Additionally I am hesitant to characterize
behavior as has been described in the white paper, as it would seem that
(in such a system) there would be an inclination or a tendency to exclude
certain patterns or groups of participants rather than determine ways in
which all participants or potential peers can serve the network.



>
> https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
>
>
> Because the code is not yet written, this idea is half-baked so to speak.
> Comments appreciated on my project thread, which will be a development
> diary. I plan a hard fork of the Bitcoin blockchain in early 2016, after a
> year of public system testing, and conditioned on wide approval.
>
> https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403
>
> -Steve
>
> Stephen L. Reed
> Austin, Texas, USA
> 512.791.7860--
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Jeff Garzik]

Indeed -- you must reinvent TCP over UDP, ultimately, to handle blocks
and large TXs.


On Tue, May 20, 2014 at 4:09 PM, Andy Alness  wrote:
> Awesome! I'm assuming this is it:
> https://bitcointalk.org/index.php?topic=156769.0
>
> It would be interesting (at least to me) to take this a step further
> and offer UDP as a full TCP replacement capable of STUN-assisted NAT
> traversal and possibly swarmed blockchain syncs. It would require open
> TCP nodes to facilitate "connection" establishment. It is obviously a
> non-trivial amount of work but would be an interesting experiment.
> Maybe BitTorrent's µTP protocol could be leveraged.
>
> On Tue, May 20, 2014 at 12:17 PM, Jeff Garzik  wrote:
>> Yes, i spec'd out the UDP traversal of the P2P protocol.  It seems
>> reasonable especially for "inv" messages.
>>
>> On Tue, May 20, 2014 at 2:46 PM, Andy Alness  wrote:
>>> Has there ever been serious discussion on extending the protocol to
>>> support UDP transport? That would allow for NAT traversal and for many
>>> more people to run effective nodes. I'm also curious if it could be
>>> made improve block propagation time.
>>>
>>> On Tue, May 20, 2014 at 7:52 AM, Gmail  wrote:
 Unlikely. I doubt any significant portion of miners in china will continue 
 to mine on a china-specific chain, since it will certainly be outmined by 
 non-Chinese miners, and will be orphaned eventually.

 More likely is that mining interests in china will make special 
 arrangements to circumvent the GFwOC.

 Users who can't access the worldwide blockchain will notice horrendously 
 slow confirmation times and other side effects.

> On May 20, 2014, at 10:37, Eugen Leitl 
>
> Could a blockchain fork due to network split happen?
>

 --
 "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform 
 available
 Simple to use. Nothing to install. Get started now for free."
 http://p.sf.net/sfu/SauceLabs
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

>>>
>>>
>>>
>>> --
>>> Andy Alness
>>> Software Engineer
>>> Coinbase
>>> San Francisco, CA
>>>
>>> --
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>> Get unparalleled scalability from the best Selenium testing platform 
>>> available
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> ___
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.  https://bitpay.com/
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Andy Alness]

Awesome! I'm assuming this is it:
https://bitcointalk.org/index.php?topic=156769.0

It would be interesting (at least to me) to take this a step further
and offer UDP as a full TCP replacement capable of STUN-assisted NAT
traversal and possibly swarmed blockchain syncs. It would require open
TCP nodes to facilitate "connection" establishment. It is obviously a
non-trivial amount of work but would be an interesting experiment.
Maybe BitTorrent's µTP protocol could be leveraged.

On Tue, May 20, 2014 at 12:17 PM, Jeff Garzik  wrote:
> Yes, i spec'd out the UDP traversal of the P2P protocol.  It seems
> reasonable especially for "inv" messages.
>
> On Tue, May 20, 2014 at 2:46 PM, Andy Alness  wrote:
>> Has there ever been serious discussion on extending the protocol to
>> support UDP transport? That would allow for NAT traversal and for many
>> more people to run effective nodes. I'm also curious if it could be
>> made improve block propagation time.
>>
>> On Tue, May 20, 2014 at 7:52 AM, Gmail  wrote:
>>> Unlikely. I doubt any significant portion of miners in china will continue 
>>> to mine on a china-specific chain, since it will certainly be outmined by 
>>> non-Chinese miners, and will be orphaned eventually.
>>>
>>> More likely is that mining interests in china will make special 
>>> arrangements to circumvent the GFwOC.
>>>
>>> Users who can't access the worldwide blockchain will notice horrendously 
>>> slow confirmation times and other side effects.
>>>
 On May 20, 2014, at 10:37, Eugen Leitl 

 Could a blockchain fork due to network split happen?

>>>
>>> --
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>> Get unparalleled scalability from the best Selenium testing platform 
>>> available
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> ___
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> --
>> Andy Alness
>> Software Engineer
>> Coinbase
>> San Francisco, CA
>>
>> --
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform 
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/



-- 
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Isidor Zeuner]

> >
> > In my opinion, the number of full nodes doesn't matter (as long as
> > it's enough to satisfy demand by other nodes).
> >
>
> Correct. Still, a high number of nodes has a few other benefits:
>
> 1) The more nodes there are, the cheaper it should be to run each one,
> given that the bandwidth and CPU for serving the chain will be spread over
> more people.
>
> 2) It makes Bitcoin *seem* bigger, more robust and more decentralised,
> because there are more people uniting to run it. So there's a psychological
> benefit.
>

Psychological benefit vs. effective benefit involves the danger of
destroying trust in the Bitcoin network when there are hard facts for
non-robustness while the node number looks big. Therefore, it may make
sense to establish better metrics.

> Also, we don't have a good way to measure capacity vs demand at the moment.
> Whether we have enough capacity is rather a shot in the dark right now.
>
>
> > What matters is how hard it is to run one.
> >
>
> Which is why I'm interested to learn the reason behind the drop. Is it
> insufficient interest, or is running a node too painful?
>
> For this purpose I'd like to exclude people running Bitcoin Core on laptops
> or non-dedicated desktops. I don't think full nodes will ever make sense
> for consumer wallets again, and I see the bleeding off of those people as
> natural and expected (as Satoshi did). But if someone feels it's too hard
> to run on a cheap server then that'd concern me.
>

In my opinion, the characteristic of being able to make use of
non-dedicated nodes should be regarded as an advantage of the Bitcoin
protocol, and not something to get rid of. Nodes being able to
contribute this way may lead to even more robustness than
decentralization alone, as they can do so without exposing a fixed
address which could be attacked.

Best regards,

Isidor

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Jeff Garzik]

Yes, i spec'd out the UDP traversal of the P2P protocol.  It seems
reasonable especially for "inv" messages.

On Tue, May 20, 2014 at 2:46 PM, Andy Alness  wrote:
> Has there ever been serious discussion on extending the protocol to
> support UDP transport? That would allow for NAT traversal and for many
> more people to run effective nodes. I'm also curious if it could be
> made improve block propagation time.
>
> On Tue, May 20, 2014 at 7:52 AM, Gmail  wrote:
>> Unlikely. I doubt any significant portion of miners in china will continue 
>> to mine on a china-specific chain, since it will certainly be outmined by 
>> non-Chinese miners, and will be orphaned eventually.
>>
>> More likely is that mining interests in china will make special arrangements 
>> to circumvent the GFwOC.
>>
>> Users who can't access the worldwide blockchain will notice horrendously 
>> slow confirmation times and other side effects.
>>
>>> On May 20, 2014, at 10:37, Eugen Leitl 
>>>
>>> Could a blockchain fork due to network split happen?
>>>
>>
>> --
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform 
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Andy Alness]

Has there ever been serious discussion on extending the protocol to
support UDP transport? That would allow for NAT traversal and for many
more people to run effective nodes. I'm also curious if it could be
made improve block propagation time.

On Tue, May 20, 2014 at 7:52 AM, Gmail  wrote:
> Unlikely. I doubt any significant portion of miners in china will continue to 
> mine on a china-specific chain, since it will certainly be outmined by 
> non-Chinese miners, and will be orphaned eventually.
>
> More likely is that mining interests in china will make special arrangements 
> to circumvent the GFwOC.
>
> Users who can't access the worldwide blockchain will notice horrendously slow 
> confirmation times and other side effects.
>
>> On May 20, 2014, at 10:37, Eugen Leitl 
>>
>> Could a blockchain fork due to network split happen?
>>
>
> --
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Andy Alness
Software Engineer
Coinbase
San Francisco, CA

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] good bitcoin summary paper in more detail than Satoshi paper (Re: Bitcoin Protocol Specification)

[Adam Back]

Actually I read the paper now as it was linked somewhere else also, and its
quite good.  So now I can summarize it:

Its a writeup of bitcoin in 29 pages, which covers things in the original
bitcoin paper but with more detail of formats, scripts with some examples,
formats etc.  Quite nice paper, concise presentation of many bitcoin details
that are otherwise hard to put together, requiring examining source or
asking people knowledgeable at algorithm/code level.

>>http://enetium.com/resources/Bitcoin.pdf

Adam

On Sun, May 18, 2014 at 04:38:53PM +0200, Adam Back wrote:
>Suggestion: maybe you want to write and post here a paragraph summarizing
>the topic of your paper so people can know if they feel qualified and if
>they need to review it from their interests.
>
>Adam
>
>On Sun, May 18, 2014 at 03:35:33PM +0200, Krzysztof Okupski wrote:
>>Dear all,
>>
>>I'd like to kindly ask, those of you that have a bit of spare time, to
>>take a look at a Bitcoin protocol specification I've written. It is still
>>in development and, as some of you have already indicated, needs
>>improvement. I'd be very thankful if some of you could take the
>>time to review it. If there are any errors or suggestions from your
>>side, I'd gladly hear them. My e-mail can be found on the front page
>>of the document:
>>
>>http://enetium.com/resources/Bitcoin.pdf
>>
>>Warm greetings,
>>Chris
>>
>>
>>--
>>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>Instantly run your Selenium tests across 300+ browser/OS combos.
>>Get unparalleled scalability from the best Selenium testing platform available
>>Simple to use. Nothing to install. Get started now for free."
>>http://p.sf.net/sfu/SauceLabs
>>___
>>Bitcoin-development mailing list
>>Bitcoin-development@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>--
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos.
>Get unparalleled scalability from the best Selenium testing platform available
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

[Nick Simpson]

Referring to the subsidy for miners as "wasting it on miners" isn't going to 
garner you much favor. 


On May 20, 2014 11:12:53 AM CDT, Stephen Reed  wrote:
>I completed a whitepaper for Bitcoin a proof-of-stake version which
>uses a single nomadic verifiable mint agent and distributed replication
>of a single blockchain by compensated full nodes to achieve 6-hop,
>sub-second transaction acknowledgement times. Plus it pays dividends to
>holders instead of wasting it on miners. Subsidized transaction fees
>are thus lower.
>
>https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE
>
>
>Because the code is not yet written, this idea is half-baked so to
>speak. Comments appreciated on my project thread, which will be a
>development diary. I plan a hard fork of the Bitcoin blockchain in
>early 2016, after a year of public system testing, and conditioned on
>wide approval.
>
>https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403
>
>-Steve
>
>Stephen L. Reed 
>Austin, Texas, USA 
>512.791.7860
>
>
>
>--
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos.
>Get unparalleled scalability from the best Selenium testing platform
>available
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>
>
>
>___
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

[Stephen Reed]

I completed a whitepaper for Bitcoin a proof-of-stake version which uses a 
single nomadic verifiable mint agent and distributed replication of a single 
blockchain by compensated full nodes to achieve 6-hop, sub-second transaction 
acknowledgement times. Plus it pays dividends to holders instead of wasting it 
on miners. Subsidized transaction fees are thus lower.

https://docs.google.com/document/d/1C4m-MFnxw0JjDorzrKs_IRQRqD9ila79o0IDt6KsbcE


Because the code is not yet written, this idea is half-baked so to speak. 
Comments appreciated on my project thread, which will be a development diary. I 
plan a hard fork of the Bitcoin blockchain in early 2016, after a year of 
public system testing, and conditioned on wide approval.

https://bitcointalk.org/index.php?topic=584719.msg6397403#msg6397403

-Steve

Stephen L. Reed 
Austin, Texas, USA 
512.791.7860--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Gmail]

Unlikely. I doubt any significant portion of miners in china will continue to 
mine on a china-specific chain, since it will certainly be outmined by 
non-Chinese miners, and will be orphaned eventually. 

More likely is that mining interests in china will make special arrangements to 
circumvent the GFwOC.

Users who can't access the worldwide blockchain will notice horrendously slow 
confirmation times and other side effects. 

> On May 20, 2014, at 10:37, Eugen Leitl  
> 
> Could a blockchain fork due to network split happen?
> 


smime.p7s
Description: S/MIME cryptographic signature
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Eugen Leitl]

On Tue, May 20, 2014 at 10:15:44AM +0200, bitcoingr...@gmx.com wrote:
>Recently China has updated its firewall blocking bitcoin sites and pools.
>Whether this is simple blacklist or more sophisticated packet targeting is
>uncertain, however this update did spefically target VPN handshakes.

Could a blockchain fork due to network split happen?
 

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] patents...

[Jeff Garzik]

On Mon, May 19, 2014 at 10:47 AM, Adam Back  wrote:
> hmm Yes and this topic now is more than a bit non dev related.  Sorry about
> that.  There seems to be no convenient mailing list format for non-dev stuff
> or I would Cc and set Reply-To for example?  (Web forums somewhat suck IMO).

There is the little-used "bitcoin-list" on SourceForge that claims a
rubric of "general discussion":
https://sourceforge.net/p/bitcoin/mailman/?source=navbar

I just subscribed there.

We can "reboot" that list with a couple new rules such as
a) be good to each other.  consistent rude behavior gets the boot.
b) anything related to decentralization, consensus, proven data
structures or crypto is on-topic

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Mike Hearn]

Yeah I'm expecting port 8333 to go away in China at some point. Actually I
was expecting that years ago and was kind of surprised that the suppression
was being done via banks. Guess the GFW operators were just slow to catch
up.
On 20 May 2014 10:16,  wrote:

> Recently China has updated its firewall blocking bitcoin sites and pools.
> Whether this is simple blacklist or more sophisticated packet targeting
> is uncertain, however this update did spefically target VPN handshakes.
>
>  *Sent:* Monday, April 07, 2014 at 1:07 PM
> *From:* Drak 
> *To:* "Mike Hearn" 
> *Cc:* "Bitcoin Dev" 
> *Subject:* Re: [Bitcoin-development] Why are we bleeding nodes?
>  For what it's worth, the number of nodes rose dramatically during the
> China bullrun (I recall 45k in China alone) and dropped as dramatically as
> the price after the first PBOC announcement designed to cool down bitcoin
> trading in China.
>
> On 7 April 2014 12:34, Mike Hearn  wrote:
>>
>> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500
>> and still falling:
>>
>>http://getaddr.bitnodes.io/dashboard/chart/?days=60
>>
>> I know all the reasons why people *might* stop running a node (uses too
>> much disk space, bandwidth, lost interest etc). But does anyone have any
>> idea how we might get more insight into what's really going on? It'd be
>> convenient if the subVer contained the operating system, as then we could
>> tell if the bleed was mostly from desktops/laptops (Windows/Mac), which
>> would be expected, or from virtual servers (Linux), which would be more
>> concerning.
>>
>> When you set up a Tor node, you can add your email address to the config
>> file and the Tor project sends you emails from time to time about things
>> you should know about. If we did the same, we could have a little exit
>> survey: if your node disappears for long enough, we could email the
>> operator and ask why they stopped.
>>
>>
>> --
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_APR
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>  
> --
> Put Bad Developers to Shame Dominate Development with Jenkins Continuous
> Integration Continuously Automate Build, Test & Deployment Start a new
> project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees___Bitcoin-development
>  mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[bitcoingrant]

Recently China has updated its firewall blocking bitcoin sites and pools. Whether this is simple blacklist or more sophisticated packet targeting is uncertain, however this update did spefically target VPN handshakes.

 



Sent: Monday, April 07, 2014 at 1:07 PM
From: Drak 
To: "Mike Hearn" 
Cc: "Bitcoin Dev" 
Subject: Re: [Bitcoin-development] Why are we bleeding nodes?


For what it's worth, the number of nodes rose dramatically during the China bullrun (I recall 45k in China alone) and dropped as dramatically as the price after the first PBOC announcement designed to cool down bitcoin trading in China.

 
On 7 April 2014 12:34, Mike Hearn  wrote:


At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and still falling:
 

   http://getaddr.bitnodes.io/dashboard/chart/?days=60

 

I know all the reasons why people might stop running a node (uses too much disk space, bandwidth, lost interest etc). But does anyone have any idea how we might get more insight into what's really going on? It'd be convenient if the subVer contained the operating system, as then we could tell if the bleed was mostly from desktops/laptops (Windows/Mac), which would be expected, or from virtual servers (Linux), which would be more concerning.

 

When you set up a Tor node, you can add your email address to the config file and the Tor project sends you emails from time to time about things you should know about. If we did the same, we could have a little exit survey: if your node disappears for long enough, we could email the operator and ask why they stopped.


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


-- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 

 

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development