Author

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 123. (Read 245170 times)

newbie
Activity: 4
Merit: 0
It makes sense, but as soon as some amateur person finds the wallet password, he will send it to his own address and others will steal it. The important thing is to have this awareness

Absolutely, thats why I posted it.

In my opinion any other method than "shadow mining" has a too high risk of going wrong:
  • Broadcast at low-traffic times: You don't know when the next block will be mined. Could be seconds or minutes away (which would give enough time for the attack).
  • Set the "do not RBF": You don't know if the miners will honor this field or not. It also does not help against an attacker simply inserting a double spend transaction.
  • Double spend risk: It seems every miner uses its own metric to determine the valid transaction. Based on fee will end up in a bidding war. Based on timestamp can work but you don't know which metric the miner will use.

So just making a "normal" transaction is much too high risk and I think everyone working on this puzzle should be very aware of that and have a solid plan in case of winning the lottery!
jr. member
Activity: 65
Merit: 1
34Sf4DnMt3z6XKKoWmZRw2nGyfGkDgNJZZ
From what we know on the "public key sniping" issue so far any my understanding is:
  • Revealing the public key in the mempool immeadiately sets of a double spending attack by the sharks - depending on miners rules they might or might not adhere to RBF or first timestamp ordering and might just accept the higher fee -> never reveal the pubkey in the mempool and work out a private deal with a miner to "shadow-mine" this transaction is the only safe way.
  • Revealing a signature to prove I own the private key is also unsecure -> communication channel with miner needs to be secure and miner needs to be trusted not to use the same attack vector as the sharks as soon as I send the private transaction to them

Under these assumptions, my game plan would be:

1. Create a post here in the forum containing:
- SHA256 hash of the private key along with my target address where I intend to send the coins to.
- SHA256 hash of a message containing a text stating my intention to send the coins to my adress along with the miner name I intend to work with.
Ask the forum to cite this post to avoid edibility and prove of time stamp.

2. Contact the miner and work out a deal to shadow-mine and include the transaction in a block without broadcast. Set an appropriatly high fee depending on the deal. There is trust required here that the miner does not act malicious (possibly via a 3rd party), however the miner name is included in the SHA256 hased message in this forum. I will notify the miner that I will reveal the message for everyone to verify via the hash in case the miner does not stick to the agreement. This is not a safeguard to revert the transaction or anything, but hopefully will prevent the miner from acting malicious in order to preserve reputation.

3. Send the transaction details to the miner.

4. Hope for the best. If everything goes well, no need to reveal the message. The name of the miner is known then anyway.

Makes sense?

It makes sense, but as soon as some amateur person finds the wallet password, he will send it to his own address and others will steal it. The important thing is to have this awareness

newbie
Activity: 4
Merit: 0
From what we know on the "public key sniping" issue so far any my understanding is:
  • Revealing the public key in the mempool immeadiately sets of a double spending attack by the sharks - depending on miners rules they might or might not adhere to RBF or first timestamp ordering and might just accept the higher fee -> never reveal the pubkey in the mempool and work out a private deal with a miner to "shadow-mine" this transaction is the only safe way.
  • Revealing a signature to prove I own the private key is also unsecure -> communication channel with miner needs to be secure and miner needs to be trusted not to use the same attack vector as the sharks as soon as I send the private transaction to them

Under these assumptions, my game plan would be:

1. Create a post here in the forum containing:
- SHA256 hash of the private key along with my target address where I intend to send the coins to.
- SHA256 hash of a message containing a text stating my intention to send the coins to my adress along with the miner name I intend to work with.
Ask the forum to cite this post to avoid edibility and prove of time stamp.

2. Contact the miner and work out a deal to shadow-mine and include the transaction in a block without broadcast. Set an appropriatly high fee depending on the deal. There is trust required here that the miner does not act malicious (possibly via a 3rd party), however the miner name is included in the SHA256 hased message in this forum. I will notify the miner that I will reveal the message for everyone to verify via the hash in case the miner does not stick to the agreement. This is not a safeguard to revert the transaction or anything, but hopefully will prevent the miner from acting malicious in order to preserve reputation.

3. Send the transaction details to the miner.

4. Hope for the best. If everything goes well, no need to reveal the message. The name of the miner is known then anyway.

Makes sense?
newbie
Activity: 6
Merit: 0
Let's assume the mempool is low when you do the transaction for the puzzle.  If I send the coins with a fee of .1BTC and someone else finds the private key 30 seconds later and sends the transaction with a 1BTC fee, would they both be in the same block and the first transaction would win because it has an earlier timestamp, or would that not matter?
Double spending in Bitcoin is an inevitable feature of the network, regardless of whether it is legitimate or not.
So how do you solve the problem of a conflicting transaction? well, through the confirmations of the miners. And how can we "win" a conflicting transaction? increasing the rate...
In fact, exchanges usually carry out these transactions to reverse a transaction in which the transaction fee was low and they need to make the transaction faster or even unblock a stuck transaction generating a double spend this time with a higher fee.
So this is part of the bitcoin protocol and there is nothing to do. If someone obtains your private address and makes a transaction before it is confirmed, both transactions will "fight" to form a block first, regardless of which was issued first.

It turns out you need to win the lottery 2 times)) first win the private key and then also so that your transaction is included in the block. But what if you choose a moment when the network is overloaded and make a transaction with a commission of 100 million sat? Will this increase the chances or does it not matter?
full member
Activity: 431
Merit: 105
Lets assume i have a btc wallet with no public key inside my core wallet, now i import this
one inside blockchain.com wallet, there i have the funds now, i will instantly sell these btc
coins for usd, and send my coins out there, said it, this is the way i assume all, keyfinders succes rate.

there now you have you have your coins on one of your own wallets, but now, not the forks??
i guess, or you have to do this inside the blockchain instantly with multiple windows open, but blockchain.com
prehibits this, one browser window allowed open logged in at the same time, the same you can do with the
bit of forks, but guessing the valuable btc should be enough to have there if imported,

is this not tested before, haha there this public key will not leave from your possession, untill you sell the coins
inside blockchain wallet, should be fine. i guess
jr. member
Activity: 41
Merit: 0
Let's assume the mempool is low when you do the transaction for the puzzle.  If I send the coins with a fee of .1BTC and someone else finds the private key 30 seconds later and sends the transaction with a 1BTC fee, would they both be in the same block and the first transaction would win because it has an earlier timestamp, or would that not matter?
Double spending in Bitcoin is an inevitable feature of the network, regardless of whether it is legitimate or not.
So how do you solve the problem of a conflicting transaction? well, through the confirmations of the miners. And how can we "win" a conflicting transaction? increasing the rate...
In fact, exchanges usually carry out these transactions to reverse a transaction in which the transaction fee was low and they need to make the transaction faster or even unblock a stuck transaction generating a double spend this time with a higher fee.
So this is part of the bitcoin protocol and there is nothing to do. If someone obtains your private address and makes a transaction before it is confirmed, both transactions will "fight" to form a block first, regardless of which was issued first.
jr. member
Activity: 56
Merit: 2
So what needs to be done is this:

If you have the key to #66, rent a crap ton, and I mean a crap ton of hash. Solve a BTC block, then include your transaction within the block you solved Smiley
How much time would professional miners need to do this ?

It doesn't matter, all depends if miners update the block that they are actually mining.
Does the miners risk losing any thing by doing this for you ?
hero member
Activity: 862
Merit: 662
Let's assume the mempool is low when you do the transaction for the puzzle.  If I send the coins with a fee of .1BTC and someone else finds the private key 30 seconds later and sends the transaction with a 1BTC fee, would they both be in the same block and the first transaction would win because it has an earlier timestamp, or would that not matter?

It doesn't matter, all depends if miners update the block that they are actually mining.
donator
Activity: 1059
Merit: 1038
Let's assume the mempool is low when you do the transaction for the puzzle.  If I send the coins with a fee of .1BTC and someone else finds the private key 30 seconds later and sends the transaction with a 1BTC fee, would they both be in the same block and the first transaction would win because it has an earlier timestamp, or would that not matter?
hero member
Activity: 862
Merit: 662
If we found a private key then can we import that into bitcoin core?

You can import any key to bitcoin core, but that will be usless to move the founds in a safest way. THB i don't recoment bitcoin core as wallet manager, there are bets option like electrum or sparrow.

Can somebody who say double-spend is possible with RBF-disabled make a video to actually proof this. This is a simple test, which I tried several times on my own addresses and I have always negative results.

Maybe in the future i may do that video, but for now i let you the next link:

Is FullRBF allowing double spend?

Original TX


First FullRFB


Second FullRFB


Final TXID: 942a454340c5115d769a16aad85b85a19875bb2f5e544de1b776570b76294f62

If you follow the link in mempool there is no record of the past replacements or the original transaction, but the images show that those transactions happened in first place, check the original TX if you see the headers in the Features section it have the Flag of RFB in RED (Disabled)
newbie
Activity: 24
Merit: 2
You have to limit yourself to only searches for #130
jr. member
Activity: 44
Merit: 2
Can somebody who say double-spend is possible with RBF-disabled make a video to actually proof this. This is a simple test, which I tried several times on my own addresses and I have always negative results.
newbie
Activity: 39
Merit: 0
If we found a private key then can we import that into bitcoin core?
jr. member
Activity: 85
Merit: 2
Opt-in RBF is still default on the current version, so there is still hope lol!   Grin  Cry


So this is a new feature - Full RBF <> RBF. Are all the miners now set up for Full RBF instead of BIP125?

Well not all the miners but some of them yes that depend of the version and custom configuration, the exact number is unknown


hero member
Activity: 862
Merit: 662
So this is a new feature - Full RBF <> RBF. Are all the miners now set up for Full RBF instead of BIP125?

Well not all the miners but some of them yes that depend of the version and custom configuration, the exact number is unknown

jr. member
Activity: 85
Merit: 2
So this is a new feature - Full RBF <> RBF. Are all the miners now set up for Full RBF instead of BIP125?


Can you explain why you feel that the miners will completely ignore the RBF flag if it is set to disable? I know it is up to the miners but wouldn't they mostly stick to the intent of the feature? I know the incentive would be to earn more money but there are many cases where the miner returned excess fee as well.

It is a Node configuration and it may vary depending of the Bitcoin Core Version.

The full name is Full RBF

Check this link:

Replace-by-fee (RBF)

Quote
Replace-By-Fee (RBF) is a node policy that allows an unconfirmed transaction in a mempool to be replaced with a different transaction that spends at least one of the same inputs and which pays a higher transaction fee.

Different node software can use different RBF rules, so there have been several variations. The most widely-used form of RBF today is BIP125 opt-in RBF as implemented in Bitcoin Core 0.12.0 and subsequent versions; this allows the creator of a transaction to signal that they’re willing to allow it to be replaced by a higher-paying version. An alternative form of RBF is full-RBF that allows any transaction to be replaced whether or not it signals BIP125 replaceability.

Also this link:

https://en.bitcoin.it/wiki/Transaction_replacement
hero member
Activity: 862
Merit: 662
Can you explain why you feel that the miners will completely ignore the RBF flag if it is set to disable? I know it is up to the miners but wouldn't they mostly stick to the intent of the feature? I know the incentive would be to earn more money but there are many cases where the miner returned excess fee as well.

It is a Node configuration and it may vary depending of the Bitcoin Core Version.

The full name is Full RBF

Check this link:

Replace-by-fee (RBF)

Quote
Replace-By-Fee (RBF) is a node policy that allows an unconfirmed transaction in a mempool to be replaced with a different transaction that spends at least one of the same inputs and which pays a higher transaction fee.

Different node software can use different RBF rules, so there have been several variations. The most widely-used form of RBF today is BIP125 opt-in RBF as implemented in Bitcoin Core 0.12.0 and subsequent versions; this allows the creator of a transaction to signal that they’re willing to allow it to be replaced by a higher-paying version. An alternative form of RBF is full-RBF that allows any transaction to be replaced whether or not it signals BIP125 replaceability.

Also this link:

https://en.bitcoin.it/wiki/Transaction_replacement
jr. member
Activity: 85
Merit: 2
Can you explain why you feel that the miners will completely ignore the RBF flag if it is set to disable? I know it is up to the miners but wouldn't they mostly stick to the intent of the feature? I know the incentive would be to earn more money but there are many cases where the miner returned excess fee as well.


Just to mention that when the nodes have many FullRBF transacions not always win that one with more fee, here some examples, Dot with Green margin was mined, some are Testnet and other are mainnet


jr. member
Activity: 65
Merit: 1
34Sf4DnMt3z6XKKoWmZRw2nGyfGkDgNJZZ
Just to mention that when the nodes have many FullRBF transacions not always win that one with more fee, here some examples, Dot with Green margin was mined, some are Testnet and other are mainnet



Here was mined a TX with 1 sat/vB instead of a 37 sat/vB


Here was mined a TX with 22 sat/vB instead of a 44 sat/vB


Here was mined a TX with 106 sat/vB instead of a 1032 sat/vB


Dear Alberto, there is a lot of speculation going around in the group. Thank you for the information you provided.
We want to look for inferior puzzles, but if they are found and someone else steals them, all our efforts will be in vain.
Full information needs to be provided on this issue.
hero member
Activity: 862
Merit: 662
Bitcoin address and Message signature  will Leak public key Huh?

Only Signed messages leak the public key. The address alone doesn't leak anything
Jump to: