Topic: [~1 BTC Bounty] - page 7. (Read 4729 times)

So in short, you won't do it using your own pool?

Well, as far as I can see, there's no way to get getblocktemplate to return a transaction of your choice that's not in the mempool.

... and as I already pointed out above, core bitcoind won't accept the transaction to put it into the mempool without a code change.

So the only possible way I see, related to your comment, is for the pool code to add it directly into the transactions after getblocktemplate, and thus into the "submitblock"
Which means either the pool already allows putting random transactions into their blocks not already known on the network, so those pools "might" consider it and ignore the risks I stated before, or they'd have to change their work generator to allow that.

So it's still back to changing code for any pool that doesn't already allow this, and the risks I already mentioned for any pool that does allow it, or do change some code to allow it.

No code changes needed.
As achow101 said above if you call getblocktemplate with the signed transaction that the OP posted it is valid. He even provided a python script to check it.
Other nodes will not relay the transaction, but once it's in your own mempool it will be part of a valid block that will be accepted.

-Dave

Ah OK, then that matches as I said at the end of my last post, that's the situation here.

The problem isn't the new transaction from someone else claiming to have sent to him (as I thought), but the previous one he is trying to spend.


So this leads directly back to my first comment also:
and the rest after that - i.e. asking a pool to change the code they run for block work generation ... and the risks involved.

Yeah I haven't heard back in months from the ones who originally told me they would do it. I'd appreciate any help possible - I'm throwing rewards on top of the 0.277 to whoever can help, directly or indirectly, lead the transaction to be mined. I'm willing to wait months no problem. Thanks for the initiative Dave.

I'm glad you posted that, when I saw what kano posted I thought I was missing something obvious.

@leventturksoy I am going to poke the pool ops who at least gave some response before to see what is up. They both said look into it then went dark. Odd that there was not even a "no it can't be done" or "yes it can be but we will not do it" response.
It might actually be easier to get this done after the May halving. The .277 fee is going to be much bigger fee percentage wise then. (Ignoring the rest of the reward you are offering)

-Dave

the problem isn't with the rawtx OP contains, the problem is with the already confirmed transaction that this rawtx is trying to spend: 6e3f9e35215c3c814ee65c58d15b8cbc6b60d04d7a36b38cd11a54397195eec0
in that tx 5.87750550BTC is sent to a "valid" but "non-standard" output (address=34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97) that was created using an uncompressed public key instead of compressed one. that is why the rawtx in OP can not propagate throughout the network since almost all bitcoin nodes reject non-standard transactions.

nothing can change about the rawtx in OP (the spending tx), it is already valid and the only way to spend that output but non-standard.

in other words the address 34dqaqvQNWMgbMJmmxVa8LeGz7St6ATT97 that has already received the coins is a nested SegWit address (or P2WPKH-P2SH) that was created using

public key instead of
which makes it non-standard not invalid, so any tx trying to spend that output is rejected by nodes.

The transaction doesn't exist.
Transactions that transfer coins, exist in the blockchain.
There is no transaction:
c842420807d44d8214509bdffc30366416ebfe033c26b8cdc3b0713cfa3846b6
(this is the txnid = the hash of your 248 byte transaction in the first post)

Even a transaction that exists out on the net and in the "mempool", but not in a block, can be replaced before it gets confirmed (by various means)

Maybe you are confusing transactions with "some web site's accounting systems saying they've sent BTC to you"

That's the fun thing about Bitcoin, there is a 100% proof of 'transferring' coins - called transactions in the blockchain.

However, if instead you are saying there already is an "Invalid" transaction (as in "Invalid" due to being 'valid' in a block yet 'invalid' due to core not accepting it) already accepted in a block and you wish to spend some of it - then be all means point out this "Invalid" transaction.

Your explanation at the end there is contradictory to what I know about Bitcoin - how can I "re-send" a transaction that has been confirmed for 8 months? What are my alternatives if no miner wants to take that risk for this?

What you are actually asking for here is some pool to change their bitcoind code to allow the transaction.
It may be a minor change, but it is still a change.

The replies you have from core members are already dodgy at best.
Saying "It's allowed but core wont allow it" is pointless since it just means there's the risk of losing a block if any large pools won't accept it in a block if their rules didn't follow this ambiguous definition correctly:
a transaction that IS allowed in a block but NOT allowed to be created

Comments like "It was a wish" and "but there was a concern" are, to be blunt, absolutely ridiculous when it comes to coding.
They've enforced it in the transaction code anyway, so it's pointless.

#error code: -26
#error message:
#non-mandatory-script-verify-flag (Using non-compressed keys in segwit) (code 64)

Other pools may or may not accept a block with this transaction in it, since it is inconsistent about the rules accepting things:
Create "No" Block "Yes"

The sending bitcoins haven't been spent, so the source still has the bitcoins and the transaction CLEARLY does not exist on the network.
c842420807d44d8214509bdffc30366416ebfe033c26b8cdc3b0713cfa3846b6

So you need (them) to send it again to a "valid" address
If the bitcoins are sourced from someone else - then they have effectively stolen them from you and they can spend them at any time they choose using a different transaction.
If they are sourced from your wallet, just create a new transaction.

did you contact those who were mentioned in this topic (-ck, NovaBlock)?
here is another one: kano https://bitcointalksearch.org/user/kano-36044

ps. weren't Roger Ver's mining pool supposed to help you?!
pps. if my calculation is correct your transaction fee is 0.27BTC, if you want to pay a 1BTC bounty you might want to increase the fee to that amount although 0.27 is still a pretty high reward for mining a simple non-standard tx. you also might want to include your tx fee value (the reward) in your messages to mining pool owners.

My chances seem to be dying out, does anyone here have an idea?

checksum0 has been MIA for a month, and is also not responding to any e-mails. Does anyone know an alternative way to contact him/her?

I PMd checksum0 and MemoryDealers

Let's see what they say.
Odd that there is no response.

-Dave

Ian said he would offer a helping hand, but I've lost touch with him

Did you email [email protected] from above? If so what did he say?

You can also try reaching out to viabtc, they do have a twitter account:

https://twitter.com/viabtc
And a facebook page:
https://www.facebook.com/viabtc

Although not very active they are there.

-Dave

The tx is still not mined as of right now!

The differentiation between consensus rules and policies is widely-known, or I have presumed that this was the case. Is it not?

well maybe it is just me, but i still think as a "documentation" (specially the BIP) it  could have been written in a much clearer way by using a slightly different terminology. for instance it doesn't mention "standardness" anywhere instead uses the term "default policy" which i interpret as meaning "consensus rule" not "standard rule".

It's not at all ambiguous, it states it exactly how it is.

It was the wish with segwit to prohibit the use of uncompressed keys. But there was a concern that problem's like OP's would arise from incompetent buggy software-- potentially involving really large funds losses.  In an abundance of caution these the rule was made initially standardness-only.  It has turned out to be less of an issue than had been feared (the OP's is the only sizable case I've heard of, at least).