Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

fred savage via bitcoin-dev  writes:
> the issues with sighash_noinput is this
>
>   1.  you cannot prevent address-reuse. because bitcoin is a PUSH
>   payment. meaning other people can send funds to one address without
>   the owner of the key approval/refusal. thus luke cannot control
>   address reuse if many people start spamming him donations.

This point is pretty much moot since these are scripts, that are used in
very specialized contexts, and should not be shown to any
end-user. Sure, if you go through the blockchain looking for these
addresses, and send the exact same value to it, and create a matching
script then you could end up exposing those funds to this, however
that'd be very silly of you, and you'd have jumped through a lot of
hoops to lose money :-)

>   2.  for average users who would just 'autopilot' LN and only see the
> GUI. they will have no clue what transaction types and technicals are
> happening under the hood. also with LN being not validated by the
> community. a user creating a channel could tweak their own LN node to
> make their counterparty sign a sighash-noinput as a term/condition of
> the channel this is also a risk for the under the hood raw tx risks
> where a tx can be signed but then allow the out's to alter value(using
> a different opcode). .. you know the premiss of allowing a counterpart
> to alter the outs value to vary so that they can control the broadcast
> fee at the time of broadcast to cover being acceptd onchain.. which
> can be abused by a counter party just editing it so A gets nothing and
> B gets it all..

You cannot force the counterparty to sign with a sighash-flag that they
don't chose themselves. We are very clear in the BIP that you should
only use sighash_noinput_unsafe in the context of protocols, that need
to be designed in such a way that these issues are excluded. In
particular, eltoo uses a public key, provided by the signing party,
which they can ensure is not reused (ensuring script
uniqueness). Finally, wallets that are not part of LN or eltoo, won't
even know how to sign with sighash-noinput (try signing anything but
sighash-all on a hardware wallet for example).

The kind of editing you describe also doesn't work, since sighash-single
is used for the late fee binding, not sighash-noinput. sighash-single
makes sure that the input is only valid if the matching output is still
intact, so redirecting funds away from the desired output doesn't work.

>   3.  by allowing certain things to change after signing. is infact
>   bringing back malleability for those that use a TXID to identify a
>   tx has been confirmed. as a TXID would change if values
>   change.. just like how malleation abused old transactions by editing
>   a tx without needing to re-sign a tx

Again, this is only to be used in the context of applications that
require it, which also means that they know how to deal with this
malleability (in fact this malleability is wanted here). If you squint
at it you can probably see that sighash-noinput is also a poor-man's
malleability fix, allowing you to take a transaction that is based on a
malleated output, and rebind it to re-establish the connection.

It seems people believe that we are advocating the use of
sighash-noinput-unsafe in general purpose wallets and in everyday
transactions, this couldn't be further from the truth: sighash-noinput
is a sharp tool, that should only be used in very specific situations,
to enable a bit more flexibility, and it can improve the safety of
off-chain protocols a lot, however general purpose wallets should not
even allow signing with it.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Coins

[PJ Fitzpatrick via bitcoin-dev]

On Fri, Jul 13, 2018 at 1:27 AM Jakub Trnka 
wrote:

> I think building some overlay scarcity and value on top of bitcoin
> blockchain would incentivize people to transact a lot. An equilibrium would
> emerge between paying transaction fees and mining new coins. Which would
> effectively be equivalent to selling bitcoin and buying some mergemined
> altcoin, except this would congest the bitcoin network. You can easily
> borrow scarcity from bitcoin in some sidechain.
>

Yes  what you say is correct. Therefore n could be a function of the
transaction fees of the block. I think this should be on bitcointalk and I
am going to start a discussion there.
PJ Fitzpatrick


> Jakub Trnka
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On 12 July 2018 10:05 AM, PJ Fitzpatrick via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I am considering a method to derive digital scarcity from bitcoin
> transactions. Coins are created from transactions if their hash is among
> the closest n to the non zero portion of the block hash. Only a single coin
> can be created per transaction irrespective of the size of the transaction.
> Therefore n coins are created per block.
>
> The initial coin supply and addresses can be fully determined by the
> existing blockchain. Additionally coins are scarce as coins can only be
> produced by transactions.
>
> There are a number of variants such as creating computation puzzles from
> the previous block.
>
> Has anyone seen anything similar.
>
>
> PJ Fitzpatrick
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transaction Coins

[Jakub Trnka via bitcoin-dev]

I think building some overlay scarcity and value on top of bitcoin blockchain 
would incentivize people to transact a lot. An equilibrium would emerge between 
paying transaction fees and mining new coins. Which would effectively be 
equivalent to selling bitcoin and buying some mergemined altcoin, except this 
would congest the bitcoin network. You can easily borrow scarcity from bitcoin 
in some sidechain.

Jakub Trnka

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On 12 July 2018 10:05 AM, PJ Fitzpatrick via bitcoin-dev 
 wrote:

> I am considering a method to derive digital scarcity from bitcoin 
> transactions. Coins are created from transactions if their hash is among the 
> closest n to the non zero portion of the block hash. Only a single coin can 
> be created per transaction irrespective of the size of the transaction. 
> Therefore n coins are created per block.
>
> The initial coin supply and addresses can be fully determined by the existing 
> blockchain. Additionally coins are scarce as coins can only be produced by 
> transactions.
>
> There are a number of variants such as creating computation puzzles from the 
> previous block.
>
> Has anyone seen anything similar.
>
> PJ Fitzpatrick___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[fred savage via bitcoin-dev]

the issues with sighash_noinput is this

  1.  you cannot prevent address-reuse. because bitcoin is a PUSH payment. 
meaning other people can send funds to one address without the owner of the key 
approval/refusal. thus luke cannot control address reuse if many people start 
spamming him donations.
  2.  for average users who would just 'autopilot' LN and only see the GUI. 
they will have no clue what transaction types and technicals are happening 
under the hood. also with LN being not validated by the community. a user 
creating a channel could tweak their own LN node to make their counterparty 
sign a sighash-noinput as a term/condition of the channel
this is also a risk for the under the hood raw tx risks where a tx can be 
signed but then allow the out's to alter value(using a different opcode). .. 
you know the premiss of allowing a counterpart to alter the outs value to vary 
so that they can control the broadcast fee at the time of broadcast to cover 
being acceptd onchain.. which can be abused by a counter party just editing it 
so A gets nothing and B gets it all..
  3.  by allowing certain things to change after signing. is infact bringing 
back malleability for those that use a TXID to identify a tx has been 
confirmed. as a TXID would change if values change.. just like how malleation 
abused old transactions by editing a tx without needing to re-sign a tx


From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Rusty Russell via 
bitcoin-dev 
Sent: 13 July 2018 00:04:14
To: DING FENG; Luke Dashjr
Cc: Bitcoin Protocol Discussion; lightning-...@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

DING FENG  writes:
> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse
> address more dangerous.

No.

A wallet should *never* create a SIGHASH_NOINPUT to spend its own UTXOs.
SIGHASH_NOINPUT is useful for smart contracts which have unique
conditions, such as a pair of peers rotating keys according to an agreed
schedule (eg. lightning).

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev