Can one offer proof that a tx was created automaticaly by bitcoin-core?

[Altoidnerd]

https://bitcointalk.org/index.php?topic=657071.msg7382765#msg7382765


In that thread I paid someone with core and quickly posted the details...

That I used bitcoin-core, I then thought...maybe his offers the guy some assurance that I did not double spend since, I am supposing, to do so, one would need to write a raw transaction.

Well not exactly..but details aside^†, the big picture is this:

I used qt and the GUI to makes this tx.  What if I could prove I did so - is that any good?

Coolness.  I don't THINK i know how to double spend.

In a way, it have shown evidence that I did not...I should have posted a screen cap of bitcoin-core.

because my guess is, to double spend, you need to write a transaction, which I did not do.

I wonder if there is a way for core to sign a TX using the combined trust of the core-devs, guaranteeing that the tx script is automated.

<sup>† By this I mean I am free to consider the details now here, that is why I am asking.  I do not wish to be overly specific at the top of the thread so to leave the matter as a very open ended question.

What I meant is something along the lines of "proof of" or "evidence of ignorance and/or innocence"  by which one could look at my tx history, and will see that I have NEVER signed a raw transaction.  Clearly, I am not willing to nor capable of double spending.  Of course this does not actually prove that I've never signed one (and I in fact have only played with them using sx and pybitcointools...I have no friggin clue how to do this with bitcoind) but anyways...that's why I am here.  It's just an ideer.</sup>

[DeathAndTaxes]

No.  There is nothing special about raw transactions.  To the protocol there are just transactions.  There are valid tx and invalid one.  Even if you could prove that a particular tx was made using a specific client what value would that have?  It provides no proof you aren't performing a double spend.  We use confirmations as "proof" (although better term would be confidence, the receiver has a higher confidence the more confirmations the tx has).

If one looked at my tx history, you will see that I have NEVER signed a raw transaction.

Tx history provides no proof on how the tx was created.   It isn't like there are "non-raw" txs and raw txs.  There are just raw txs.  Every single one of your txs could have been made using the createrawtx RPC call.  "Raw tx" is just HOW the tx is created, they are all txs.

[Altoidnerd]

Thanks.  Now, it is cryptographically possible (for future versions perhaps, let us disregard whether or not it would ever be pulled into core) to sign it in such a way as to prove it was signed with an unaltered build signed by people we are currently already trusting?

As you said

there is nothing special about raw transactions

and indeed, there never will be.  But there could in principle be something special about a tx that is "not as raw." One you make with core, where change and all that is abstracted away.

[DeathAndTaxes]

Thanks.  Now, it is cryptographically possible (for future versions perhaps, let us disregard whether or not it would ever be pulled into core) to sign it in such a way as to prove it was signed with an unaltered build signed by people we are currently already trusting?

No.  For the client to sign the tx would require that the client have the private key.  If the client has the private key an attacker could use that same key to impersonate the client.  Don't feel bad this is very similar to DRM and countless billions of dollars have been wasted on that flawed concept that.  Any security system which relies on the code running on an attacker machines to not do "bad stuff" is just feel good security.  Don't feel bad this is very similar to DRM and countless billions of dollars have been wasted on that flawed concept that.  The good news is Bitcoin doesn't rely on feel good security it relies on strong cryptography.  You can modify your copy of the client to do anything you want (like make the next block have difficulty of 1, and a block reward of 84390482930 quadrillion BTC).  You can't control how other clients will react to that and in this case they would simply ignore it as invalid data.

Still even if you could absolutely cryptographically PROVE that a tx was created by a particular client it would still be utterly useless.  The term is "double spend" for a reason.  There are two txs in a double spend.  Proving that one of them is "legit" means nothing because the problem isn't with the legit transaction, it is with the competing one which you may be included in the next block.  The "proof" that this isn't the case is tx confirmations.  Nothing else has any value.

But there could in principle be something special about a tx that is "not as raw."

No, there is nothing special about "not as raw" txs either.  Not today, not ever.  The security model of Bitcoin doesn't rely on your client doing the right thing.  In fact all other nodes implicitly distrust your node and independently verify data received from your node before relaying it.  The security model of Bitcoin is strong because it doesn't (weakly) rely on an assumption that there are "good clients" and "bad clients" as indicated above that is pointless feel good security.

[Altoidnerd]

You are right.  Like a good scientist, I will try to argue in favor of the concept a bit more but in no small part agreed - I already feared this anyhow.  I invite you to entertain some possibilities of such a feature realizing that sub-cryptogrophically-perfect evidence can be useful as a judgement of character.

Still even if you could absolutely cryptographically PROVE that a tx was created by a particular client it would still be utterly useless.

Again I technically agree that there isn't possibility to prove no malice, but I think in practice, "for all intent and purposes", it may not be entirely useless - one could do something like

1) pay with bitcoin core with previously unspent coins

2) stay on camera (google gchat or something) and juggle 5 balls in front of the camera for 1 confirmation.

[DannyHamilton]

one could do something like

1) pay with bitcoin core with previously unspent coins

2) stay on camera (google gchat or something) and juggle 5 balls in front of the camera for 1 confirmation.

While an accomplice off camera with another computer secretly submits a competing transaction that pays an address you control directly to a mining pool that is willing to replace transactions with ones that pay a higher fee.  It is never seen by the rest of the network.  That miner is lucky enough to solve the next block and "poof" the original transaction disappears, replaced with the new transaction.  You get to keep your bitcoins, and receive whatever else was given to you in exchange.

[Altoidnerd]

Hmm I see.  It seems we are cornered here by the generality of the bitcoin protocol (which is great).  I won't continue to entertain this idea if it offers no true benefits without requiring huge overhauls.

I had in mind a simple ECDSA something or another on any script signed by the "ignorant" GUI in core.  That is easy enough to conceive, and perhaps implement.  But if you are saying even that will not help, then I'll let it go because I do not like major fundamental changes (who does).

[Altoidnerd]

To Death/Danny are you going to go to btc-chicago?

[DannyHamilton]

To Death/Danny are you going to go to btc-chicago?

Not aware of it.

When?  Where?

[DannyHamilton]

But if you are saying even that will not help

It won't.

A transaction sent with one client can be double-spent with another client if it isn't confirmed yet.

Confirmations are the mechanism that Bitcoin contains for determining consensus on which transaction is the "real" one.

[Altoidnerd]

http://btcchicago.com/

I went to the one in Miami in January or Feb?  Anyway, it was an excellent experience.  I got to meet Jeff Garzik, and Vitalik.  Matt Corallo (TheBlueMatt) invited me to lunch with him and luke-jr.  It was very cool meet them in the flesh.  And really learned quite a bit from Matt who was kind to me.

The conference was attended by many people from whom I had nothing to learn.  It's an eclectic crowd.  Many are there to try to use you.  But those interactions I did have with the right individuals more than made the event worth it.  I highly recommend it to anyone who thinks reading this part of the forum is fun.

[DannyHamilton]

http://btcchicago.com/

I went to the one in Miami in January or Feb?  Anyway, it was an excellent experience.  I got to meet Jeff Garzik, and Vitalik.  Matt Corallo (TheBlueMatt) invited me to lunch with him and luke-jr.  It was very cool meet them in the flesh.  And really learned quite a bit from Matt who was kind to me.

The conference was attended by many people from whom I had nothing to learn.  It's an eclectic crowd.  Many are there to try to use you.  But those interactions I did have with the right individuals more than made the event worth it.  I highly recommend it to anyone who thinks reading this part of the forum is fun.

I would absolutely love to go.

Unfortunately, the Chicago Yacht Club Race to Mackinac is that weekend.  I'll be on a boat in the middle of Lake Michigan during the entire conference, and won't be able to attend.

[Altoidnerd]

Oh that's a shame!  If something changes, or you can make it just sunday or something, lmk.  I was planning on only going the last day this time.

[DannyHamilton]

Oh that's a shame!  If something changes, or you can make it just sunday or something, lmk.  I was planning on only going the last day this time.

The race starts Saturday at noon at Navy Pier in Chicago, and we'll finish 333 miles away at Mackinac Island Michigan probably sometime in the middle of the night Monday night.

The only way something would change would be if I broke a leg and couldn't participate.