I have a very special address for events like this:

1DoofusZqKv2wDhUAvKRjUPVQsyZw3NKCw


Rico

This.

~1820 “Rail travel at high speeds is not possible because passengers, unable to breathe, would die of asphyxia.” - Dionysius Lardner
~1950 "Continental drift is impossible ... young scientists shouldn't work on such a stupid idea" - MIT geology courses for undergrads
~1960 "A Proton/Neutron is indivisible" - Physics consensus
~1990 "You cannot have structures smaller than half of the light wavelength." - Physics consensus photolithography
[...]
~2016 "The DAO is safe" - slock.it


Of course one can assume the task is infeasible. And at the moment I have no indication of the contrary. On the other hand not doing something because everyone says it's infeasible seems just wrong. The list above would not seem ridiculous to us today if people were like that. If nothing else, I have learned in the past month a lot of things about efficient computation of the privkey -> pubkey -> *munge* *munge* -> address

That's why I agree with the GPU requirement. If someone could hack oclvanitygen to do certain bidding (throw out a list of uncomressed and compressed addresses for a given privkey-range), that would certainly leverage the project by at least 3 orders of magnitude.

As I started to explore how to efficiently distribute the work on several computers of mine, I did some more hacking towards a user-friendly client. I hope at least those interested in physics do like the name:





Rico

Meanwhile in "pillar node land"...


So the blockchain now takes around 91GB, with logs, and Index etc. etc. 93GB. Bitcoind takes about 1 core and 1,5GB of memory.

Right now, I'm going to increase /dev/vdb to 200GB and after that, I have not yet decided if I increase it to 400GB or broadcast a big "Fuck You" to the network. 


Rico

The Large Bitcoin Collider (LBC - a.k.a. Collision Finders Pool) is a distributed effort to find private keys to BTC addresses that have funds on them.
See also https://lbc.cryptoguru.org/man/theory#what-we-do
It was using clients that have been developed in the Collision Attack Feasibility Study and later also a derivative of brainflayer (called "HRD-core"). Meanwhile, HRD-core is a complete re-implementation of the BTC address generation process and as such the fastest program on the planet!

Project homepage: https://lbc.cryptoguru.org
Downloads: https://lbc.cryptoguru.org/download
Statistics: https://lbc.cryptoguru.org/stats
Twitter: https://twitter.com/LBC_collider

News:

!!!Visit the New Thread 2.0!!!

• 2017-03-27: CPU generators with arulbero-ECC released with up to 79% speed increase
• 2017-03-25: again 250% speed increase with a new CPU/GPU hybrid generator! (Arulbero-ECC)

TODO:

Pending work/development on the LBC components.

Generator (hrd-core):

• unified generator (one binary for CPU and GPU)

LBC client

• More elaborated benchmark (not just maximal performance, but adaptive, also in relation to number of CPUs used)
• Aggregator: manage several generators even on remote servers by just one LBC client (postponed)

LBC server

• manual updates & extensions (GPU/OpenCL)

----

German thread: https://bitcointalk.org/index.php?topic=1581701.0

I beg to differ with eligius.st merged mining "Yes".

Allegedly eligius has merged mining.

In reality I never saw a single NMC (or a fraction thereof), nor any stats of what I would have been maybe eventually hypothetically have merge-mined. Nor any answer to my query about such.

I think it is safe for now to mark eligius.st as merged mining "No".


Rico

 

2^160 keys. See also this.

As for the list of balances: you can get an up-to-date list with all addresses that have at least 1 Satoshi on them (~9.2 mio adr) from me. Sorted from highest balance to smallest. So you can cut-off wherever you want. However not for free 0.01BTC - yes, I am that greedy. PM me if interested.

Rico

It seems "grondilu" also contributed code that is part of the library to the Rosetta Code site, so I took the liberty of rewriting it.

Result is code which is about 40 times faster (orig vs pcun)


So I may finally ditch that Go implementation in my Collision Attack Study.

Rico

I have several hypotheses

• you're talking about a very special definition of "full node"
• or you're talking about a very special definition of "virtually free"
• or you have not operated a "pillar node" (see above in the thread) in the past year
• or you're a mining stakeholder not interested in sharing tx fees

I have several more, but these could be interpreted as "ad hominem" (which I believe
they aren't, but we would have to dig into your knowledge of the bitcoin network and might reveal a lack of).

Am I correct, that you offer VM hosting "virtually for free"?

Rico

No, running a full node does not protect your privacy. Contrary to a lightweight that connects to supernodes (e.g. Mycelium) where you lose privacy to some entity (i.e. the operator of the supernode), With a full node you lose privacy globally as today the network sees the originating IP for a transaction. Because statistically the "Relayed by IP" information is now unmasked to the world.

However, I am NOT advocating the lightweight/supernode concept. Just debunking the privacy claims.


 

So... if all nodes out there were "full nodes" according to your definition (and probably according to the bitcoin.it wiki, which currently shows only a Error 524 cloudflare) - where would the "every block" come from? If all nodes today turned on pruning, bitcoin could never ever add a new full node again.


Oh. So now we are in the "define that word" game. What will we call nodes "that are able to bootstrap full nodes"? Hypernodes?
I'm fine with that. Let's incentivize only those.


See above. Apparently we are talking about some other name now. Because there clearly is a difference between "full nodes" and "more full nodes". And if you - just for a second - forgot about nitpicking and remembered the true reason why we have this discussion in the 1st place (ensuring a robust network), you would probably start to see value in the "more full nodes".


True. How is that different from the situation today? Does "incentive" make a difference there?


Actually those nodes would do more harm than good, because without dropping invalid tx they could cause kind of epileptic brainstorm to the bitcoin network, where a malevolent attacker would feed invalid tx and rely on these nodes to amplify his spam.

How about this:

I will call the nodes that IMHO would deserve an incentive "pillar nodes". These are nodes, that

a) can bootstrap any other node, i.e. carry all blocks
b) do validate transactions
c) maybe some more requirements about throughput/latency...
d) are available 24/7 (or sufficiently close to it)


Let me compare the situation to the electric grid. A blackout is a bad thing. Even more so, because there can be a cascade of events leading to a blackout in some geographically extensive area. Some power plants and/or grid lines go down, causing overload, causing shutdowns, causing more shutdowns. Nearly ALL modern power plants cannot start without power.

There are some, that can. I know of a hydroelectric power plant that is designated to be able to start up a nuclear power plant in case everything else (grid, generators, ...) went black. Because hydroelectric power plants can start delivering power "into the night".

I hope it is clear where I am heading with this.

In the early days of Bitcoin, a "full node" actually meant a node containing ALL blocks. It meant validating transactions. It even meant mining. The only thing it never meant was 24/7.

People did run full nodes, because it was not a big deal (I had a 200GB HDD in 2010 and the blockchain was like 1 GB in 2012) and there was an incentive: mining This incentive is now gone, the blockchain today is 85GB and I have purged my wallet to my home server, because I will certainly not let it occupy my quite expensive 512GB NVMe SSD.

Running a node similar to what it used to be back then (= not crippled) has become a PITA nowadays. You basically have one core constantly busy, around 750GB of monthly traffic, and 85GB of disk space, constantly rising.

How long do you expect this will go on with people running "nodes like that" for free?

If your answer to this problem is "then don't run nodes like that" (which at the moment I'm afraid is just what you're saying), then unfortunately you're advocating Bitcoins demise in the long term.


Ok. I see that now. Even though the fingerprint does not contain the IP, it can be derived from the connection info. If you see above the lightweight/supernode concept that is e.g. with Mycelium - that is actually something that would ensure the senders anonymity in this case. Again, I'm not advocating this. You have to trust someone, which is not quite the concept we would like to have.

How about this:

A "pillar node" is a node that

a) has all blocks - can bootstrap anyone
b) verifies transactions
c) maybe some more requirements about throughput/latency...
d) is available "24/7" (say - at least 99% of the week)
e) is purely altruistic: does not have a wallet

A corollary to e) would be "full nodes containing a wallet cannot add any info to the tx" - for their own good.

Now if some "pillar node" got a tx without a fingerprint, it could be from the originating IP, but effectively all it knows is that the originating IP does have a wallet or (because that should be optional) simply forfeits any potential incentive or just relayed the tx from another wallet-node that did the transaction. The deanonymization problem should be gone with that.



Rico

P E R F E C T !!!

Thanks for bringing this up. Let's scrap the mining incentive. Same story.


Rico

Uh... I got a /48 IPv6 net for every account with our ISP. If I am not entirely mistaken, this is 2⁸⁰ addresses...

Even if you stayed in IPv4 land, then you have HP, IBM, the US military and what not with their Class-A networks.

And even if you somehow could/would reduce it to a node per IP, it's quite discriminatory in almost any NAT environment.

=> I do not think that is a viable solution.


Rico

About education: I've been longer a - registered - contributor to Wikipedia than Bitcoin actually exists. Trying to educate me about AGF is like trying to count - slowly - from 1 to 10 in front of a sentient computer. ~ (c) Douglas Adams

The article is not about "bitcoin's security model", it is about it's authors twisted view of the bitcoin ecosystem. That's what made me angry in the 1st place.


Stop right there. You lost the bet. What was the wager?


When my youngest son played the flute at some school event, I also told him it was good. This is not an endorsement of his flute skill, nor of my musical perception skill. There is a czech saying "weak pupils have to be praised more often" - is that what you want? More praise?


Rico

In case you are in need of serious $SUBJ, I'm offering my services at 0.1BTC/h.

By serious, I mean I am highly-skilled, resourceful, experienced, with formal education in computer science and with quite a lot machinery at my fingertips.

call me when e.g.

• you need some custom parsing of the blockchain or anything else
• have some data blob you need to convert to some other specific format
• fetch and/or extract, process, analyze data
• machine translations, natural language processing, deep learning and similar
• legal and not annoying crypto-specific VM hosting with a punch
• ...

For less public yadda yadda, thread closed. PM me.


What I'll do and what not:

In general, I consider myself a grey hat. Ethics is relative and I will build you that formidable Damascus steel knife, but it's your responsibility what you do with it. If you expect me to use it, I will - at most - cut a cucumber with it, not someones throat.

If I see you need to extract terabytes of emails which you'll use for spamming: I will extract them, but please do not expect I would let you do that spamming from any of my machines.

If I see you are preparing some credit card fraud or similar, I'll stop it right there.

In short: If there is one jurisdiction on this planet, where your action is legal, I'll most probably do it. If you want something to be done that is illegal at any jurisdiction on this planet, forget it.

The more interesting the job, the more probable it is I'll do it.

1h minimum commitment , I don't take smaller jobs than that and I do not negotiate the rate. Also, my skill will accomplish what the force of many cannot.

Remember:

First class people hire first class people; second class people hire third class people - Manfred Kets de Vries



Rico

Yeah - I know how MediaWiki works...


Pretty much sure. If it hasn't changed radically in the past 24h. It's mindless. "You should run a full node, because ... 'privacy'" - which actually is an outright lie. It talks about how beneficial full nodes to the network are and then gives advices how to run a crippled "full node" (pruned, limiting connections, bandwidth targeting and disabling listening,  -blocksonly, ...) which isn't a full node anymore - ofc.


So? That's some faking that could skew statistics - or malevolently bind "good nodes" shortly. It's not a faking that could actually pretend in concrete data transfer a true full node. I do not care about faking statistics, I care about the robustness of the Bitcoin network.


Ah - ok (I like when the discussion changes from IF to HOW). This is for a separate thread, as it requires solving another problem of Bitcoin: Trustless exchange of digital goods without an intermediary. Until then Bitcoin is of course not a very good P2P payment platform. It's most probably even for an own BIP.  I have a crude concept for that in my mind and it could use more elaboration through discussion.

IMHO one could start off even more primitively: Announce bounty, negotiate sender, receive blocks, send bounty. In case the receiving node would not fullfill it's promise, ban it. That way it could "rip off" data from the network but at the cost to land in some banlists - which kind of counters the desire of priorization. Ripping off data from the network is todays default mode of operation, so limited damage.


WHAT? The "you" in de-anonymized is who exactly? The one sending the tx? The node operator? It doesn't matter - why is there a deanonymization you think? I didn't write the fingerprint would contain IP addresses. Fingerprint of a relaying node could very well point to a Bitcoin address (for the receiving funds). Are you telling me Bitcoin addreses break the idea of privacy? 

Think before you dismiss something as terrible idea. You sure you want to participate in a technical discussion leading to some advancement or do you prefer a "technical discussion" where you can excel in thinking of ways how something doesn't work or why it's not possible?

The concept I'm talking about has several problems, but deanonymization isn't one of them. Blowing things out of proportion is. Because as it stands, you would have n transactions (to relaying nodes) for every 1 transaction (which makes it into the block). And who should relay these? ... This is something that probably should be addressed with a sidechain - actually IMHO the perfect use case candidate for that.


Rico

I'm operating a full node, and a fat one. Not pruned, running 24/7 quite among the top 30 or so.

If I could lay my hands on the faggot who wrote this: https://en.bitcoin.it/wiki/Clearing_Up_Misconceptions_About_Full_Nodes, it would not leave him happy.

Some may be offended by the following not politically correct statements, Caution! Turn around - walk away. Don't say you haven't been warned.

IMHO the farthead who wrote this Bitcoin Wiki article is either a Chinese operator of some mining pool, or - given the English - someone hired by some mining pool operator. Or someone completely delusional. I'm actually not sure how anyone could advocate the altruism aspect of a full node, while there is a consolidation and condensation and monopolization of mining (pool) operations. Which are actually DESTINED to get all the transaction fees in time.

So excuse me if I rant, but while a mining pool operator usually gets ALL transaction fees while he does NOTHING for decentralization, the full node operator is expected to be altruistic. Gimme a break. A surgical strike against the top10 mining pool operators TODAY and our beloved bitcoin is in the gutter for quite some time to come. Don't want to think about the situation in the future.

I do not expect full nodes to get any of the mining reward, but I think it would be fair if the full nodes got their share from the tx-fee.

As for "faking full nodes" ... srsly? If you deliver blocks out there, so new nodes can sync faster - isn't it very easy to see if you are faking the data?

A 1st step could be some tx-fee for seeding the network. I.e. you could get your full node synced and your 100GB blockchain (or more in the future) downloaded eventually - for free if you wished so. But you could also pay/indicate the network some BTC bounty for priority data.

A full node could attach it's own fingerprint to a transaction it has relayed. This relay-blockchain of fingerprints could be thrown away when the tx was integrated in the block, but the miner would pay - say 50% of the tx fee - to the relaying nodes in that list.


Rico

It's about a different - and very academic - topic. It's about the probability, that some addresses cannot be produced using the existing algorithm.
And Vitalik gives the exact probability as

[–]vbuterin 1 point 2 years ago
It's the probability that all 2²⁵⁶ private keys do not hash to a given address, yes.
Actually, it's (1 - 2¹⁶⁰ ) ^ (2²⁵⁷ - 2³³ - 1954) due to key compression and redundant EC points, but close enough.

He's not precise when he says "all ... keys", because he meant "any of the ... keys". But this is something we do not care about. a) it's never going to happen and b) even if there might be this theoretical private key cannot hash to a valid address ... pfff who cares - no one will ever see that address.

As for the question how many priv keys there are for each public key, it's still safe to believe them are 2⁹⁶ (on average).


Rico

I'm quite near the top of the ladder: https://bitnodes.21.co/nodes/leaderboard/, You need about 100GB disk space for the full chain, one CPU is constantly busy and the monthly transfer data is around 700GB.

No, in terms of money it's not worth it. But if you have the spare capacities - why not? And yes - forget the nice talk about how you help the network. Especially when it comes from some mining pool gonzo.



Rico

I fetched the library, squashed some bugs and silenced some others.

At least it "runs" now with Perl 5.24 without immediately breaking. Unfortunately it runs, but doesn't "work" yet. (Wrong computations).
I'll dig into that deeper.

The original author did a great job, but one can see that the code has been mostly lying around for 4+ years and that is never a good thing.
I'm confident I'll be able to shape it up again and will publish then. Stay tuned.


Rico

I should probably add, that for me - from a moral perspective - it is stealing.

OTOH - also from a moral perspective  - I consider some performances of some employees as stealing the company funds, because they get something for nothing.  Not sure if that would be considered stealing from a legal perspective.

And "Legal" this part of the forum has in its name.

I suppose the question cannot be answered in general, as it seems to depend at least on the jurisdiction. See another thread here, where the legal interpretation in Japan is pointed out. "Bitcoins cannot be owned". Most legislative constructs require ownership as prerequisite to theft.

In Germany you actually do OWN the paper Eur money, so you are even allowed to burn it if you like. Different story in US and completely different story in Thailand.

Given the fact, that in Japan Bitcoins cannot be owned, legally, if you went to Japan and performed there a collision attack or seizure of BTC funds, it would legally not be stealing. Now even when you left Japan, you probably would be the rightful owner of the seized bitcoins because you did not steal them. Of course only after you actually left the Japanese jurisdiction, because there you could not be "owner" of bitcoins.


Rico

So the study has been going on for some days and I have some side-info I'd like to share:

Other attempts

Lurking in the forums I learned that someone in the german forum started something similar, more clandestine and - luckily - more naive. Wgetting http://directory.io ...  And these people write/think they are "IT-Freaks".

The Rico666-Vanity

I could offer a totally useless service of "the 1st Vanity address". Namely I found 1FVCvgkHJU7JczSm9NouG1hRico6668oBa and I know for a fact, there is no other pubkey containing that string before that pubkey. Where "before" means with a smaller privkey. By definition, "1st vanity address with a given string with the smallest numerical privkey" call such a specific vanity address the Rico666-Vanity. It's evil because insecure. But just for fun, if someone would like to know a specific Rico666-Vanity (6-7 chars), I could look it up.

Extending the Collision checks

Because I have now some 30bn pubkeys (and their privkeys) testset, I will run a crosscheck for any duplicates. RIght now I have checked "only" about 9 mio addresses with funds against 30bn keys. I have not checked these 30bn keys against the 30bn keys for any collisions. I do not expect to find any, but you never know...



Rico