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 <a...@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 <ta...@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 <sl...@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 <etothe...@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 >> ------------------------------------------------------------------------------ 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
