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
137
138
139
140
141
142
143
144
145
146
147
148
149
|
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 <adam.back@gmail.com>) id 1YEgvN-0007sP-3g
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 16:17:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.45 as permitted sender)
client-ip=209.85.216.45; envelope-from=adam.back@gmail.com;
helo=mail-qa0-f45.google.com;
Received: from mail-qa0-f45.google.com ([209.85.216.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YEgvL-0000kx-QA
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Jan 2015 16:17:33 +0000
Received: by mail-qa0-f45.google.com with SMTP id n8so6457529qaq.4
for <bitcoin-development@lists.sourceforge.net>;
Fri, 23 Jan 2015 08:17:26 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.167.80 with SMTP id p16mr3885673qay.78.1422029846046;
Fri, 23 Jan 2015 08:17:26 -0800 (PST)
Sender: adam.back@gmail.com
Received: by 10.96.235.10 with HTTP; Fri, 23 Jan 2015 08:17:25 -0800 (PST)
In-Reply-To: <CALqxMTGTUYgA9OebK7aaTnrMEf=OMaW=e36m_0BMyprCX=yFQw@mail.gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
<78662993-6C67-4480-8062-55CC9FA63908@bitsofproof.com>
<54C26BFE.1080103@gmail.com>
<CAJna-HiXxt5E=FBiDuWMCKrK4C0dcvhHEjTAoK3LGQLafJOqtQ@mail.gmail.com>
<954BF4E3-8DF2-4927-9E25-C5D66127FFA5@bitsofproof.com>
<CALqxMTGTUYgA9OebK7aaTnrMEf=OMaW=e36m_0BMyprCX=yFQw@mail.gmail.com>
Date: Fri, 23 Jan 2015 16:17:25 +0000
X-Google-Sender-Auth: 8wIWLV_vfiwtFZulZ8q2hFdN0O4
Message-ID: <CALqxMTH2F5-Aj+U-D5KAtbJAAejCxmKgi+8knYAmSKJ_De0kyg@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YEgvL-0000kx-QA
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
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: Fri, 23 Jan 2015 16:17:33 -0000
Issues like that particular one (simple elegant fix, strong utility
justification) plus previously more privacy stuff (like committed tx,
homomorphic encrypted values) was what got me wondering about a way to
do a live beta (one-way peg) and then to get excited about the 2wp &
Greg's mechanism for that.
I think it would be hypothetically possible to make a "special"
singleton sidechain which is merge mined, and has a consensus rule to
require some proportion of reward be sent to it via coinbase tx (a
mechanism to address incentive incompatibility) and a general timeline
eg 12mo to next version +/- etc. might be an interesting thing to
explore as a place to store live versions of "hard fork wishlist"
items where people who need them early can help validate them.
I am not sure that helps the full network upgrade issue though.
Adam
On 23 January 2015 at 16:12, Adam Back <adam@cypherspace.org> wrote:
> its an always offline node, so it knows nothing really other than a
> BIP 32 hierarchy of keys & a signature request.
>
> So the signature request has to drag with it information to validate
> what the value is, in order to be sure not to sign away 99% to fees.
> Signing the transaction value and having the network validate that the
> value in the sig matches full nodes view of the tx value avoids that
> issue. Simple, elegant, but... we have no live beta mechanism, and
> hence risk & testing makes that tricky. Plus the full network upgrade
> issue if its not backwards compatible.
>
> Adam
>
> On 23 January 2015 at 16:08, Tamas Blummer <tamas@bitsofproof.com> wrote:
>> You mean an isolated signing device without memory right?
>>
>> An isolated node would still know the transactions substantiating its coins,
>> why would it sign them away to fees ?
>>
>> Tamas Blummer
>>
>> On Jan 23, 2015, at 4:47 PM, slush <slush@centrum.cz> wrote:
>>
>> Correct, plus the most likely scenario in such attack is that the malware
>> even don't push such tx with excessive fees to the network, but send it
>> directly to attacker's pool/miner.
>>
>> M.
>>
>> On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>>>
>>> Unfortunately, one major attack vector is someone isolating your node,
>>> getting you to sign away your whole wallet to fee, and then selling it to a
>>> mining pool to mine it before you can figure why your transactions aren't
>>> making it to the network. In such an attack, the relay rules aren't
>>> relevant, and if the attacker can DoS you for 24 hours, it doesn't take a
>>> ton of mining power to make the attack extremely likely to succeed.
>>>
>>>
>>>
>>>
>>> On 01/23/2015 10:31 AM, Tamas Blummer wrote:
>>>
>>> Not a fix, but would reduce the financial risk, if nodes were not relaying
>>> excessive fee transactions.
>>>
>>> Tamas Blummer
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
>> GigeNET is offering a free month of service with a new server in Ashburn.
>> Choose from 2 high performing configs, both with 100TB of bandwidth.
>> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>> http://p.sf.net/sfu/gigenet
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
|
