Re: [bitcoin-dev] BIP70 is dead. What now?

[P G via bitcoin-dev]

Hi Thomas,

> Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
that payment requests were signed.

In addition to signing the actual payment request, a nice addition to a new
payment protocol is an assurance that the receiving address can in fact
spend later on. Many users send "test" transactions to a wallet address
before sending their intended full amount. If the protocol includes a
response containing a signature using BIP322, there is better assurance for
the sender. Outside of the merchant context, a sender can use the protocol
to have peace of mind when sending between their own wallets. This should
likely be an optional parameter given cold storage setups cannot return a
signature quickly.

- Philip


On Sun, Feb 21, 2021 at 5:26 AM Eoin McQuinn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What is a 'pull request'?
>
> On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Thomas,
>>
>> I am working on an experimental implementation [1] of a new payment
>> request format in Trezor T. In some respects it's similar to BIP-70. The
>> main differences are:
>>
>> 1. There is no reliance on X.509, since that seems to have been the main
>> reason for BIP-70's downfall. The signature is mandatory, since for us the
>> main feature is protection against a man-in-the-middle attack. So in this
>> sense it's more similar to BOLT11.
>>
>> 2. It can be used to solve a similar problem with coin exchange. When you
>> are sending BTC to a trusted exchange service and expecting another
>> cryptocurrency in return, say LTC, you want to be sure that you not only
>> have the correct BTC address, but also that the exchange service has your
>> correct LTC address.
>>
>> 3. It uses an optional nonce for replay protection.
>>
>> The two interesting parts in [1] are probably the `TxAckPaymentRequest`
>> protobuf message [2] and the signature verification [3]. The protobuf
>> message is only for communication between Trezor and the host software
>> running on the user's computer. It's not intended for interchange between
>> wallets. We haven't defined the interchange format yet. I intend to create
>> a SLIP documenting all this.
>>
>> Andrew
>>
>> [1]
>> https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2
>> [2]
>> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427
>> [3]
>> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py
>>
>> On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi, Thomas,
>>>
>>> I developed a URL signing scheme for use with LNURL as a method for
>>> authorizing payments on behalf of offline devices /applications. It's
>>> not specifically off-chain or on-chain related, but could be repurposed.
>>> The gist of the scheme is as follows:
>>>
>>> Before any signing is done:
>>>
>>> 0) Generate an API key (ID/reference, secret, encoding) to be shared
>>> between a server and an offline device or application.
>>>
>>> To generate a signature:
>>>
>>> 1) Generate a random nonce (unique per API key)
>>>
>>> 2) Build a query string with the `id`, `nonce`, `tag`, "Server
>>> parameters" (see [Subprotocols](#subprotocols) above), and any custom
>>> parameters. The `id` parameter should be equal to the API key's ID.
>>> Example:
>>> `id=b6cb8e81e3=d585674cf991dbbab42b=withdrawRequest=5000=7000=example=CUSTOM1_PARAM_VALUE=CUSTOM2_PARAM_VALUE`.
>>>
>>> Note that both the keys and values for query parameters should be URL
>>> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9
>>> - _ . ! ~ * ' ( )`. See
>>> [encodeURIComponent](
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description)
>>>
>>> for more details.
>>>
>>> 3) Sort the query parameters by key (alphabetically). This is referred
>>> to as the "payload". Example:
>>>
>>> `custom1=CUSTOM1_PARAM_VALUE=CUSTOM2_PARAM_VALUE=example=b6cb8e81e3=7000=5000=d585674cf991dbbab42b=withdrawRequest`
>>>
>>> 4) Sign the payload (the sorted query string) using the API key secret.
>>> Signatures are generated using HMAC-SHA256, where the API key secret is
>>> the key.
>>>
>>> 5) Append the signature to the payload as follows:
>>>
>>> `custom1=CUSTOM1_PARAM_VALUE=CUSTOM2_PARAM_VALUE=example=b6cb8e81e3=7000=5000=d585674cf991dbbab42b=withdrawRequest=HMAC_SHA256_SIGNATURE`.
>>>
>>> You can find more details here:
>>>
>>>
>>> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme
>>>
>>>
>>> I would change a few things with this scheme to fit better with the
>>> use-case you describe. For example:
>>>
>>> * Remove the "tag" and LNURL-specific parameters
>>>
>>> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key
>>> signing instead. The 

[bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures

[Sridhar G via bitcoin-dev]

Hi everyone,

N-of-n multisig transaction using Schnorr aggregate signature is trivial
and is similar to the current P2PKH. I would like to propose a model for
m-of-n multisig transactions using Schnorr aggregate signatures and use
this to enable CoinPools for off-chain scalability.

1. Creating the pool

A transaction is made on the bitcoin network with an output having the
following script:

   ..  N M OP_POOL

Bitcoin network will create a ‘pool’ with all the ‘N’ public keys and note
down the threshold M for this pool. This UTXO would be referred as 

2. Depositing money to pool

Deposits can be made to a pool with  with the following script

 OP_LOAD_POOL_AGG_PUB_KEY OP_CHECKSIG

3. Redeeming money from pool

Redeem script would contain the aggregated signature from all signers and
the bitmap of signers.

* *   OP_LOAD_POOL_AGG_PUB_KEY
OP_CHECKSIG


With   provided by the person that redeems money
from a pool, where

 - is the aggregated signature

 - Is a bitmap representing whether the member of the pool
at position 'i' of bitmap has signed or not(1 = signed, 0 - has not signed)



So we will be introducing two new opcodes:

   1.

   OP_POOL - this will be used to create a new coin pool.
   2.

   OP_LOAD_POOL_AGG_PUB_KEY - This opcode does three things
   1.

  loads the pool (POOL_ID)
  2.

  checks if there are atleast 'm' signers (based on SIGNERS_BITMAP)
  3.

  aggregates the public key of the signers. (based on SIGNERS_BITMAP)

  The opcode uses the top two elements from the stack- the first
element from the stack specifies the POOL_ID to load, which will load the
public keys from the pool. This opcode also checks if there are ‘M’
signers(as specified at the time of creation of the pool) and aggregates
the public keys that have signed based on SIGNERS_BITMAP using Schnorr
aggregate signature scheme and puts back this aggregated public key onto
the stack.


SIGNERS_BITMAP is a 32 byte value, and represents a bitmap of which public
keys from the pool have signed the transaction.

Having this scheme would enable-

   1.

   Scalability of m-of-n multisig transactions - People can deposit money
   to a pool(with 32 byte SIGNERS_BITMAP, we can allow for 256 possible
   signers).
   2.

   Trust minimized off-chain scalability solutions due to the use of a
   sufficiently large pool of signers. Most existing pools might allow for
   only a few signers as having many signers would mean higher transaction
   cost.


Downsides:

   1.

   We need to have the public keys of the members of the pool exposed.


Despite the downsides of exposing public keys, do you think this would be a
viable scheme for enabling CoinPool for the Bitcoin network? Or, any scheme
that may expose public keys is a no-go in the Bitcoin network?


Thanks! Looking for your feedback and thoughts on this.

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

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

[g via bitcoin-dev]

Makes sense. I would love if GPUs were back as the main hashing tool.

However, we need to consider the environmental impact of mining, which 
currently consumes a quite exorbitant amount of energy. Any ideas on this front?

--
Garrett MacDonald
+1 720 515 2248
g...@cognitive.ch
GPG Key

On Apr 10, 2017, 12:17 PM -0600, Erik Aronesty , wrote:
> I own some miners, but realistically their end of life is what, 6 months from 
> now if I'm lucky?    If we used difficulty ramps on two selected POW's, then 
> the migration could be made smooth.   I don't think changing the POW would be 
> very challenging.  Personally, I would absolutely love to be back in the 
> business of buying GPU's instead of ASICs which are uniformly sketchy.   Does 
> anyone *not* mine their own equipment before "shipping late" these days?
>
> Maybe sample a video game's GPU operations and try to develop a secure hash 
> whose optimal implementation uses them in a similar ratio?   Ultimately, I 
> think it would very challenging to find a POW that doesn't make a bad problem 
> worse.  I understand that's why you suggested SHA3.
>
> Hopefully, the "nanometer race" we have will work more smoothly once the 
> asicboost issue is resolved and competition can return to normal.   But 
> "waiting things out" rarely seems to work in Bitcoin land.
>
>
>
>
>
>
> > On Mon, Apr 10, 2017 at 11:25 AM, g  wrote:
> > > Erik,
> > >
> > > I completely agree that it will be in the long term interest of bitcoin 
> > > to migrate, gradually, toward a commoditized POW away from the current 
> > > mass centralization. There is a big problem here though: Hundreds of 
> > > millions of dollars have been spent on the current algorithm, and will be 
> > > a huge loss if this is not done slowly enough, and the miners who control 
> > > the chain currently would likely never allow this change to happen.
> > >
> > > Do you have any ideas regarding how to mitigate the damage of such a 
> > > change for the invested parties? Or even how we can make the change 
> > > agreeable for them?
> > >
> > > Warm regards,
> > > Garrett
> > >
> > > --
> > > Garrett MacDonald
> > > +1 720 515 2248
> > > g...@cognitive.ch
> > > GPG Key
> > >
> > > On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev 
> > > , wrote:
> > > > Curious: I'm not sure why a serious discussion of POW change is not on 
> > > > the table as a part of a longer-term roadmap.
> > > >
> > > > Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of 
> > > > the proven, np-complete graph-theoretic or polygon manipulation POW 
> > > > would keep Bitcoin in commodity hardware and out of the hands of 
> > > > centralized manufacturing for many years.
> > > >
> > > > Clearly a level-playing field is critical to keeping centralization 
> > > > from being a "defining feature" of Bitcoin over the long term.   I've 
> > > > heard the term "level playing field" bandied about quite a bit.   And 
> > > > it seems to me that the risk of state actor control and botnet attacks 
> > > > is less than state-actor manipulation of specialized manufacturing of 
> > > > "SHA-256 forever" hardware.   Indeed, the reliance on a fairly simple 
> > > > hash seems less and less likely a "feature" and more of a baggage.
> > > >
> > > > Perhaps regular, high-consensus POW changes might even be *necessary* 
> > > > as a part of good maintenance of cryptocurrency in general.   Killing 
> > > > the existing POW, and using an as-yet undefined, but deployment-bit 
> > > > ready POW field to flip-flop between the current and the "next one" 
> > > > every 8 years or or so, with a ramp down beginning in the 7th year  
> > > > A stub function that is guaranteed to fail unless a new consensus POW 
> > > > is selected within 7 years.
> > > >
> > > > Something like that?
> > > >
> > > > Haven't thought about it *that* much, but I think the network would 
> > > > respond well to a well known cutover date.   This would enable 
> > > > rapid-response to quantum tech, or some other needed POW switch as 
> > > > well... because the mechanisms would be in-place and ready to switch as 
> > > > needed.
> > > >
> > > > Lots of people seem to panic over POW changes as "irresponsible", but 
> > > > it's only irresponsible if done irresponsibly.
> > > >
> > > >
> > > > > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev 
> > > > >  wrote:
> > > > > > Jimmy Song,
> > > > > >
> > > > > > Why would the actual end users of Bitcoin (the long term and short 
> > > > > > term owners of bitcoins) who run fully verifying nodes want to 
> > > > > > change Bitcoin policy in order to make their money more vulnerable 
> > > > > > to 51% attack?
> > > > > >
> > > > > > If anything, we would be making policy changes to prevent the use 
> > > > > > of patented PoW algorithms instead of making changes to enable them.
> > > > > >
> > > 

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

[g via bitcoin-dev]

Erik,

I completely agree that it will be in the long term interest of bitcoin to 
migrate, gradually, toward a commoditized POW away from the current mass 
centralization. There is a big problem here though: Hundreds of millions of 
dollars have been spent on the current algorithm, and will be a huge loss if 
this is not done slowly enough, and the miners who control the chain currently 
would likely never allow this change to happen.

Do you have any ideas regarding how to mitigate the damage of such a change for 
the invested parties? Or even how we can make the change agreeable for them?

Warm regards,
Garrett

--
Garrett MacDonald
+1 720 515 2248
g...@cognitive.ch
GPG Key

On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev 
, wrote:
> Curious: I'm not sure why a serious discussion of POW change is not on the 
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of the 
> proven, np-complete graph-theoretic or polygon manipulation POW would keep 
> Bitcoin in commodity hardware and out of the hands of centralized 
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from 
> being a "defining feature" of Bitcoin over the long term.   I've heard the 
> term "level playing field" bandied about quite a bit.   And it seems to me 
> that the risk of state actor control and botnet attacks is less than 
> state-actor manipulation of specialized manufacturing of "SHA-256 forever" 
> hardware.   Indeed, the reliance on a fairly simple hash seems less and less 
> likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a 
> part of good maintenance of cryptocurrency in general.   Killing the existing 
> POW, and using an as-yet undefined, but deployment-bit ready POW field to 
> flip-flop between the current and the "next one" every 8 years or or so, with 
> a ramp down beginning in the 7th year  A stub function that is guaranteed 
> to fail unless a new consensus POW is selected within 7 years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would respond 
> well to a well known cutover date.   This would enable rapid-response to 
> quantum tech, or some other needed POW switch as well... because the 
> mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's 
> only irresponsible if done irresponsibly.
>
>
> > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev 
> >  wrote:
> > > Jimmy Song,
> > >
> > > Why would the actual end users of Bitcoin (the long term and short term 
> > > owners of bitcoins) who run fully verifying nodes want to change Bitcoin 
> > > policy in order to make their money more vulnerable to 51% attack?
> > >
> > > If anything, we would be making policy changes to prevent the use of 
> > > patented PoW algorithms instead of making changes to enable them.
> > >
> > > Thanks,
> > > Praxeology Guy
> > >
> > > ___
> > > 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

[bitcoin-dev] AT/ISPs making Bitcoin Core near impossible to use as a full node via hidden private dynamic IPs, not by specifically blocking 8333 or Bitcoin as stated in original email

[Zach G via bitcoin-dev]

I sent out an email after 48 hours of dealing with trying to open up my ports 
for Bitcoin, I was quite frustrated and angry since I had to call like 10 times 
and I was making zero progress. Most of the AT people didn't give me any 
helpful clues on how to fix the situation. The original email described how 
there is a firewall in the DVR, and I thought it was blocking the ports. It is 
true there is a uncontrollable firewall in the DVR, it is false this blocks 
8333.

The actual problem is due to AT Uverse customers being forced to use a 
private dynamic IP, the IP is literally hidden from the internet, so it isn't 
possible to send any requests at it. It will literally ignore pings across all 
ports. So the solution is to switch to public static IP and make sure you allow 
incoming traffic. 

It's not so simple though, AT will not let you have a public static IP 
without paying. I've had my router reset 10 times today by AT (probably 
automatically) and it comes back with a private dynamic IP. Then I have to 
reset it to use public IP and that lasts less than an hour. It literally went 
from open to closed while typing this email... the IP address went from public 
to private dynamic. 

https://i.gyazo.com/3c732687fc3d21acb7d62f6d0e23a346.png

This is making using Bitcoin Core almost impossible. I'm at least getting some 
synch now but maybe a few days of blocks the entire day, cause I can't sit here 
all day with the computer and keep fixing it.

The proof is in the pudding, there are 37 nodes using AT in the ENTIRE world. 
AT is a massive ISP so this is strong evidence that using Bitcoin Core as a 
full node on AT is extremely difficult and actually just about impossible.

https://i.gyazo.com/90beebe056f5fc338165e8d200536c06.png

The other big ISPs have pathetic numbers also due to the same sort've things 
that AT does, but at least Comcast has 400 nodes. AT is much harder to use 
than any other ISP I've dealt with when it comes to Bitcoin Core.

I apologize for sending out the wrong info the first time, although it is still 
worth noting the DVR firewall is out of your control, which might be a problem 
if not now then in the future. In any case AT has effectively blocked full 
nodes for Bitcoin Core via the private subnet, and the disability to change it 
to public without paying $15 more per month, and buying a $15 connection 
service so they will give you that info (if you dont pay the connection 
'specialists' hang up on you). 

It is important to note this is not Bitcoin specific, but effects every program 
that depends on freely open ports. I don't think AT has anything against 
Bitcoin, it's just their security settings and policies have disabled Bitcoin 
Core for most customers. Also important to note this isn't a problem specific 
to AT, all the big ISPs are doing similar things. I believe the changes in 
ISP protocol are the main driving force behind the massive decline in Bitcoin 
nodes. Another big factor is firewalls, most people can't even remove the 
firewalls enough to open ports at will. The community needs to educate people 
on how to use Bitcoin Core when facing these intensifying security measures, or 
the decline of node numbers will continue.

 

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

Re: [bitcoin-dev] AT 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 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 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 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 <b...@mattwhitlock.name>
To: hurricanewarn1 <hurricanewa...@aol.com>
Sent: Wed, Sep 2, 2015 4:32 am
Subject: Re: [bitcoin-dev] AT 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 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 (
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 arti

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

[Zach G via bitcoin-dev]

 The only reason someone would want to make a license is so they can 
sue/threaten people for not following the license rules. At best this is 
pointless since Bitcoin cannot be controlled, and at worst it will result in a 
group of people using coercion against the community to gain profits. 
 
 There is no legal ground for anyone to make a Bitcoin license, it simply 
wouldn't stand in court. Not even the MIT license is valid or meaningful. But I 
wouldn't be surprised if people tried scaring people with a license even if 
they knew it was invalid.


It's actually disgusting that you wrote what people are allowed and not 
allowed to do with Bitcoin. Pure centralization ideology. Maybe go work for the 
government and make regulations instead of trying to centralize one of the only 
de-centralized things left on the planet.

   


 

 

-Original Message-
From: Ahmed Zsales via bitcoin-dev 
To: Bitcoin Dev 
Sent: Tue, Sep 1, 2015 9:30 am
Subject: [bitcoin-dev]  Open Block Chain Licence, BIP[] Draft


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

[Zach G via bitcoin-dev]

Yup I've been looking over twister thoroughly this week, it's very close to 
what I'm thinking and I'm sure the developer of that could easily do the 
project I'm doing. However he decided to make an alt coin and didn't use the 
real blockchain, which makes his network weak. It's a waste to not take 
advantage of the immense bitcoin computing power for this. I'm only planning on 
storing hashes in the blockchain though to prevent data bloat, and the parallel 
program which stores all the data will be a lot like twister. Additionally I'm 
going to take it beyond a messaging system, will be able to literally upload 
anything and everything to this system. Theres no limit to what this 
de-centralized system can do if designed correctly. Crypto graffiti has given a 
taste of that by uploading jpeg and png to the blockchain. 

Will be working on this 24/7 until the first release, will definitely tell you 
and others when the code is ready to be looked over. Fortunately I am employed 
by bitcoin so I can focus on this 

-Original Message-
From: Michael Wozniak <mwozn...@itbit.com>
To: hurricanewarn1 <hurricanewa...@aol.com>
Sent: Mon, Aug 31, 2015 09:15 AM
Subject: Re: [bitcoin-dev] Censorship





 
Have you seen this: 
  http://twister.net.co/;>http://twister.net.co/
  
   

  
  

It sounds very similar to what you're trying to do.  Also, I'd be willing to 
help out in the form of running some alpha/beta software as part of the network 
once you get something working.  Depending what languages you're writing in, I 
might help with code.
  
 
 
  

  
On Mon, Aug 31, 2015 at 8:06 AM, Zach G via bitcoin-dev 
   <mailto:bitcoin-dev@lists.linuxfoundation.org;>bitcoin-dev@lists.linuxfoundation.org>
 wrote:
   

   
The de-centralized forum directly integrates the 
Bitcoin blockchain with every post. I can see how you misunderstood since I 
wasn't specific in my first email. I'm surprised no one has done this yet, 
people have done things very similar but never took the leap to integrate the 
actual Bitcoin blockchain. Basically http://cryptograffiti.info/;>http://cryptograffiti.info/
 but with a parallel program that stores most of the data in a hash reference 
table, and shares that data via a torrent-esque system.
 
  The Bitcoin of thoughts. 
 
 
  
 
  
 
 
  
 
  
 
  -Original Message-
 From: Natanael <mailto:natanae...@gmail.com;>natanae...@gmail.com>
 To: NxtChg <mailto:nxt...@hush.com;>nxt...@hush.com>
 Cc: bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org;>bitcoin-dev@lists.linuxfoundation.org>;
 hurricanewarn1 <mailto:hurricanewa...@aol.com;>hurricanewa...@aol.com>
 Sent: Mon, Aug 31, 2015 7:46 am
 Subject: Re: [bitcoin-dev] Censorship
 
 
  

   
 
  
  
One last comment here on this topic;
   
  
For anybody who wants to discuss decentralized communication mechanisms in 
general, they can come to 
   http://www.reddit.com/r/p2pcomms;>www.reddit.com/r/p2pcomms
 (up until these decentralized forums have become stable and common).
   
  
I've seen quite a few more of these projects lately, I want to make a list of 
them and would definitely like to contribute to making them not just usable, 
but good enough to gain popularity on their own. 
   
  
(And in case you wonder about my approach to moderation: let every user pick 
which moderators / filters / servers he trusts, and let them share their 
subscription preferences in place of sharing links to centralized forums.) 
   
  
- Sent from my phone
   
  
 Den 31 aug 2015 10:45 skrev "NxtChg via bitcoin-dev" < 
   mailto:bitcoin-dev@lists.linuxfoundation.org;>bitcoin-dev@lists.linuxfoundation.org>:
 
   
 


 >I am creating a de-centralized forum, and I mean truly decentralized as I nor 
 >anyone else will be able to control it. 

 

 Zander is working on the same thing: 
https://www.reddit.com/r/AetheralResearch/;>https://www.reddit.com/r/AetheralResearch/
 

 

 But it's actually quite difficult to make it truly censorship-resistant: both 
in solving the theymos factor and spam/abuse/overloading as an attack. 

 

 

 >There is no doubt that the centralization and censorship of the Bitcoin 
 >community is massively inhibiting the advance of Bitcoin 

 >and also the growth of the Bitcoin economy. We are scaring away 
 >intellectuals, businessman, and newbies that are just getting started. 

 

 We have /r/bitcoinxt and so far it has been great. But we also need a regular 
forum. 

 

 Roger Ver controls 
http://bitcoin.com;>bitc

[bitcoin-dev] AT has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box

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

Re: [bitcoin-dev] Censorship

[Zach G via bitcoin-dev]

 When I say de-centralized I mean it, all the things you listed are 
centralized. Reddit is actually a purely centralized system and just as 
unhealthy as the current bitcoin forum. We have the technology, I'm simply 
putting together the pieces that other people have already built. This forum 
will literally be uncontrollable in raw form, once it's unleashed it can't be 
stopped. It will exist on thousands of computers so it cannot be destroyed, it 
will not be centrally hosted. 

I expect users to create their own external software to parse the data, so 
people can centralize as much or as little as they want in their own 
'sub-forums' built on this system. I will be releasing some very rudimentary 
external software/website to go along with this de-centralized system just so 
people can post and read what's posted, and will worry about the finer details 
at a later time.

There will be various leaders who utilize this program and organize quality 
forums, but fundamentally the raw de-centralized system cannot be controlled, 
so people posting to it will always have a venue to speak without being 
censored.

I actually started this project to create a journal of uncensored scientific 
research, but it didn't take long to realize this sort've thing is useful for 
pretty much everyone, so I'm rushing the basic release out. Then I will work on 
making my science journal 'sub-forum' software and everyone else can do 
whatever they want. 

 

 

-Original Message-
From: NxtChg 
To: hurricanewarn1 ; bitcoin-dev 

Sent: Mon, Aug 31, 2015 4:45 am
Subject: Re: [bitcoin-dev] Censorship



>I am creating a de-centralized forum, and I mean truly decentralized as I nor
anyone else will be able to control it.

Zander is working on the same thing:
https://www.reddit.com/r/AetheralResearch/

But it's actually quite difficult
to make it truly censorship-resistant: both in solving the theymos factor and
spam/abuse/overloading as an attack.


>There is no doubt that the
centralization and censorship of the Bitcoin community is massively inhibiting
the advance of Bitcoin 
>and also the growth of the Bitcoin economy. We are
scaring away intellectuals, businessman, and newbies that are just getting
started.

We have /r/bitcoinxt and so far it has been great. But we also need
a regular forum.

Roger Ver controls bitcoin.com, as I understand?
https://bitcoin.com/forum/ would be nice.

And it must be a real community,
not "say whatever you want because free speech". We've seen how that turned out
to be.

Something like battle.net or Steam forums: heavily moderated, not for
opinions, but for spam/noise/insults.

Again, this needs leadership. Anyone
can install a forum software, what is needed is an "official seal of approval"
and regular presence of top XT people there.

And a will to setup proper
moderation. Then people will move.


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

Re: [bitcoin-dev] Censorship

[Zach G via bitcoin-dev]

The de-centralized forum directly integrates the Bitcoin blockchain with every 
post. I can see how you misunderstood since I wasn't specific in my first 
email. I'm surprised no one has done this yet, people have done things very 
similar but never took the leap to integrate the actual Bitcoin blockchain. 
Basically http://cryptograffiti.info/ but with a parallel program that stores 
most of the data in a hash reference table, and shares that data via a 
torrent-esque system.
 
  The Bitcoin of thoughts.
 

 

-Original Message-
From: Natanael 
To: NxtChg 
Cc: bitcoin-dev ; hurricanewarn1 

Sent: Mon, Aug 31, 2015 7:46 am
Subject: Re: [bitcoin-dev] Censorship


 
One last comment here on this topic;
  
For anybody who wants to discuss decentralized communication mechanisms in 
general, they can come to www.reddit.com/r/p2pcomms (up until these 
decentralized forums have become stable and common).
  
I've seen quite a few more of these projects lately, I want to make a list of 
them and would definitely like to contribute to making them not just usable, 
but good enough to gain popularity on their own. 
  
(And in case you wonder about my approach to moderation: let every user pick 
which moderators / filters / servers he trusts, and let them share their 
subscription preferences in place of sharing links to centralized forums.) 
  
- Sent from my phone
  
Den 31 aug 2015 10:45 skrev "NxtChg via bitcoin-dev" <  
bitcoin-dev@lists.linuxfoundation.org>:  
  
   
 >I am creating a de-centralized forum, and I mean truly decentralized as I nor 
 >anyone else will be able to control it.   

 Zander is working on the same thing:
https://www.reddit.com/r/AetheralResearch/   

 But it's actually quite difficult to make it truly censorship-resistant: both 
in solving the theymos factor and spam/abuse/overloading as an attack.   


 >There is no doubt that the centralization and censorship of the Bitcoin 
 >community is massively inhibiting the advance of Bitcoin   
 >and also the growth of the Bitcoin economy. We are scaring away 
 >intellectuals, businessman, and newbies that are just getting started.   

 We have /r/bitcoinxt and so far it has been great. But we also need a regular 
forum.   

 Roger Ver controlsbitcoin.com, as I understand?
https://bitcoin.com/forum/ would be nice.   

 And it must be a real community, not "say whatever you want because free 
speech". We've seen how that turned out to be.   

 Something likebattle.net or Steam forums: heavily moderated, not for 
opinions, but for spam/noise/insults.   

 Again, this needs leadership. Anyone can install a forum software, what is 
needed is an "official seal of approval" and regular presence of top XT people 
there.   

 And a will to setup proper moderation. Then people will move.   

 ___   
 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