From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <78662993-6C67-4480-8062-55CC9FA63908@bitsofproof.com> <54C26BFE.1080103@gmail.com> <954BF4E3-8DF2-4927-9E25-C5D66127FFA5@bitsofproof.com> Date: Fri, 23 Jan 2015 16:17:25 +0000 X-Google-Sender-Auth: 8wIWLV_vfiwtFZulZ8q2hFdN0O4 Message-ID: From: Adam Back To: Adam Back 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" Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 >>