summaryrefslogtreecommitdiff
path: root/c5/63614bf6256ef6ec15e93d6eec0057f965c212
blob: d274df5cb66c51ba7fd86a7007e52f4313dce513 (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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <drak@zikula.org>) id 1WNlis-0002Hv-Nj
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Mar 2014 16:09:38 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.46 as permitted sender)
	client-ip=74.125.82.46; envelope-from=drak@zikula.org;
	helo=mail-wg0-f46.google.com; 
Received: from mail-wg0-f46.google.com ([74.125.82.46])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WNlir-0000TP-Ov
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Mar 2014 16:09:38 +0000
Received: by mail-wg0-f46.google.com with SMTP id b13so5493111wgh.29
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 12 Mar 2014 09:09:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=PRZbC6b1rP2ggRcaYPie3ToyZ0q3iLzGzuAZ0LjOv5o=;
	b=O3acaVwb9w9ABBVBdyf9FNMtMcdQDxwQR1CVjRnOBUre8RmhTyaV8nnJH5eI1NS6TK
	K/iLkzMRNMSO6oBsetny4ULyWFGiHxa9ANOmpjXJm8C5INTq3RjVbBRnHSYIwgVwIFyQ
	zQ8Gd/XRG8ud0TKXUP+iGLX1LuYBi+Vr9IIGlJCK4nxU/KNdBpC67jiP0o4S/rhdXLOS
	feZYzEKfdmqmNloOItLU7fWwW9bD7364YVzNPzM4Yd/Etn6uEZocSMbGGUn+RaWtgN4d
	t5m/zuoGnrcpZxy0oja5wfsiViDfYUrxLdP8zE2DLjzkSYn6Ltwq582Y/vojCg75dWwK
	7ZJQ==
X-Gm-Message-State: ALoCoQlqYSEaJWc64c9qQn0iaOd1mEYSxAr1XH9BugzaTcaSJTa4feM4efUW5UiFreeFo1i/CIks
X-Received: by 10.180.77.129 with SMTP id s1mr8066187wiw.56.1394640571320;
	Wed, 12 Mar 2014 09:09:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.205.69 with HTTP; Wed, 12 Mar 2014 09:09:11 -0700 (PDT)
In-Reply-To: <CANEZrP2Lr0Do8dPXAvRPkZU0Hk4UBt=CjgXSSKbopawoq8NjgA@mail.gmail.com>
References: <CANAnSg3Bt0e7CfUcJXe96xhU6nqif9ey_vurZMZkSa9OHjHStw@mail.gmail.com>
	<CABsx9T0SMi6Gp4JY=CpHxLEu5pVkvDmnug7PsY7m_dvtT7khzg@mail.gmail.com>
	<531DFDF8.80008@gmail.com> <531E52FE.5090107@jerviss.org>
	<531E5454.1030601@gmail.com>
	<CAJHLa0NZkzQQvMxgCJAJGT=Yn6vrVNK8Bg7RAfAjctpnrfg5zA@mail.gmail.com>
	<CABsx9T3eViYDsEmLm7ceimJNwci3mCOxWoVnVZHrqp7pDmm0+g@mail.gmail.com>
	<CANAnSg2kzPF0886PsQW8chzsWi6Urp+=-x+9bbv8Mv6hmpvBPw@mail.gmail.com>
	<CAJHLa0Mu2kiv3CCme7BPwzWtT++PNLQ2aAKdLyA8LFTtXEg9fg@mail.gmail.com>
	<CABsx9T0Lvg84qFVRbc7Ef4vZEQj9eO7Jhup5PTRLLeuJFvXi-w@mail.gmail.com>
	<4fca6b510dd57d2f92affeb988d2ee5d.squirrel@fulvetta.riseup.net>
	<531FAA55.2020108@xeno-genesis.com> <531FC808.7060709@gmail.com>
	<9A6499BC-E546-45CC-A7EF-5182FC86052D@gmail.com>
	<53202D51.8010008@plan99.net>
	<CAJHLa0OuXyEz6gcq_dQKmGjJQf3cJjFyzjb38RCB3E6-wMLJ0g@mail.gmail.com>
	<CANEZrP2Lr0Do8dPXAvRPkZU0Hk4UBt=CjgXSSKbopawoq8NjgA@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Wed, 12 Mar 2014 16:09:11 +0000
Message-ID: <CANAnSg22Hmip6n7VvftODO9zoRghDdnPoJtxJrc55Jt_ccnG0Q@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d043c801ed7e88904f46b0f5c
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1WNlir-0000TP-Ov
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Multisign payment protocol?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 16:09:38 -0000

--f46d043c801ed7e88904f46b0f5c
Content-Type: text/plain; charset=UTF-8

On 12 March 2014 16:02, Mike Hearn <mike@plan99.net> wrote:

> This is what bitcoind produces and expects by default, for a partially
>> signed transaction.
>
>
> What happens if the act of filling out the signature pushes the
> transaction into a higher fee level?
>

Can this be calculated in advance knowing the initial transaction size and
the number of signatures required? Should be quite easy to make an
estimation from that? It's probably more of an implementation detail
though...

Drak

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
2 March 2014 16:02, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike=
@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">This is what bitcoind produces a=
nd expects by default, for a partially<br>



signed transaction.</blockquote><div><br></div></div><div>What happens if t=
he act of filling out the signature pushes the transaction into a higher fe=
e level?=C2=A0</div></div></div></div></blockquote><div><br></div><div>Can =
this be calculated in advance knowing the initial transaction size and the =
number of signatures required? Should be quite easy to make an estimation f=
rom that? It&#39;s probably more of an implementation detail though...</div=
>

<div><br>Drak</div></div></div></div>

--f46d043c801ed7e88904f46b0f5c--