Pages:
Author

Topic: [~1 BTC Bounty] - page 8. (Read 4638 times)

legendary
Activity: 3458
Merit: 6231
Crypto Swap Exchange
October 20, 2019, 08:59:41 PM
#37
If you want PM me and I'll pass it on.

It would help if the slackers at bitcoin.com pool stopped playing around and found a block :-)
Seriously, I'm glad we have pool operators like you who are willing to help out.

-Dave
member
Activity: 79
Merit: 36
October 20, 2019, 02:08:16 PM
#36
Hello, I am offering up to 1 BTC to help recover my funds. The situation is as this: 5.87750550 BTC is stuck. I am offering 0.277 BTC as a miner fee, and up to 0.7 BTC to a person(s) who can help me retrieve it. The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard". I have reached out to every major mining pool with no luck, hence the reason to create this bounty.

If you are a reputed member of this forum, please message me for the bounty explaining what you can do.

If you are a miner, here is a signed transaction hex containing a 0.277 BTC miner fee:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0 000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01d65f6c21000000 0017a914d7cfe4484ffb71b224a0a8eda75bbe7f9494369e8702483045022100a13fb354cde016b 28e96d7cecb9b3fce216739f92e72c832a8ba3acde6bc9eb002201ebc94729b3753291de875860e 8404c0833cf6ed96060bae8a1080956770a1ec0141044b8d17d6f5fae04c9213da069f4e9fdd25d f5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73c f8bb7dd95e3fd200000000




I can't DM you unfortunately. If that transaction has not been mined yet, please send me the transaction with a 1sat/bytes fee to [email protected] and we will mine it.

If I don't hear from you shortly I will nonetheless add the transaction on Monday and you can email me to get the fee back.

I heard about your issue from our support staff when I was travelling, I told them I only needed a valid raw tx and we would add it but I didn't hear back from the support staff and I forgot to follow up on this. Sorry about that.

I can't DM you either, but I e-mailed you again. I am very appreciative for you guys at Bitcoin.com for your initiative to help me out  Smiley
newbie
Activity: 5
Merit: 3
October 19, 2019, 09:20:21 PM
#35
Hello, I am offering up to 1 BTC to help recover my funds. The situation is as this: 5.87750550 BTC is stuck. I am offering 0.277 BTC as a miner fee, and up to 0.7 BTC to a person(s) who can help me retrieve it. The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard". I have reached out to every major mining pool with no luck, hence the reason to create this bounty.

If you are a reputed member of this forum, please message me for the bounty explaining what you can do.

If you are a miner, here is a signed transaction hex containing a 0.277 BTC miner fee:

01000000000101c0ee957139541ad18cb3367a4dd0606bbc8c5bd1585ce64e813c5c21359e3f6e0 000000017160014ef3247d77adecb1f22692e899931e75e1a5cbb26ffffffff01d65f6c21000000 0017a914d7cfe4484ffb71b224a0a8eda75bbe7f9494369e8702483045022100a13fb354cde016b 28e96d7cecb9b3fce216739f92e72c832a8ba3acde6bc9eb002201ebc94729b3753291de875860e 8404c0833cf6ed96060bae8a1080956770a1ec0141044b8d17d6f5fae04c9213da069f4e9fdd25d f5f567f867a6a957a850c45a602b788c4a699afacbca54cfc5ba0cd659f20575f2fb20eee6ed73c f8bb7dd95e3fd200000000




I can't DM you unfortunately. If that transaction has not been mined yet, please send me the transaction with a 1sat/bytes fee to [email protected] and we will mine it.

If I don't hear from you shortly I will nonetheless add the transaction on Monday and you can email me to get the fee back.

I heard about your issue from our support staff when I was travelling, I told them I only needed a valid raw tx and we would add it but I didn't hear back from the support staff and I forgot to follow up on this. Sorry about that.
legendary
Activity: 3472
Merit: 1721
October 19, 2019, 02:00:22 PM
#34
You could set aside one day out of the year where everyone can send in txs as a celebration to show their support of such things.

Sounds like a recipe for a lot of losses from double spending attacks Wink

It would be better if most nodes & miners decided to start accepting non-standard transactions for good.
legendary
Activity: 3458
Merit: 6231
Crypto Swap Exchange
October 18, 2019, 08:11:52 PM
#33
ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction.
Would this be something a miner can easily change? Say Pool X sets up nodes that accept it, assuming the fee is above a certain very high threshold, so they become the go-to location for all similar cases?

An interesting thing to think about.
In theory the pool operator would not even have to have nodes that listen for it, all they would need is a web page that you paste in the signed transaction and it can take it from there.


Core does not allow accepting non-standard transactions on mainnet. There is a -acceptnonstdtxn option that can be enabled, but it does not do anything on mainnet; it only works on testnet and regtest. However, it is trivial to change that, there is just one if block that can be removed to allow accepting non-standard transactions on mainnet.
So it would be pretty easy for a pool operator to run a slightly modified version of Core that accepts non-standard transactions.

Do you know if the larger pool operators (poolin / btc.com / viabtc / antpool) even use "stock" core or some heavily modified version of it or some custom code.
I would think that they would have something heavily customized for their use as it is now.

-Dave
staff
Activity: 3374
Merit: 6530
Just writing some code
October 18, 2019, 05:01:17 PM
#32
My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined? Is not it creating an asymmetry to Bitcoin network in general?
It is impossible for the sender to know whether the redeemScript is a standard script. The address is a P2SH address, which means it is the hash of a redeemScript. The sender does not know whether the redeemScript is standard, or even valid, because they don't have the redeemScript, and there is no reason that they should.

Furthermore, because the redeemScript is a public key hash, even if the sender had the redeemScript, they wouldn't know whether the public key is compressed or uncompressed unless they had the public key. And there is no reason they would have the public key either.

This is turning into fallacy. A valid Bitcoin address can receive fund, but hindrance will be created in the process of moving fund out of it! IMHO, this situation was needed to be taken care of while implementing SegWit.
It is the receiver's job to ensure that the coins are spendable by them, not the sender. It is in the receiver's best interest that they can spend the coins. Why should the sender be sure the receiver can spend those coins? It would be a severe hindrance to have to check that the receiver could spend the coins, and may even make it less secure for the receiver.
sr. member
Activity: 860
Merit: 423
October 18, 2019, 02:55:31 PM
#31
My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined?
Any valid Bitcoin address can receive funds. It's not possible to see how an address was created when funds are deposited.
This is turning into fallacy. A valid Bitcoin address can receive fund, but hindrance will be created in the process of moving fund out of it! IMHO, this situation was needed to be taken care of while implementing SegWit.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
October 18, 2019, 02:46:18 PM
#30
My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined?
Any valid Bitcoin address can receive funds. It's not possible to see how an address was created when funds are deposited.
sr. member
Activity: 860
Merit: 423
October 18, 2019, 02:41:46 PM
#29
The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".
no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.
-snip- then why a transaction to an address created with uncompressed public key is considered standard?
Where did he mentioned it's standard Huh
What pooya meant by "no" was already written in his reply: he said "invalid", what his "no" means isn't standard.
But later, it's countered by the link in my post.

P.S. Yes, most non-standard TXs wont be relayed but invalid TXs can't be mined.

My point is if the Tx from 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 is not mined by miners because it is non-standard, then why the Tx to the same address, i.e. 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0, was mined? Is not it creating an asymmetry to Bitcoin network in general?
staff
Activity: 3374
Merit: 6530
Just writing some code
October 18, 2019, 11:03:32 AM
#28
ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction.
Would this be something a miner can easily change? Say Pool X sets up nodes that accept it, assuming the fee is above a certain very high threshold, so they become the go-to location for all similar cases?
Core does not allow accepting non-standard transactions on mainnet. There is a -acceptnonstdtxn option that can be enabled, but it does not do anything on mainnet; it only works on testnet and regtest. However, it is trivial to change that, there is just one if block that can be removed to allow accepting non-standard transactions on mainnet.

So it would be pretty easy for a pool operator to run a slightly modified version of Core that accepts non-standard transactions.
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
October 18, 2019, 09:43:51 AM
#27
ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction.
Would this be something a miner can easily change? Say Pool X sets up nodes that accept it, assuming the fee is above a certain very high threshold, so they become the go-to location for all similar cases?
member
Activity: 79
Merit: 36
October 18, 2019, 02:23:52 AM
#26
So do you know any miners off hand that would allow him to do it, and have other miners also validate the tx?


edit:

The majority of hashpower would have to allow uncompressed for that tx type.
I don't think the network would get in a hashing war over this guy (there is always one) and his boo boo.
ALL miners and nodes will allow this transaction. It is non-standard

I see what has happened in the validation files.

So if tx checking validates it despite that, will the douche pay up what he should other than meager tx fee?

$2,000+ USD is not meager, and what did I do to be called a douche?  Huh
staff
Activity: 3374
Merit: 6530
Just writing some code
October 17, 2019, 11:32:38 PM
#25
So do you know any miners off hand that would allow him to do it, and have other miners also validate the tx?


edit:

The majority of hashpower would have to allow uncompressed for that tx type.
I don't think the network would get in a hashing war over this guy (there is always one) and his boo boo.
ALL miners and nodes will allow this transaction. It is non-standard, which just means that they won't relay it for normal transaction relay as an unconfirmed transaction. But if it is included in a block, it is still consensus valid and all nodes (including miners) will validate and accept it.

Standardness only applies to the relay of unconfirmed transactions. It has no effect on transactions in blocks.
staff
Activity: 3374
Merit: 6530
Just writing some code
October 17, 2019, 10:23:08 PM
#24
This is wrong???:

"To create a P2SH-P2WSH address:
Define a script, called (witnessScript)
Calculate the SHA256 of the witnessScript (scripthash). Please pay attention that a single SHA256 is used, not double SHA256 nor RIPEMD160(SHA256)"

edit:

here is his tx:


            "script_type": "pay-to-script-hash",
His script isn't P2SH-P2WSH, it's P2SH-P2WPKH. It's key hash, not script hash, so it's still RIPEMD160(SHA256()), and the documentation does say that.
staff
Activity: 3374
Merit: 6530
Just writing some code
October 17, 2019, 09:59:41 PM
#23
Really incredible. So segwit can have uncompressed keys which is larger in bytes?
Apparently yes.

P2SH-P2WPKH uses the same public key format as P2PKH, with a very important exception: the public key used in P2SH-P2WPKH MUST be compressed, i.e. 33 bytes in size, and starting with a 0x02 or 0x03. Using any other format such as uncompressed public key may lead to irrevocable fund loss.

https://bitcoincore.org/en/segwit_wallet_dev/
The documentation is wrong and should be fixed.
staff
Activity: 3374
Merit: 6530
Just writing some code
October 17, 2019, 05:36:45 PM
#22
Roger, if you tried to submit a block with that transaction, and other miners or nodes do not accept it as valid according to protocol or code, the block would be orphaned.

Now, if you want to out of your pocket try and see if the tx would be considered valid, it is your choice to do so, to help out.

But there is a significant chance the block would be rejected and orphaned.
It won't be because the transaction is consensus valid. Blocks have never been rejected for containing non-standard transactions.

If you don't think it is consensus valid, you can test it yourself. The getblocktemplate RPC allows you to submit a block proposal. It is just a block that does not have a valid proof of work, everything else needs to be valid (scripts, signatures, merkle root, etc.). That block proposal is validated for everything except the Proof of Work (and no attempt is made to relay it). The RPC will tell you whether the block proposal is valid (everything passes validation) or what the specific validation error is if not valid. So if you make a block proposal with OPs transaction, you will find that it is in fact consensus valid.

Here is a python script that will connect to a bitcoind and check whether the given txs are consensus valid: https://gist.github.com/achow101/51751f10f394ec1a5fb1cd77a3e30181
vip
Activity: 1052
Merit: 1155
October 17, 2019, 03:34:41 PM
#21
I've asked our pool team to look into this to see if it is possible.
pool.bitcoin.com

Good luck!
legendary
Activity: 2394
Merit: 5531
Self-proclaimed Genius
October 16, 2019, 10:30:05 PM
#20
The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".
no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.
-snip- then why a transaction to an address created with uncompressed public key is considered standard?
Where did he mentioned it's standard Huh
What pooya meant by "no" was already written in his reply: he said "invalid", what his "no" means isn't standard.
But later, it's countered by the link in my post.

P.S. Yes, most non-standard TXs wont be relayed but invalid TXs can't be mined.
sr. member
Activity: 860
Merit: 423
October 16, 2019, 08:52:36 PM
#19
The address is a seg-wit address created with an uncompressed private key. This means that the outgoing transaction is considered "non-standard".

no, if the address was indeed created using an uncompressed public key then it is considered invalid and your funds are irretrievable.

If a transaction from an address created with uncompressed public key is considered non-standard, then why a transaction to an address created with uncompressed public key is considered standard? I mean, if Bitcoin Core nodes consider a certain type of address to be non-standard, then Bitcoin Core nodes should reject transactions sent to it at the first place. Is not it?
member
Activity: 79
Merit: 36
October 16, 2019, 08:26:14 PM
#18
I'll give that a shot, at this point I'll contact and ask anyone seeing as though my offer is just about pennies for larger pools who don't care about me Sad

Sent you a message on reddit. Did you reach out to u/MemoryDealers there or here https://bitcointalksearch.org/user/memorydealers-10310 ? He is more involved with BCH not BTC but he does run a pool and might be able to help.

He is not real popular here because of his pro BCH anti BTC attitude but he does tend to respond to people, even if it's a no answer.

-Dave

No response on Reddit. I can't PM him here as I am a newbie, if you could PM him for me on my behalf I would greatly appreciate that
Pages:
Jump to: