summaryrefslogtreecommitdiff
path: root/94/6d4b82c7b9711def555f688b39fb1661787dd0
blob: de52393c4cce11a9d4586585f0f27adfc875a557 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
Return-Path: <prayank@tutanota.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 24AA2C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Aug 2021 09:32:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 09DBA400E7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Aug 2021 09:32:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_SBL_A=0.1]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DGb3tmPvr4CH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Aug 2021 09:32:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6ACD2400DA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Aug 2021 09:32:50 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id 5EF3EFA037E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Aug 2021 09:32:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1630229567; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
 bh=FU6WqrLT04o82ZzCxRbCZQ3c4WmPiGB17cuTlVEvntg=;
 b=b1tPbCGnJ+/zaXb0RNJTX1gmV4gYvUYMohEjyn5LofEPtlN1XQVtPCChsLFbCJif
 kBccmQ9RHFNvVGgNVRMv7EAT9C2bJnDGC5woiwmyKUinuYpXA2vdwkplOcXpcLqcQme
 nidcpEnC0Fi/SRswfxFHwP9Be6cZYh7LXULSrmp3HTZxXV/7MGWHLII5AF2RSNkM0pd
 9661McHqZl0uuUkxwflzEs7Pr5eSsyXMfrcQcfzD68aw7AiJkzNV0+mHa4tSczfFaLa
 PFFmAojSeEqVuX8OAgCVnSGFFxz3LARKCflQiZ5bDWcGSAbDRgMPm+QgdXj863PzPg5
 9LioG4rA+g==
Date: Sun, 29 Aug 2021 11:32:47 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <MiGFGDc--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_454059_1302865444.1630229567375"
X-Mailman-Approved-At: Sun, 29 Aug 2021 10:06:38 +0000
Subject: [bitcoin-dev] Using transaction version number in different projects
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Aug 2021 09:32:55 -0000

------=_Part_454059_1302865444.1630229567375
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

print('Hello, world!')

I had asked related question on Bitcoin Stackexchange:=C2=A0https://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 out=
comes:

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 want=
ed to confirm if everything looks okay until funding transaction. Nothing i=
nvolves 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 us=
er and other from mempool.
4.Funding transaction will use the version bits to indicate if Alice wants =
to bet on India or Australia.


--=20
Prayank

A3B1 E430 2298 178F

------=_Part_454059_1302865444.1630229567375
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>print('Hello, world!')<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I had asked related question on Bitcoin Stackexchange:&nbsp;https=
://bitcoin.stackexchange.com/questions/108248/version-in-transaction<br></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">Wanted to know if others t=
hink we should allow more numbers in transaction version by considering suc=
h transaction standard. I have shared an example how transaction version ca=
n be used to bet on something that involves 2 outcomes:<br><br></div><div d=
ir=3D"auto">https://gist.github.com/prayank23/6f54e9a27f057abd1182436e7f88d=
1ac<br><br>Anything wrong with this approach? We could use oracles (DLC) or=
 something else later to settle the bet and create a release transaction. H=
owever wanted to confirm if everything looks okay until funding transaction=
. Nothing involves any centralized server or trusting third parties:</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">1.Tx1 is a normal OP_RETURN tr=
ansaction.<br></div><div dir=3D"auto">2.App will save results for `getrawme=
mpool` regularly in local db. It will check if any transaction wants to par=
ticipate in bets.<br></div><div dir=3D"auto">3.Multisig address will be cre=
ated using two public keys. One entered by user and other from mempool.<br>=
</div><div dir=3D"auto">4.Funding transaction will use the version bits to =
indicate if Alice wants to bet on India or Australia.<br></div><div dir=3D"=
auto"><br></div><div><br></div><div>-- <br></div><div>Prayank<br></div><div=
><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div>  </body>
</html>

------=_Part_454059_1302865444.1630229567375--