public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] Using transaction version number in different projects
@ 2021-08-29  9:32 Prayank
  2021-08-29 14:56 ` Pieter Wuille
  0 siblings, 1 reply; 2+ messages in thread
From: Prayank @ 2021-08-29  9:32 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

print('Hello, world!')

I had asked related question on Bitcoin Stackexchange: https://bitcoin.stackexchange.com/questions/108248/version-in-transaction

Wanted to know if others think we should allow more numbers in transaction version by considering such transaction standard. I have shared an example how transaction version can be used to bet on something that involves 2 outcomes:

https://gist.github.com/prayank23/6f54e9a27f057abd1182436e7f88d1ac

Anything wrong with this approach? We could use oracles (DLC) or something else later to settle the bet and create a release transaction. However wanted to confirm if everything looks okay until funding transaction. Nothing involves any centralized server or trusting third parties:
1.Tx1 is a normal OP_RETURN transaction.
2.App will save results for `getrawmempool` regularly in local db. It will check if any transaction wants to participate in bets.
3.Multisig address will be created using two public keys. One entered by user and other from mempool.
4.Funding transaction will use the version bits to indicate if Alice wants to bet on India or Australia.


-- 
Prayank

A3B1 E430 2298 178F

[-- Attachment #2: Type: text/html, Size: 1664 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [bitcoin-dev] Using transaction version number in different projects
  2021-08-29  9:32 [bitcoin-dev] Using transaction version number in different projects Prayank
@ 2021-08-29 14:56 ` Pieter Wuille
  0 siblings, 0 replies; 2+ messages in thread
From: Pieter Wuille @ 2021-08-29 14:56 UTC (permalink / raw)
  To: Prayank, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

On Sunday, August 29th, 2021 at 5:32 AM, Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Wanted to know if others think we should allow more numbers in transaction version by considering such transaction standard. I have shared an example how transaction version can be used to bet on something that involves 2 outcomes:
> https://gist.github.com/prayank23/6f54e9a27f057abd1182436e7f88d1ac

I can't say I understand what you're suggesting, or what transaction version numbers have to do with it, so take the following with the caveat that I may be missing your point.

Generally, my view is that Bitcoin transactions should solely contain the information necessary for the world to validate them. Given that, as of now, there are no consensus rules (or even generally-adopted relay policies) that care about the version number except it being 1 or 2 (due to BIP68), I would say that the usage of anything but those 2 possible numbers is both pointless and a gratuitous loss of privacy: for numbers with no protocol-defined meaning, the usage of an uncommon one reveals something to the world that should be privately communicated to the parties involved instead.

Combined with the fact that currently-unused version numbers may well be used for future consensus rules like BIP68, which any use you're suggesting may interfere with, I say no: versions numbers with no protocol-defined meaning should not be standard. They are reserved for future extensions.

Cheers,

--
Pieter

[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-08-29 14:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-29  9:32 [bitcoin-dev] Using transaction version number in different projects Prayank
2021-08-29 14:56 ` Pieter Wuille

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox