[Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Given the recent news about Chainanalysis
(https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/),
and other companies who are disrupting the Bitcoin network
(https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_unrelated_thread_a_bitcoin_dev_claimed/copzt3x)
it might be worth reviewing the terms of the Computer Fraud and Abuse
Act and similar legislation in other countries.

Although it's not possible to stop network attacks by making them
illegal, it's certainly possible to stop traditionally funded
companies from engaging in that activity. Note there exist no
VC-funded DDoS as a service companies operating openly.

It's also worth discussing ways to make the responsibilities of
network peers more explicit in the protocol, so that when an entity
decides to access the network for purposes other than for what full
node operators made connection slots available that behavior will be a
more obvious violation of various anti-hacking laws.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJVA0IFAAoJECpf2nDq2eYjp0IP+wVsW69xOpFIX4yRTHrEQYh7
MCPM7OTkIay/O13TSewbxTRPww9Z6vOpmrDkFlWGYKyrLWyqUGwcKqOscE8r3P3U
xdV5ACppol5HXra/bykxuaXJWF/yTM7PybFNQ2Ary0X41CFrOUITsO8SwWDl8jBu
GtRgbWdALA6IQeeRLVQmMo3zC/uShOplOh/HrS2z9ZtXSm3rNkLzhnUWfznbixb0
9C1yvIM5VOwoNcRKt7uoX6cl4mFsBO3Gfjz4rr5gABerTltBlRk4c3jnUDUlQiFC
cppX9eaEYMLR7y0gHWnmzWcFW7LFwMR2isyJ79O2cpUpYNzbfp0fWetM1WVAMFSK
7hyUlwVx4WgaVRT5hDb6QPHHvzCYjYq+19+9/uChh9P3s3QkKuFJUVYwHQ+wnruK
hPS3/vb7Tmt1eLTUeno4RRyJJ7likHsNA2bxWSG9rDezTownkSVZe2BQh3GIZOBg
H8Nu2IDWK4pHJaCiswW4jfDsucuYiP7978p8ZFbZbymeflsXz1qyUHSVm9kngfZn
sYUK4rgRsdrPpong0nqlmWcQW3VgmNO1tw5gmUqWTxQLnrCxgqnSdT7srzAw1ZaS
YIAaB1rBy8k7QyDCOyIsIV+n1H26ZBa8PrqdRExlz6PuWcywjuEbcIfEl9QSURA+
pLuNJ+uQN+JBjKokmaSQ
=ZO1/
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

That would be rather new and tricky legal territory.

But even putting the legal issues to one side, there are definitional
issues.

For instance if the Chainalysis nodes started following the protocol specs
better and became just regular nodes that happen to keep logs, would that
still be a violation? If so, what about blockchain.info? It'd be shooting
ourselves in the foot to try and forbid block explorers given how useful
they are.

If someone non-maliciously runs some nodes with debug logging turned on,
and makes full system backups every night, and keeps those backups for
years, are they in violation of whatever pseudo-law is involved?

I think it's a bit early to think about these things right now. Michael
Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
interested to know their thoughts on all of this.

[-- Attachment #2: Type: text/html, Size: 1208 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2015 04:48 PM, Mike Hearn wrote:
> That would be rather new and tricky legal territory.
> 
> But even putting the legal issues to one side, there are
> definitional issues.
> 
> For instance if the Chainalysis nodes started following the
> protocol specs better and became just regular nodes that happen to
> keep logs, would that still be a violation? If so, what about
> blockchain.info? It'd be shooting ourselves in the foot to try and
> forbid block explorers given how useful they are.

I'm not talking about keeping logs, I mean purporting to be a network
peer in order to gain a connection slot and then not behaving as one
(not relaying transactions), thereby depriving the peers to which
operator actually intends to offer service of the ability to connect.

That someone wants to run a large number of nodes in order to make
their own logs more saleable, does not mean they are entitled to break
the protocol to make other node operators subsidize their log collection.

Especially if a data collection company is deploying nodes that do not
relay and aggressively reconnect after a ban, it seems like they'd
have a hard time arguing that they were not knowingly exceeding
authorized access.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJVA16sAAoJECpf2nDq2eYjxsUP/3ASGcsdGR8IEO7Fk8VghuVp
jwIIM8Bu/WsoWKG76GhuPKs/qC0VC6GXKpGUBVy7bF8uwdhfdSXcyld9MIzIENJF
I0wMX6B3SjqQG/g0rNZ91Dh3xKIF39/TQdDERM3yiQi1oavAc5TPLReN9ZbyRcVw
vCfPWorTvrad5INCn/krcEopbI013aW2ryWnkN6sFGinF5Yf4xhrNQbQeGbhlH15
/XUIBva6/PbUs4HaC+wqJPSUfB4OmcP1ZfXMuPDEmKEWdI+3WqUYF4sNAVOke560
+RL5qMJIxSUMYMAb3p+025Fn6WOc2wupQzpH/ISkuaI+5+ne54Mx/ZHJg7Z7inov
WMKfiUS6R8EHrY8IoNpO9uNqsgC+y0vlU3ELqu+gOhFTpMK7pVX2aAek8Qe7hSHy
GwtG5U6AFubLqyzP9/pBJHnmDG71brsKffAXOePDjXWfLfhy78aeQ3HOnzVhv9QK
snmE2C6Ex/tQDUwT9MKTdw59Hy7E7GdQlSPH+MYQKUBlkpWLDGpi7oriBRwvEy4/
NJCJU9+x7jijD7vrjBE+LSYdIQoZqE240N6teWqVc2wRPM8g+e+kSQqfjdKQdiQY
waeKHBKerqRq2EGffeJWV1RIEFtFND1l8zw/5ZQF4w959zLvhk/QPHzxKyTbCM2f
3DOgEWCJFLsNzpPQ8es2
=MV9D
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

>
> I'm not talking about keeping logs, I mean purporting to be a network
> peer in order to gain a connection slot and then not behaving as one
> (not relaying transactions)


That definition would include all SPV clients?

I get what you are trying to do. It just seems extremely tricky.

[-- Attachment #2: Type: text/html, Size: 539 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2015 05:08 PM, Mike Hearn wrote:
> 
> That definition would include all SPV clients?

Don't SPV clients announce their intentions by the act of uploading a
filter?

> I get what you are trying to do. It just seems extremely tricky.

Certainly the protocol could be designed in a way that provides
finer-grained access controls and connection limits, which would make
the situation more clear.

What I'd actually like to see is for network users to pay for the node
resources that they consume, so that anyone who wants to place
increased load on the network would compensate node operators for the
burden:

http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/

Absent that kind of comprehensive solution, problems like this will
continue to recur.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJVA2HLAAoJECpf2nDq2eYjcvYP/iqYBxboMmTPLp9Kx3GlBdR/
IPtCxVoaZQkqrAHlbbED1YHoI7QqaufdPMb9mw8bErFX7E89u4gD93jvx2x+skqW
KtqIyc5fHe4MgbtGypvE5GjSiqZZIqn7EYzLGVE5ydmO4SKpfodXIIRuQRkZ1fTG
j0ovFc/bmigS7Cvf3gsMT5oW26IcEaH6mAZ/YU5oVEi1LGff8hUTq90uddOCpoqp
mIj8MHMdd0yvtihjLwyJPdfT0qTOkbAxHJqwPLoOWzmrN0z1PbU9qcf0aHdDnMlT
+jWHqHzSxjwyB1bmUhi6vZKVFfd1moOTI3BBj+Jqjc+xaOmXCcyAtpfzq97VITZw
qhAnYM4unsC0A1GH3fQEJPvoOy0kwyNNtI7z5YOrRJtihCpFSbtULqN9DUmxwgKL
/0cmOc2SyjgflTiCejazBIJk4Ie+WcV2cbgepdX8USb0tusQs+jn2HMFGUfxywTz
riy9Ex8Wftl12LAYXSbMQl7GnADYG9t0HIY3JqPAhAzEdPynXUduveatiQyNc6SH
IqXraTgHj6IFFWB7eLjWuIleyxcFC81qTFNUYxEajGDLbCX00emKiR3RUpVZ/wP7
8CXcV4zco1y1+va1eD/7eNhTW/Xuf3+KdqJs2reLq23fLV01HA92sRYbgLIxb0Yz
yBsE+PpY06vrHqoVD/4l
=Ofbb
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18667 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

>
> Don't SPV clients announce their intentions by the act of uploading a
> filter?
>

Well they don't set NODE_NETWORK, so they don't claim to be providing
network services. But then I guess the Chainalysis nodes could easily just
clear that bit flag too.


> What I'd actually like to see is for network users to pay for the node
> resources that they consume


It's not quite pay-as-you-go, but I just posted a scheme for funding of
network resources using crowdfunding contracts here:

https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064

That comment doesn't have any kind of provision for access control, but
group signatures could be extended in both directions: the server proves it
was a part of the group that was funded by the contract, and the client
proves it was in group that funded the contract, but it's done in a
(relatively) anonymous way. Then any client can use any node it funded, or
at least, buy priority access.

But it's rather complicated. I'd hope that nodes can be like email
accounts: yes they have a cost but in practice people everyone gets one for
free because of random commercial cross-subsidisation, self hosting and
other things.

[-- Attachment #2: Type: text/html, Size: 1872 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2015 05:24 PM, Mike Hearn wrote:
> Well they don't set NODE_NETWORK, so they don't claim to be
> providing network services. But then I guess the Chainalysis nodes
> could easily just clear that bit flag too.

If a peer claims to provide network services, and does not do so while
consuming another node's resources, that might be considered exceeding
authorized access.

bitcoind should probably have more fine-grained control over how it
allocates connection resources between peers vs clients.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJVA2bPAAoJECpf2nDq2eYjm/UP/0MZmdEBameT6tnLnebkru5d
UeHsX6Qikv3qF+i936SkoDylg08PJNWlpApuXC5t52x262V763y9tGV8qqh3vTSf
LeLeKY1M4mYCjHjegpz3JXzzF9i9OqgWl+0OxGOHDHyp8COfzKzC9FEUP3XBqitb
swyeS2t0LkzJnXYV8z8pDOxn4pZN0cUaKPvBIRKEUs4PgA4JVpRTM5Rvzi7oOItz
GHknxH++ja7kfFpgRSJMh3gHu4xhRiHfzGPaszrrrznpubNr42+4ouBy+QDr2XYr
1AtklROYLySeUtd0yNxeWdeaLIBSTiiDisNkD62MOTr0Zmdnc6M7IefSCqLN4fD9
wPu5a5h4HI/N/4/+kUhGmW+g5vagKMkCVlUIsG7gpGQJk4HyLElAdmgDToPJTrvr
htrd7k5HjjZu8oAt/vYcx15myuQ7VXc7v193g7m3kRRx4rnZ5XCu5BJd92uaOW1e
9ARhN7hfNQbfVkZw0f+qfG0fzMSAk3aHxpao7topwKARQfYJ++Mry5qAzFfxWred
IHXHbd4JqafsUJxTqDvm7oVP+l+XqlFkZTGi5u6NjPSeJL0IMFI5NqOepqAqwi0P
n9tePxN19+TmK2TSGtuzWBNZXcbwujSmvzRnDouxpcTyhRXc5YBbetI4/s0xcAyK
sQ2dm0SKF4S8MclylelW
=IpAp
-----END PGP SIGNATURE-----

[-- Attachment #2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 18381 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Jan Møller]

[-- Attachment #1: Type: text/plain, Size: 3992 bytes --]

What we were trying to achieve was determining the flow of funds between
countries by figuring out which country a transaction originates from.
To do that with a certain accuracy you need many nodes. We chose a class C
IP range as we knew that bitcoin core and others only connect to one node
in any class C IP range. We were not aware that breadwallet didn't follow
this practice. Breadwallet risked getting tar-pitted, but that was not our
intention and we are sorry about that.

Our nodes DID respond with valid blocks and merkle-blocks and allowed
everyone connecting to track the blockchain. We did however not relay
transactions. The 'service' bit in the version message is not meant for
telling whether or how the node relays transactions, it tells whether you
can ask for block headers only or full blocks.

Many implementations enforce non standard rules for handling transactions;
some nodes ignore transactions with address reuse, some nodes happily
forward double spends, and some nodes forward neither blocks not
transactions. We did blocks but not transactions.

In hindsight we should have done two things:
1. relay transactions
2. advertise address from 'foreign' nodes

Both would have fixed the problems that breadwallet experienced. My
understanding is that breadwallet now has the same 'class C' rule as
bitcoind, which would also fix it.

Getting back on the topic of this thread and whether it is illegal, your
guess is as good as mine. I don't think it is illegal to log incoming
connections and make statistical analysis on it. That would more or less
incriminate anyone who runs a web-server and looks into the access log.
At lease one Bitcoin service has been collecting IP addresses for years and
given them to anyone visiting their web-site (you know who) and I believe
that this practise is very wrong. We have no intention of giving IP
addresses away to anyone, but we believe that you are free to make
statistics on connection logs when nodes connect to you.

On a side note: When you make many connections to the network you see lots
of strange nodes and suspicious patterns. You can be certain that we were
not the only ones connected to many nodes.

My takeaway from this: If nodes that do not relay transactions is a problem
then there is stuff to fix.

/Jan

On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net> wrote:

> That would be rather new and tricky legal territory.
>
> But even putting the legal issues to one side, there are definitional
> issues.
>
> For instance if the Chainalysis nodes started following the protocol specs
> better and became just regular nodes that happen to keep logs, would that
> still be a violation? If so, what about blockchain.info? It'd be shooting
> ourselves in the foot to try and forbid block explorers given how useful
> they are.
>
> If someone non-maliciously runs some nodes with debug logging turned on,
> and makes full system backups every night, and keeps those backups for
> years, are they in violation of whatever pseudo-law is involved?
>
> I think it's a bit early to think about these things right now. Michael
> Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
> interested to know their thoughts on all of this.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5062 bytes --]

[Bitcoin-development] "network disruption as a service" and proof of local storage

[Sergio Lerner]

The problem of pseudo-nodes will come over and over. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage here:
https://bitcointalk.org/index.php?topic=310323.msg3332919#msg3332919

I proposed a (what I think) is better protocol for Proof of Storage that
I call "Proof of Local storage" here
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
. It's better because it does not need the storage of additional data,
but more importantly, it allows you to prove full copy of the blockchain
is being maintained by the peer.
This is specially important now that Bitnodes is trying a full-node
incentive program that may be easily cheated
(http://qntra.net/2015/02/pseudonode-proxy-fools-bitcoin-full-node-incentive-program/)

Proof of local storage allows a node to prove another peer that he is
storing a LOCAL copy of a PUBLIC file, such as the blockchain. So the
peer need not waste more resources (well, just some resources to
encode/decode the block-chain).
The main idea is to use what I called asymmetric-time-encoding.
Basically you encode the block-chain in a way that it takes 100 more
times to write it than to read it. Since the block-chain is an
append-only (write-only) file, this fit good for our needs. For instance
(and as a simplification), choosing a global 1024-bit prime, then
splitting the block-chain in 1024-bit blocks, and encrypting each block
using Polihg-Hellman (modexp) with decryption exponent 3.  Then
encryption is at least 100 times slower than decryption. Before PH
encryption each node must xor each block with a pseudo-random mask
derived from the public IP and the block index.  So block encryption
could be: 
BlockEncryptIndex(i) = E(IP+i,block(i))^inv(3) (mod p),

where inv(3) is 3^-1 mod (p-1). E() could be a fast tweaked encryption
routine (tweak = index), but we only need the PRNG properties of E() and
that E() does share algebraic properties with P.H..

Two protocols can be performed to prove local possession:
1. (prover and verifier pay a small cost) The verifier sends a seed to
derive some n random indexes, and the prover must respond with the hash
of the decrypted blocks within a certain time bound. Suppose that
decryption of n blocks take 100 msec (+-100 msec of network jitter).
Then an attacker must have a computer 50 faster to be able to
consistently cheat. The last 50 blocks should not be part of the list to
allow nodes to catch-up and encrypt the blocks in background.

2. (prover pay a high cost, verified pays negligible cost). The verifier
chooses a seed n, and then pre-computes the encrypted blocks derived
from the seed using the prover's IP. Then the verifier sends the  seed,
and the prover must respond with the hash of the encrypted blocks within
a certain time bound. The proved does not require to do any PH
decryption, just take the encrypted blocks for indexes derived from the
seed, hash them and send the hash back to the verifier. The verifier
validates the time bound and the hash.

Both protocols can me made available by the client, under different
states. For instance, new nodes are only allowed to request protocol 2
(and so they get an initial assurance their are connecting to
full-nodes). After a first-time mutual authentication, they are allowed
to periodically perform protocol 1. Also new nodes may be allowed to
perform protocol 1 with a small index set, and increase the index set
over time, to get higher confidence.

The important difference between this protocol and classical remote
software attestation protocols, is that the time gap between a good peer
and a malicious peer can be made arbitrarily high, picking a larger p.
Maybe there is even another crypto primitive which is more asymmetric
than exponent 3 decryption (the LUC or NTRU cryptosystem?).

In GMaxwell proposal each peer builds a table for each other peer. In my
proposal, each peer builds a single table (the encrypted blockchain), so
it could be still possible to establish a thousands of connections to
the network from a single peer. Nevertheless, the attacker's IP will be
easily detected (he cannot hide under a thousands different IPs). It's
also possible to restrict the challenge-response to a portion of the
block-chain, the portion offset being derived from the hash of both IP
addresses and one random numbers provided by each peer. Suppose each
connection has a C-R space equivalent to 1% of the block-chain. Then
having 100 connections and responding to C-R on each connection means
storing approximate 1 copy of the block-chain (there may be overlaps,
which would need to be stored twice) , while having 1K connections would
require storing 10 copies of the blockchain.


Best regards,
 Sergio

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 5396 bytes --]

Thanks Jan, we added several additional checks for non-standard protocol
responses, and also made the client revert to DNS seeding more quickly if
it runs into trouble, so it's now more robust against sybil/DOS attack. I
mentioned in the coindesk article that I didn't think what your nodes were
doing was intended to be malicious with respect to network disruption. It's
our job to better handle non-standard or even malicious behavior from
random p2p nodes.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Mon, Mar 16, 2015 at 1:44 AM, Jan Møller <jan.moller@gmail.com> wrote:

> What we were trying to achieve was determining the flow of funds between
> countries by figuring out which country a transaction originates from.
> To do that with a certain accuracy you need many nodes. We chose a class C
> IP range as we knew that bitcoin core and others only connect to one node
> in any class C IP range. We were not aware that breadwallet didn't follow
> this practice. Breadwallet risked getting tar-pitted, but that was not our
> intention and we are sorry about that.
>
> Our nodes DID respond with valid blocks and merkle-blocks and allowed
> everyone connecting to track the blockchain. We did however not relay
> transactions. The 'service' bit in the version message is not meant for
> telling whether or how the node relays transactions, it tells whether you
> can ask for block headers only or full blocks.
>
> Many implementations enforce non standard rules for handling transactions;
> some nodes ignore transactions with address reuse, some nodes happily
> forward double spends, and some nodes forward neither blocks not
> transactions. We did blocks but not transactions.
>
> In hindsight we should have done two things:
> 1. relay transactions
> 2. advertise address from 'foreign' nodes
>
> Both would have fixed the problems that breadwallet experienced. My
> understanding is that breadwallet now has the same 'class C' rule as
> bitcoind, which would also fix it.
>
> Getting back on the topic of this thread and whether it is illegal, your
> guess is as good as mine. I don't think it is illegal to log incoming
> connections and make statistical analysis on it. That would more or less
> incriminate anyone who runs a web-server and looks into the access log.
> At lease one Bitcoin service has been collecting IP addresses for years
> and given them to anyone visiting their web-site (you know who) and I
> believe that this practise is very wrong. We have no intention of giving IP
> addresses away to anyone, but we believe that you are free to make
> statistics on connection logs when nodes connect to you.
>
> On a side note: When you make many connections to the network you see lots
> of strange nodes and suspicious patterns. You can be certain that we were
> not the only ones connected to many nodes.
>
> My takeaway from this: If nodes that do not relay transactions is a
> problem then there is stuff to fix.
>
> /Jan
>
> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> That would be rather new and tricky legal territory.
>>
>> But even putting the legal issues to one side, there are definitional
>> issues.
>>
>> For instance if the Chainalysis nodes started following the protocol
>> specs better and became just regular nodes that happen to keep logs, would
>> that still be a violation? If so, what about blockchain.info? It'd be
>> shooting ourselves in the foot to try and forbid block explorers given how
>> useful they are.
>>
>> If someone non-maliciously runs some nodes with debug logging turned on,
>> and makes full system backups every night, and keeps those backups for
>> years, are they in violation of whatever pseudo-law is involved?
>>
>> I think it's a bit early to think about these things right now. Michael
>> Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
>> interested to know their thoughts on all of this.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7142 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

If you (e.g. Chainalysis) or anyone else are doing surveillance on the
network and gathering information for later use, and whether or not
the ultimate purpose is to divulge it to other parties for compliance
purposes, you can bet that ultimately the tables will be turned on
you, and you will be the one having your ass handed to you so to
speak, before or after you are served, in legal parlance.  Whether or
not the outcome of that is meaningful and beneficial to any concerned
parties and what is the upshot of it in the end depends on on what you
do and just how far you decide to take your ill-advised enterprise.

Chainalysis and similar operations would be, IMHO, well advised to
cease operations.  This doesn't mean they will, but guess what:

Shot over the bow, folks.

Jan Møller:
> What we were trying to achieve was determining the flow of funds
> between countries by figuring out which country a transaction
> originates from. To do that with a certain accuracy you need many
> nodes. We chose a class C IP range as we knew that bitcoin core and
> others only connect to one node in any class C IP range. We were
> not aware that breadwallet didn't follow this practice. Breadwallet
> risked getting tar-pitted, but that was not our intention and we
> are sorry about that.
> 
> Our nodes DID respond with valid blocks and merkle-blocks and
> allowed everyone connecting to track the blockchain. We did however
> not relay transactions. The 'service' bit in the version message is
> not meant for telling whether or how the node relays transactions,
> it tells whether you can ask for block headers only or full
> blocks.
> 
> Many implementations enforce non standard rules for handling
> transactions; some nodes ignore transactions with address reuse,
> some nodes happily forward double spends, and some nodes forward
> neither blocks not transactions. We did blocks but not
> transactions.
> 
> In hindsight we should have done two things: 1. relay transactions 
> 2. advertise address from 'foreign' nodes
> 
> Both would have fixed the problems that breadwallet experienced.
> My understanding is that breadwallet now has the same 'class C'
> rule as bitcoind, which would also fix it.
> 
> Getting back on the topic of this thread and whether it is illegal,
> your guess is as good as mine. I don't think it is illegal to log
> incoming connections and make statistical analysis on it. That
> would more or less incriminate anyone who runs a web-server and
> looks into the access log. At lease one Bitcoin service has been
> collecting IP addresses for years and given them to anyone visiting
> their web-site (you know who) and I believe that this practise is
> very wrong. We have no intention of giving IP addresses away to
> anyone, but we believe that you are free to make statistics on
> connection logs when nodes connect to you.
> 
> On a side note: When you make many connections to the network you
> see lots of strange nodes and suspicious patterns. You can be
> certain that we were not the only ones connected to many nodes.
> 
> My takeaway from this: If nodes that do not relay transactions is a
> problem then there is stuff to fix.
> 
> /Jan
> 
> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net>
> wrote:
> 
>> That would be rather new and tricky legal territory.
>> 
>> But even putting the legal issues to one side, there are
>> definitional issues.
>> 
>> For instance if the Chainalysis nodes started following the
>> protocol specs better and became just regular nodes that happen
>> to keep logs, would that still be a violation? If so, what about
>> blockchain.info? It'd be shooting ourselves in the foot to try
>> and forbid block explorers given how useful they are.
>> 
>> If someone non-maliciously runs some nodes with debug logging
>> turned on, and makes full system backups every night, and keeps
>> those backups for years, are they in violation of whatever
>> pseudo-law is involved?
>> 
>> I think it's a bit early to think about these things right now.
>> Michael Grønager and Jan Møller have been Bitcoin hackers for a
>> long time. I'd be interested to know their thoughts on all of
>> this.
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development,
>> from weekly thought leadership blogs to news, videos, case
>> studies, tutorials and more. Take a look and join the 
>> conversation now. http://goparallel.sourceforge.net/ 
>> _______________________________________________ 
>> Bitcoin-development mailing list 
>> Bitcoin-development@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

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

iQEcBAEBCgAGBQJVD34mAAoJEGxwq/inSG8CvrQH/28Rt26oGdo9rS+PaR1fIQ1p
Jwks11Axsmu5x3emTgIz0xUJ6zz/4ERM0LeNLBpfSFwZyLbuCgw1uiJplT+9uPgY
hPXb9OTNejfWZJjYc3i6rNjf2SNc5E3/4PtgeOI6lI/SsGQ6ineNm6gFjwe8xVpt
wCLOPetzCukQegXluFZZdALnPDf4H9yAeSsrfX2h2iCBAJ3qd9f1DP7+e6hvr+xr
POVBjlRYtnSd/viKJ2IhMbRvnqd86pRNAKEWrjZp0CIkGyY7wh4nqtYErZi4TcOK
H7yhU8o4/mgTNSIYdLTOSMlRi+nTMPWUD2jvO/Z9i9VTR9afn8E7j7iHD6QPMB0=
=vdbG
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Jeremy Spilman]

On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner  
<sergiolerner@certimix.com> wrote:
> I proposed a (what I think) is better protocol for Proof of Storage that
> I call "Proof of Local storage" here
> https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/

Thanks so much for publishing this. It could be useful in any application  
to try to prove a keyed copy of some data.

If I understand correctly, transforming raw blocks to keyed blocks takes  
512x longer than transforming keyed blocks back to raw. The key is public,  
like the IP, or some other value which perhaps changes less frequently.

The verifier keeps blocks in the keyed format, and can decrypt quickly to  
provide raw data, or use the keyed data for hashing to try to demonstrate  
they have a pre-keyed copy.

>
> Two protocols can be performed to prove local possession:
> 1. (prover and verifier pay a small cost) The verifier sends a seed to
> derive some n random indexes, and the prover must respond with the hash
> of the decrypted blocks within a certain time bound. Suppose that
> decryption of n blocks take 100 msec (+-100 msec of network jitter).
> Then an attacker must have a computer 50 faster to be able to
> consistently cheat. The last 50 blocks should not be part of the list to
> allow nodes to catch-up and encrypt the blocks in background.
>

Can you clarify, the prover is hashing random blocks of *decrypted*, as-in  
raw, blockchain data? What does this prove other than, perhaps, fast  
random IO of the blockchain? (which is useful in its own right, e.g. as a  
way to ensure only full-node IO-bound mining if baked into the PoW)

How is the verifier validating the response without possession of the full  
blockchain?

> 2. (prover pay a high cost, verified pays negligible cost). The verifier
> chooses a seed n, and then pre-computes the encrypted blocks derived
> from the seed using the prover's IP. Then the verifier sends the  seed,
> and the prover must respond with the hash of the encrypted blocks within
> a certain time bound. The proved does not require to do any PH
> decryption, just take the encrypted blocks for indexes derived from the
> seed, hash them and send the hash back to the verifier. The verifier
> validates the time bound and the hash.

The challenger requests a hash-sum of a random sequence of indices of the  
keyed data, based on a challenge seed. So in a few bytes round-trip we can  
see how fast the computation is completed. If the data is already keyed,  
the hash of 1,000 random 1024-bit blocks should come back much faster than  
if the data needs to be keyed on-the-fly.

To verify the response, the challenger would have to use the peer's  
identity key and perform the slower transforms on those same 1,000 blocks  
and see that the result matches, so cost to challenger is higher than  
prover, assuming they actually do the computation.

Which brings up a good tweak, a full-node challenger could have to do the  
computation first, then also include something like HMAC(identityKey,  
expectedResult). The prover could then know if the challenger was honest  
before returning a result, and blacklist them if not.

>
> Both protocols can me made available by the client, under different
> states. For instance, new nodes are only allowed to request protocol 2
> (and so they get an initial assurance their are connecting to
> full-nodes). After a first-time mutual authentication, they are allowed
> to periodically perform protocol 1. Also new nodes may be allowed to
> perform protocol 1 with a small index set, and increase the index set
> over time, to get higher confidence.

I guess a new-node could see if different servers all returned the same  
challenge response, but they would have no way to know if the challenge  
response was technically correct, or sybil.

I also wonder about the effect of spinning disk versus SSD. Seek time for  
1,000 random reads is either nearly zero or dominating depending on the  
two modes. I wonder if a sequential read from a random index is a possible  
trade-off,; it doesn't prove possession of the whole chain nearly as well,  
but at least iowait converges significantly. Then again, that presupposes  
a specific ordering on disk which might not exist. In X years it will all  
be solid-state, so eventually it's moot.

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Sergio Lerner]

> If I understand correctly, transforming raw blocks to keyed blocks
> takes 512x longer than transforming keyed blocks back to raw. The key
> is public, like the IP, or some other value which perhaps changes less
> frequently.
>
Yes. I was thinking that the IP could be part of a first layer of
encryption done to the blockchain data prior to the asymetric operation.
That way the asymmetric operation can be the same for all users (no
different primers for different IPs, and then the verifiers does not
have to verify that a particular p is actually a pseudo-prime suitable
for P.H. ) and the public exponent can be just 3.

>
>> Two protocols can be performed to prove local possession:
>> 1. (prover and verifier pay a small cost) The verifier sends a seed to
>> derive some n random indexes, and the prover must respond with the hash
>> of the decrypted blocks within a certain time bound. Suppose that
>> decryption of n blocks take 100 msec (+-100 msec of network jitter).
>> Then an attacker must have a computer 50 faster to be able to
>> consistently cheat. The last 50 blocks should not be part of the list to
>> allow nodes to catch-up and encrypt the blocks in background.
>>
>
> Can you clarify, the prover is hashing random blocks of *decrypted*,
> as-in raw, blockchain data? What does this prove other than, perhaps,
> fast random IO of the blockchain? (which is useful in its own right,
> e.g. as a way to ensure only full-node IO-bound mining if baked into
> the PoW)
>
> How is the verifier validating the response without possession of the
> full blockchain?

You're right, It is incorrect. Not the decrypted blocks must be sent,
but the encrypted blocks. There correct protocol is this:

1. (prover and verifier pay a small cost) The verifier sends a seed to
derive some n random indexes, and the prover must respond with the the
encrypted blocks within a certain time bound. The verifier decrypts
those blocks to check if they are part of the block-chain.

But then there is this improvement which allows the verifier do detect
non full-nodes with much less computation:

3. (prover pays a small cost, verifier smaller cost) The verifier asks
the prover to send a Merkle tree root of hashes of encrypted blocks with
N indexes selected by a psudo-random function seeded by a challenge
value, where each encrypted-block is previously prefixed with the seed
before being hashed (e.g. N=100). The verifier receives the Markle Root
and performs a statistical test on the received information. From the N
hashes blocks, it chooses M < N (e.g. M = 20), and asks the proved for
the blocks at these indexes. The prover sends the blocks, the verifier
validates the blocks by decrypting them and also verifies that the
Merkle tree was well constructed for those block nodes. This proves with
high probability that the Merkle tree was built on-the-fly and
specifically for this challenge-response protocol.

> I also wonder about the effect of spinning disk versus SSD. Seek time
> for 1,000 random reads is either nearly zero or dominating depending
> on the two modes. I wonder if a sequential read from a random index is
> a possible trade-off,; it doesn't prove possession of the whole chain
> nearly as well, but at least iowait converges significantly. Then
> again, that presupposes a specific ordering on disk which might not
> exist. In X years it will all be solid-state, so eventually it's moot.
>
Good idea.

Also we don't need that every node implements the protocol, but only
nodes that want to prove full-node-ness, such as the ones which want to
receive bitnodes subsidy.

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Matt Whitlock]

Maybe I'm overlooking something, but I've been watching this thread with increasing skepticism at the complexity of the offered solution. I don't understand why it needs to be so complex. I'd like to offer an alternative for your consideration...

Challenge:
"Send me: SHA256(SHA256(concatenation of N pseudo-randomly selected bytes from the block chain))."

Choose N such that it would be infeasible for the responding node to fetch all of the needed blocks in a short amount of time. In other words, assume that a node can seek to a given byte in a block stored on local disk much faster than it can download the entire block from a remote peer. This is almost certainly a safe assumption.

For example, choose N = 1024. Then the proving node needs to perform 1024 random reads from local disk. On spinning media, this is likely to take somewhere on the order of 15 seconds. Assuming blocks are averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of data. Can 500 MiB be downloaded in 15 seconds? This data transfer rate is 280 Mbps. Almost certainly not possible. And if it is, just increase N. The challenge also becomes more difficult as average block size increases.

This challenge-response protocol relies on the lack of a "partial getdata" command in the Bitcoin protocol: a node cannot ask for only part of a block; it must ask for an entire block. Furthermore, nodes could ban other nodes for making too many random requests for blocks.


On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote:
> 
> > If I understand correctly, transforming raw blocks to keyed blocks
> > takes 512x longer than transforming keyed blocks back to raw. The key
> > is public, like the IP, or some other value which perhaps changes less
> > frequently.
> >
> Yes. I was thinking that the IP could be part of a first layer of
> encryption done to the blockchain data prior to the asymetric operation.
> That way the asymmetric operation can be the same for all users (no
> different primers for different IPs, and then the verifiers does not
> have to verify that a particular p is actually a pseudo-prime suitable
> for P.H. ) and the public exponent can be just 3.
> 
> >
> >> Two protocols can be performed to prove local possession:
> >> 1. (prover and verifier pay a small cost) The verifier sends a seed to
> >> derive some n random indexes, and the prover must respond with the hash
> >> of the decrypted blocks within a certain time bound. Suppose that
> >> decryption of n blocks take 100 msec (+-100 msec of network jitter).
> >> Then an attacker must have a computer 50 faster to be able to
> >> consistently cheat. The last 50 blocks should not be part of the list to
> >> allow nodes to catch-up and encrypt the blocks in background.
> >>
> >
> > Can you clarify, the prover is hashing random blocks of *decrypted*,
> > as-in raw, blockchain data? What does this prove other than, perhaps,
> > fast random IO of the blockchain? (which is useful in its own right,
> > e.g. as a way to ensure only full-node IO-bound mining if baked into
> > the PoW)
> >
> > How is the verifier validating the response without possession of the
> > full blockchain?
> 
> You're right, It is incorrect. Not the decrypted blocks must be sent,
> but the encrypted blocks. There correct protocol is this:
> 
> 1. (prover and verifier pay a small cost) The verifier sends a seed to
> derive some n random indexes, and the prover must respond with the the
> encrypted blocks within a certain time bound. The verifier decrypts
> those blocks to check if they are part of the block-chain.
> 
> But then there is this improvement which allows the verifier do detect
> non full-nodes with much less computation:
> 
> 3. (prover pays a small cost, verifier smaller cost) The verifier asks
> the prover to send a Merkle tree root of hashes of encrypted blocks with
> N indexes selected by a psudo-random function seeded by a challenge
> value, where each encrypted-block is previously prefixed with the seed
> before being hashed (e.g. N=100). The verifier receives the Markle Root
> and performs a statistical test on the received information. From the N
> hashes blocks, it chooses M < N (e.g. M = 20), and asks the proved for
> the blocks at these indexes. The prover sends the blocks, the verifier
> validates the blocks by decrypting them and also verifies that the
> Merkle tree was well constructed for those block nodes. This proves with
> high probability that the Merkle tree was built on-the-fly and
> specifically for this challenge-response protocol.
> 
> > I also wonder about the effect of spinning disk versus SSD. Seek time
> > for 1,000 random reads is either nearly zero or dominating depending
> > on the two modes. I wonder if a sequential read from a random index is
> > a possible trade-off,; it doesn't prove possession of the whole chain
> > nearly as well, but at least iowait converges significantly. Then
> > again, that presupposes a specific ordering on disk which might not
> > exist. In X years it will all be solid-state, so eventually it's moot.
> >
> Good idea.
> 
> Also we don't need that every node implements the protocol, but only
> nodes that want to prove full-node-ness, such as the ones which want to
> receive bitnodes subsidy.

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Robert McKay]

Basically the problem with that is that someone could setup a single 
full node that has the blockchain and can answer those challenges and 
then a bunch of other non-full nodes that just proxy any such challenges 
to the single full node.

Rob

On 2015-03-26 23:04, Matt Whitlock wrote:
> Maybe I'm overlooking something, but I've been watching this thread
> with increasing skepticism at the complexity of the offered solution.
> I don't understand why it needs to be so complex. I'd like to offer 
> an
> alternative for your consideration...
>
> Challenge:
> "Send me: SHA256(SHA256(concatenation of N pseudo-randomly selected
> bytes from the block chain))."
>
> Choose N such that it would be infeasible for the responding node to
> fetch all of the needed blocks in a short amount of time. In other
> words, assume that a node can seek to a given byte in a block stored
> on local disk much faster than it can download the entire block from 
> a
> remote peer. This is almost certainly a safe assumption.
>
> For example, choose N = 1024. Then the proving node needs to perform
> 1024 random reads from local disk. On spinning media, this is likely
> to take somewhere on the order of 15 seconds. Assuming blocks are
> averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of
> data. Can 500 MiB be downloaded in 15 seconds? This data transfer 
> rate
> is 280 Mbps. Almost certainly not possible. And if it is, just
> increase N. The challenge also becomes more difficult as average 
> block
> size increases.
>
> This challenge-response protocol relies on the lack of a "partial
> getdata" command in the Bitcoin protocol: a node cannot ask for only
> part of a block; it must ask for an entire block. Furthermore, nodes
> could ban other nodes for making too many random requests for blocks.
>
>
> On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote:
>>
>> > If I understand correctly, transforming raw blocks to keyed blocks
>> > takes 512x longer than transforming keyed blocks back to raw. The 
>> key
>> > is public, like the IP, or some other value which perhaps changes 
>> less
>> > frequently.
>> >
>> Yes. I was thinking that the IP could be part of a first layer of
>> encryption done to the blockchain data prior to the asymetric 
>> operation.
>> That way the asymmetric operation can be the same for all users (no
>> different primers for different IPs, and then the verifiers does not
>> have to verify that a particular p is actually a pseudo-prime 
>> suitable
>> for P.H. ) and the public exponent can be just 3.
>>
>> >
>> >> Two protocols can be performed to prove local possession:
>> >> 1. (prover and verifier pay a small cost) The verifier sends a 
>> seed to
>> >> derive some n random indexes, and the prover must respond with 
>> the hash
>> >> of the decrypted blocks within a certain time bound. Suppose that
>> >> decryption of n blocks take 100 msec (+-100 msec of network 
>> jitter).
>> >> Then an attacker must have a computer 50 faster to be able to
>> >> consistently cheat. The last 50 blocks should not be part of the 
>> list to
>> >> allow nodes to catch-up and encrypt the blocks in background.
>> >>
>> >
>> > Can you clarify, the prover is hashing random blocks of 
>> *decrypted*,
>> > as-in raw, blockchain data? What does this prove other than, 
>> perhaps,
>> > fast random IO of the blockchain? (which is useful in its own 
>> right,
>> > e.g. as a way to ensure only full-node IO-bound mining if baked 
>> into
>> > the PoW)
>> >
>> > How is the verifier validating the response without possession of 
>> the
>> > full blockchain?
>>
>> You're right, It is incorrect. Not the decrypted blocks must be 
>> sent,
>> but the encrypted blocks. There correct protocol is this:
>>
>> 1. (prover and verifier pay a small cost) The verifier sends a seed 
>> to
>> derive some n random indexes, and the prover must respond with the 
>> the
>> encrypted blocks within a certain time bound. The verifier decrypts
>> those blocks to check if they are part of the block-chain.
>>
>> But then there is this improvement which allows the verifier do 
>> detect
>> non full-nodes with much less computation:
>>
>> 3. (prover pays a small cost, verifier smaller cost) The verifier 
>> asks
>> the prover to send a Merkle tree root of hashes of encrypted blocks 
>> with
>> N indexes selected by a psudo-random function seeded by a challenge
>> value, where each encrypted-block is previously prefixed with the 
>> seed
>> before being hashed (e.g. N=100). The verifier receives the Markle 
>> Root
>> and performs a statistical test on the received information. From 
>> the N
>> hashes blocks, it chooses M < N (e.g. M = 20), and asks the proved 
>> for
>> the blocks at these indexes. The prover sends the blocks, the 
>> verifier
>> validates the blocks by decrypting them and also verifies that the
>> Merkle tree was well constructed for those block nodes. This proves 
>> with
>> high probability that the Merkle tree was built on-the-fly and
>> specifically for this challenge-response protocol.
>>
>> > I also wonder about the effect of spinning disk versus SSD. Seek 
>> time
>> > for 1,000 random reads is either nearly zero or dominating 
>> depending
>> > on the two modes. I wonder if a sequential read from a random 
>> index is
>> > a possible trade-off,; it doesn't prove possession of the whole 
>> chain
>> > nearly as well, but at least iowait converges significantly. Then
>> > again, that presupposes a specific ordering on disk which might 
>> not
>> > exist. In X years it will all be solid-state, so eventually it's 
>> moot.
>> >
>> Good idea.
>>
>> Also we don't need that every node implements the protocol, but only
>> nodes that want to prove full-node-ness, such as the ones which want 
>> to
>> receive bitnodes subsidy.
>
>
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all
> things parallel software development, from weekly thought leadership 
> blogs to
> news, videos, case studies, tutorials and more. Take a look and join 
> the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Matt Whitlock]

I agree that someone could do this, but why is that a problem? Isn't the goal of this exercise to ensure more full nodes on the network? In order to be able to answer the challenges, an entity would need to be running a full node somewhere. Thus, they have contributed at least one additional full node to the network. I could certainly see a case for a company to host hundreds of lightweight (e.g., EC2) servers all backed by a single copy of the block chain. Why force every single machine to have its own copy? All you really need to require is that each agency/participant have its own copy.


On Friday, 27 March 2015, at 2:32 pm, Robert McKay wrote:
> Basically the problem with that is that someone could setup a single 
> full node that has the blockchain and can answer those challenges and 
> then a bunch of other non-full nodes that just proxy any such challenges 
> to the single full node.
> 
> Rob
> 
> On 2015-03-26 23:04, Matt Whitlock wrote:
> > Maybe I'm overlooking something, but I've been watching this thread
> > with increasing skepticism at the complexity of the offered solution.
> > I don't understand why it needs to be so complex. I'd like to offer 
> > an
> > alternative for your consideration...
> >
> > Challenge:
> > "Send me: SHA256(SHA256(concatenation of N pseudo-randomly selected
> > bytes from the block chain))."
> >
> > Choose N such that it would be infeasible for the responding node to
> > fetch all of the needed blocks in a short amount of time. In other
> > words, assume that a node can seek to a given byte in a block stored
> > on local disk much faster than it can download the entire block from 
> > a
> > remote peer. This is almost certainly a safe assumption.
> >
> > For example, choose N = 1024. Then the proving node needs to perform
> > 1024 random reads from local disk. On spinning media, this is likely
> > to take somewhere on the order of 15 seconds. Assuming blocks are
> > averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of
> > data. Can 500 MiB be downloaded in 15 seconds? This data transfer 
> > rate
> > is 280 Mbps. Almost certainly not possible. And if it is, just
> > increase N. The challenge also becomes more difficult as average 
> > block
> > size increases.
> >
> > This challenge-response protocol relies on the lack of a "partial
> > getdata" command in the Bitcoin protocol: a node cannot ask for only
> > part of a block; it must ask for an entire block. Furthermore, nodes
> > could ban other nodes for making too many random requests for blocks.
> >
> >
> > On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote:
> >>
> >> > If I understand correctly, transforming raw blocks to keyed blocks
> >> > takes 512x longer than transforming keyed blocks back to raw. The 
> >> key
> >> > is public, like the IP, or some other value which perhaps changes 
> >> less
> >> > frequently.
> >> >
> >> Yes. I was thinking that the IP could be part of a first layer of
> >> encryption done to the blockchain data prior to the asymetric 
> >> operation.
> >> That way the asymmetric operation can be the same for all users (no
> >> different primers for different IPs, and then the verifiers does not
> >> have to verify that a particular p is actually a pseudo-prime 
> >> suitable
> >> for P.H. ) and the public exponent can be just 3.
> >>
> >> >
> >> >> Two protocols can be performed to prove local possession:
> >> >> 1. (prover and verifier pay a small cost) The verifier sends a 
> >> seed to
> >> >> derive some n random indexes, and the prover must respond with 
> >> the hash
> >> >> of the decrypted blocks within a certain time bound. Suppose that
> >> >> decryption of n blocks take 100 msec (+-100 msec of network 
> >> jitter).
> >> >> Then an attacker must have a computer 50 faster to be able to
> >> >> consistently cheat. The last 50 blocks should not be part of the 
> >> list to
> >> >> allow nodes to catch-up and encrypt the blocks in background.
> >> >>
> >> >
> >> > Can you clarify, the prover is hashing random blocks of 
> >> *decrypted*,
> >> > as-in raw, blockchain data? What does this prove other than, 
> >> perhaps,
> >> > fast random IO of the blockchain? (which is useful in its own 
> >> right,
> >> > e.g. as a way to ensure only full-node IO-bound mining if baked 
> >> into
> >> > the PoW)
> >> >
> >> > How is the verifier validating the response without possession of 
> >> the
> >> > full blockchain?
> >>
> >> You're right, It is incorrect. Not the decrypted blocks must be 
> >> sent,
> >> but the encrypted blocks. There correct protocol is this:
> >>
> >> 1. (prover and verifier pay a small cost) The verifier sends a seed 
> >> to
> >> derive some n random indexes, and the prover must respond with the 
> >> the
> >> encrypted blocks within a certain time bound. The verifier decrypts
> >> those blocks to check if they are part of the block-chain.
> >>
> >> But then there is this improvement which allows the verifier do 
> >> detect
> >> non full-nodes with much less computation:
> >>
> >> 3. (prover pays a small cost, verifier smaller cost) The verifier 
> >> asks
> >> the prover to send a Merkle tree root of hashes of encrypted blocks 
> >> with
> >> N indexes selected by a psudo-random function seeded by a challenge
> >> value, where each encrypted-block is previously prefixed with the 
> >> seed
> >> before being hashed (e.g. N=100). The verifier receives the Markle 
> >> Root
> >> and performs a statistical test on the received information. From 
> >> the N
> >> hashes blocks, it chooses M < N (e.g. M = 20), and asks the proved 
> >> for
> >> the blocks at these indexes. The prover sends the blocks, the 
> >> verifier
> >> validates the blocks by decrypting them and also verifies that the
> >> Merkle tree was well constructed for those block nodes. This proves 
> >> with
> >> high probability that the Merkle tree was built on-the-fly and
> >> specifically for this challenge-response protocol.
> >>
> >> > I also wonder about the effect of spinning disk versus SSD. Seek 
> >> time
> >> > for 1,000 random reads is either nearly zero or dominating 
> >> depending
> >> > on the two modes. I wonder if a sequential read from a random 
> >> index is
> >> > a possible trade-off,; it doesn't prove possession of the whole 
> >> chain
> >> > nearly as well, but at least iowait converges significantly. Then
> >> > again, that presupposes a specific ordering on disk which might 
> >> not
> >> > exist. In X years it will all be solid-state, so eventually it's 
> >> moot.
> >> >
> >> Good idea.
> >>
> >> Also we don't need that every node implements the protocol, but only
> >> nodes that want to prove full-node-ness, such as the ones which want 
> >> to
> >> receive bitnodes subsidy.
> >
> >
> > 
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> > sponsored
> > by Intel and developed in partnership with Slashdot Media, is your
> > hub for all
> > things parallel software development, from weekly thought leadership 
> > blogs to
> > news, videos, case studies, tutorials and more. Take a look and join 
> > the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Robert McKay]

The main motivation is to try and stop a single entity running lots of 
nodes in order to harvest transaction origin IPs. That's what's behind 
this.

Probably the efforts are a waste of time.. if someone has to keep a few 
hundred copies of the blockchain around in order to keep IP specific 
precomputed data around for all the IPs they listen on then they'll just 
buy a handful of 5TB HDs and call it a day.. still some of the ideas 
proposed are quite interesting and might not have much downside.

Rob


On 2015-03-27 15:16, Matt Whitlock wrote:
> I agree that someone could do this, but why is that a problem? Isn't
> the goal of this exercise to ensure more full nodes on the network? 
> In
> order to be able to answer the challenges, an entity would need to be
> running a full node somewhere. Thus, they have contributed at least
> one additional full node to the network. I could certainly see a case
> for a company to host hundreds of lightweight (e.g., EC2) servers all
> backed by a single copy of the block chain. Why force every single
> machine to have its own copy? All you really need to require is that
> each agency/participant have its own copy.
>
>
> On Friday, 27 March 2015, at 2:32 pm, Robert McKay wrote:
>> Basically the problem with that is that someone could setup a single
>> full node that has the blockchain and can answer those challenges 
>> and
>> then a bunch of other non-full nodes that just proxy any such 
>> challenges
>> to the single full node.
>>
>> Rob
>>
>> On 2015-03-26 23:04, Matt Whitlock wrote:
>> > Maybe I'm overlooking something, but I've been watching this 
>> thread
>> > with increasing skepticism at the complexity of the offered 
>> solution.
>> > I don't understand why it needs to be so complex. I'd like to 
>> offer
>> > an
>> > alternative for your consideration...
>> >
>> > Challenge:
>> > "Send me: SHA256(SHA256(concatenation of N pseudo-randomly 
>> selected
>> > bytes from the block chain))."
>> >
>> > Choose N such that it would be infeasible for the responding node 
>> to
>> > fetch all of the needed blocks in a short amount of time. In other
>> > words, assume that a node can seek to a given byte in a block 
>> stored
>> > on local disk much faster than it can download the entire block 
>> from
>> > a
>> > remote peer. This is almost certainly a safe assumption.
>> >
>> > For example, choose N = 1024. Then the proving node needs to 
>> perform
>> > 1024 random reads from local disk. On spinning media, this is 
>> likely
>> > to take somewhere on the order of 15 seconds. Assuming blocks are
>> > averaging 500 KiB each, then 1024 blocks would comprise 500 MiB of
>> > data. Can 500 MiB be downloaded in 15 seconds? This data transfer
>> > rate
>> > is 280 Mbps. Almost certainly not possible. And if it is, just
>> > increase N. The challenge also becomes more difficult as average
>> > block
>> > size increases.
>> >
>> > This challenge-response protocol relies on the lack of a "partial
>> > getdata" command in the Bitcoin protocol: a node cannot ask for 
>> only
>> > part of a block; it must ask for an entire block. Furthermore, 
>> nodes
>> > could ban other nodes for making too many random requests for 
>> blocks.
>> >
>> >
>> > On Thursday, 26 March 2015, at 7:09 pm, Sergio Lerner wrote:
>> >>
>> >> > If I understand correctly, transforming raw blocks to keyed 
>> blocks
>> >> > takes 512x longer than transforming keyed blocks back to raw. 
>> The
>> >> key
>> >> > is public, like the IP, or some other value which perhaps 
>> changes
>> >> less
>> >> > frequently.
>> >> >
>> >> Yes. I was thinking that the IP could be part of a first layer of
>> >> encryption done to the blockchain data prior to the asymetric
>> >> operation.
>> >> That way the asymmetric operation can be the same for all users 
>> (no
>> >> different primers for different IPs, and then the verifiers does 
>> not
>> >> have to verify that a particular p is actually a pseudo-prime
>> >> suitable
>> >> for P.H. ) and the public exponent can be just 3.
>> >>
>> >> >
>> >> >> Two protocols can be performed to prove local possession:
>> >> >> 1. (prover and verifier pay a small cost) The verifier sends a
>> >> seed to
>> >> >> derive some n random indexes, and the prover must respond with
>> >> the hash
>> >> >> of the decrypted blocks within a certain time bound. Suppose 
>> that
>> >> >> decryption of n blocks take 100 msec (+-100 msec of network
>> >> jitter).
>> >> >> Then an attacker must have a computer 50 faster to be able to
>> >> >> consistently cheat. The last 50 blocks should not be part of 
>> the
>> >> list to
>> >> >> allow nodes to catch-up and encrypt the blocks in background.
>> >> >>
>> >> >
>> >> > Can you clarify, the prover is hashing random blocks of
>> >> *decrypted*,
>> >> > as-in raw, blockchain data? What does this prove other than,
>> >> perhaps,
>> >> > fast random IO of the blockchain? (which is useful in its own
>> >> right,
>> >> > e.g. as a way to ensure only full-node IO-bound mining if baked
>> >> into
>> >> > the PoW)
>> >> >
>> >> > How is the verifier validating the response without possession 
>> of
>> >> the
>> >> > full blockchain?
>> >>
>> >> You're right, It is incorrect. Not the decrypted blocks must be
>> >> sent,
>> >> but the encrypted blocks. There correct protocol is this:
>> >>
>> >> 1. (prover and verifier pay a small cost) The verifier sends a 
>> seed
>> >> to
>> >> derive some n random indexes, and the prover must respond with 
>> the
>> >> the
>> >> encrypted blocks within a certain time bound. The verifier 
>> decrypts
>> >> those blocks to check if they are part of the block-chain.
>> >>
>> >> But then there is this improvement which allows the verifier do
>> >> detect
>> >> non full-nodes with much less computation:
>> >>
>> >> 3. (prover pays a small cost, verifier smaller cost) The verifier
>> >> asks
>> >> the prover to send a Merkle tree root of hashes of encrypted 
>> blocks
>> >> with
>> >> N indexes selected by a psudo-random function seeded by a 
>> challenge
>> >> value, where each encrypted-block is previously prefixed with the
>> >> seed
>> >> before being hashed (e.g. N=100). The verifier receives the 
>> Markle
>> >> Root
>> >> and performs a statistical test on the received information. From
>> >> the N
>> >> hashes blocks, it chooses M < N (e.g. M = 20), and asks the 
>> proved
>> >> for
>> >> the blocks at these indexes. The prover sends the blocks, the
>> >> verifier
>> >> validates the blocks by decrypting them and also verifies that 
>> the
>> >> Merkle tree was well constructed for those block nodes. This 
>> proves
>> >> with
>> >> high probability that the Merkle tree was built on-the-fly and
>> >> specifically for this challenge-response protocol.
>> >>
>> >> > I also wonder about the effect of spinning disk versus SSD. 
>> Seek
>> >> time
>> >> > for 1,000 random reads is either nearly zero or dominating
>> >> depending
>> >> > on the two modes. I wonder if a sequential read from a random
>> >> index is
>> >> > a possible trade-off,; it doesn't prove possession of the whole
>> >> chain
>> >> > nearly as well, but at least iowait converges significantly. 
>> Then
>> >> > again, that presupposes a specific ordering on disk which might
>> >> not
>> >> > exist. In X years it will all be solid-state, so eventually 
>> it's
>> >> moot.
>> >> >
>> >> Good idea.
>> >>
>> >> Also we don't need that every node implements the protocol, but 
>> only
>> >> nodes that want to prove full-node-ness, such as the ones which 
>> want
>> >> to
>> >> receive bitnodes subsidy.
>> >
>> >
>> >
>> > 
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel 
>> Website,
>> > sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your
>> > hub for all
>> > things parallel software development, from weekly thought 
>> leadership
>> > blogs to
>> > news, videos, case studies, tutorials and more. Take a look and 
>> join
>> > the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> 
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, 
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your 
>> hub for all
>> things parallel software development, from weekly thought leadership 
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join 
>> the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Matt Whitlock]

On Friday, 27 March 2015, at 4:57 pm, Wladimir J. van der Laan wrote:
> On Fri, Mar 27, 2015 at 11:16:43AM -0400, Matt Whitlock wrote:
> > I agree that someone could do this, but why is that a problem? Isn't the goal of this exercise to ensure more full nodes on the network? In order to be able to answer the challenges, an entity would need to be running a full node somewhere. Thus, they have contributed at least one additional full node to the network. I could certainly see a case for a company to host hundreds of lightweight (e.g., EC2) servers all backed by a single copy of the block chain. Why force every single machine to have its own copy? All you really need to require is that each agency/participant have its own copy.
> 
> They would not even have to run one. It could just pass the query to a random other node, and forward its result :)

D'oh. Of course. Thanks. :/

The suggestion about encrypting blocks with a key tied to IP address seems like a bad idea, though. Lots of nodes are on dynamic IP addresses. It wouldn't really be practical to re-encrypt the entire block chain every time a node's IP address changes.

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Matt Whitlock]

On Friday, 27 March 2015, at 4:57 pm, Wladimir J. van der Laan wrote:
> On Fri, Mar 27, 2015 at 11:16:43AM -0400, Matt Whitlock wrote:
> > I agree that someone could do this, but why is that a problem? Isn't the goal of this exercise to ensure more full nodes on the network? In order to be able to answer the challenges, an entity would need to be running a full node somewhere. Thus, they have contributed at least one additional full node to the network. I could certainly see a case for a company to host hundreds of lightweight (e.g., EC2) servers all backed by a single copy of the block chain. Why force every single machine to have its own copy? All you really need to require is that each agency/participant have its own copy.
> 
> They would not even have to run one. It could just pass the query to a random other node, and forward its result :)

Ah, easy way to fix that. In fact, in my first draft of my suggestion, I had the answer, but I removed it because I thought it was superfluous.

Challenge:
"Send me: SHA256(SHA256(concatenation of N pseudo-randomly selected bytes from the block chain | prover's nonce | verifier's nonce))."

The nonces are from the "version" messages exchanged at connection startup. A node can't pass the buck because it can't control the nonce that a random other node chooses.

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Jeremy Spilman]

> On Mar 27, 2015, at 8:16 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:
> 
> Isn't the goal of this exercise to ensure more full nodes on the network?

Basically we're talking about a form of Sybil defense and better quantifying true blockchain resiliency by proof of storage.

In this case the goal is to see if we can prove the number of distinct digital copies of the blockchain. This is actually a tricky problem because it will (always?) devolve to inferences from response timing, and we are running over a heterogenous network with heterogeneous machines.

It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost. 

I think while its a difficult cost-benefit analysis, even code complexity aside, it's interesting to discuss all the same!

Simply having many unique IP addresses possibly accessing the same unique copy provides a different (if any) benefit. E.g. Tor uses IPs as a cost factor, but (until recently?) didn't even factor in things like them all being the same Class C. 

Re: [Bitcoin-development] "network disruption as a service" and proof of local storage

[Sergio Lerner]

Matt is right:  the goal is to prove digital copies of a public file.
Nothing more, nothing less.

Regarding the IP, I don't claim that every machine should provide the
protocol. Mobiles phones shouldn't. But machines that what to be
prioritized in some way or that want to be rewarded for hosting a node
should use a fixed IP. That's the cost of prioritization/reward. The
protocol could be a service bit, advertised in the version message.

My response to your comment below:

On 27/03/2015 03:40 p.m., Jeremy Spilman wrote:
>
> It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost. 
I see it differently. The asymmetric-time protocol is quite reliable. If
can be made to have almost no false positives/false negatives (not
considering rare communication problems, such as congestion and packet
loss for more than 5 seconds).
These are my back-of-the-envelope calculations:
Bitcoind takes approximately 1 second to serve a 1 Mb block (seek time,
but mostly transfer time)
Then decryption of a block can take 150 msec without problem (15%
overhead). The last N blocks could be cached so they don't need to be
decrypted to be sent.
In 150 msec a PC can decrypt a 1MB of data split over 1024-bit blocks
decrypted by modexp 3 (0.2 msec for 3 bigint multiplications), so a full
block can be decrypted.
Encrypting such block would take approximately 15 seconds (which is much
less than the 10 minutes available to encrypt each block)
Then the protocol works with a security margin of approximately 50x.
A communication problem during 5 seconds would be needed to disturb a
protocol of that takes 100 msec for the prover.

Regards,
 Sergio.

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Shizzle's opinion, it would seem, is highly important.  I'm done here.

Thy Shizzle:
> Oh so you're talking about the criminality of one single entity? So
> having a quick look, it seems that the issue is they are collecting
> IPs and that kind of thing as well? So similar to what
> http://getaddr.bitnodes.io is doing but without the funding from
> the bitcoin foundation? If you are worried about your IP getting
> out you're behind a VPN. They can only collect the information made
> available to them. Botnets etc are completely different because you
> are forcing control over something you have no right to do. If
> companies want to sit there and collect publicly available
> information that you are voluntarily making available to them, why
> do you care? I can't see how it could be at all criminal.
> Remembering that most privacy laws relate to information that YOU
> PROVIDE to an entity during an agreement for service, payment, etc.
> You are providing this information publicly and they are collecting
> it from the public domain, not you giving it to them in an
> agreement, therefore the usual provisions of privacy etc don't
> apply. If you connect to their scraper node, of course they can log
> that. How could it possibly be criminal? 
> ________________________________ From:
> odinn<mailto:odinn.cyberguerrilla@riseup.net> Sent: ‎23/‎03/‎2015
> 4:50 PM To: Thy Shizzle<mailto:thyshizzle@outlook.com> Cc:
> bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@lists.sourceforge.net>
>
> 
Subject: Re: [Bitcoin-development] Criminal complaints against "network
disruption as a service" startups
> 
> Back to what is Chainalysis and country of their origin, so
> criminal complaints against them would likely relate to violation
> of Swiss laws, as is described here: 
> https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882
>
>  It is fairly obvious that Chainalysis is not merely doing what 
> blockchain.info etc. is. Let's not delude ourselves here.
> 
> As stated, it would be advisable for such a firm to cease
> operations, and it would seem that plenty of polite shots over the
> bow have been given to Chainalysis, which should now fold up its
> operation, pack its bags, and go back to its hole before trying to
> serve its masters again in another way. Etc.
> 
> Corporations similar to Chainalysis which are domiciled in other 
> countries which conduct collection of information in ways that
> violate countries' laws (there are many countries and each have
> their own ways of interpreting user privacy and what constitutes
> permissible breach and in what circumstances) can indeed be held to
> legal standards that may result in minimal or severe legal
> penalties.  It is true that analyzing information that is publicly
> available, such as that which is in a library, is not illegal. But
> the act of surveillance is. (Then there is the question of what
> sort of surveillance, targeted or general, and whether it is
> limited to the bitcoin network or if it moves beyond that to
> attempts to correlate with usernames, IDs, IPs, and other
> information available on fora and apparent from services, but I
> won't get into that here.)  Even if you argue that the manner in 
> which you are performing your actions is not actually
> "surveillance," or you argue that it is "legally permissible,"
> someone else will certainly come along and make a reasonable
> argument that you are indeed engaging in illegal surveillance.
> They may even suggest to a judge that you are in the process of
> constructing a botnet and demand that your domains be seized, and
> may successfully obtain an ex parte temporary restraining order
> (TRO) against Chainalysis and similar corporations to have
> domain(s) seized.  Any and all arguments may be added in here,
> there are 196 countries in the world today - each with their own
> unique laws - (maybe less by the time you read this) and a shit-ton
> of possible legal arguments that can be made by creative minds that
> might want to sue you if you have been surveilling people, each
> different depending on where your surveillance corporation is 
> domiciled.  There are plenty of legal processes available for
> people to do exactly that.  You are indeed subject to having that
> happen to you if you continue to surveill the network even if you
> are doing so on behalf of the state for the purpose of gathering
> information for a state's compliance initiative.
> 
> So, don't delude yourself, and be happy if all that happens is
> your little surveillance initiative has to close its doors (or gets
> sued if it stays open).  Because that is the legal side of things.
> The extralegal stuff is far worse.  The community is helping you by
> asking you gently to close up shop and go away. It is a helpful
> suggestion and I believe also a fair warning, again, a shot off the
> bow.
> 
> On the development side, developers are certainly responsible for 
> doing what they can to resist this kind of surveillance activity.
> But I have a feeling that will be a different thread which is more 
> technical and so won't comment on it here, except to say it will 
> likely involve working toward giving the user an anonymity option 
> which can be exercised as part of any transaction.
> 
> Thy Shizzle:
>> I don't believe that at all. Analyzing information publicly 
>> available is not illegal. Chainalysis or whatever you call it
>> would be likened to observing who comes and feeds birds at the
>> park everyday. You can sit in the park and observe who feeds the
>> birds, just as you can connect to the Bitcoin P2P network and
>> observe the blocks being formed into the chain and transactions
>> etc. Unless there is some agreement taking place where it is
>> specified that upon connecting to the Bitcoin P2P swarm you agree
>> to a set of terms, however as every node is providing their own
>> "entry" into the P2P swarm it becomes really up to the node
>> providing the connection to uphold and enforce the terms of the
>> agreement. If you allow people to connect to you without terms of
>> agreement, you cannot cry foul when they record the data that
>> passes through. To say Chainalysis needs to cease is silly, the
>> whole point of the public blockchain is for Chainalysis, whether
>> it be for the verification of transactions, research or
>> otherwise.
> 
>> -----Original Message----- From: "odinn" 
>> <odinn.cyberguerrilla@riseup.net> Sent: ‎23/‎03/‎2015 1:48 PM
>> To: "bitcoin-development@lists.sourceforge.net" 
>> <bitcoin-development@lists.sourceforge.net> Subject: Re: 
>> [Bitcoin-development] Criminal complaints against "network 
>> disruption as a service" startups
> 
>> If you (e.g. Chainalysis) or anyone else are doing surveillance
>> on the network and gathering information for later use, and
>> whether or not the ultimate purpose is to divulge it to other
>> parties for compliance purposes, you can bet that ultimately the
>> tables will be turned on you, and you will be the one having your
>> ass handed to you so to speak, before or after you are served, in
>> legal parlance. Whether or not the outcome of that is meaningful
>> and beneficial to any concerned parties and what is the upshot of
>> it in the end depends on on what you do and just how far you
>> decide to take your ill-advised enterprise.
> 
>> Chainalysis and similar operations would be, IMHO, well advised
>> to cease operations.  This doesn't mean they will, but guess
>> what:
> 
>> Shot over the bow, folks.
> 
>> Jan Møller:
>>> What we were trying to achieve was determining the flow of
>>> funds between countries by figuring out which country a
>>> transaction originates from. To do that with a certain accuracy
>>> you need many nodes. We chose a class C IP range as we knew
>>> that bitcoin core and others only connect to one node in any
>>> class C IP range. We were not aware that breadwallet didn't
>>> follow this practice. Breadwallet risked getting tar-pitted,
>>> but that was not our intention and we are sorry about that.
> 
>>> Our nodes DID respond with valid blocks and merkle-blocks and 
>>> allowed everyone connecting to track the blockchain. We did 
>>> however not relay transactions. The 'service' bit in the
>>> version message is not meant for telling whether or how the
>>> node relays transactions, it tells whether you can ask for
>>> block headers only or full blocks.
> 
>>> Many implementations enforce non standard rules for handling 
>>> transactions; some nodes ignore transactions with address
>>> reuse, some nodes happily forward double spends, and some nodes
>>> forward neither blocks not transactions. We did blocks but not 
>>> transactions.
> 
>>> In hindsight we should have done two things: 1. relay 
>>> transactions 2. advertise address from 'foreign' nodes
> 
>>> Both would have fixed the problems that breadwallet
>>> experienced. My understanding is that breadwallet now has the
>>> same 'class C' rule as bitcoind, which would also fix it.
> 
>>> Getting back on the topic of this thread and whether it is 
>>> illegal, your guess is as good as mine. I don't think it is 
>>> illegal to log incoming connections and make statistical
>>> analysis on it. That would more or less incriminate anyone who
>>> runs a web-server and looks into the access log. At lease one
>>> Bitcoin service has been collecting IP addresses for years and
>>> given them to anyone visiting their web-site (you know who) and
>>> I believe that this practise is very wrong. We have no
>>> intention of giving IP addresses away to anyone, but we believe
>>> that you are free to make statistics on connection logs when
>>> nodes connect to you.
> 
>>> On a side note: When you make many connections to the network 
>>> you see lots of strange nodes and suspicious patterns. You can 
>>> be certain that we were not the only ones connected to many 
>>> nodes.
> 
>>> My takeaway from this: If nodes that do not relay transactions
>>> is a problem then there is stuff to fix.
> 
>>> /Jan
> 
>>> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net> 
>>> wrote:
> 
>>>> That would be rather new and tricky legal territory.
>>>> 
>>>> But even putting the legal issues to one side, there are 
>>>> definitional issues.
>>>> 
>>>> For instance if the Chainalysis nodes started following the 
>>>> protocol specs better and became just regular nodes that 
>>>> happen to keep logs, would that still be a violation? If so, 
>>>> what about blockchain.info? It'd be shooting ourselves in
>>>> the foot to try and forbid block explorers given how useful
>>>> they are.
>>>> 
>>>> If someone non-maliciously runs some nodes with debug
>>>> logging turned on, and makes full system backups every night,
>>>> and keeps those backups for years, are they in violation of 
>>>> whatever pseudo-law is involved?
>>>> 
>>>> I think it's a bit early to think about these things right 
>>>> now. Michael Grønager and Jan Møller have been Bitcoin
>>>> hackers for a long time. I'd be interested to know their
>>>> thoughts on all of this.
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>
>>>> 
>>>> 
> Dive into the World of Parallel Programming The Go Parallel
> Website,
>>>> sponsored by Intel and developed in partnership with
>>>> Slashdot Media, is your hub for all things parallel software 
>>>> development, from weekly thought leadership blogs to news, 
>>>> videos, case studies, tutorials and more. Take a look and
>>>> join the conversation now.
>>>> http://goparallel.sourceforge.net/ 
>>>> _______________________________________________ 
>>>> Bitcoin-development mailing list 
>>>> Bitcoin-development@lists.sourceforge.net 
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>
>>>> 
>>>> 
> 
> 
>>> ------------------------------------------------------------------------------
>
>>> 
>>> 
> 
>> Dive into the World of Parallel Programming The Go Parallel 
>> Website, sponsored
>>> by Intel and developed in partnership with Slashdot Media, is 
>>> your hub for all things parallel software development, from 
>>> weekly thought leadership blogs to news, videos, case studies, 
>>> tutorials and more. Take a look and join the conversation now. 
>>> http://goparallel.sourceforge.net/
> 
> 
> 
>>> _______________________________________________ 
>>> Bitcoin-development mailing list 
>>> Bitcoin-development@lists.sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>>> 
> 
> 
>> ------------------------------------------------------------------------------
>
>> 
> 
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now. 
>> http://goparallel.sourceforge.net/ 
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 

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

iQEcBAEBCgAGBQJVD7aKAAoJEGxwq/inSG8C4KsIAIu5atra8Y9R9oejNryjMQkz
UOVORw3y0eD8yaAiJJQzJjmNE6UXC92R3gM3KtQoQchSQ6RhyhZUZkzCY7k2Ug08
8UZnxjgAHCwScGUSgpDu2hcGDtC+Csa1EKOExjCxYCBlVRI+cCJqxIm9d7vGDi4V
R1y57xtKtussJxhZKVjIxothkHtSy5HuaKdKLfI7ikoBAerOVY7bGCxE+drUr4OO
Sgxe94M8z/ecFk3h37ZhuL2P+mNAlCKQkW592628XC0bXN8iT2vW7MnB3BLEBzvb
TeWFYUFjs5v09B6Cw6LQWFGKdFwLGganybeEqoKNfzrihEAa19PFsRWHPStMUCM=
=JnJQ
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 13640 bytes --]

Oh so you're talking about the criminality of one single entity? So having a quick look, it seems that the issue is they are collecting IPs and that kind of thing as well? So similar to what http://getaddr.bitnodes.io is doing but without the funding from the bitcoin foundation? If you are worried about your IP getting out you're behind a VPN. They can only collect the information made available to them. Botnets etc are completely different because you are forcing control over something you have no right to do. If companies want to sit there and collect publicly available information that you are voluntarily making available to them, why do you care? I can't see how it could be at all criminal. Remembering that most privacy laws relate to information that YOU PROVIDE to an entity during an agreement for service, payment, etc. You are providing this information publicly and they are collecting it from the public domain, not you giving it to them in an agreement, therefore the usual provisions of privacy etc don't apply. If you connect to their scraper node, of course they can log that. How could it possibly be criminal?
________________________________
From: odinn<mailto:odinn.cyberguerrilla@riseup.net>
Sent: ‎23/‎03/‎2015 4:50 PM
To: Thy Shizzle<mailto:thyshizzle@outlook.com>
Cc: bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Back to what is Chainalysis and country of their origin, so criminal
complaints against them would likely relate to violation of Swiss
laws, as is described here:
https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882

It is fairly obvious that Chainalysis is not merely doing what
blockchain.info etc. is. Let's not delude ourselves here.

As stated, it would be advisable for such a firm to cease operations,
and it would seem that plenty of polite shots over the bow have been
given to Chainalysis, which should now fold up its operation, pack its
bags, and go back to its hole before trying to serve its masters again
in another way. Etc.

Corporations similar to Chainalysis which are domiciled in other
countries which conduct collection of information in ways that violate
countries' laws (there are many countries and each have their own ways
of interpreting user privacy and what constitutes permissible breach
and in what circumstances) can indeed be held to legal standards that
may result in minimal or severe legal penalties.  It is true that
analyzing information that is publicly available, such as that which
is in a library, is not illegal. But the act of surveillance is.
(Then there is the question of what sort of surveillance, targeted or
general, and whether it is limited to the bitcoin network or if it
moves beyond that to attempts to correlate with usernames, IDs, IPs,
and other information available on fora and apparent from services,
but I won't get into that here.)  Even if you argue that the manner in
which you are performing your actions is not actually "surveillance,"
or you argue that it is "legally permissible," someone else will
certainly come along and make a reasonable argument that you are
indeed engaging in illegal surveillance.  They may even suggest to a
judge that you are in the process of constructing a botnet and demand
that your domains be seized, and may successfully obtain an ex parte
temporary restraining order (TRO) against Chainalysis and similar
corporations to have domain(s) seized.  Any and all arguments may be
added in here, there are 196 countries in the world today - each with
their own unique laws - (maybe less by the time you read this) and a
shit-ton of possible legal arguments that can be made by creative
minds that might want to sue you if you have been surveilling people,
each different depending on where your surveillance corporation is
domiciled.  There are plenty of legal processes available for people
to do exactly that.  You are indeed subject to having that happen to
you if you continue to surveill the network even if you are doing so
on behalf of the state for the purpose of gathering information for a
state's compliance initiative.

So, don't delude yourself, and be happy if all that happens is your
little surveillance initiative has to close its doors (or gets sued if
it stays open).  Because that is the legal side of things.  The
extralegal stuff is far worse.  The community is helping you by asking
you gently to close up shop and go away. It is a helpful suggestion
and I believe also a fair warning, again, a shot off the bow.

On the development side, developers are certainly responsible for
doing what they can to resist this kind of surveillance activity.  But
I have a feeling that will be a different thread which is more
technical and so won't comment on it here, except to say it will
likely involve working toward giving the user an anonymity option
which can be exercised as part of any transaction.

Thy Shizzle:
> I don't believe that at all. Analyzing information publicly
> available is not illegal. Chainalysis or whatever you call it would
> be likened to observing who comes and feeds birds at the park
> everyday. You can sit in the park and observe who feeds the birds,
> just as you can connect to the Bitcoin P2P network and observe the
> blocks being formed into the chain and transactions etc. Unless
> there is some agreement taking place where it is specified that
> upon connecting to the Bitcoin P2P swarm you agree to a set of
> terms, however as every node is providing their own "entry" into
> the P2P swarm it becomes really up to the node providing the
> connection to uphold and enforce the terms of the agreement. If you
> allow people to connect to you without terms of agreement, you
> cannot cry foul when they record the data that passes through. To
> say Chainalysis needs to cease is silly, the whole point of the
> public blockchain is for Chainalysis, whether it be for the
> verification of transactions, research or otherwise.
>
> -----Original Message----- From: "odinn"
> <odinn.cyberguerrilla@riseup.net> Sent: ‎23/‎03/‎2015 1:48 PM To:
> "bitcoin-development@lists.sourceforge.net"
> <bitcoin-development@lists.sourceforge.net> Subject: Re:
> [Bitcoin-development] Criminal complaints against "network
> disruption as a service" startups
>
> If you (e.g. Chainalysis) or anyone else are doing surveillance on
> the network and gathering information for later use, and whether or
> not the ultimate purpose is to divulge it to other parties for
> compliance purposes, you can bet that ultimately the tables will be
> turned on you, and you will be the one having your ass handed to
> you so to speak, before or after you are served, in legal parlance.
> Whether or not the outcome of that is meaningful and beneficial to
> any concerned parties and what is the upshot of it in the end
> depends on on what you do and just how far you decide to take your
> ill-advised enterprise.
>
> Chainalysis and similar operations would be, IMHO, well advised to
> cease operations.  This doesn't mean they will, but guess what:
>
> Shot over the bow, folks.
>
> Jan Møller:
>> What we were trying to achieve was determining the flow of funds
>> between countries by figuring out which country a transaction
>> originates from. To do that with a certain accuracy you need
>> many nodes. We chose a class C IP range as we knew that bitcoin
>> core and others only connect to one node in any class C IP range.
>> We were not aware that breadwallet didn't follow this practice.
>> Breadwallet risked getting tar-pitted, but that was not our
>> intention and we are sorry about that.
>
>> Our nodes DID respond with valid blocks and merkle-blocks and
>> allowed everyone connecting to track the blockchain. We did
>> however not relay transactions. The 'service' bit in the version
>> message is not meant for telling whether or how the node relays
>> transactions, it tells whether you can ask for block headers only
>> or full blocks.
>
>> Many implementations enforce non standard rules for handling
>> transactions; some nodes ignore transactions with address reuse,
>> some nodes happily forward double spends, and some nodes forward
>> neither blocks not transactions. We did blocks but not
>> transactions.
>
>> In hindsight we should have done two things: 1. relay
>> transactions 2. advertise address from 'foreign' nodes
>
>> Both would have fixed the problems that breadwallet experienced.
>> My understanding is that breadwallet now has the same 'class C'
>> rule as bitcoind, which would also fix it.
>
>> Getting back on the topic of this thread and whether it is
>> illegal, your guess is as good as mine. I don't think it is
>> illegal to log incoming connections and make statistical analysis
>> on it. That would more or less incriminate anyone who runs a
>> web-server and looks into the access log. At lease one Bitcoin
>> service has been collecting IP addresses for years and given them
>> to anyone visiting their web-site (you know who) and I believe
>> that this practise is very wrong. We have no intention of giving
>> IP addresses away to anyone, but we believe that you are free to
>> make statistics on connection logs when nodes connect to you.
>
>> On a side note: When you make many connections to the network
>> you see lots of strange nodes and suspicious patterns. You can
>> be certain that we were not the only ones connected to many
>> nodes.
>
>> My takeaway from this: If nodes that do not relay transactions is
>> a problem then there is stuff to fix.
>
>> /Jan
>
>> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net>
>> wrote:
>
>>> That would be rather new and tricky legal territory.
>>>
>>> But even putting the legal issues to one side, there are
>>> definitional issues.
>>>
>>> For instance if the Chainalysis nodes started following the
>>> protocol specs better and became just regular nodes that
>>> happen to keep logs, would that still be a violation? If so,
>>> what about blockchain.info? It'd be shooting ourselves in the
>>> foot to try and forbid block explorers given how useful they
>>> are.
>>>
>>> If someone non-maliciously runs some nodes with debug logging
>>> turned on, and makes full system backups every night, and
>>> keeps those backups for years, are they in violation of
>>> whatever pseudo-law is involved?
>>>
>>> I think it's a bit early to think about these things right
>>> now. Michael Grønager and Jan Møller have been Bitcoin hackers
>>> for a long time. I'd be interested to know their thoughts on
>>> all of this.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>
>>>
Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot
>>> Media, is your hub for all things parallel software
>>> development, from weekly thought leadership blogs to news,
>>> videos, case studies, tutorials and more. Take a look and join
>>> the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>
>>>
>
>
>> ------------------------------------------------------------------------------
>
>>
>
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now.
>> http://goparallel.sourceforge.net/
>
>
>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

iQEcBAEBCgAGBQJVD6mmAAoJEGxwq/inSG8CkLUH/iWvn7kp6KW2fe5RFca1eAmH
L+5P+kNDzMARIRt8A3CvopoQQMZx44aZ8pMdErUk+78A7oeP/x+scYEkSiXE17Iv
saBWv43mO+qFxgVrU7y+9njwLJoywHitBymhLGisi3hv+H7lfIMdPK2dLVThwxel
bVO0Ga8Y9qDYAwtK23yEOCT7klj5mT0tG50U4HxDpIXaJj8kCnVUC2O1MdYhr1pP
93cDuhBmXOg7sOLAPpdWVhgfnz0Vm8M0ZWUIK+4FGzpQugWHcmdp3YUDCeczOYzD
u5zVdAqvdL6qQcWkUcGfkKaAqfJH3u5F2zeQvDUEJeeEz1lWnrsXuT7cCvcp/TU=
=6io6
-----END PGP SIGNATURE-----

[-- Attachment #2: Type: text/html, Size: 17492 bytes --]

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Back to what is Chainalysis and country of their origin, so criminal
complaints against them would likely relate to violation of Swiss
laws, as is described here:
https://bitcointalk.org/index.php?topic=978088.msg10774882#msg10774882

It is fairly obvious that Chainalysis is not merely doing what
blockchain.info etc. is. Let's not delude ourselves here.

As stated, it would be advisable for such a firm to cease operations,
and it would seem that plenty of polite shots over the bow have been
given to Chainalysis, which should now fold up its operation, pack its
bags, and go back to its hole before trying to serve its masters again
in another way. Etc.

Corporations similar to Chainalysis which are domiciled in other
countries which conduct collection of information in ways that violate
countries' laws (there are many countries and each have their own ways
of interpreting user privacy and what constitutes permissible breach
and in what circumstances) can indeed be held to legal standards that
may result in minimal or severe legal penalties.  It is true that
analyzing information that is publicly available, such as that which
is in a library, is not illegal. But the act of surveillance is.
(Then there is the question of what sort of surveillance, targeted or
general, and whether it is limited to the bitcoin network or if it
moves beyond that to attempts to correlate with usernames, IDs, IPs,
and other information available on fora and apparent from services,
but I won't get into that here.)  Even if you argue that the manner in
which you are performing your actions is not actually "surveillance,"
or you argue that it is "legally permissible," someone else will
certainly come along and make a reasonable argument that you are
indeed engaging in illegal surveillance.  They may even suggest to a
judge that you are in the process of constructing a botnet and demand
that your domains be seized, and may successfully obtain an ex parte
temporary restraining order (TRO) against Chainalysis and similar
corporations to have domain(s) seized.  Any and all arguments may be
added in here, there are 196 countries in the world today - each with
their own unique laws - (maybe less by the time you read this) and a
shit-ton of possible legal arguments that can be made by creative
minds that might want to sue you if you have been surveilling people,
each different depending on where your surveillance corporation is
domiciled.  There are plenty of legal processes available for people
to do exactly that.  You are indeed subject to having that happen to
you if you continue to surveill the network even if you are doing so
on behalf of the state for the purpose of gathering information for a
state's compliance initiative.

So, don't delude yourself, and be happy if all that happens is your
little surveillance initiative has to close its doors (or gets sued if
it stays open).  Because that is the legal side of things.  The
extralegal stuff is far worse.  The community is helping you by asking
you gently to close up shop and go away. It is a helpful suggestion
and I believe also a fair warning, again, a shot off the bow.

On the development side, developers are certainly responsible for
doing what they can to resist this kind of surveillance activity.  But
I have a feeling that will be a different thread which is more
technical and so won't comment on it here, except to say it will
likely involve working toward giving the user an anonymity option
which can be exercised as part of any transaction.

Thy Shizzle:
> I don't believe that at all. Analyzing information publicly
> available is not illegal. Chainalysis or whatever you call it would
> be likened to observing who comes and feeds birds at the park
> everyday. You can sit in the park and observe who feeds the birds,
> just as you can connect to the Bitcoin P2P network and observe the
> blocks being formed into the chain and transactions etc. Unless
> there is some agreement taking place where it is specified that
> upon connecting to the Bitcoin P2P swarm you agree to a set of
> terms, however as every node is providing their own "entry" into
> the P2P swarm it becomes really up to the node providing the
> connection to uphold and enforce the terms of the agreement. If you
> allow people to connect to you without terms of agreement, you
> cannot cry foul when they record the data that passes through. To
> say Chainalysis needs to cease is silly, the whole point of the
> public blockchain is for Chainalysis, whether it be for the
> verification of transactions, research or otherwise.
> 
> -----Original Message----- From: "odinn"
> <odinn.cyberguerrilla@riseup.net> Sent: ‎23/‎03/‎2015 1:48 PM To:
> "bitcoin-development@lists.sourceforge.net"
> <bitcoin-development@lists.sourceforge.net> Subject: Re:
> [Bitcoin-development] Criminal complaints against "network
> disruption as a service" startups
> 
> If you (e.g. Chainalysis) or anyone else are doing surveillance on
> the network and gathering information for later use, and whether or
> not the ultimate purpose is to divulge it to other parties for
> compliance purposes, you can bet that ultimately the tables will be
> turned on you, and you will be the one having your ass handed to
> you so to speak, before or after you are served, in legal parlance.
> Whether or not the outcome of that is meaningful and beneficial to
> any concerned parties and what is the upshot of it in the end
> depends on on what you do and just how far you decide to take your
> ill-advised enterprise.
> 
> Chainalysis and similar operations would be, IMHO, well advised to 
> cease operations.  This doesn't mean they will, but guess what:
> 
> Shot over the bow, folks.
> 
> Jan Møller:
>> What we were trying to achieve was determining the flow of funds 
>> between countries by figuring out which country a transaction 
>> originates from. To do that with a certain accuracy you need
>> many nodes. We chose a class C IP range as we knew that bitcoin
>> core and others only connect to one node in any class C IP range.
>> We were not aware that breadwallet didn't follow this practice.
>> Breadwallet risked getting tar-pitted, but that was not our
>> intention and we are sorry about that.
> 
>> Our nodes DID respond with valid blocks and merkle-blocks and 
>> allowed everyone connecting to track the blockchain. We did
>> however not relay transactions. The 'service' bit in the version
>> message is not meant for telling whether or how the node relays
>> transactions, it tells whether you can ask for block headers only
>> or full blocks.
> 
>> Many implementations enforce non standard rules for handling 
>> transactions; some nodes ignore transactions with address reuse, 
>> some nodes happily forward double spends, and some nodes forward 
>> neither blocks not transactions. We did blocks but not 
>> transactions.
> 
>> In hindsight we should have done two things: 1. relay
>> transactions 2. advertise address from 'foreign' nodes
> 
>> Both would have fixed the problems that breadwallet experienced. 
>> My understanding is that breadwallet now has the same 'class C' 
>> rule as bitcoind, which would also fix it.
> 
>> Getting back on the topic of this thread and whether it is
>> illegal, your guess is as good as mine. I don't think it is
>> illegal to log incoming connections and make statistical analysis
>> on it. That would more or less incriminate anyone who runs a
>> web-server and looks into the access log. At lease one Bitcoin
>> service has been collecting IP addresses for years and given them
>> to anyone visiting their web-site (you know who) and I believe
>> that this practise is very wrong. We have no intention of giving
>> IP addresses away to anyone, but we believe that you are free to
>> make statistics on connection logs when nodes connect to you.
> 
>> On a side note: When you make many connections to the network
>> you see lots of strange nodes and suspicious patterns. You can
>> be certain that we were not the only ones connected to many
>> nodes.
> 
>> My takeaway from this: If nodes that do not relay transactions is
>> a problem then there is stuff to fix.
> 
>> /Jan
> 
>> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net> 
>> wrote:
> 
>>> That would be rather new and tricky legal territory.
>>> 
>>> But even putting the legal issues to one side, there are 
>>> definitional issues.
>>> 
>>> For instance if the Chainalysis nodes started following the 
>>> protocol specs better and became just regular nodes that
>>> happen to keep logs, would that still be a violation? If so,
>>> what about blockchain.info? It'd be shooting ourselves in the
>>> foot to try and forbid block explorers given how useful they
>>> are.
>>> 
>>> If someone non-maliciously runs some nodes with debug logging 
>>> turned on, and makes full system backups every night, and
>>> keeps those backups for years, are they in violation of
>>> whatever pseudo-law is involved?
>>> 
>>> I think it's a bit early to think about these things right
>>> now. Michael Grønager and Jan Møller have been Bitcoin hackers
>>> for a long time. I'd be interested to know their thoughts on
>>> all of this.
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>>
>>>
>
>>> 
Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot 
>>> Media, is your hub for all things parallel software
>>> development, from weekly thought leadership blogs to news,
>>> videos, case studies, tutorials and more. Take a look and join
>>> the conversation now. http://goparallel.sourceforge.net/ 
>>> _______________________________________________ 
>>> Bitcoin-development mailing list 
>>> Bitcoin-development@lists.sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>
>>> 
> 
> 
>> ------------------------------------------------------------------------------
>
>> 
> 
> Dive into the World of Parallel Programming The Go Parallel
> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all things parallel software development, from
>> weekly thought leadership blogs to news, videos, case studies,
>> tutorials and more. Take a look and join the conversation now. 
>> http://goparallel.sourceforge.net/
> 
> 
> 
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/ 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

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

iQEcBAEBCgAGBQJVD6mmAAoJEGxwq/inSG8CkLUH/iWvn7kp6KW2fe5RFca1eAmH
L+5P+kNDzMARIRt8A3CvopoQQMZx44aZ8pMdErUk+78A7oeP/x+scYEkSiXE17Iv
saBWv43mO+qFxgVrU7y+9njwLJoywHitBymhLGisi3hv+H7lfIMdPK2dLVThwxel
bVO0Ga8Y9qDYAwtK23yEOCT7klj5mT0tG50U4HxDpIXaJj8kCnVUC2O1MdYhr1pP
93cDuhBmXOg7sOLAPpdWVhgfnz0Vm8M0ZWUIK+4FGzpQugWHcmdp3YUDCeczOYzD
u5zVdAqvdL6qQcWkUcGfkKaAqfJH3u5F2zeQvDUEJeeEz1lWnrsXuT7cCvcp/TU=
=6io6
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

[Thy Shizzle]

I don't believe that at all. Analyzing information publicly available is not illegal. Chainalysis or whatever you call it would be likened to observing who comes and feeds birds at the park everyday. You can sit in the park and observe who feeds the birds, just as you can connect to the Bitcoin P2P network and observe the blocks being formed into the chain and transactions etc. Unless there is some agreement taking place where it is specified that upon connecting to the Bitcoin P2P swarm you agree to a set of terms, however as every node is providing their own "entry" into the P2P swarm it becomes really up to the node providing the connection to uphold and enforce the terms of the agreement. If you allow people to connect to you without terms of agreement, you cannot cry foul when they record the data that passes through. To say Chainalysis needs to cease is silly, the whole point of the public blockchain is for Chainalysis, whether it be for the verification of transactions, research or otherwise.

-----Original Message-----
From: "odinn" <odinn.cyberguerrilla@riseup.net>
Sent: ‎23/‎03/‎2015 1:48 PM
To: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

If you (e.g. Chainalysis) or anyone else are doing surveillance on the
network and gathering information for later use, and whether or not
the ultimate purpose is to divulge it to other parties for compliance
purposes, you can bet that ultimately the tables will be turned on
you, and you will be the one having your ass handed to you so to
speak, before or after you are served, in legal parlance.  Whether or
not the outcome of that is meaningful and beneficial to any concerned
parties and what is the upshot of it in the end depends on on what you
do and just how far you decide to take your ill-advised enterprise.

Chainalysis and similar operations would be, IMHO, well advised to
cease operations.  This doesn't mean they will, but guess what:

Shot over the bow, folks.

Jan Møller:
> What we were trying to achieve was determining the flow of funds
> between countries by figuring out which country a transaction
> originates from. To do that with a certain accuracy you need many
> nodes. We chose a class C IP range as we knew that bitcoin core and
> others only connect to one node in any class C IP range. We were
> not aware that breadwallet didn't follow this practice. Breadwallet
> risked getting tar-pitted, but that was not our intention and we
> are sorry about that.
> 
> Our nodes DID respond with valid blocks and merkle-blocks and
> allowed everyone connecting to track the blockchain. We did however
> not relay transactions. The 'service' bit in the version message is
> not meant for telling whether or how the node relays transactions,
> it tells whether you can ask for block headers only or full
> blocks.
> 
> Many implementations enforce non standard rules for handling
> transactions; some nodes ignore transactions with address reuse,
> some nodes happily forward double spends, and some nodes forward
> neither blocks not transactions. We did blocks but not
> transactions.
> 
> In hindsight we should have done two things: 1. relay transactions 
> 2. advertise address from 'foreign' nodes
> 
> Both would have fixed the problems that breadwallet experienced.
> My understanding is that breadwallet now has the same 'class C'
> rule as bitcoind, which would also fix it.
> 
> Getting back on the topic of this thread and whether it is illegal,
> your guess is as good as mine. I don't think it is illegal to log
> incoming connections and make statistical analysis on it. That
> would more or less incriminate anyone who runs a web-server and
> looks into the access log. At lease one Bitcoin service has been
> collecting IP addresses for years and given them to anyone visiting
> their web-site (you know who) and I believe that this practise is
> very wrong. We have no intention of giving IP addresses away to
> anyone, but we believe that you are free to make statistics on
> connection logs when nodes connect to you.
> 
> On a side note: When you make many connections to the network you
> see lots of strange nodes and suspicious patterns. You can be
> certain that we were not the only ones connected to many nodes.
> 
> My takeaway from this: If nodes that do not relay transactions is a
> problem then there is stuff to fix.
> 
> /Jan
> 
> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net>
> wrote:
> 
>> That would be rather new and tricky legal territory.
>> 
>> But even putting the legal issues to one side, there are
>> definitional issues.
>> 
>> For instance if the Chainalysis nodes started following the
>> protocol specs better and became just regular nodes that happen
>> to keep logs, would that still be a violation? If so, what about
>> blockchain.info? It'd be shooting ourselves in the foot to try
>> and forbid block explorers given how useful they are.
>> 
>> If someone non-maliciously runs some nodes with debug logging
>> turned on, and makes full system backups every night, and keeps
>> those backups for years, are they in violation of whatever
>> pseudo-law is involved?
>> 
>> I think it's a bit early to think about these things right now.
>> Michael Grønager and Jan Møller have been Bitcoin hackers for a
>> long time. I'd be interested to know their thoughts on all of
>> this.
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot
>> Media, is your hub for all things parallel software development,
>> from weekly thought leadership blogs to news, videos, case
>> studies, tutorials and more. Take a look and join the 
>> conversation now. http://goparallel.sourceforge.net/ 
>> _______________________________________________ 
>> Bitcoin-development mailing list 
>> Bitcoin-development@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

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

iQEcBAEBCgAGBQJVD34mAAoJEGxwq/inSG8CvrQH/28Rt26oGdo9rS+PaR1fIQ1p
Jwks11Axsmu5x3emTgIz0xUJ6zz/4ERM0LeNLBpfSFwZyLbuCgw1uiJplT+9uPgY
hPXb9OTNejfWZJjYc3i6rNjf2SNc5E3/4PtgeOI6lI/SsGQ6ineNm6gFjwe8xVpt
wCLOPetzCukQegXluFZZdALnPDf4H9yAeSsrfX2h2iCBAJ3qd9f1DP7+e6hvr+xr
POVBjlRYtnSd/viKJ2IhMbRvnqd86pRNAKEWrjZp0CIkGyY7wh4nqtYErZi4TcOK
H7yhU8o4/mgTNSIYdLTOSMlRi+nTMPWUD2jvO/Z9i9VTR9afn8E7j7iHD6QPMB0=
=vdbG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development