Hi,
is any progress or even discussion in this area?
https://bitcointalk.org/index.php?topic=181734.0
I don't insist on any specific solution, but this is becoming a real issue
as hardware wallets are more widespread. I'm sitting next to TREZOR for 40
minutes already, because it streams and vali
The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
non-intrusive, doesn't change any TxOut scripts, doesn't change any
tx/block parsing (besides verification), it works with all existing
coins in the network, and existing software doesn't have to use it if
they don't want to upgrade t
Not a fix, but would reduce the financial risk, if nodes were not relaying
excessive fee transactions.
Tamas Blummer
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
New Year. New Location. New B
> I *strongly* encourage this to be considered for inclusion at some point.
Thanks Alan for a nice summary. I also agree that such stuff should be
implemented at some point. Anyway, I would probably not vote for doing hard
fork *just* for this change, but if I remember well, there're other ideas
f
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,
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 isolat
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner wrote:
> Unfortunately, it seems that there was no soft-fork way to achieve this
> benefit, at least not one that had favorable properties. Most of the
> soft-fork variations of it required the coins being spent to have been
> originated in a special w
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
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
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
On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell wrote:
> I think this is unreasonable. There is a straight-forward soft-fork
> approach which is safe (e.g. no risk of invalidating existing
> transactions). Yes, it means that you need to use newly created
> addresses to get coins that use the new
On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner wrote:
>> Unfortunately, it seems that there was no soft-fork way to achieve this
>> benefit, at least not one that had favorable properties. Most of the
>> soft-fork variations of it required the coins
On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner wrote:
>> Unfortunately, it seems that there was no soft-fork way to achieve this
>> benefit, at least not one that had favorable properties. Most of the
>> soft-fork variations of it required the coins
On 01/23/2015 11:27 AM, Alan Reiner wrote:
>
> I am happy to entertain other ideas that achieve our goals here, but I'm
> fairly confident that the new SIGHASH type is the only way that would
> allow devices like Trezor to truly simplify their design (and still work
> securely on 100% of funds con
Oh, now I got the 'soft-fork' alternative. If that means that *senders* to
Trezor need to be nice guys and use some special outputs, then it's,
obviously, no-go solution.
I understand political aspect around hard-fork. Anyway, are there any other
pending projects waiting for hard-fork? Maybe we sh
On Fri, Jan 23, 2015 at 4:18 PM, slush wrote:
> Can you send me any reference about this? Of course if that solves the
> problem, hard fork would not be necessary anymore. I'm just not aware of
> any.
Sure; will aggregate up the citations when I'm not travling later today.
> To sign transaction
Yes, the step you're missing is "and build the table". Dynamic memory
allocation is something you want to avoid, as well as any artifical
restrictions to number of inputs or outputs. Current solution is slow, but
there's really no limitation on tx size.
Plus there're significant restrictions to me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23 January 2015 08:35:23 GMT-08:00, slush wrote:
>Oh, now I got the 'soft-fork' alternative. If that means that *senders*
>to
>Trezor need to be nice guys and use some special outputs, then it's,
>obviously, no-go solution.
That's what P2SH is
On Fri, Jan 23, 2015 at 5:40 PM, slush wrote:
> Yes, the step you're missing is "and build the table". Dynamic memory
> allocation is something you want to avoid, as well as any artifical
> restrictions to number of inputs or outputs. Current solution is slow, but
> there's really no limitation on
You're right, there can be done some optimizations. Workarounds of
workaround. All this adds complexity, which reduces the security.
Marek
On Fri, Jan 23, 2015 at 7:51 PM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 5:40 PM, slush wrote:
> > Yes, the step you're missing is "and build the
20 matches
Mail list logo
