Break it up into 25-50 CLAM "chunks" all on the same address.

The title of this thread is a bit misleading.  It should probably read "It appears BurtW had his CLAM address private key collide with a Dogecoin address". Maybe we can get it changed.

tldr: It appears to me that the same private key was generated by someone else's DOGE wallet and my CLAM wallet and may have also been generated by a BTC wallet.  So the provable collision is between my CLAM wallet and someone else's DOGE wallet.

I have 26 CLAM addresses where I claimed CLAM using an old BTC address.

Just to make sure I am not losing my mind I went to Just Dice and did the /addr check on all 26 addresses.

In all cases I got the expected result:
  

• The BTC address shows my activity from 2014
• The CLAM address shows my recent activity
• There is no activity on the LTC address
• There is no activity on the DOGE address

There is something very strange and fishy about the private key for xWAS3PbHr3FBdLsV1s8UYKuwXaJWMsTcjw.  You do not have to take my word for it, you can see for yourself.  Go to the chat room at Just Dice and type in "/addr xWAS3PbHr3FBdLsV1s8UYKuwXaJWMsTcjw" then open up separate browser tabs for the four addresses calculated.

• The BTC address shows activity from 2015-06-29 to 2017-05-19 which is not mine
• There is no activity on the LTC address, the only expected result
• The DOGE address shows activity from 2014-05-10 to 2015-12-28 which is not mine
• The CLAM address shows the claim activity from 2015-01-21 which is not mine
• The CLAM address also shows the recent activity from 2017-10-26 13:35:44 where I sent 25 CLAM and then 2017-10-31 14:16:16 when the 25 CLAM were moved by the other owner of the private key

So unless the owner of the DOGE address that claimed the CLAM address are the same person as the owner of the BTC address and that person used the private key for his DOGE address to create a BTC address on purpose, then this specific private key has collided twice.

Against all odds I believe I have proof of a private key collision!

It all started when 25 CLAMs just up and left my wallet without my permission.

The transaction is shown here.

Notice that my 25 clams left my address of xWAS3PbHr3FBdLsV1s8UYKuwXaJWMsTcjw and ended up at the new address of x8f8YKkNJk6mU92ZmerhWqwqqvZKnTaZ9Y where, at the time of this post, they sit.

The source address is valid and is mine:


The new address is valid and is not mine:


Digging into the source address we find that it was originally funded in the airdrop:


This means that the CLAM private key is either a BTC, LTC, or DOGE private key.

FACTS:  I have never owned LTC or DOGE and I only imported BTC private keys into my CLAM client.  The three possible source addresses for the airdrop are:


Remember, I only imported BTC private keys.  Therefore the only key that could have been mine is the private key for the Bitcoin address of 1Nro9WkpaKm9axmcfPVp79dAJU1Gx7VmMZ

Taking a closer look at that address you will see that the first transaction made on that address was on 2015-06-29 20:35:06.  Therefore this could not have been the address used to claim the CLAMS.  Also, I do not recognize this address as one of mine and my first CLAM transaction was on 4/19/2017 so I could not have moved the claimed CLAMs off the address on 2015-01-21 19:42:08!

My conclusion is that this address is an address that was generated by my wallet that collided with all this past activity.

The person that owned the DOGE address DSztgmhTsjfS7xxDPyVNeunmBbjaJMfz92 is the person that claimed the CLAMs and them moved them on 2015-01-21 19:42:08.

My client appears to have generated the same private key!

I expect this person noticed 25 CLAMS magically appear in their wallet and then moved them to another address.

I must have incredible luck - which I hope will someday translates into a win in the lottery

If you owned the DOGE address DSztgmhTsjfS7xxDPyVNeunmBbjaJMfz92, used it to claim CLAMs back in 2015, saw 25 CLAM magically appear in your wallet 2017-10-26 13:35:44, moved them 2017-10-31 14:16:16, and are feeling honest or guilty about it let's talk.

I would love another explanation.  Right now I am out 25 CLAMs.

I think the answer he is looking for is as follows.  From my current understanding of the vulnerability and the upgrade:

IF (you have upgraded the firmware to the latest) AND (someone gets physical access to your Trezor) THEN:

If they try to install ANY new firmware including old versions, their own hacking code, etc. they no longer have access to the secrets in SRAM because the latest firmware destroys all secrets in SRAM if and when ANY new code is loaded (including all future firmware updates).  Obviously the secrets are still kept in a safe and secure non volatile location, they are just destroyed in SRAM in order to prevent this very attack vector.

Now, his question might have been as as follows:

If someone manages to get physical access to my updated Trezor and then uploads an older version of the firmware (destroying the secrets in SRAM per the new code) is there any possibility that the old code will still put the secrets into SRAM even though the attacker does not have the PIN?  If so then, of course they can then upload a hack and get the secrets.

My assumption is that the old code accidentally left the secrets in SRAM during a code update but did not load them into SRAM until the PIN was correctly entered.  If so, then all is good.

Can TREZOR verify my statements above to be all true?

Most smart phones have calculators built in.  Do you have a smart phone?

Which wallet are you using?  I use Trezor and they did propose a signature algorithm and implement it but then they backed it out because the proposed algorithm did not get any traction with other wallets and exchanges.  This really needs an official BIP so that we can get everyone to implement the same algorithm.

OK then, we will see how it goes.

This is not a Byteball issue.  It is a SegWit issue.  Currently there is no standard message signing algorithm for SegWit addresses so you cannot sign a message using a SegWit address.

I was just so glad to see a real new account by a real person actually interested in Bitcoins and not just another account from an account farmer only interested in making a quick buck!

How about "If you owned Bitcoin on 2014-05-12 at 12:48:17 (block 300377) then you can claim your CLAMs!"

Welcome.  If you have any specific questions let me know.

In the so called "evidence" used to get the sealed warrant for my arrest under the Patriot act the government's view of Bitcoin was expressed as "there are little or no legal reasons for using Bitcoins".  So from their point of view the simple fact you are a Bitcoin user or enthusiast can be used to start an investigation into all of your activities.

As dead as a dead zombie - for real

Done.  Thanks.

So, are you are claiming that you really expect to find Bitcoins that have been properly stored using a functioning cryptographically secure random number generator with an adequate source of entropy?

Zero or maybe imperceptibly and immeasurably just above zero.

All of the sudden my Byteball client fails to run with the following exception:


Which is then followed by many pages (thousands) of addresses.

I have included the lottery chat bot.  Could this be being caused by a bug in that chat bot?

Also, I have not updated to the latest version yet.  Would it help to update?

Can I temporarily remove the lottery chat bot by editing a file somewhere so I can get my client to run again?

 

You and your opinion are totally wrong.  The entire purpose of this project is to see just how quickly sequential addresses can be generated in order to sequentially search and find addresses that currently contain or have previously contained Bitcoin.  Since that is the purpose there is no reason to under report the number of addresses that have previously contained Bitcoins.  With the exception of Bitcoins that have been purposefully placed in low entropy addresses, like the puzzle transaction, or Bitcoins that have been inadvertently placed in low entropy addresses, for example from a defective random number generator, this project will never find any Bitcoins that have been properly stored at Bitcoin address generated from an adequate source of entropy.  But again, that is not the purpose of the project.

Also, your comment "we cannot rely on this sort of luck" indicates you have absolutely no idea how this project works.  It is sequentially creating all possible addresses starting at private key 0x1.  There is no luck involved.

Oh wait, I just ranted at another f!@#ing account farmer that will never be back to this thread.  Oh well...


Bruno, you crack me up.  Blaze on dude.

Knowing that the 22 seeds are in order but that the position of the two missing words is not known helps some but the key can still be brute forced.

This only increases the number of trials by about 24² = 576 so the total number of trials is less than 2,415,919,104

Assuming English words are being used here is the list.

So you only have to enter 2,048² = 4,194,304 possible combinations of words.

Given the list above a simple program to iterate through each of the 4,194,304 possible values could be easily written.

However, as described in the previous post you would need to know the correct order of the other words and the correct position of the two missing words.