Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2011-11-09 🗒️ Summary of this message: Gavin Andresen ...
📅 Original date posted:2011-11-09
🗒️ Summary of this message: Gavin Andresen suggests that partially-signed transactions should not be on the main Bitcoin P2P network due to the possibility of spamming. He proposes a half-baked idea of using an escrow transaction with extra data in the scriptSig to distribute signatures, which could potentially clog up the blockchain.
📝 Original message:> I don't think partially-signed transactions belong on the main Bitcoin
> P2P network, mostly because I don't see any way of preventing somebody
> from endlessly spamming bogus, will-never-be-completed partial
> transactions just to be annoying.
... of course I write that and then start thinking about ways you
COULD use the P2P network to distribute signatures, maybe by
broadcasting (and paying fees for) complete transactions that contain
extra signatures for the transaction that you want to sign.
Here's a half-baked idea that might be brilliant or stupid:
+ Start with an escrow transaction, with 3 public keys. I own one of the keys.
+ I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key
I own. But I add extra data to the scriptSig; something like:
scriptSig: <escrow_signature> <serialized_escrow_transaction> <sig> <pubkey>
scriptPubKey: ...standard DUP HASH160 <pubkeyhash> ...etc
nValue: 0
The other parties to the escrow transaction could monitor the
block-chain for transactions to my <pubkeyhash>, and get the signature
and proposed "spend the funds in escrow" transaction from the
scriptSig.
.......
"But won't that gunk up the block chain with more data?"
Yup. But the parties to the transaction will have to pay for the
extra data they're including.
And everything in the scriptSigs can, theoretically, be forgotten (or
never sent) to most nodes on the network once the transaction is spent
and is buried deep enough in the block chain. (a nValue=0 transaction
can be considered 'immediately spent').
"Can you really put arbitrary stuff in the scriptSig?"
Yup. The IsStandard() check today allows up to 200 bytes, which
wouldn't be enough for an extra signature and <serialized
transaction>.
The standard <sig> <pubkey> is about 150 bytes; part of the
multi-signature proposal will be increasing that to 500 bytes to
accomodate 3-signatures transactions. A simple 1-input-1-output
<serialized transaction> would be around 50 bytes or so.
"Wouldn't it be cheaper/better to NOT use the block chain to
distribute signatures?"
Yup. The only advantage I see is it might be more anonymous to use the
blockchain instead of directly connecting to, and finding out the IP
address of, the parties involved in the transaction.
--
--
Gavin Andresen
🗒️ Summary of this message: Gavin Andresen suggests that partially-signed transactions should not be on the main Bitcoin P2P network due to the possibility of spamming. He proposes a half-baked idea of using an escrow transaction with extra data in the scriptSig to distribute signatures, which could potentially clog up the blockchain.
📝 Original message:> I don't think partially-signed transactions belong on the main Bitcoin
> P2P network, mostly because I don't see any way of preventing somebody
> from endlessly spamming bogus, will-never-be-completed partial
> transactions just to be annoying.
... of course I write that and then start thinking about ways you
COULD use the P2P network to distribute signatures, maybe by
broadcasting (and paying fees for) complete transactions that contain
extra signatures for the transaction that you want to sign.
Here's a half-baked idea that might be brilliant or stupid:
+ Start with an escrow transaction, with 3 public keys. I own one of the keys.
+ I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key
I own. But I add extra data to the scriptSig; something like:
scriptSig: <escrow_signature> <serialized_escrow_transaction> <sig> <pubkey>
scriptPubKey: ...standard DUP HASH160 <pubkeyhash> ...etc
nValue: 0
The other parties to the escrow transaction could monitor the
block-chain for transactions to my <pubkeyhash>, and get the signature
and proposed "spend the funds in escrow" transaction from the
scriptSig.
.......
"But won't that gunk up the block chain with more data?"
Yup. But the parties to the transaction will have to pay for the
extra data they're including.
And everything in the scriptSigs can, theoretically, be forgotten (or
never sent) to most nodes on the network once the transaction is spent
and is buried deep enough in the block chain. (a nValue=0 transaction
can be considered 'immediately spent').
"Can you really put arbitrary stuff in the scriptSig?"
Yup. The IsStandard() check today allows up to 200 bytes, which
wouldn't be enough for an extra signature and <serialized
transaction>.
The standard <sig> <pubkey> is about 150 bytes; part of the
multi-signature proposal will be increasing that to 500 bytes to
accomodate 3-signatures transactions. A simple 1-input-1-output
<serialized transaction> would be around 50 bytes or so.
"Wouldn't it be cheaper/better to NOT use the block chain to
distribute signatures?"
Yup. The only advantage I see is it might be more anonymous to use the
blockchain instead of directly connecting to, and finding out the IP
address of, the parties involved in the transaction.
--
--
Gavin Andresen