Large Bitcoin Collider (Collision Finders Pool)

[doc12]

Hi I have a off-topic but LBC related question:

If one addess generated from BIP32-Seed is compromised, are the remaining addresses save or is the whole BIP32-Wallet compromised then?

I am no BIP32 expert, but as far as I understand the specification, you would have to

a) find a BIP32 private key (can happen)
b) You'd have to know it is a BIP32 privkey (LBC cannot know that, but we could assume so)
and finally
c) You'd have to know the master seed to derive any children.

Obviously, c) is the KO-criterion, maybe even the only necessary criterion to break BIP32-Seeds and such a master seed is nothing within the reach of the LBC. LBC just looks at private keys and the hash160 they resolve to.

AFAICS the answer is therefore: no


Rico

THX !

[1715026113]

1715026113

[1715026113]

1715026113

[1715026113]

1715026113

[1715026113]

1715026113

[unknownhostname]

9c297c7914d3a0d212abe54dfcf3300683d039ab:c:priv:0000000000000000000000000000000000000000000000000008c184912ff001 + 0xf9e

[SlarkBoy]

only 4 addresses have been taken. where the rest?
I'm going to wait until 25 april, then moved to this address 1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6

[rico666]

only 4 addresses have been taken. where the rest?
I'm going to wait until 25 april, then moved to this address 1LBCPotwPzBvBcTtd7ADGzCWPXXsZE19j6

I think the addresses have been placed so we find about 1 a day. The pool has gained speed since then, so we find one each 7-8 hours. Right? Most people who have no hook-find setup check their FOUND.txt only once 24-48 hours, so I expect some finds to pop up in time.

But I agree: April, 25th should be a sufficient deadline.


Rico

[unknownhostname]

last address found 14 hours ago ... I guess someone else found something ..

[rico666]

last address found 14 hours ago ... I guess someone else found something ..

Looks like RealDuke - he will handle it in a couple hours.

[rico666]

last address found 14 hours ago ... I guess someone else found something ..

In a gesture of trust, SlarkBoy gave me all the private keys to all the Bounties he planted.

So I could find out, that the unclaimed bounty of https://blockchain.info/address/1L1TjHQQM75mLYVn9QoFuBvWN7rPPTaio
was in fact given in a block to one of your clients. It seems this client is running an old version of LBC and therefore I assume its BLF file was not up-to-date also.

This client returned PoW for the block interval he should have found something. If you were not informed, either the hook-find is not working (unlikely) or outdated BLF (more likely).

I will not tell the concrete client and block interval, just as a hint you might want to update all your clients (1.067 and current BLF) if you don't want some bounties to escape you.

Sure, an older BLF will still see the 2014 dormant 10.000 BTC address you're looking after.  


I may reschedule the block(s) in question as the LBC easter egg hunt.


Rico

edit: Other than that, it seems we are finding everything we are supposed to find, although some people do not/cannot report their finds immediately.

edit2: @unknownhostname same applies for the unclaimed bounty https://blockchain.info/address/17VAHtuREREixUm1ZqextyEt4VWNv86E5Z
old client...

[unknownhostname]

im too lazy to check those clients for 0.01 btc :>

[Janu$$]

the number of strings that we cannot get is then:

                                                                            k (1-1/k) ^n

where n=2^257 (input) and k = 2^256 (output).

The result is: 2^256 * (1 - 1/2^256) ^ (2^257) =  2^256 * ((1 - 1 / 2^256)^(2^256))^(2) = 2^256 * ((1/e)^2) = 0,135 * 2^256      so we can get at this stage the 86,5% of all the 256 bit strings.

I would have appreciated if we could have given this more time (especially me to wrap my head around it) - but sure, maybe someone else can chime in with some insight.

All these models assume a hash function to behave like a random (or pseudo-random) number generator. Normally, a good hash function - by design - tries to

map the expected inputs as evenly as possible over its output range.

see https://en.wikipedia.org/wiki/Hash_function#Uniformity

Also

Note that this criterion only requires the value to be uniformly distributed, not random in any sense. A good randomizing function is (barring computational efficiency concerns) generally a good choice as a hash function, but the converse need not be true.

I had a look at the referenced paper, but I'm still not convinced about the premises to model a hash function as a pseudo-random generator. Please don't forget, that I've been looking at the SHA256 and RIPEMD160 implementation for months! They are both very similar (RIPEMD160 being way more "light-weight") and I cannot see how these would qualify as pseudorandoms.

...

Rico

Hi rico, hi arulbero,

to check wether sha256 and ripemd160 behave like a PNG and meet the expectations regarding the formula  k (1-1/k) ^n one could do that:
Hash all possible 2^33 bit values with sha256 and XOR the first half of the bits with the second half. The 128 result is xored in the same manner. The 64 bit result as well. Thus we get a 32 bit output from the 2^33 input. Check how many values of all possible 32bit expression could not be generated. If k (1-1/k) ^n is applicable to sha256 than the result should equal arulbero´s 13,5%.  If this is true, than this small model can be used to investigate futher assumptions regarding distribution and prohabilities.
For Ripemd160 the same can be done with a 2^21 input and 2^20 output.
Due to the neutral behavior of XOR it should be possible to scale the 160 respectively 256 bit problem down to a manageable size.

Regards,
Janu$$

[unknownhostname]

24h Pool Performance: 2048.75 Mkeys/s

I currently have 2129Mkeys


the pool is slower than me :>

[rico666]

24h Pool Performance: 2048.75 Mkeys/s

I currently have 2129Mkeys


the pool is slower than me :>

  You might want to look at the green line too. (1h avg: 2312 Mkeys/s)

Although - yes - you provide 90% of the pool speed. With CPUs. It's insane. It's like almost 4000 CPU (modern) cores.
Or the equivalent of 100 of my notebooks (with GPU).

If I didn't know better I'd suspect you are testing some ASIC prototype. 


Rico

[unknownhostname]

If I didn't know better I'd suspect you are testing some ASIC prototype.  


Rico

gief GPU please ... that means 4k CPU's with at least 1k GPU's = billions of keys / sec

[Real-Duke]

gief GPU please ... that means 4k CPU's with at least 1k GPU's = billions of keys / sec

That would be the moment I have to quit 

[rico666]

That would be the moment I have to quit 

Didn't you want to tell us something? 

[rico666]

Next would-have-been-unknownhostname-bounty-if-he-had-his-clients-up-to-date:

https://blockchain.info/address/137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH

and user "cagrund" missed it by 7 seconds (else his client would have gotten it assigned by the server).



Rico

[unknownhostname]

Next would-have-been-unknownhostname-bounty-if-he-had-his-clients-up-to-date:

https://blockchain.info/address/137L9goS9xfjvBWTNkWBb2a3jYveJrAWoH

and user "cagrund" missed it by 7 seconds (else his client would have gotten it assigned by the server).



Rico

My machines didnt found anything for about 1 day ... usually it was getting around 3/day ...


today it didnt get anything

[rico666]

My machines didnt found anything for about 1 day ... usually it was getting around 3/day ...

today it didnt get anything

You should just look which of your servers run 1.031 version. Update these. It's a pretty good indicator that these have an older BLF file.
You do not need to look at the 1.067 Servers - if they get the block, they find it.

If you want a list of the 1.031 IPs I can send it via PM.

Rico

[ddosamerica7]

This is actually really cool. I'm going to start running the VMWare iso and see what I can find. Cheers man!  

[unknownhostname]

2e62d626197061e24c6e7981bfd7bbb085a2ec9d:c:priv:00000000000000000000000000000000000000000000000000098434c83ff001 + 0xfeb
b3b5e4f4740ee89cb0fc9ad729699054a8928592:c:priv:0000000000000000000000000000000000000000000000000009b4b6a3bff001 + 0xfbd

[rico666]

2e62d626197061e24c6e7981bfd7bbb085a2ec9d:c:priv:00000000000000000000000000000000000000000000000000098434c83ff001 + 0xfeb
b3b5e4f4740ee89cb0fc9ad729699054a8928592:c:priv:0000000000000000000000000000000000000000000000000009b4b6a3bff001 + 0xfbd

Hey whale! Leave some krill for the smaller fish.   (ok - a whale is not exactly a fish ... but hey)

Rico