Would you help the real finder of puzzle 66 if you could transfer his bitcoin to your own wallet? (a big share of it ...)
Ok, first try to quote properly to avoid unnecesary sub-quotes. I am going to add some previous comment that I already did: I can try it, i only wan the 10% y send you the 90% share
Even 5% for me is OK But as i write before, the only ways to perform securely that Transactions are: -Mine a block by yourself including your TX, but (It is very unlikely to happend but not impossible)
-Use the Marathon Slipstream service to mine the TX privately (This may be not trusted but it is the Marathon reputation againts only 6.6 BTC)
Anyone with a little of knowlege can use the Marathom Slipstream service, So i don't see the point to request do that to someone else. |
|
|
|
Would you consider adding a stride option that works in address and vanity mode?
Well It is not so simple, i already try it before but my first code was wrong My use case - I've found a good amount of 13zb1hQbWV prefix matches for puzzle 66 so far. When I convert their hex key into their base10 decimal number, I notice many of them (about 1/3) have a factor of 13 and/or 17. An example is 3FEE2509944801483 (13zb1hQbWVECopz4XMEYH8e2t2gX4v4Us3) = (decimal) 73706563070708421763 = 7 × 13 × 809962231546246393.
Nice finding, from a statistical point of view, is your data set Significant? In the 66 bit space maybe there around of 12344 address that start with 13zb1hQbWV, so I don't know how many we require so demonstrate that those prime factors are relevant or not. Another thing is that there is no relationship between the prime factors of a private key and the generated address prefix, I can found a lot of address that aren't related to 13zb1hQbWV and have those factors, so the number of "(about 1/3)" is just some statistical or probabilistic According to some research that i just did the percentage of numbers that has 11 or 13 as factor is near to 20%, that may vary from one rank to another I bet that half of your data set has 2 as prime factor and other 1/3 has 3 as prime factor no? I really may consider to add the stride option if you share your data set with me in public or in private. |
|
|
|
|
El tema de Lavado de Dinero es muy amplio y extenso que va mas alla de las nuevas tecnologias de Bitcoin y Blockchain es algo que ya ha existido desde decadas atras y seguira existiendo.
Por ejemplo hace unos dias acabo de ver este documental en Netflix "Dirty Money" donde se presentan diversas historias de lavado de Dinero entre ellas una que habla de Peru el capitulo es "Oro sucio" Capitulo 4 de la Segunda tempora.
Dicho documental muestra como los carteles estan lavando dinero mediante el uso de Oro sucio y empresas fachadas en Peru y Maimi.
|
|
|
|
09b4873f442749ef3e86c71d9286b122a9ddf97625a0035888fb9625460e2716
Wrong hash. Expected rmd160 for puzzle 66 is: 20d45a6a762535700ce9e0b216e31994335db8a5
Your hash result is: 20d45a6a7625334252c8318a87ed303533c1c7bb
Nice try keep participating! |
|
|
|
Just pay a high transaction fee so that it goes into the next block and take the BTC.
Obviously my image was edited I've not fount the key yet. By the way try to quote properly without do a mess About to pay a high transaction fee it is a bad recomendation. As we see some weeks ago some of us had a bot waiting a mempool TX to extract the public key, crack it and make a new Full RBF TX. I have my bot UP and running to do IT. As we see the bests and only two option to move the funds are: -Mine a block by yourself including your TX, but (It is very unlikely to happend but not impossible) -Use the Marathon Slipstream service to mine the TX privately (This may be not trusted but it is the Marathon reputation againts only 6.6 BTC) Wait a moment! the total amount is not correct. This is probably fake....  The amount is correct! Prove that you have the 66 private key by sharing the SHA-256 of the public key. This way we can verify if the address is correct
No one will be able to derive the public key, but we can verify that you have it
That is correct, it is the only way to prove that you have the KEY with expose anything. Regards! |
|
|
|
Waiting for someone to help me move the balance without losing it.
I am also waiting for that:  |
|
|
|
You have to change to qr code as well it's still showing puzzle 64's address.
Those fuckers believe that they can scam us |
|
|
|
Guys learn to quote properly without unnecesary sub-quotes Only I can help to withdrawal, you need share PK with me, I will withdraw and send you 50% share,
I can try it, i only wan the 10% y send you the 90% share |
|
|
|
help with p66 withdrawal?
No, none of them help |
|
|
|
I don't understand people that setup multi-tens of GB stuff via BSGS to crack it in minutes, it makes no sense. Keep it simple.
Some people don't have GPU, some of them don't even know what they are doing |
|
|
|
If I RIPMED160 hash of my target address and use bags mode then how do I calculate the number which you have shown in your post above. Please explain. Thanks for your prompt reply. Appreciate it.
BSGS mode is for Public keys ONLY RMD160 hash is different from a Public keys. Please READ this link 4 Times before ask your next question: https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch04.html |
|
|
|
For wallet #120, when generating the Bitcoin address from the private keys found by Keyhunt, it does not reach the Bitcoin address presented for the wallet on the challenge website.
Shouldn't it be the same address?
The 120 keys/address for the keyhunt documentation are examplest to test the speed. Please Read and Understand the documentation before running it without know what are you doing. I have been studying BSGS, and Pollard's Kangaroo methods for a while now. I have made an observation trying to mix BSGS with the Kangaroo method that I believe could be helpful.
I need time to understand what are you doing, because right now Kangaroo its still a mystery for me. So i CANT say anything about what you write
I am newbie to keyhunt. I have 32gb ram and rtx4070. While running the command line as ->
./keyhunt -t 8 -m address -f abc.txt -r (from hexadecimal to hexadecimal) -q -s 10 -k 2048 -R
the speed is 5564110 keys/s. I wanna to scan backwards because I think the target address is nearest to back end of the range. Please suggest what is the most efficient command line I need to follow. Thanks
Kehunt is for CPU only, so you GPU model doesn't have anything to do here. For address there is no backwards mode, if you believe that your target is near of the end, THEN select a sub-range that is near of the desire range and not the whole range.... |
|
|
|
is it matter for keyhunt that public key is from which type of address ? address start with 1 or 3 or bc
it doesn't matter at all. A public key is directly related to the Private key, regarless the type of address. |
|
|
|
Thoughts, comments, questions?
What if... someone inside Mara is aware of this challenge/addresses with weak privatekeys and had access to that private mempool? Is hard to trust in this services. So for all those users who said they've found the key this is the fire test to prove it. |
|
|
|
Hey,
hypothetically i find the key, submit tx transaction with 0.1BTC going to my address and pay fee of 6.5 BTC. How do you steal my transaction ?
Thank you!
It is a lose-lose example in my case the bot will keep increment 1sat/vB more than your or anyone else TX. In the final round in case to reach the limit of the input balance it will append an extra input to the TX and send 100% of the puzzle address as fee. |
|
|
|
About the minig class theory you can omit it, it is well documented: https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12_mining.adocBlock size is 1MB, Merkle trees, Block header etc... all is there. Therefore, Alberto, it’s possible that the miner didn’t choose your transaction, even if it had a higher fee.
Yes I know that that depends of how often miners update their mining block template, also depends of miner Node policies to acept or not Full RBF as I said before that is outside of our control. |
|
|
|
Is anyone else concerned about digaran?
TBH no, I think he is using another account, what you can expected from a troll. I decide in my code 250~500 transactions with better fees and ~2500 with small fees and get ~4000transactions and try mine block. I think lucky your transaction faill
Nice to know, What you mean with " I think lucky your transaction faill" ? BTW edit your post and quote it correctly. |
|
|
|
Do those who have Bots consider sharing?
Learn python or any other language to develop your own tools, Stop being a Beggar. For all those who develop their own bots here are the main mistakes to avoid. - Don't start your first transactions from a fixed fee. - Don't increment a fixed amount. To solve previous points you need to read what is the current fee in sat/vB and increment from that point, network only will accept transactions if those are +1 Sat/vB from previous know transactions. Learn how to calculate your transaction size and set your fee multiplier this must done to try to maximize your possibilities to be accepted in mempool, without the need of burn all the fee. tx bc16e7ce388d9.. was added to the block at 2024-07-28 09:42:12 (GMT +8) you only had one attempt at 2024-07-28 09:42:08 (GMT +8)
this is not all correct, that is the same Timestamp for the block mining: Block 854265 - 2024-07-27 19:42:12 (GMT -6)But since all the bots have enough time to get the publickey, calculate the private key and broadcast transactions, then we can assume that the original transactions was broadcasted somewhere after the previous Block 854264 2024-07-27 19:37:48 (GMT -6). |
|
|
|
WARNING:root:Fee bump attempt 6 failed.
ERROR:root:Max fee bump attempts reached for transaction
I think that you are being limited somehow by that electrum API, it only let you 6 tries? I think that it should give you a more detailed error of why it fail. ●Response from mempool.space : sendrawtransaction RPC error: {"code":-26,"message":"insufficient fee, rejecting replacement c938ceda6608cf912dba5dda7b2979ed11fa287c67670b359d365b436445116a; new feerate 0.00051681 BTC/kvB <= old feerate 0.00307514 BTC/kvB"}
●Response from mempool.space : sendrawtransaction RPC error: {"code":-26,"message":"insufficient fee, rejecting replacement 8bd50cf10b880973a65a37b78e10f7c64413a6b995f1b639d184a2518449fbf2; new feerate 0.00103076 BTC/kvB <= old feerate 0.00307514 BTC/kvB"}
●Response from mempool.space : sendrawtransaction RPC error: {"code":-26,"message":"insufficient fee, rejecting replacement 8adcb6a53e6524ca8c5c6b819e14d17ed7842a5a10ff597d763ff8c964039695; new feerate 0.00154319 BTC/kvB <= old feerate 0.00307514 BTC/kvB"}
●Response from mempool.space : sendrawtransaction RPC error: {"code":-26,"message":"insufficient fee, rejecting replacement cc0d34c088e6e62a077ccd154db7cc0d4b0789d4a3a649c4907193d4d48412f3; new feerate 0.00205562 BTC/kvB <= old feerate 0.00669492 BTC/kvB"}
looks like none of your TX were accepted. the sendrawtransaction RPC errors are something tricky sometimes they told you the required fee to replace the transaction but sometimes in satoshis and sometimes BTC/KvB We need to parse that error and determine exactly how much fee increase in our TX Also when the 429 Too Many Requests< error need to be handle correctly, like add some waiting time between requests |
|
|
|
|
Show Posts
