Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.182 as permitted sender)
	client-ip=209.85.216.182; envelope-from=adam.back@gmail.com;
	helo=mail-qc0-f182.google.com; 
MIME-Version: 1.0
Sender: adam.back@gmail.com
In-Reply-To: <954BF4E3-8DF2-4927-9E25-C5D66127FFA5@bitsofproof.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>
Date: Fri, 23 Jan 2015 16:12:28 +0000
Message-ID: <CALqxMTGTUYgA9OebK7aaTnrMEf=OMaW=e36m_0BMyprCX=yFQw@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: text/plain; charset=UTF-8
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Precedence: list

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
>