* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 11:22 99% ` Melvin Carvalho
@ 2019-04-01 11:50 99% ` Dana L. Coe
0 siblings, 0 replies; 123+ results
From: Dana L. Coe @ 2019-04-01 11:50 UTC (permalink / raw)
To: Melvin Carvalho, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8013 bytes --]
I suggest in the spirit of the times that we not use USD as the reference, but USDT.
Everyone knows Tethers are much more flexible in tracking the true value of the US dollar.
Dana
> On Apr 1, 2019, at 7:22 PM, Melvin Carvalho via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
>
> On Mon, 1 Apr 2019 at 02:32, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki <https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki>
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki <https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki>
>
> A reference implementation is here:
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k <https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k>
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> This seems a little arbitrary. Ask yourself, "Why the USD?". Yes, it is the dominant currency now, but in 2, 6, 10, 14 years? Who knows.
>
> You could make equally an argument to denominate in euros. Or a basket of currencies, or even the Bancor.
>
> However the wider question is why even denominate in fiat at all?
>
> I suggest denominating the minimum value in satoshsis themselves, which would be a negligable upgrade to the network.
>
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip@dashjr•org <mailto:luke%2Bbip@dashjr•org>>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?? <https://github.com/bitcoin/bips/wiki/Comments:BIP-??>??
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to the
> price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing, weight
> calculation, and so on, the output count must be incremented by one. Prior to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero, and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field <https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field>
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip@dashjr•org <mailto:luke%2Bbip@dashjr•org>>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?? <https://github.com/bitcoin/bips/wiki/Comments:BIP-??>??
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions. Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1), a
> block is reject as invalid unless all transactions it contains both declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k <https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <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
[-- Attachment #2: Type: text/html, Size: 11805 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 0:30 99% [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC Luke Dashjr
` (2 preceding siblings ...)
2019-04-01 2:54 99% ` Omar Shibli
@ 2019-04-01 11:22 99% ` Melvin Carvalho
2019-04-01 11:50 99% ` Dana L. Coe
3 siblings, 1 reply; 123+ results
From: Melvin Carvalho @ 2019-04-01 11:22 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6567 bytes --]
On Mon, 1 Apr 2019 at 02:32, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
>
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
This seems a little arbitrary. Ask yourself, "Why the USD?". Yes, it is
the dominant currency now, but in 2, 6, 10, 14 years? Who knows.
You could make equally an argument to denominate in euros. Or a basket of
currencies, or even the Bancor.
However the wider question is why even denominate in fiat at all?
I suggest denominating the minimum value in satoshsis themselves, which
would be a negligable upgrade to the network.
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip@dashjr•org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to
> the
> price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation
> of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency
> other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing,
> weight
> calculation, and so on, the output count must be incremented by one. Prior
> to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero,
> and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip@dashjr•org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions.
> Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1),
> a
> block is reject as invalid unless all transactions it contains both
> declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at
> a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 8858 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 3:07 99% ` Satoshin
@ 2019-04-01 8:55 99% ` LORD HIS EXCELLENCY JAMES HRMH
0 siblings, 0 replies; 123+ results
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-04-01 8:55 UTC (permalink / raw)
To: Peter Todd, Satoshin, Bitcoin Protocol Discussion,
Bitcoin Protocol Discussion, Luke Dashjr
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
It is April 1st. Nonetheless, I am agreed that the first part to track the exchange rate in USD (why not use Gold $/oz?) has merit if properly implemented. Voluntary data is notoriously difficult to enforce for accuracy.
Regards,
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Satoshin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Monday, 1 April 2019 2:07 PM
To: Peter Todd; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
Hi Everyone,
First portion of your First BIP is excellent- with this field the protocol can actually attain HFT- by pinning of value at time of trade for later unblock scaling as a mark to market tool which is used in HFT.
The Second BIP of a minimum price would never allow Bitcoin to pass the SEC test of a viable asset. - I hope that portion was actually a Joke since it makes no sense economically.
If one has ever seen a stock drop 90% in one day then you would understand the volatile nature of future valuation.
Prices have to be able to go higher and lower based on market demand and not tethering to perceived norms. If the US dollar was crashed and it went down to Venezuelan currency levels [hypothetically then where would your 50k limit lead the currency} Never say never-
Best Regards
XX
> On Mar 31, 2019, at 9:11 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Mon, Apr 01, 2019 at 12:30:34AM +0000, Luke Dashjr via bitcoin-dev wrote:
>> Certain parts of the community have been selling bitcoins for unreasonably
>> low prices. This has halted Bitcoin's valuation at $20k and even driven the
>> price down below $15k! However, clearly Bitcoin is worth much more than
>> that, and there is widespread support for higher prices.
>>
>> In light of this, I have written and implemented two BIPs: one to add a
>> signed price field to Bitcoin transactions, and the other to softfork a
>> minimum price of $50k USD/BTC a year from today.
>
> I believe I've found a serious vulnerability in your proposal: there's no limit
> on the maximum supply of USD.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> 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
[-- Attachment #2: Type: text/html, Size: 4096 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 1:11 99% ` Peter Todd
2019-04-01 2:55 99% ` Omar Shibli
2019-04-01 3:02 99% ` ZmnSCPxj
@ 2019-04-01 3:07 99% ` Satoshin
2019-04-01 8:55 99% ` LORD HIS EXCELLENCY JAMES HRMH
2 siblings, 1 reply; 123+ results
From: Satoshin @ 2019-04-01 3:07 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
Hi Everyone,
First portion of your First BIP is excellent- with this field the protocol can actually attain HFT- by pinning of value at time of trade for later unblock scaling as a mark to market tool which is used in HFT.
The Second BIP of a minimum price would never allow Bitcoin to pass the SEC test of a viable asset. - I hope that portion was actually a Joke since it makes no sense economically.
If one has ever seen a stock drop 90% in one day then you would understand the volatile nature of future valuation.
Prices have to be able to go higher and lower based on market demand and not tethering to perceived norms. If the US dollar was crashed and it went down to Venezuelan currency levels [hypothetically then where would your 50k limit lead the currency} Never say never-
Best Regards
XX
> On Mar 31, 2019, at 9:11 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Mon, Apr 01, 2019 at 12:30:34AM +0000, Luke Dashjr via bitcoin-dev wrote:
>> Certain parts of the community have been selling bitcoins for unreasonably
>> low prices. This has halted Bitcoin's valuation at $20k and even driven the
>> price down below $15k! However, clearly Bitcoin is worth much more than
>> that, and there is widespread support for higher prices.
>>
>> In light of this, I have written and implemented two BIPs: one to add a
>> signed price field to Bitcoin transactions, and the other to softfork a
>> minimum price of $50k USD/BTC a year from today.
>
> I believe I've found a serious vulnerability in your proposal: there's no limit
> on the maximum supply of USD.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 1:04 99% ` Ricardo Filipe
2019-04-01 2:57 99% ` Thomas France
@ 2019-04-01 3:04 99% ` Dave Scotese
1 sibling, 0 replies; 123+ results
From: Dave Scotese @ 2019-04-01 3:04 UTC (permalink / raw)
To: Ricardo Filipe, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7683 bytes --]
I think EXACTLY ONE YEAR is the perfect time. Well, a year and a day for
me because I'm on the wrong side of the date line, apparently.
On Sun, Mar 31, 2019 at 6:04 PM Ricardo Filipe via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> one year seems too long. i think with the BIP-148 experience you have
> we could easily get there in 6 months at most.
>
> Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> escreveu no dia segunda, 1/04/2019 à(s) 01:33:
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably
> > low prices. This has halted Bitcoin's valuation at $20k and even driven
> the
> > price down below $15k! However, clearly Bitcoin is worth much more than
> > that, and there is widespread support for higher prices.
> >
> > In light of this, I have written and implemented two BIPs: one to add a
> > signed price field to Bitcoin transactions, and the other to softfork a
> > minimum price of $50k USD/BTC a year from today.
> >
> > The BIPs are here, as well as included at the bottom of this email for
> > convenience:
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
> >
> > A reference implementation is here:
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
> >
> > Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
> >
> > Luke
> >
> >
> > <pre>
> > BIP: ?
> > Layer: Applications
> > Title: Signed USD Price Indicator
> > Author: Luke Dashjr <luke+bip@dashjr•org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> > for transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > This problem can be fixed by setting a global minimum price for bitcoins.
> > Unfortunately, today, the consensus protocol is completely oblivious to
> the
> > price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> > transactions to indicate their price.
> >
> > ==Specification==
> >
> > ===New field and legal implication===
> >
> > A new field is added to Bitcoin transactions. This field, if present,
> must
> > represent the honest and true USD/BTC rate used for the transaction. By
> > signing the transaction, the sender legally affirms this is the
> valuation of
> > bitcoins used for the transaction.
> >
> > For the avoidance of doubt: when the transaction is valued in a currency
> other
> > than USD, any reasonable exchange rate may be used to come up with the
> USD
> > valuation.
> >
> > ===Serialisation===
> >
> > When serialising the transaction for any purpose, including signing,
> weight
> > calculation, and so on, the output count must be incremented by one.
> Prior to
> > the first real output, the following bytes must be inserted:
> >
> > * Constant: 00 00 00 00 00 00 00 00
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * Constant: 6a 04 55 53 44 24
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * The USD/BTC rate used for the transaction, in standard signed integer
> > serialisation, with all leading zeros removed (except as necessary to
> > preserve the sign bit).
> >
> > ==Backwards compatibility==
> >
> > ===Consensus===
> >
> > The new price field is serialised as a dummy output, with a value of
> zero, and
> > a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will
> ignore
> > this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> > is never considered spendable.
> >
> > Therefore, current nodes will ignore the new field entirely, and accept
> > transactions using it.
> >
> > ===Wallets===
> >
> > Existing wallets do not typically generate price indicators as specified.
> > Under this BIP, this absence of the field is perfectly acceptable.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
> >
> > <pre>
> > BIP: ?
> > Layer: Consensus (soft fork)
> > Title: $50k USD/BTC Minimum Price
> > Author: Luke Dashjr <luke+bip@dashjr•org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > Requires: usdprice
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP defines a minimum price of $50k USD/BTC for Bitcoin
> transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > bip-usdprice defines a new field to indicate the price of transactions.
> Using
> > this, we can softfork to require a minimum transaction price.
> >
> > ==Specification==
> >
> > Beginning with block height 622370 (expected approximately 2020 April
> 1), a
> > block is reject as invalid unless all transactions it contains both
> declare a
> > USD/BTC price (as defined in bip-usdprice) and specify a price that is
> at a
> > minimum $50k USD/BTC.
> >
> > ==Backwards compatibility==
> >
> > As a soft fork, older nodes will continue to accept the blockchain
> without
> > modification. Non-upgraded nodes, however, will not validate the minimum
> > price requirement, and may accept invalid blocks if miners choose to make
> > them. Since transactions not declaring a price are at this time still
> > common-place, the softfork activation has been set a full year into the
> > future to ensure time to upgrade both nodes and wallet software.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> > _______________________________________________
> > 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
[-- Attachment #2: Type: text/html, Size: 10410 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 1:11 99% ` Peter Todd
2019-04-01 2:55 99% ` Omar Shibli
@ 2019-04-01 3:02 99% ` ZmnSCPxj
2019-04-01 3:07 99% ` Satoshin
2 siblings, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-04-01 3:02 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
Hard NAK.
A minimum 50000 USD : 1 BTC exchange rate implies that the value of 1 USD = 0.00002 BTC at maximum.
However, such a USD value in BTC value maximum makes no sense since the true value of 1 USD = 0.00000000 BTC.
(on Lightning, 1 USD = 0.00000000000 BTC)
In particular, the encoding proposed in the BIP does not support a representation of infinity USD per BTC, such that it is impossible to express the true value of USD under this BIP.
> * The USD/BTC rate used for the transaction, in standard signed integer serialisation, with all leading zeros removed (except as necessary to preserve the sign bit).
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 1:04 99% ` Ricardo Filipe
@ 2019-04-01 2:57 99% ` Thomas France
2019-04-01 3:04 99% ` Dave Scotese
1 sibling, 0 replies; 123+ results
From: Thomas France @ 2019-04-01 2:57 UTC (permalink / raw)
To: Ricardo Filipe, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7240 bytes --]
Once again, Core shows how conservative they are. I am in favor of 2X with
a 100kUSD minimum price, all Bitcoin businesses are with me !
On Sun, Mar 31, 2019 at 7:48 PM Ricardo Filipe via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> one year seems too long. i think with the BIP-148 experience you have
> we could easily get there in 6 months at most.
>
> Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> escreveu no dia segunda, 1/04/2019 à(s) 01:33:
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably
> > low prices. This has halted Bitcoin's valuation at $20k and even driven
> the
> > price down below $15k! However, clearly Bitcoin is worth much more than
> > that, and there is widespread support for higher prices.
> >
> > In light of this, I have written and implemented two BIPs: one to add a
> > signed price field to Bitcoin transactions, and the other to softfork a
> > minimum price of $50k USD/BTC a year from today.
> >
> > The BIPs are here, as well as included at the bottom of this email for
> > convenience:
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> >
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
> >
> > A reference implementation is here:
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
> >
> > Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
> >
> > Luke
> >
> >
> > <pre>
> > BIP: ?
> > Layer: Applications
> > Title: Signed USD Price Indicator
> > Author: Luke Dashjr <luke+bip@dashjr•org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> > for transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > This problem can be fixed by setting a global minimum price for bitcoins.
> > Unfortunately, today, the consensus protocol is completely oblivious to
> the
> > price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> > transactions to indicate their price.
> >
> > ==Specification==
> >
> > ===New field and legal implication===
> >
> > A new field is added to Bitcoin transactions. This field, if present,
> must
> > represent the honest and true USD/BTC rate used for the transaction. By
> > signing the transaction, the sender legally affirms this is the
> valuation of
> > bitcoins used for the transaction.
> >
> > For the avoidance of doubt: when the transaction is valued in a currency
> other
> > than USD, any reasonable exchange rate may be used to come up with the
> USD
> > valuation.
> >
> > ===Serialisation===
> >
> > When serialising the transaction for any purpose, including signing,
> weight
> > calculation, and so on, the output count must be incremented by one.
> Prior to
> > the first real output, the following bytes must be inserted:
> >
> > * Constant: 00 00 00 00 00 00 00 00
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * Constant: 6a 04 55 53 44 24
> > * A single byte, the size in bytes of the remainder of the inserted data
> > * The USD/BTC rate used for the transaction, in standard signed integer
> > serialisation, with all leading zeros removed (except as necessary to
> > preserve the sign bit).
> >
> > ==Backwards compatibility==
> >
> > ===Consensus===
> >
> > The new price field is serialised as a dummy output, with a value of
> zero, and
> > a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will
> ignore
> > this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> > is never considered spendable.
> >
> > Therefore, current nodes will ignore the new field entirely, and accept
> > transactions using it.
> >
> > ===Wallets===
> >
> > Existing wallets do not typically generate price indicators as specified.
> > Under this BIP, this absence of the field is perfectly acceptable.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
> >
> > <pre>
> > BIP: ?
> > Layer: Consensus (soft fork)
> > Title: $50k USD/BTC Minimum Price
> > Author: Luke Dashjr <luke+bip@dashjr•org>
> > Comments-Summary: No comments yet.
> > Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> > Status: Draft
> > Type: Standards Track
> > Created: 2019-04-01
> > License: BSD-2-Clause
> > Requires: usdprice
> > </pre>
> >
> > ==Abstract==
> >
> > This BIP defines a minimum price of $50k USD/BTC for Bitcoin
> transactions.
> >
> > ==Copyright==
> >
> > This BIP is licensed under the BSD 2-clause license.
> >
> > ==Motivation==
> >
> > Certain parts of the community have been selling bitcoins for
> unreasonably low
> > prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> > down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> > there is widespread support for higher prices.
> >
> > bip-usdprice defines a new field to indicate the price of transactions.
> Using
> > this, we can softfork to require a minimum transaction price.
> >
> > ==Specification==
> >
> > Beginning with block height 622370 (expected approximately 2020 April
> 1), a
> > block is reject as invalid unless all transactions it contains both
> declare a
> > USD/BTC price (as defined in bip-usdprice) and specify a price that is
> at a
> > minimum $50k USD/BTC.
> >
> > ==Backwards compatibility==
> >
> > As a soft fork, older nodes will continue to accept the blockchain
> without
> > modification. Non-upgraded nodes, however, will not validate the minimum
> > price requirement, and may accept invalid blocks if miners choose to make
> > them. Since transactions not declaring a price are at this time still
> > common-place, the softfork activation has been set a full year into the
> > future to ensure time to upgrade both nodes and wallet software.
> >
> > ==Reference implementation==
> >
> >
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> > _______________________________________________
> > 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
>
[-- Attachment #2: Type: text/html, Size: 9805 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 1:11 99% ` Peter Todd
@ 2019-04-01 2:55 99% ` Omar Shibli
2019-04-01 3:02 99% ` ZmnSCPxj
2019-04-01 3:07 99% ` Satoshin
2 siblings, 0 replies; 123+ results
From: Omar Shibli @ 2019-04-01 2:55 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
Shit, so we are vulnerable today? is this zero day vulnerability? so we
could be f***** big?
On Mon, Apr 1, 2019 at 5:47 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Mon, Apr 01, 2019 at 12:30:34AM +0000, Luke Dashjr via bitcoin-dev
> wrote:
> > Certain parts of the community have been selling bitcoins for
> unreasonably
> > low prices. This has halted Bitcoin's valuation at $20k and even driven
> the
> > price down below $15k! However, clearly Bitcoin is worth much more than
> > that, and there is widespread support for higher prices.
> >
> > In light of this, I have written and implemented two BIPs: one to add a
> > signed price field to Bitcoin transactions, and the other to softfork a
> > minimum price of $50k USD/BTC a year from today.
>
> I believe I've found a serious vulnerability in your proposal: there's no
> limit
> on the maximum supply of USD.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1949 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 0:30 99% [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC Luke Dashjr
2019-04-01 1:04 99% ` Ricardo Filipe
2019-04-01 1:11 99% ` Peter Todd
@ 2019-04-01 2:54 99% ` Omar Shibli
2019-04-01 11:22 99% ` Melvin Carvalho
3 siblings, 0 replies; 123+ results
From: Omar Shibli @ 2019-04-01 2:54 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6382 bytes --]
Reasonable, I think also first timer should be forbidden form transacting
for at least 3 years from the first purchase, after going in '3 years' into
the rabbit hole, you can consider selling bitcoins. that's fair for low
time hard money folks, imho.
On Mon, Apr 1, 2019 at 3:33 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
>
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip@dashjr•org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to
> the
> price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation
> of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency
> other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing,
> weight
> calculation, and so on, the output count must be incremented by one. Prior
> to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero,
> and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip@dashjr•org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions.
> Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1),
> a
> block is reject as invalid unless all transactions it contains both
> declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at
> a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 8436 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 0:30 99% [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC Luke Dashjr
2019-04-01 1:04 99% ` Ricardo Filipe
@ 2019-04-01 1:11 99% ` Peter Todd
2019-04-01 2:55 99% ` Omar Shibli
` (2 more replies)
2019-04-01 2:54 99% ` Omar Shibli
2019-04-01 11:22 99% ` Melvin Carvalho
3 siblings, 3 replies; 123+ results
From: Peter Todd @ 2019-04-01 1:11 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Mon, Apr 01, 2019 at 12:30:34AM +0000, Luke Dashjr via bitcoin-dev wrote:
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
I believe I've found a serious vulnerability in your proposal: there's no limit
on the maximum supply of USD.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
2019-04-01 0:30 99% [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC Luke Dashjr
@ 2019-04-01 1:04 99% ` Ricardo Filipe
2019-04-01 2:57 99% ` Thomas France
2019-04-01 3:04 99% ` Dave Scotese
2019-04-01 1:11 99% ` Peter Todd
` (2 subsequent siblings)
3 siblings, 2 replies; 123+ results
From: Ricardo Filipe @ 2019-04-01 1:04 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
one year seems too long. i think with the BIP-148 experience you have
we could easily get there in 6 months at most.
Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
escreveu no dia segunda, 1/04/2019 à(s) 01:33:
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>
> Luke
>
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Signed USD Price Indicator
> Author: Luke Dashjr <luke+bip@dashjr•org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to the
> price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing, weight
> calculation, and so on, the output count must be incremented by one. Prior to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero, and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> <pre>
> BIP: ?
> Layer: Consensus (soft fork)
> Title: $50k USD/BTC Minimum Price
> Author: Luke Dashjr <luke+bip@dashjr•org>
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
> Status: Draft
> Type: Standards Track
> Created: 2019-04-01
> License: BSD-2-Clause
> Requires: usdprice
> </pre>
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably low
> prices. This has halted Bitcoin's valuation at $20k and even driven the price
> down below $15k! However, clearly Bitcoin is worth much more than that, and
> there is widespread support for higher prices.
>
> bip-usdprice defines a new field to indicate the price of transactions. Using
> this, we can softfork to require a minimum transaction price.
>
> ==Specification==
>
> Beginning with block height 622370 (expected approximately 2020 April 1), a
> block is reject as invalid unless all transactions it contains both declare a
> USD/BTC price (as defined in bip-usdprice) and specify a price that is at a
> minimum $50k USD/BTC.
>
> ==Backwards compatibility==
>
> As a soft fork, older nodes will continue to accept the blockchain without
> modification. Non-upgraded nodes, however, will not validate the minimum
> price requirement, and may accept invalid blocks if miners choose to make
> them. Since transactions not declaring a price are at this time still
> common-place, the softfork activation has been set a full year into the
> future to ensure time to upgrade both nodes and wallet software.
>
> ==Reference implementation==
>
> https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC
@ 2019-04-01 0:30 99% Luke Dashjr
2019-04-01 1:04 99% ` Ricardo Filipe
` (3 more replies)
0 siblings, 4 replies; 123+ results
From: Luke Dashjr @ 2019-04-01 0:30 UTC (permalink / raw)
To: bitcoin-dev
Certain parts of the community have been selling bitcoins for unreasonably
low prices. This has halted Bitcoin's valuation at $20k and even driven the
price down below $15k! However, clearly Bitcoin is worth much more than
that, and there is widespread support for higher prices.
In light of this, I have written and implemented two BIPs: one to add a
signed price field to Bitcoin transactions, and the other to softfork a
minimum price of $50k USD/BTC a year from today.
The BIPs are here, as well as included at the bottom of this email for
convenience:
https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
A reference implementation is here:
https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
Luke
<pre>
BIP: ?
Layer: Applications
Title: Signed USD Price Indicator
Author: Luke Dashjr <luke+bip@dashjr•org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Standards Track
Created: 2019-04-01
License: BSD-2-Clause
</pre>
==Abstract==
This BIP proposes a method to explicitly specify and sign the USD/BTC price
for transactions.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Certain parts of the community have been selling bitcoins for unreasonably low
prices. This has halted Bitcoin's valuation at $20k and even driven the price
down below $15k! However, clearly Bitcoin is worth much more than that, and
there is widespread support for higher prices.
This problem can be fixed by setting a global minimum price for bitcoins.
Unfortunately, today, the consensus protocol is completely oblivious to the
price bitcoins are traded at. Therefore, we must first add a field to Bitcoin
transactions to indicate their price.
==Specification==
===New field and legal implication===
A new field is added to Bitcoin transactions. This field, if present, must
represent the honest and true USD/BTC rate used for the transaction. By
signing the transaction, the sender legally affirms this is the valuation of
bitcoins used for the transaction.
For the avoidance of doubt: when the transaction is valued in a currency other
than USD, any reasonable exchange rate may be used to come up with the USD
valuation.
===Serialisation===
When serialising the transaction for any purpose, including signing, weight
calculation, and so on, the output count must be incremented by one. Prior to
the first real output, the following bytes must be inserted:
* Constant: 00 00 00 00 00 00 00 00
* A single byte, the size in bytes of the remainder of the inserted data
* Constant: 6a 04 55 53 44 24
* A single byte, the size in bytes of the remainder of the inserted data
* The USD/BTC rate used for the transaction, in standard signed integer
serialisation, with all leading zeros removed (except as necessary to
preserve the sign bit).
==Backwards compatibility==
===Consensus===
The new price field is serialised as a dummy output, with a value of zero, and
a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
this dummy output, and the leading OP_RETURN in the scriptPubKey ensures it
is never considered spendable.
Therefore, current nodes will ignore the new field entirely, and accept
transactions using it.
===Wallets===
Existing wallets do not typically generate price indicators as specified.
Under this BIP, this absence of the field is perfectly acceptable.
==Reference implementation==
https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
<pre>
BIP: ?
Layer: Consensus (soft fork)
Title: $50k USD/BTC Minimum Price
Author: Luke Dashjr <luke+bip@dashjr•org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Standards Track
Created: 2019-04-01
License: BSD-2-Clause
Requires: usdprice
</pre>
==Abstract==
This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
Certain parts of the community have been selling bitcoins for unreasonably low
prices. This has halted Bitcoin's valuation at $20k and even driven the price
down below $15k! However, clearly Bitcoin is worth much more than that, and
there is widespread support for higher prices.
bip-usdprice defines a new field to indicate the price of transactions. Using
this, we can softfork to require a minimum transaction price.
==Specification==
Beginning with block height 622370 (expected approximately 2020 April 1), a
block is reject as invalid unless all transactions it contains both declare a
USD/BTC price (as defined in bip-usdprice) and specify a price that is at a
minimum $50k USD/BTC.
==Backwards compatibility==
As a soft fork, older nodes will continue to accept the blockchain without
modification. Non-upgraded nodes, however, will not validate the minimum
price requirement, and may accept invalid blocks if miners choose to make
them. Since transactions not declaring a price are at this time still
common-place, the softfork activation has been set a full year into the
future to ensure time to upgrade both nodes and wallet software.
==Reference implementation==
https://github.com/luke-jr/bitcoin/compare/usd_price_tx_field...softfork_50k
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
2019-03-22 21:04 99% [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) Jonas Schnelli
2019-03-24 13:29 99% ` David A. Harding
@ 2019-03-25 6:32 99% ` Eric Voskuil
1 sibling, 0 replies; 123+ results
From: Eric Voskuil @ 2019-03-25 6:32 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 7756 bytes --]
On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote:
> Proposal:
>
> <pre>
> BIP: ???
> Layer: Peer Services
> Title: Version 2 Peer-to-Peer Message Transport Protocol
> Author: Jonas Schnelli <dev@jonasschnelli•ch>
> Status: Draft
> Type: Standards Track
> Created: 2019-03-08
> License: PD
> </pre>
>
> == Abstract ==
>
> This BIP describes a new Bitcoin peer to peer transport protocol with
> opportunistic encryption.
>
> == Motivation ==
>
> The current peer-to-peer protocol is partially inefficient and in plaintext.
>
> With the current unencrypted message transport, BGP hijack,
> block delay attacks
> and message tempering are inexpensive and can be executed in a covert way
> (undetectable MITM)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
> Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
> Zohar, L.Vanbever]</ref>.
This proposal does not provide mitigation for BGP hijacking, message
tampering or delaying, between anonymous peers.
> Adding opportunistic encryption introduces a high risk for attackers of
> being detected. Peer operators can compare encryption session IDs
This is only possible if the peers have access to a secure/trusted side
channel between them. In other words, this does not benefit anonymous
peers. It also seems like quite a stretch to consider it creating "high
risk" for the attacker, since the chances of any given pair of peers
actually comparing session IDs over a secure channel seems extremely remote.
> or use other form of authentication schemes <ref
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> BIP150]</ref> to identify an attack.
Authentication helps mitigate attacks by requiring the identity of the
peer (based only on the presumption that a trusted peer wouldn't
attack). This provides no benefit to anonymous peers.
Data communicated between peers is entirely public. Unlike other systems
that maintain data integrity through encryption, Bitcoin relies on
validation. Encrypting public data between anonymous peers is pointless,
and thus counterproductive from an engineering and software security
standpoint.
More importantly Bitcoin system security *requires* widespread anonymous
participation. It's generally not a good idea to implement features that
backfire if they actually get widespread use. While we cannot prevent
people from using VPNs, incorporating them into the protocol is
counterproductive from a system security standpoint.
> Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256
> checksum truncated to 4 bytes. Roughly the same amount of computation power
> would be required for encrypting and authenticating a peer-to-peer
> message with ChaCha20 & Poly1305.
The proposal overlooks the simple alternatives of (1) not validating the
checksum, which is never necessary, and (2) proposing a protocol change
to drop the checksum altogether. The former requires no protocol change
and the latter can allow the checksum to be dropped in all messages
except "version" given a simple protocol version number increment (i.e.
no need to consume a service bit), saving not only the CPU resource but
also network bandwidth.
> Additionally, this BIP describes a way how data manipulation (blocking or
> tempering commands by an intercepting TCP/IP node) would be identifiable
> by the communicating peers.
The only such method described is manual comparison of session ID's
between trusted parties over a secure side channel.
> Encrypting traffic between peers is already possible with VPN, tor,
> stunnel,
> curveCP or any other encryption mechanism on a deeper OSI level,
> however, most
> of those solutions require significant knowhow in how to setup such a
> secure
> channel and are therefore not widely deployed.
Yet this is exactly what a secure side channel is. Furthermore, being
manual, not only would it also suffer from not being widely deployed,
but also widely ignored.
> == Specification ==
>
> <blockquote>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD",
> "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are
> to be
> interpreted as described in RFC
> 2119<ref>[https://tools.ietf.org/html/rfc2119
> RFC 2119]</ref>.
> </blockquote>
>
> A peer that supports the message transport protocol as defined in this
> proposal
> MUST accept encryption requests from all peers.
>
> Both communication direction share the same shared-secret but have
> different
> symmetric cipher keys.
>
> The encryption handshake MUST happen before sending any other messages
> to the
> responding peer.
>
> If the responding peer closes the connection after sending the handshake
> request, the initiating peer MAY try to connect again with the v1
> peer-to-peer
> transport protocol. Such reconnects allow an attacker to "downgrade" the
> encryption to plaintext communication and thus, accepting v1 connections
> MUST
> not be done when the Bitcoin peer-to-peer network uses almost only v2
> communication.
>
>
> === NODE_P2P_V2 ===
>
> Peers supporting the transport protocol after this proposal MUST signal
> <code>NODE_P2P_V2</code>
> <pre>
> NODE_P2P_V2 = (1 << 11)
> </pre>
>
> A peer usually learns an address along with the expected service flags
> which
> MAY be used to filter possible outbound peers.
>
> A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted
> communication
> specified in this proposal.
>
> Peers MAY only make outbound connections to peers supporting
> <code>NODE_P2P_V2</code>.
>
> === Handshake ===
...
> ==== Short Command ID ====
The shortening of message identifiers hardly seems worth the effort.
Dropping the checksum seems a much easier way to save more on the wire
(and in the CPU).
> === Risks ===
>
> The encryption does not include an authentication scheme.
> This BIP does not
> cover a proposal to avoid MITM attacks during the encryption
> initialization.
Then to be clear it cannot prevent MITM attacks. The only actual
mitigation requires manual comparison of session IDs after each
connection (and reconnection).
> However, peers MUST show the session-id to the user on request which
> allows to identify a MITM by a manual verification on a secure channel.
This scenario presumes that the two peers are operated by individuals
who know and trust each other and have the ability to communicate over a
secure side channel, and will each extract the session ID from their
respective peers and use the side channel to compare them.
Not only does this not support anonymous peering, it's not clear what
process would exist to make this actually useful in practice.
> Optional authentication schemes may be covered by other proposals <ref
> name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
> BIP150]</ref>.
>
> An attacker could delay or halt v2 protocol enforcement by providing a
> reasonable amount of peers not supporting the v2 protocol.
>
> == Compatibility ==
>
> This proposal is backward compatible (as long as not enforced).
Kudos for making this second attempt backward compatible.
> Non-supporting
> peers can still use unencrypted communications.
>
> == Reference implementation ==
> * Complete Bitcoin Core implementation:
> https://github.com/bitcoin/bitcoin/pull/14032
> * Reference implementation of the AEAD in C:
> https://github.com/jonasschnelli/chacha20poly1305
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
2019-03-24 13:29 99% ` David A. Harding
2019-03-24 15:38 99% ` David A. Harding
@ 2019-03-24 19:35 99% ` Jonas Schnelli
1 sibling, 0 replies; 123+ results
From: Jonas Schnelli @ 2019-03-24 19:35 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]
Hi Dave
Thanks for the review...
>> ==== Short Command ID ====
>>
>> To save valuable bandwidth, the v2 message format supports message command
>> short IDs for message types with high frequency. The ID/string mapping is a
>> peer to peer arrangement and MAY be negotiated between the initiating and
>> responding peer.
>
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
> There's only 26 different types at present[1], so it seems better to
> simply make this a one-byte fixed-length field than it is to deal with
> variable size, mapping negotiation, per-peer mapping in general, and
> (once the network is fully v2) the dual-logic of being able to process
> messages either from a short ID or a full command name.
One thing I was trying to avoid is some sort of central planing.
Strings as message command identifier do usually bring some sort of collision resistance when competitive implementations work on different features.
An example are the service bits where we AFAIK had an (almost) collision.
This is the main reason why I think we should avoid setting the short IDs mandatory (naturally by not giving all commands a short ID).
Short IDs do probably make most sense for messages with high frequency.
By only giving frequent messages a short ID, we may avoid ID collisions in future.
Short IDs can be altered with the message protocol version (not the transport protocol, the message protocol like 70015, etc.) and new/different negation should be straight forward.
I just ran some random stats (non representative) and inv makes about 66% of all messages (pruned peer, not helping IBDing others) followed by tx and getdata.
Those three probably deserve a short ID.
I have no big objection against adding short IDs for other commands as long as we don’t make short IDs mandatory.
Though, there are little benefits for commands like VERSION, FILTERxx, SENDHEADERS, etc.,... and, we only(?!) have 244 short IDs.
/jonas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
2019-03-24 13:29 99% ` David A. Harding
@ 2019-03-24 15:38 99% ` David A. Harding
2019-03-24 19:35 99% ` Jonas Schnelli
1 sibling, 0 replies; 123+ results
From: David A. Harding @ 2019-03-24 15:38 UTC (permalink / raw)
To: Bitcoin Protocol Discussion; +Cc: Gregory Maxwell
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
On Sun, Mar 24, 2019 at 09:29:10AM -0400, David A. Harding via bitcoin-dev wrote:
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
Gregory Maxwell discussed this with me on IRC[1]. My summary of our
conversation:
Although the BIP can easily allocate short-ids to all existing messages,
anyone who wants to add an additional protocol message later will need
to coordinate their number allocation with all other developers working
on protocol extensions. This includes experimental and private
extensions. At best this would be annoying, and at worst it'd be
another set of bikeshed problems we'd waste time arguing about.
Allowing nodes to continue using arbitrary command names eliminates this
coordination problem. Yet we can also gain the advantage of saving
bandwidth by allowing mapping (with optional negotiation) of short-ids.
Now that I understand the motivation, this part of the proposal makes
sense to me.
-Dave
[1] http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-24.html#l-159
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
2019-03-22 21:04 99% [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) Jonas Schnelli
@ 2019-03-24 13:29 99% ` David A. Harding
2019-03-24 15:38 99% ` David A. Harding
2019-03-24 19:35 99% ` Jonas Schnelli
2019-03-25 6:32 99% ` Eric Voskuil
1 sibling, 2 replies; 123+ results
From: David A. Harding @ 2019-03-24 13:29 UTC (permalink / raw)
To: Jonas Schnelli, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wrote:
> === v2 Messages Structure ===
>
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte short command ID)
> [...]
> The command field MUST start with a byte that defines the length of the ASCII
> command string up to 12 chars (1 to 12) or a short command ID (see below).
> [...]
> ==== Short Command ID ====
>
> To save valuable bandwidth, the v2 message format supports message command
> short IDs for message types with high frequency. The ID/string mapping is a
> peer to peer arrangement and MAY be negotiated between the initiating and
> responding peer.
Why is this optional and only specified here for some message types
rather than being required by v2 and specified for all message types?
There's only 26 different types at present[1], so it seems better to
simply make this a one-byte fixed-length field than it is to deal with
variable size, mapping negotiation, per-peer mapping in general, and
(once the network is fully v2) the dual-logic of being able to process
messages either from a short ID or a full command name.
Thanks,
-Dave
[1] src/protocol.cpp:
const static std::string allNetMessageTypes[] = {
NetMsgType::VERSION,
NetMsgType::VERACK,
NetMsgType::ADDR,
NetMsgType::INV,
NetMsgType::GETDATA,
NetMsgType::MERKLEBLOCK,
NetMsgType::GETBLOCKS,
NetMsgType::GETHEADERS,
NetMsgType::TX,
NetMsgType::HEADERS,
NetMsgType::BLOCK,
NetMsgType::GETADDR,
NetMsgType::MEMPOOL,
NetMsgType::PING,
NetMsgType::PONG,
NetMsgType::NOTFOUND,
NetMsgType::FILTERLOAD,
NetMsgType::FILTERADD,
NetMsgType::FILTERCLEAR,
NetMsgType::REJECT,
NetMsgType::SENDHEADERS,
NetMsgType::FEEFILTER,
NetMsgType::SENDCMPCT,
NetMsgType::CMPCTBLOCK,
NetMsgType::GETBLOCKTXN,
NetMsgType::BLOCKTXN,
};
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151)
@ 2019-03-22 21:04 99% Jonas Schnelli
2019-03-24 13:29 99% ` David A. Harding
2019-03-25 6:32 99% ` Eric Voskuil
0 siblings, 2 replies; 123+ results
From: Jonas Schnelli @ 2019-03-22 21:04 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 25232 bytes --]
Hi
The overhauled version of the former BIP151 has fundamental differences and deserves (requires?) a new BIP.
Calling it „v2 peer-to-peer message transport protocol“ is more accurate since it is no longer only about encryption.
The formatted draft proposal can be found here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
Significant changes compared to the current available BIP151
* A optimised AEAD construct is now proposed (ChaCha20Poly1305@Bitcoin), reducing the required ChaCha20 rounds (compared to the openSSH version).
* introduce NODE_P2P_V2
* 32bytes-per-side „pseudorandom" key exchange
* the multi message envelope has been removed
* the length of a packet uses now a 3-byte integer with 23 available bits
* introduction of short-command-ID (ex.: uint8_t 13 == INV, etc.) which result in
some v2 messages require less bandwidth then v1
* the key derivation and what communication direction uses what key is now more
specific
First benchmarks of the used primitives
https://github.com/bitcoin/bitcoin/pull/15519#issuecomment-469705289 <https://github.com/bitcoin/bitcoin/pull/15519#issuecomment-469705289>
Benchmark of the AEAD compared to the HASH (double SHA256)
(Indicates that v2 messages may be more performant):
https://github.com/bitcoin/bitcoin/pull/15649#issuecomment-475782376 <https://github.com/bitcoin/bitcoin/pull/15649#issuecomment-475782376>
Proposal:
<pre>
BIP: ???
Layer: Peer Services
Title: Version 2 Peer-to-Peer Message Transport Protocol
Author: Jonas Schnelli <dev@jonasschnelli•ch>
Status: Draft
Type: Standards Track
Created: 2019-03-08
License: PD
</pre>
== Abstract ==
This BIP describes a new Bitcoin peer to peer transport protocol with
opportunistic encryption.
== Motivation ==
The current peer-to-peer protocol is partially inefficient and in plaintext.
With the current unencrypted message transport, BGP hijack, block delay attacks
and message tempering are inexpensive and can be executed in a covert way
(undetectable MITM)<ref>[https://btc-hijack.ethz.ch/files/btc_hijack.pdf
Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - M. Apostolaki, A.
Zohar, L.Vanbever]</ref>.
Adding opportunistic encryption introduces a high risk for attackers of being
detected. Peer operators can compare encryption session IDs or use other form
of authentication schemes <ref
name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
BIP150]</ref> to identify an attack.
Each current version 1 Bitcoin peer-to-peer message uses a double-SHA256
checksum truncated to 4 bytes. Roughly the same amount of computation power
would be required for encrypting and authenticating a peer-to-peer message with
ChaCha20 & Poly1305.
Additionally, this BIP describes a way how data manipulation (blocking or
tempering commands by an intercepting TCP/IP node) would be identifiable by the
communicating peers.
Encrypting traffic between peers is already possible with VPN, tor, stunnel,
curveCP or any other encryption mechanism on a deeper OSI level, however, most
of those solutions require significant knowhow in how to setup such a secure
channel and are therefore not widely deployed.
== Specification ==
<blockquote>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119<ref>[https://tools.ietf.org/html/rfc2119
RFC 2119]</ref>.
</blockquote>
A peer that supports the message transport protocol as defined in this proposal
MUST accept encryption requests from all peers.
Both communication direction share the same shared-secret but have different
symmetric cipher keys.
The encryption handshake MUST happen before sending any other messages to the
responding peer.
If the responding peer closes the connection after sending the handshake
request, the initiating peer MAY try to connect again with the v1 peer-to-peer
transport protocol. Such reconnects allow an attacker to "downgrade" the
encryption to plaintext communication and thus, accepting v1 connections MUST
not be done when the Bitcoin peer-to-peer network uses almost only v2
communication.
=== NODE_P2P_V2 ===
Peers supporting the transport protocol after this proposal MUST signal
<code>NODE_P2P_V2</code>
<pre>
NODE_P2P_V2 = (1 << 11)
</pre>
A peer usually learns an address along with the expected service flags which
MAY be used to filter possible outbound peers.
A peer signaling <code>NODE_P2P_V2</code> MUST accept encrypted communication
specified in this proposal.
Peers MAY only make outbound connections to peers supporting
<code>NODE_P2P_V2</code>.
=== Handshake ===
<pre>
----------------------------------------------------------------------------------------
| Initiator Responder |
| |
| x, X := SECP256k1_KEYGEN() |
| CLIENT_HDATA := X |
| |
| --- CLIENT_HDATA ---> |
| |
| y, Y := SECP256k1_KEYGEN() |
| ECDH_KEY := SECP256k1_ECDH(X,y) |
| SERVER_HDATA := Y |
| |
| <-- SERVER_HDATA ---- |
| |
| ECDH_KEY := SECP256k1_ECDH(x,Y) |
----------------------------------------------------------------------------------------
</pre>
To request encrypted communication (only possible if yet no other messages have
been sent or received), the initiating peer generates an EC secp256k1 ephemeral
key and sends the corresponding 32-byte public key to the responding peer and
waits for the remote 32-byte public key from the counterparty.
ODD secp256k1 public keys MUST be used (public keys starting with 0x02). If the
public key from the generated ephemeral key is an EVEN public key (starting
with 0x03), negating the key and recalculating its public key SHOULD be done.
Only using ODD public makes it more complex to identify the handshake based on
analyzing the traffic.
The handshake request and response message are raw 32byte payloads containing
no header, length or checksum (the pure 32byte payload) and MUST be sent before
anything else.
Public keys starting with the 4-byte network magic are forbidden and MUST lead
to locally re-generate an ephemeral-key.
Pseudocode for the ephemeral-key generation
<pre>
do {
ecdh_key.MakeNewKey();
if (ecdh_key.GetPubKey()[0] == 3) {
ecdh_key.Negate();
}
} while (m_ecdh_key.GetPubKey()[0..3] == NETWORK_MAGIC);
</pre>
Once a peer has received the public key from its counterparty, the shared
secret MUST be calculated by using secp256k1 ECDH.
Private keys will never be transmitted. The shared secret can only be
calculated if an attacker knows at least one private key and the counterparties
public key. This key-exchange is based on the discrete log problem and thus not
sufficiently strong against known forms of possible quantum computer
algorithms. Adding an additional quantum resistant key exchange like NewHope is
possible but out of scope for this proposal.
After a successful handshake, the messages format MUST use the "v2 messages
structure". Non-encrypted v1 messages from the initiating peer MUST lead to an
immediate connection termination.
After a successful handshake, both peers MUST cleanse the ephemeral-session-key
from memory and/or persistence storage.
A peer not supporting this proposal will not perform the described handshake
and thus send a v1 version message.
Peers supporting this BIP MAY optionally allow unencrypted v1 communication by
detecting a v1 version message by the initial 11-byte sequence of <code>4byte
net magic || "version"</code>.
=== Symmetric Encryption Cipher Keys ===
Once the ECDH secret (<code>ECDH_KEY</code>) is calculated on each side, the
symmetric encryption cipher keys MUST be derived with HKDF
<ref>[https://tools.ietf.org/html/rfc5869 HKDF (RFC 5869)]</ref> after the
following specification:
1. HKDF extraction
<code>PRK = HKDF_EXTRACT(hash=SHA256, salt="BitcoinSharedSecret||INITIATOR_32BYTES_PUBKEY||RESPONDER_32BYTES_PUBKEY", ikm=ECDH_KEY)</code>.
2. Derive Key_1_A (K_1 communication direction A)
<code>K1A = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_1_A", L=32)</code>
2. Derive Key_2_A (K_2 communication direction A)
<code>K1B = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_2_A", L=32)</code>
3. Derive Key_1_B (K_1 communication direction B)
<code>K2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_1_B", L=32)</code>
3. Derive Key_2_B (K_2 communication direction B)
<code>K2 = HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinK_2_B", L=32)</code>
=== Session ID ===
Both parties MUST also calculate the 256bit session-id using <code>SID =
HKDF_EXPAND(prk=PRK, hash=SHA256, info="BitcoinSessionID", L=32)</code>. The
session-id can be used for authenticating the encryption-session (identity
check).
The session-id MUST be presented to the user on request.
=== ChaCha20-Poly1305@Bitcoin Cipher Suite ===
==== Background ====
ChaCha20 is a stream cipher designed by Daniel Bernstein and described in
<ref>[http://cr.yp.to/chacha/chacha-20080128.pdf ChaCha20]</ref>. It operates
by permuting 128 fixed bits, 128 or 256 bits of key, a 64 bit nonce and a 64
bit counter into 64 bytes of output. This output is used as a keystream, with
any unused bytes simply discarded.
Poly1305 <ref>[http://cr.yp.to/mac/poly1305-20050329.pdf Poly1305]</ref>, also
by Daniel Bernstein, is a one-time Carter-Wegman MAC that computes a 128 bit
integrity tag given a message and a single-use 256 bit secret key.
The chacha20-poly1305@bitcoin combines these two primitives into an
authenticated encryption mode. The construction used is based on that proposed
for TLS by Adam Langley in
<ref>[http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03 "ChaCha20
and Poly1305 based Cipher Suites for TLS", Adam Langley]</ref>, but differs in
the layout of data passed to the MAC and in the addition of encryption of the
packet lengths.
==== Detailed Construction ====
The chacha20-poly1305@bitcoin cipher requires two 256 bits of key material as
output from the key exchange. Each key (K_1 and K_2) are used by two separate
instances of chacha20.
The instance keyed by K_1 is a stream cipher that is used only to encrypt the 3
byte packet length field and has its own sequence number. The second instance,
keyed by K_2, is used in conjunction with poly1305 to build an AEAD
(Authenticated Encryption with Associated Data) that is used to encrypt and
authenticate the entire packet.
Two separate cipher instances are used here so as to keep the packet lengths
confidential but not create an oracle for the packet payload cipher by
decrypting and using the packet length prior to checking the MAC. By using an
independently-keyed cipher instance to encrypt the length, an active attacker
seeking to exploit the packet input handling as a decryption oracle can learn
nothing about the payload contents or its MAC (assuming key derivation,
ChaCha20 and Poly1305 are secure).
The AEAD is constructed as follows: for each packet, generate a Poly1305 key by
taking the first 256 bits of ChaCha20 stream output generated using K_2, an IV
consisting of the packet sequence number encoded as an LE uint64 and a ChaCha20
block counter of zero. The K_2 ChaCha20 block counter is then set to the
little-endian encoding of 1 (i.e. {1, 0, 0, 0, 0, 0, 0, 0}) and this instance
is used for encryption of the packet payload.
==== Packet Handling ====
When receiving a packet, the length must be decrypted first. When 3 bytes of
ciphertext length have been received, they may be decrypted.
A ChaCha20 round always calculates 64bytes which is sufficient to crypt 21
times a 3 bytes length field (21*3 = 63). The length field sequence number can
thus be used 21 times (keystream caching).
The length field must be enc-/decrypted with the ChaCha20 keystream keyed with
K_1 defined by block counter 0, the length field sequence number in little
endian and a keystream position from 0 to 60.
Pseudo code example:
<pre>
// init
sequence_nr_payload = 0; //payload sequence number
sequence_nr_length_field = 0; //length field sequence number (will be reused)
aad_length_field_pos = 0; //position in the length field cipher instance keystream chunk
...
// actual encryption
if cache_length_field_sequence_number != sequence_nr_length_field {
cache_keystream_64_bytes = ChaCha20(key=K_1, iv=little_endian(sequence_nr_length_field), counter=0);
cache_length_field_sequence_number = sequence_nr_length_field
}
packet_length = XOR_TO_LE(cache_length_field_sequence_number[aad_length_field_pos - aad_length_field_pos+3], ciphertext[0-3])
sequence_nr_payload++;
aad_length_field_pos += 3; //skip 3 bytes in keystream
if (aad_length_field_pos + 3 > 64) { //if we are outside of the 64byte keystream...
aad_length_field_pos = 0; // reset at position 0
sequence_nr_length_field++; // increase length field sequence number
}
</pre>
Once the entire packet has been received, the MAC MUST be checked before
decryption. A per-packet Poly1305 key is generated as described above and the
MAC tag calculated using Poly1305 with this key over the ciphertext of the
packet length and the payload together. The calculated MAC is then compared in
constant time with the one appended to the packet and the packet decrypted
using ChaCha20 as described above (with K_2, the packet sequence number as
nonce and a starting block counter of 1).
Detection of an invalid MAC MUST lead to immediate connection termination.
To send a packet, first encode the 3 byte length and encrypt it using K_1 as
described above. Encrypt the packet payload (using K_2) and append it to the
encrypted length. Finally, calculate a MAC tag and append it.
The initiating peer MUST use <code>K_1_A, K_2_A</code> to encrypt messages on
the send channel, <code>K_1_B, K_2_B</code> MUST be used to decrypt messages on
the receive channel.
The responding peer MUST use <code>K_1_A, K_2_A</code> to decrypt messages on
the receive channel, <code>K_1_B, K_2_B</code> MUST be used to encrypt messages
on the send channel.
Optimized implementations of ChaCha20-Poly1305@bitcoin are relatively fast in
general, therefore it is very likely that encrypted messages require not more
CPU cycles per bytes then the current unencrypted p2p message format
(ChaCha20/Poly1305 versus double SHA256).
The initial packet sequence numbers are 0.
K_2 ChaCha20 cipher instance (payload) must never reuse a {key, nonce} for
encryption nor may it be used to encrypt more than 2^70 bytes under the same
{key, nonce}.
K_1 ChaCha20 cipher instance (length field/AAD) must never reuse a {key, nonce,
position-in-keystream} for encryption nor may it be used to encrypt more than
2^70 bytes under the same {key, nonce}.
We use message sequence numbers for both communication directions.
<pre>
------------------------------------------------------------------------------------------
| Initiator Responder |
| |
| AEAD() = ChaCha20Poly1305Bitcoin() |
| MSG_A_CIPH = AEAD(k=K_1_A, K_2_A, payload_nonce=0, aad_nonce=0, aad_pos=0, msg) |
| |
| --- MSG_CIPH ---> |
| |
| msg := AEAD(k=K_1_A,K_2_A, n=0, ..., MSG_A_CIPH) |
| |
------------------------------------------------------------------------------------------
</pre>
==== Test Vectors ====
<pre>
message 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k1 (DATA) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k2 (AAD) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AAD keystream
76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28 bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7 da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37 6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86
ciphertext
76 b8 e0 9f 07 e7 be 55 51 38 7a 98 ba 97 7c 73 2d 08 0d cb 0f 29 a0 48 e3 65 69 12 c6 53 3e 32
MAC
d2 fc 11 82 9c 1b 6c 1d f1 f5 51 cd 61 31 ff 08
</pre>
<pre>
message 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k1 (DATA) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
k2 (AAD) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AAD keystream
76 b8 e0 ad a0 f1 3d 90 40 5d 6a e5 53 86 bd 28 bd d2 19 b8 a0 8d ed 1a a8 36 ef cc 8b 77 0d c7 da 41 59 7c 51 57 48 8d 77 24 e0 3f b8 d8 4a 37 6a 43 b8 f4 15 18 a1 1c c3 87 b6 69 b2 ee 65 86
ciphertext
77 b8 e0 9f 07 e7 be 55 51 38 7a 98 ba 97 7c 73 2d 08 0d cb 0f 29 a0 48 e3 65 69 12 c6 53 3e 32
MAC
ba f0 c8 5b 6d ff 86 02 b0 6c f5 2a 6a ef c6 2e
</pre>
<pre>
message
ff 00 00 f1 95 e6 69 82 10 5f fb 64 0b b7 75 7f 57 9d a3 16 02 fc 93 ec 01 ac 56 f8 5a c3 c1 34 a4 54 7b 73 3b 46 41 30 42 c9 44 00 49 17 69 05 d3 be 59 ea 1c 53 f1 59 16 15 5c 2b e8 24 1a 38 00 8b 9a 26 bc 35 94 1e 24 44 17 7c 8a de 66 89 de 95 26 49 86 d9 58 89 fb 60 e8 46 29 c9 bd 9a 5a cb 1c c1 18 be 56 3e b9 b3 a4 a4 72 f8 2e 09 a7 e7 78 49 2b 56 2e f7 13 0e 88 df e0 31 c7 9d b9 d4 f7 c7 a8 99 15 1b 9a 47 50 32 b6 3f c3 85 24 5f e0 54 e3 dd 5a 97 a5 f5 76 fe 06 40 25 d3 ce 04 2c 56 6a b2 c5 07 b1 38 db 85 3e 3d 69 59 66 09 96 54 6c c9 c4 a6 ea fd c7 77 c0 40 d7 0e af 46 f7 6d ad 39 79 e5 c5 36 0c 33 17 16 6a 1c 89 4c 94 a3 71 87 6a 94 df 76 28 fe 4e aa f2 cc b2 7d 5a aa e0 ad 7a d0 f9 d4 b6 ad 3b 54 09 87 46 d4 52 4d 38 40 7a 6d eb 3a b7 8f ab 78 c9
k1 (DATA) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
k2 (AAD) ff 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
AAD keystream
c6 40 c1 71 1e 3e e9 04 ac 35 c5 7a b9 79 1c 8a 1c 40 86 03 a9 0b 77 a8 3b 54 f6 c8 44 cb 4b 06 d9 4e 7f c6 c8 00 e1 65 ac d6 61 47 e8 0e c4 5a 56 7f 6c e6 6d 05 ec 0c ae 67 9d ce eb 89 00 17
ciphertext
39 40 c1 e9 2d a4 58 2f f6 f9 2a 77 6a eb 14 d0 14 d3 84 ee b3 0f 66 0d ac f7 0a 14 a2 3f d3 1e 91 21 27 01 33 4e 2c e1 ac f5 19 9d c8 4f 4d 61 dd be 65 71 bc a5 af 87 4b 4c 92 26 c2 6e 65 09 95 d1 57 64 4e 18 48 b9 6e d6 c2 10 2d 54 89 a0 50 e7 1d 29 a5 a6 6e ce 11 de 5f b5 c9 55 8d 54 da 28 fe 45 b0 bc 4d b4 e5 b8 80 30 bf c4 a3 52 b4 b7 06 8e cc f6 56 ba e7 ad 6a 35 61 53 15 fc 7c 49 d4 20 03 88 d5 ec a6 7c 2e 82 2e 06 93 36 c6 9b 40 db 67 e0 f3 c8 12 09 c5 0f 32 16 a4 b8 9f b3 ae 1b 98 4b 78 51 a2 ec 6f 68 ab 12 b1 01 ab 12 0e 1e a7 31 3b b9 3b 5a 0f 71 18 5c 7f ea 01 7d db 92 76 98 61 c2 9d ba 4f bc 43 22 80 d5 df f2 1b 36 d1 c4 c7 90 12 8b 22 69 99 50 bb 18 bf 74 c4 48 cd fe 54 7d 8e d4 f6 57 d8 00 5f dc 0c d7 a0 50 c2 d4 60 50 a4 4c 43 76 35 58 58
MAC
98 1f be 8b 18 42 88 27 6e 7a 93 ea bc 89 9c 4a
</pre>
=== v2 Messages Structure ===
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 3 || length & flag || 23 + 1 bits || Encrypted length of ciphertext payload (not counting the MAC tag) in number of bytes (only 2^23 is usable, most significant bit is the rekey-flag)
|-
| 1-13 || encrypted command || variable || ASCII command (or one byte short command ID)
|-
| ? || encrypted payload || ? || The actual data
|-
| 16 || MAC tag || ? || 128bit MAC-tag
|}
Encrypted messages do not have the 4byte network magic.
The maximum message size is 2^23 (8’388’608) bytes. Future communication MAY
exceed this limit and thus MUST be split into different messages.
Decrypting and processing the message before the authentication succeeds (MAC
verified) MUST not be done.
The 4byte sha256 checksum is no longer required because the AEAD (MAC).
Both peers MUST keep track of the message sequence number (uint32) of sent and
received messages for building a 64-bit symmetric cipher IV.
The command field MUST start with a byte that defines the length of the ASCII
command string up to 12 chars (1 to 12) or a short command ID (see below).
==== Short Command ID ====
To save valuable bandwidth, the v2 message format supports message command
short IDs for message types with high frequency. The ID/string mapping is a
peer to peer arrangement and MAY be negotiated between the initiating and
responding peer. A peer conforming to this proposal MUST support short IDs
based on the table below and SHOULD use short command IDs for outgoing messages.
{|class="wikitable"
! Number !! Command
|-
| 13 || INV
|-
| 14 || HEADERS
|-
| 15 || PING
|-
| 16 || PONG
|-
|}
==== Length comparisons between v1 and v2 messages ====
<pre>
v1 in: 4(Magic)+12(Command)+4(MessageSize)+4(Checksum)+36(Payload) == 60
v2 inv: 3(MessageSize&Flag)+1(Command)+36(Payload)+16(MAC) == 56
(93.33%)
</pre>
<pre>
v1 ping: 4(Magic)+12(Command)+4(MessageSize)+4(Checksum)+8(Payload) == 32
v2 pong: 3(MessageSize&Flag)+1(Command)+8(Payload)+16(MAC) == 28
(87.5%)
</pre>
<pre>
v1 block: 4(Magic)+12(Command)+4(MessageSize)+4(Checksum)+1’048’576(Payload) = 1’048’600
v2 block: 3(MessageSize&Flag)+6(CommandStr)+8(Payload)+16(MAC) == 28 = 1’048’601
(100.000095%)
</pre>
=== Re-Keying ===
Re-keying can be signaled by setting the most significant bit in the length
field before encryption. A peer signaling a rekey MUST use the next key for
encryption messages AFTER the message where the signaling has been done.
A peer identifying a rekey by checking the most significant bit in the envelope
length must use the next key for decrypt messages AFTER the message where the
signaling has been detected.
The next symmetric cipher key MUST be calculated by <code>SHA256(SHA256(session
ID || old_symmetric_cipher_key))</code> and the packet sequence number of the
according encryption direction must be set to 0.
Re-Keying interval is a peer policy with a minimum timespan of 10 seconds.
The Re-Keying must be done after every 1GB of data sent (recommended by RFC4253
SSH Transport) or if the last rekey was more than an hour ago.
Peers calculate the counterparty limits and MUST disconnect immediately if a
violation of the limits has been detected.
=== Risks ===
The encryption does not include an authentication scheme. This BIP does not
cover a proposal to avoid MITM attacks during the encryption initialization.
However, peers MUST show the session-id to the user on request which allows to
identify a MITM by a manual verification on a secure channel.
Optional authentication schemes may be covered by other proposals <ref
name="bip150">[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki
BIP150]</ref>.
An attacker could delay or halt v2 protocol enforcement by providing a
reasonable amount of peers not supporting the v2 protocol.
== Compatibility ==
This proposal is backward compatible (as long as not enforced). Non-supporting
peers can still use unencrypted communications.
== Reference implementation ==
* Complete Bitcoin Core implementation: https://github.com/bitcoin/bitcoin/pull/14032
* Reference implementation of the AEAD in C: https://github.com/jonasschnelli/chacha20poly1305
== References ==
<references/>
== Acknowledgements ==
* Pieter Wuille and Gregory Maxwell for most of the ideas in this BIP.
* Tim Ruffing for the review and the hint for the enhancement of the symmetric
key derivation
== Copyright ==
This work is placed in the public domain.
[-- Attachment #1.2: Type: text/html, Size: 42809 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP proposal - Hashed Time-Locked Collateral Contract transactions
@ 2019-03-22 17:29 99% Matthew Black
0 siblings, 0 replies; 123+ results
From: Matthew Black @ 2019-03-22 17:29 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
I have written up a proposed BIP. It has to do a new cross-chain debt
protocol. It is here:
https://github.com/AtomicLoans/BIP/blob/master/README.md
This BIP was written up for the Atomic Loans protocol specified here:
https://arxiv.org/pdf/1901.05117.pdf
Any feedback would be appreciated. Please let me know what the steps are
with regards to getting a BIP number assigned or any other process steps
required.
Regards,
Matthew
[-- Attachment #2: Type: text/html, Size: 762 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
2019-03-22 10:23 99% ` Kenshiro []
2019-03-22 11:15 99% ` Kenshiro []
@ 2019-03-22 16:05 99% ` ZmnSCPxj
1 sibling, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-03-22 16:05 UTC (permalink / raw)
To: Kenshiro \[\], Bitcoin Protocol Discussion
Good morning,
> >There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
>
> For users that really want privacy it should not be a problem. When a wallet receive a high amount of btc (+100$ or another amount defined by the user) it can automatically make a transaction to itself splitting the amount in several addresses. The amounts that are already small don't need to be splitted again. Small amount addresses + Payjoin could give real privacy to bitcoin users. Users that don't want privacy could disable the "Private" mode in the wallet and disable the auto-splitting feature.
>
> i.e.: you receive 1000$ in btc and the wallet make an automatic transaction to itself to 10 addresses, 100$ each.
>
It seems to me, to interact somewhat with ZeroLink.
Under ZeroLink, post-mix UTXOs must not be combined.
(Basic Post-Mix Wallet Requirement: "Post-mix wallet MUST prevent joining inputs together.")
The upshot of this, for practical use, is that as payments are done by the user, available coins become smaller and smaller.
And the maximum amount the user can pay with, is limited by the largest post-mix coin they have.
If a ZeroLink post-mix wallet were to split its UTXOs as soon as it got them from the mix, then it would immediately find itself limiting the maximum amount the user could pay.
I suppose if the ZeroLink post-mix wallet had multiple post-mix coins, it could split one of them for the same purpose as above.
Another thought, is if a ZeroLink post-mix wallet could support a Payjoin, as either receiver or sender.
Naively, it seems to me to improve privacy to do so, as long as the ZeroLink post-mix wallet only provides a single UTXO to the Payjoin, whether as receiver or sender.
For a ZeroLink post-mix wallet to a ZeroLink post-mix wallet Payjoin, this would typically result in a two-input, two-output transaction, with both participants having one input and one output each in the transaction, but difficult (?) for third parties to determine which input/output belongs to which.
Now, if we suppose that both ZeroLink and Payjoin become commonly used, then it is likely that two users using the same Chaumian CoinJoin mix transaction will find that one needs to pay the other.
Thus hopefully it may become common for a Chaumian CoinJoin mix transaction to have outputs that (directly or indirectly) merge into Payjoin two-input two-output transactions.
This can then be used to allow a ZeroLink post-mix wallet some limited amount of merging its post-mix UTXOs.
For instance, if a ZeroLink post-mix wallet has a 0.25BTC and a 0.15BTC coin, and needs to pay 0.3 BTC, it may very well simulate a Payjoin to itself, and create a transaction (0.25, 0.15) -> (0.35, 0.05).
Then it can use the 0.35BTC output to pay the 0.3 BTC.
Possibly, anyway.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
2019-03-22 10:23 99% ` Kenshiro []
@ 2019-03-22 11:15 99% ` Kenshiro []
2019-03-22 16:05 99% ` ZmnSCPxj
1 sibling, 0 replies; 123+ results
From: Kenshiro [] @ 2019-03-22 11:15 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, rhavar
[-- Attachment #1: Type: text/plain, Size: 4287 bytes --]
They Payjoin protocol could include the possibility of receive "safe" amounts (i.e.: 0.025 btc) to several addresses so every user using Payjoin already have a splitted balance. Only people receiving a regular public transaction should need the extra splitting transaction.
Regards
________________________________
From: Kenshiro []
Sent: Friday, March 22, 2019 11:23
To: Bitcoin Protocol Discussion; rhavar@protonmail•com
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
>I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
Yeah, it affects normal transactions too. But I'm focused in Payjoin because it should allow private transactions. The problem I see is that Payjoin shouldn't allow that the sender or the receiver of the transaction can get information about the bitcoin balance of each other. A person could have his savings in btc in a single address, use Payjoin to send/receive a payment thinking it's private and leaking to the receptor he has a high amount of btc. But an automatic splitting to itself in the background could solve the problem (maybe 100$ amounts) or so.
>There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
For users that really want privacy it should not be a problem. When a wallet receive a high amount of btc (+100$ or another amount defined by the user) it can automatically make a transaction to itself splitting the amount in several addresses. The amounts that are already small don't need to be splitted again. Small amount addresses + Payjoin could give real privacy to bitcoin users. Users that don't want privacy could disable the "Private" mode in the wallet and disable the auto-splitting feature.
i.e.: you receive 1000$ in btc and the wallet make an automatic transaction to itself to 10 addresses, 100$ each.
I would prefer wait some time and have privacy than the opposite.
Regards
________________________________
From: rhavar@protonmail•com <rhavar@protonmail•com>
Sent: Thursday, March 21, 2019 17:52
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
Hi,
I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:
- If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.
What do you think?
Regards,
[-- Attachment #2: Type: text/html, Size: 7465 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
2019-03-21 16:52 99% ` rhavar
@ 2019-03-22 10:23 99% ` Kenshiro []
2019-03-22 11:15 99% ` Kenshiro []
2019-03-22 16:05 99% ` ZmnSCPxj
0 siblings, 2 replies; 123+ results
From: Kenshiro [] @ 2019-03-22 10:23 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, rhavar
[-- Attachment #1: Type: text/plain, Size: 3771 bytes --]
>I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
Yeah, it affects normal transactions too. But I'm focused in Payjoin because it should allow private transactions. The problem I see is that Payjoin shouldn't allow that the sender or the receiver of the transaction can get information about the bitcoin balance of each other. A person could have his savings in btc in a single address, use Payjoin to send/receive a payment thinking it's private and leaking to the receptor he has a high amount of btc. But an automatic splitting to itself in the background could solve the problem (maybe 100$ amounts) or so.
>There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
For users that really want privacy it should not be a problem. When a wallet receive a high amount of btc (+100$ or another amount defined by the user) it can automatically make a transaction to itself splitting the amount in several addresses. The amounts that are already small don't need to be splitted again. Small amount addresses + Payjoin could give real privacy to bitcoin users. Users that don't want privacy could disable the "Private" mode in the wallet and disable the auto-splitting feature.
i.e.: you receive 1000$ in btc and the wallet make an automatic transaction to itself to 10 addresses, 100$ each.
I would prefer wait some time and have privacy than the opposite.
Regards
________________________________
From: rhavar@protonmail•com <rhavar@protonmail•com>
Sent: Thursday, March 21, 2019 17:52
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
Hi,
I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:
- If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.
What do you think?
Regards,
[-- Attachment #2: Type: text/html, Size: 7019 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-22 2:58 99% ` Anthony Towns
@ 2019-03-22 7:46 99% ` ZmnSCPxj
0 siblings, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-03-22 7:46 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev, lightning-dev
Good morning aj,
I understand.
Looks like that makes sense.
It seems possible to use this, then, together with watchtowers.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 22, 2019 10:58 AM, Anthony Towns <aj@erisian•com.au> wrote:
> On Fri, Mar 22, 2019 at 01:59:14AM +0000, ZmnSCPxj wrote:
>
> > > If codeseparator is too scary, you could probably also just always
> > > require the locktime (ie for settlmenet txs as well as update txs), ie:
> > > OP_CHECKLOCKTIMEVERIFY OP_DROP
> > > <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
> > > and have update txs set their timelock; and settlement txs set a absolute
> > > timelock, relative timelock via sequence, and commit to the script code.
> >
> > I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
>
> You can enforce the relative timelock in the settlement branch simply
> by refusing to sign a settlement tx that doesn't have the timelock set;
> the OP_CSV is redundant.
>
> > Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
> > If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
>
> settlement-1 was signed by you, and when you signed it you ensured that
> nsequence was set as per BIP-68, and NOINPUT sigs commit to nsequence,
> so if anyone changed that after the fact the sig isn't valid. Because
> BIP-68 is enforced by consensus, update-1 isn't immediately spendable
> by settlement-1.
>
> Cheers,
> aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-22 1:59 99% ` ZmnSCPxj
2019-03-22 2:58 99% ` Anthony Towns
@ 2019-03-22 4:23 99% ` Johnson Lau
1 sibling, 0 replies; 123+ results
From: Johnson Lau @ 2019-03-22 4:23 UTC (permalink / raw)
To: ZmnSCPxj, bitcoin-dev; +Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 3783 bytes --]
> On 22 Mar 2019, at 9:59 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Good morning aj,
>>
>> If you are committing to the script code, though, then each settlement
>> sig is already only usable with the corresponding update tx, so you
>> don't need to roll the keys. But you do need to make it so that the
>> update sig requires the CLTV; one way to do that is using codeseparator
>> to distinguish between the two cases.
>>
>>> Also, I cannot understand `OP_CODESEPARATOR`, please no.
>>
>> If codeseparator is too scary, you could probably also just always
>> require the locktime (ie for settlmenet txs as well as update txs), ie:
>>
>> OP_CHECKLOCKTIMEVERIFY OP_DROP
>> <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
>>
>> and have update txs set their timelock; and settlement txs set a absolute
>> timelock, relative timelock via sequence, and commit to the script code.
>>
>> (Note that both those approaches (with and without codesep) assume there's
>> some flag that allows you to commit to the scriptcode even though you're
>> not committing to your input tx (and possibly not committing to the
>> scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
>> B_s_i key rolling is necessary)
>
> I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
>
> Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
> If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
> But settlement-1 cannot be spent by update-2 and thus the invalidation of older state fails.
>
> The `OP_CSV` in the settlement branch of the update transaction outputs exists to allow later update transactions have higher priority over settlement transactions.
>
> To ensure that a settlement signature can only take the settlement branch, we need a distinct public key for the branch, so at least `A_s` and `B_s` without rolling them for each `i`, if we use `nLockTime` on the settlement transactions and enforce it with `OP_CHECKLOCKTIMEVERIFY`.
> It might be possible to do this with `OP_CODESEPARATOR`, but we do need the `OP_CSV` in the settlement branch.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
OP_CSV (BIP112) is not needed. Only BIP68 relative-time is needed.
With this script:
<t> OP_CHECKLOCKTIMEVERIFY OP_DROP <muSig(A,B)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
For update purpose, A and B will co-sign the muSig with nLockTime = t, not committing to the scriptCode, and no BIP68 lock time
For settlement purpose, A and B will co-sign the muSig with nLockTime = t, committing to the scriptCode, and with an agreed BIP68 locktime
Without committing to the scriptCode and BIP68 lock time, the update sig could be bind to any previous update tx immediately.
OTOH, the settlement sig will only bind to a specific update tx (thought scriptCode), and only after the relative locktime is passed.
The eltoo paper is wrong about using OP_CSV. That’s a common mistake even for experienced bitcoin developer. OP_CSV is needed only if one party could single handedly decide the relative-lock-time. However, this is not the case here as it is a muSig.
(With some risks of distracting the discussion, please note that even this script: <t> OP_CHECKLOCKTIMEVERIFY OP_DROP <A> OP_CHECKSIGVERIFY <B> OP_CHECKSIG doesn’t need OP_CSV, despite not using muSig. It is because the 2 sigs must use the same relative locktime, or the tx is invalid.)
[-- Attachment #2: Type: text/html, Size: 5087 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-22 1:59 99% ` ZmnSCPxj
@ 2019-03-22 2:58 99% ` Anthony Towns
2019-03-22 7:46 99% ` ZmnSCPxj
2019-03-22 4:23 99% ` Johnson Lau
1 sibling, 1 reply; 123+ results
From: Anthony Towns @ 2019-03-22 2:58 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
On Fri, Mar 22, 2019 at 01:59:14AM +0000, ZmnSCPxj wrote:
> > If codeseparator is too scary, you could probably also just always
> > require the locktime (ie for settlmenet txs as well as update txs), ie:
> > OP_CHECKLOCKTIMEVERIFY OP_DROP
> > <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
> > and have update txs set their timelock; and settlement txs set a absolute
> > timelock, relative timelock via sequence, and commit to the script code.
>
> I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
You can enforce the relative timelock in the settlement branch simply
by refusing to sign a settlement tx that doesn't have the timelock set;
the OP_CSV is redundant.
> Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
> If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
settlement-1 was signed by you, and when you signed it you ensured that
nsequence was set as per BIP-68, and NOINPUT sigs commit to nsequence,
so if anyone changed that after the fact the sig isn't valid. Because
BIP-68 is enforced by consensus, update-1 isn't immediately spendable
by settlement-1.
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-21 11:55 99% ` Anthony Towns
@ 2019-03-22 1:59 99% ` ZmnSCPxj
2019-03-22 2:58 99% ` Anthony Towns
2019-03-22 4:23 99% ` Johnson Lau
0 siblings, 2 replies; 123+ results
From: ZmnSCPxj @ 2019-03-22 1:59 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev, lightning-dev
Good morning aj,
>
> If you are committing to the script code, though, then each settlement
> sig is already only usable with the corresponding update tx, so you
> don't need to roll the keys. But you do need to make it so that the
> update sig requires the CLTV; one way to do that is using codeseparator
> to distinguish between the two cases.
>
> > Also, I cannot understand `OP_CODESEPARATOR`, please no.
>
> If codeseparator is too scary, you could probably also just always
> require the locktime (ie for settlmenet txs as well as update txs), ie:
>
> OP_CHECKLOCKTIMEVERIFY OP_DROP
> <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
>
> and have update txs set their timelock; and settlement txs set a absolute
> timelock, relative timelock via sequence, and commit to the script code.
>
> (Note that both those approaches (with and without codesep) assume there's
> some flag that allows you to commit to the scriptcode even though you're
> not committing to your input tx (and possibly not committing to the
> scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
> B_s_i key rolling is necessary)
I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
But settlement-1 cannot be spent by update-2 and thus the invalidation of older state fails.
The `OP_CSV` in the settlement branch of the update transaction outputs exists to allow later update transactions have higher priority over settlement transactions.
To ensure that a settlement signature can only take the settlement branch, we need a distinct public key for the branch, so at least `A_s` and `B_s` without rolling them for each `i`, if we use `nLockTime` on the settlement transactions and enforce it with `OP_CHECKLOCKTIMEVERIFY`.
It might be possible to do this with `OP_CODESEPARATOR`, but we do need the `OP_CSV` in the settlement branch.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction
2019-03-18 10:55 99% [bitcoin-dev] Payjoin privacy with the receiver of the transaction Kenshiro []
@ 2019-03-21 16:52 99% ` rhavar
2019-03-22 10:23 99% ` Kenshiro []
0 siblings, 1 reply; 123+ results
From: rhavar @ 2019-03-21 16:52 UTC (permalink / raw)
To: Kenshiro \[\], Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
I'm not really sure the problem you're describing, but it sounds like something that affects normal bitcoin transactions as well.
There's certainly some interesting about the idea of "pre-fragmenting" your wallet utxo so you can make (or in payjoin: receive) payments with better privacy aspects.However, it's pretty unlikely to be practical for normal users, as it'll generally result in pretty big and cost-ineffective transactions.
In general though, there's like a 1000 different things you can do with coin selection, utxo management (and payjoin contributed input selection) but more often than not you are just making just making 1 trade off for another and good solutions will be wildly different depending on how you use your wallet.
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 3:55 AM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi,
>
> I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:
>
> - If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.
>
> What do you think?
>
> Regards,
[-- Attachment #2: Type: text/html, Size: 2480 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-21 10:05 99% ` ZmnSCPxj
@ 2019-03-21 11:55 99% ` Anthony Towns
2019-03-22 1:59 99% ` ZmnSCPxj
0 siblings, 1 reply; 123+ results
From: Anthony Towns @ 2019-03-21 11:55 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
On Thu, Mar 21, 2019 at 10:05:09AM +0000, ZmnSCPxj wrote:
> > IF OP_CODESEPARATOR <i> OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF
> > <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
> > Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV
> > and allows binding to any prior update tx -- so works for an update tx
> > spending previous update txs; while signing with codeseparatorpos=-1
> > and NOINPUT but committing to the script code and nSequence (for the
> > CSV delay) allows binding to only that update tx -- so works for the
> > settlement tx. That's two pubkeys, two sigs, and the taproot point
> > reveal.
>
> Actually, the shared keys are different in the two branches above.
Yes, if you're not committing to the script code you need the separate
keys as otherwise any settlement transaction could be used with any
update transaction.
If you are committing to the script code, though, then each settlement
sig is already only usable with the corresponding update tx, so you
don't need to roll the keys. But you do need to make it so that the
update sig requires the CLTV; one way to do that is using codeseparator
to distinguish between the two cases.
> Also, I cannot understand `OP_CODESEPARATOR`, please no.
If codeseparator is too scary, you could probably also just always
require the locktime (ie for settlmenet txs as well as update txs), ie:
OP_CHECKLOCKTIMEVERIFY OP_DROP
<muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
and have update txs set their timelock; and settlement txs set a absolute
timelock, relative timelock via sequence, and commit to the script code.
(Note that both those approaches (with and without codesep) assume there's
some flag that allows you to commit to the scriptcode even though you're
not committing to your input tx (and possibly not committing to the
scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and
B_s_i key rolling is necessary)
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-21 9:06 99% ` Anthony Towns
@ 2019-03-21 10:05 99% ` ZmnSCPxj
2019-03-21 11:55 99% ` Anthony Towns
0 siblings, 1 reply; 123+ results
From: ZmnSCPxj @ 2019-03-21 10:05 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev, lightning-dev
Good morning aj,
> > Then each update transaction pays out to:
> > OP_IF
> > <csv_delta> OP_CSV OP_DROP
> > <muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
> > OP_ELSE
> > <i> OP_CHECKLOCKTIMEVERIFY OP_DROP
> > <muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
> > OP_ENDIF
>
> Yeah.
>
> I think we could potentially make that shorter still:
>
> IF OP_CODESEPARATOR <i> OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF
> <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
>
> Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV
> and allows binding to any prior update tx -- so works for an update tx
> spending previous update txs; while signing with codeseparatorpos=-1
> and NOINPUT but committing to the script code and nSequence (for the
> CSV delay) allows binding to only that update tx -- so works for the
> settlement tx. That's two pubkeys, two sigs, and the taproot point
> reveal.
Actually, the shared keys are different in the two branches above.
The "update" branch (which has no `OP_CSV`) uses the same constant `A_u` and `B_u` points.
The "state commit" branch (which has `OP_CSV`) uses different `A_si` and `B_si` points depending on `i` (state/sequence number).
Also, I cannot understand `OP_CODESEPARATOR`, please no.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-20 8:07 99% ` ZmnSCPxj
2019-03-21 8:37 99% ` Johnson Lau
@ 2019-03-21 9:06 99% ` Anthony Towns
2019-03-21 10:05 99% ` ZmnSCPxj
1 sibling, 1 reply; 123+ results
From: Anthony Towns @ 2019-03-21 9:06 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
On Wed, Mar 20, 2019 at 08:07:00AM +0000, ZmnSCPxj via Lightning-dev wrote:
> Re-reading again, I think perhaps I was massively confused by this:
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > <A> CHECKSIGVERIFY <B> CHECKSIG
> > or <P> CHECKSIGVERIFY <Q> CHECKSIG
> Do you mean that *either* of the above two scripts is OK, *or* do you mean they are alternatives within a single MAST or `OP_IF`?
I meant "either of the two scripts is okay".
> In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as well as the `q` private key.
> Would it be safe for Watchtower to know that?
I think so. From Alice/Bob's point-of-view, the NOINPUT sig ensures they
control their money; and from the network's point-of-view (or at least
that part of the network that thinks NOINPUT is unsafe) the Q private
key being shared makes the tx no worse than a 1-of-n multisig setup,
which has to be dealt with anyway.
> Then each update transaction pays out to:
> OP_IF
> <csv_delta> OP_CSV OP_DROP
> <muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
> OP_ELSE
> <i> OP_CHECKLOCKTIMEVERIFY OP_DROP
> <muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
> OP_ENDIF
Yeah.
I think we could potentially make that shorter still:
IF OP_CODESEPARATOR <i> OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF
<muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV
and allows binding to any prior update tx -- so works for an update tx
spending previous update txs; while signing with codeseparatorpos=-1
and NOINPUT but committing to the script code and nSequence (for the
CSV delay) allows binding to only that update tx -- so works for the
settlement tx. That's two pubkeys, two sigs, and the taproot point
reveal.
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-20 8:07 99% ` ZmnSCPxj
@ 2019-03-21 8:37 99% ` Johnson Lau
2019-03-21 9:06 99% ` Anthony Towns
1 sibling, 0 replies; 123+ results
From: Johnson Lau @ 2019-03-21 8:37 UTC (permalink / raw)
To: ZmnSCPxj, bitcoin-dev; +Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
> On 20 Mar 2019, at 4:07 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi aj,
>
> Re-reading again, I think perhaps I was massively confused by this:
>
>> - alternatively, we could require every script to have a valid signature
>> that commits to the input. In that case, you could do eltoo with a
>> script like either:
>>
>> <A> CHECKSIGVERIFY <B> CHECKSIG
>> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>>
>>
>> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
>> a key they both know the private key for. In the first case, Alice
>> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
>> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
>> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
>> finish that when they wanted to publish.
>
> Do you mean that *either* of the above two scripts is OK, *or* do you mean they are alternatives within a single MAST or `OP_IF`?
>
It means either.
If you use <A> CHECKSIGVERIFY <B> CHECKSIG style, A and B will exchange the NOINPUT sig, and they will add the required non-NOINPUT sig when needed.
If you use <muSig(A,B)> CHECKVERIFY <Q> CHECKSIG, A and B will co-sign the muSig(A,B) with NOINPUT. They will also share the private key of Q, so they could produce a non-NOINPUT sig when needed.
The first style is slightly easier as it doesn’t need muSig. But with 3 or more parties, the second style is more efficient.
However, if you use watchtower, you have to use the second style. That means you need to share the private key for Q with the watchtower, That also means the watchtower will have the ability to reply the NOINPU muSig. But it is still strictly better than anyone-can-replay.
[-- Attachment #2: Type: text/html, Size: 6419 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-20 7:38 99% ` ZmnSCPxj
@ 2019-03-20 8:07 99% ` ZmnSCPxj
2019-03-21 8:37 99% ` Johnson Lau
2019-03-21 9:06 99% ` Anthony Towns
0 siblings, 2 replies; 123+ results
From: ZmnSCPxj @ 2019-03-20 8:07 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
Hi aj,
Re-reading again, I think perhaps I was massively confused by this:
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.
Do you mean that *either* of the above two scripts is OK, *or* do you mean they are alternatives within a single MAST or `OP_IF`?
If you mean that *either* of the above two scripts is OK, then this script:
<muSig(A,B)> CHECKVERIFY <Q> CHECKSIG
should probably be used for Watchtower-compatibility.
When creating a new state, both A and B would cooperatively sign with `muSig(A,B)` with a `SIGHASH_NOINPUT` that ensures the state transaction is correct.
Then they somehow derive or share the private key to `Q`.
In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as well as the `q` private key.
Would it be safe for Watchtower to know that?
Note that the above `Q` would need to be the same in the "state" trunk of the Decker-Russell-Osuntokun construction.
So, building this, our initial setup transaction pays out to script:
<muSig(A_u,B_u)> CHECKVERIFY <Q> CHECKSIG
Then each update transaction pays out to:
OP_IF
<csv_delta> OP_CSV OP_DROP
<muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
OP_ELSE
<i> OP_CHECKLOCKTIMEVERIFY OP_DROP
<muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
OP_ENDIF
The `SIGHASH_NOINPUT` signature for `muSig(A_u,B_u)` would then be sufficient to unlock the setup transaction, or any update transaction with lower `nLockTime`.
The watchtower would then have to generate the signature for `Q`, committing to a particular UTXO.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, March 20, 2019 3:38 PM, ZmnSCPxj via Lightning-dev <lightning-dev@lists•linuxfoundation.org> wrote:
> Hi all,
>
> > Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
> > scenario (as well as the second), I'd be content with that proposal.
>
> How would this work with watchtowers?
>
> As I understand it, the current plan for eltoo watchtowers would be to store both `SIGHASH_NOINPUT` signatures from both sides in the blob sent to the watchtower.
>
> Then the watchtower can always attach this to whatever is the tipmost available on the chain of transactions.
>
> However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how does the watchtower create such a non-`SIGHASH_NOINPUT` signature?
>
> Regards,
> ZmnSCPxj
>
> > Future segwit versions may choose to relax it.[1]
> > Cheers,
> > Rusty.
> > [1] Must be consensus, not standardness; my prev suggestion was bogus.
> > Rusty Russell rusty@rustcorp•com.au writes:
> >
> > > Anthony Towns aj@erisian•com.au writes:
> > >
> > > > If you publish to the blockchain:
> > > > ...
> > > > 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> > > > is chosen by the participants, the above is still a possible scenario
> > > > in eltoo, though, and it means there's some risk for someone accepting
> > > > bitcoins that result from a non-cooperative close of an eltoo channel.
> > >
> > > AJ, this was a meandering random walk which shed very little light.
> > > I don't find the differentiation between malicious and non-malicious
> > > double-spends convincing. Even if you trust A, you already have to
> > > worry about person-who-sent-the-coins-to-A. This expands that set to be
> > > "miner who mined coins sent-to-A", but it's very hard to see what
> > > difference that makes to how you'd handle coins from A.
> > >
> > > > Beyond that, I think NOINPUT has two fundamental ways to cause problems
> > > > for the people doing NOINPUT sigs:
> > > >
> > > > 1. your signature gets applied to a unexpectedly different
> > > > script, perhaps making it look like you've being dealing
> > > > with some blacklisted entity. OP_MASK and similar solves
> > > > this.
> > > >
> > >
> > > ... followed by two paragraphs describing how it's not a "fundamental
> > > way to cause problems" that you (or I) can see.
> > >
> > > > For the second case, that seems a little more concerning. The nightmare
> > > > scenario is maybe something like:
> > > >
> > > > - naive users do silly things with NOINPUT signatures, and end up
> > > > losing funds due to replays like the above
> > > >
> > >
> > > As we've never seen with SIGHASH_NONE?
> > >
> > > > - initial source of funds was some major exchange, who decide it's
> > > > cheaper to refund the lost funds than deal with the customer complaints
> > > >
> > > > - the lost funds end up costing enough that major exchanges just outright
> > > > ban sending funds to any address capable of NOINPUT, which also bans
> > > > all taproot/schnorr addresses
> > > >
> > >
> > > I don't find this remotely credible.
> > >
> > > > FWIW, I don't have a strong opinion here yet, but:
> > > >
> > > > - I'm still inclined to err on the side of putting more safety
> > > > measures in for NOINPUT, rather than fewer
> > > >
> > >
> > > In theory, sure. But not feel-good and complex "safety measures" which
> > > don't actually help in practical failure scenarios.
> > >
> > > > - the "must have a sig that commits to the input tx" seems like it
> > > > should be pretty safe, not too expensive, and keeps taproot's privacy
> > > > benefits in the cases where you end up needing to use NOINPUT
> > > >
> > >
> > > If this is considered necessary, can it be a standardness rule rather
> > > than consensus?
> > > Thanks,
> > > Rusty.
> >
> > Lightning-dev mailing list
> > Lightning-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-20 3:33 99% ` Rusty Russell
@ 2019-03-20 7:38 99% ` ZmnSCPxj
2019-03-20 8:07 99% ` ZmnSCPxj
0 siblings, 1 reply; 123+ results
From: ZmnSCPxj @ 2019-03-20 7:38 UTC (permalink / raw)
To: Rusty Russell; +Cc: bitcoin-dev, lightning-dev
Hi all,
> Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
> scenario (as well as the second), I'd be content with that proposal.
How would this work with watchtowers?
As I understand it, the current plan for eltoo watchtowers would be to store both `SIGHASH_NOINPUT` signatures from both sides in the blob sent to the watchtower.
Then the watchtower can always attach this to whatever is the tipmost available on the chain of transactions.
However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how does the watchtower create such a non-`SIGHASH_NOINPUT` signature?
Regards,
ZmnSCPxj
> Future segwit versions may choose to relax it.[1]
>
> Cheers,
> Rusty.
> [1] Must be consensus, not standardness; my prev suggestion was bogus.
>
> Rusty Russell rusty@rustcorp•com.au writes:
>
> > Anthony Towns aj@erisian•com.au writes:
> >
> > > If you publish to the blockchain:
> > > ...
> > > 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> > > is chosen by the participants, the above is still a possible scenario
> > > in eltoo, though, and it means there's some risk for someone accepting
> > > bitcoins that result from a non-cooperative close of an eltoo channel.
> >
> > AJ, this was a meandering random walk which shed very little light.
> > I don't find the differentiation between malicious and non-malicious
> > double-spends convincing. Even if you trust A, you already have to
> > worry about person-who-sent-the-coins-to-A. This expands that set to be
> > "miner who mined coins sent-to-A", but it's very hard to see what
> > difference that makes to how you'd handle coins from A.
> >
> > > Beyond that, I think NOINPUT has two fundamental ways to cause problems
> > > for the people doing NOINPUT sigs:
> > >
> > > 1. your signature gets applied to a unexpectedly different
> > > script, perhaps making it look like you've being dealing
> > > with some blacklisted entity. OP_MASK and similar solves
> > > this.
> > >
> >
> > ... followed by two paragraphs describing how it's not a "fundamental
> > way to cause problems" that you (or I) can see.
> >
> > > For the second case, that seems a little more concerning. The nightmare
> > > scenario is maybe something like:
> > >
> > > - naive users do silly things with NOINPUT signatures, and end up
> > > losing funds due to replays like the above
> > >
> >
> > As we've never seen with SIGHASH_NONE?
> >
> > > - initial source of funds was some major exchange, who decide it's
> > > cheaper to refund the lost funds than deal with the customer complaints
> > >
> > > - the lost funds end up costing enough that major exchanges just outright
> > > ban sending funds to any address capable of NOINPUT, which also bans
> > > all taproot/schnorr addresses
> > >
> >
> > I don't find this remotely credible.
> >
> > > FWIW, I don't have a strong opinion here yet, but:
> > >
> > > - I'm still inclined to err on the side of putting more safety
> > > measures in for NOINPUT, rather than fewer
> > >
> >
> > In theory, sure. But not feel-good and complex "safety measures" which
> > don't actually help in practical failure scenarios.
> >
> > > - the "must have a sig that commits to the input tx" seems like it
> > > should be pretty safe, not too expensive, and keeps taproot's privacy
> > > benefits in the cases where you end up needing to use NOINPUT
> > >
> >
> > If this is considered necessary, can it be a standardness rule rather
> > than consensus?
> > Thanks,
> > Rusty.
>
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Notice: List Infrastructure Migration
2019-03-19 18:01 99% ` Peter Todd
@ 2019-03-20 6:03 99% ` Omar Shibli
0 siblings, 0 replies; 123+ results
From: Omar Shibli @ 2019-03-20 6:03 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
Also, quick question, is groups.io has same structure as Linux Foundation?
foundation/transparency/openness... I think in general it would be great if
this migration will be communicated much more in advance with relaxed
timelines, just by examining priori cases, it's all suggestions. hope next
phase will be more inclusive and open.
On Wed, Mar 20, 2019 at 2:45 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Mon, Mar 18, 2019 at 06:35:47PM -0400, Warren Togami Jr. via
> bitcoin-dev wrote:
> > The new archive will be operated independently outside from the Linux
> > Foundation as generated by this open source tool. This hopefully will
> allow
> > all future archives to never move again even if the underlying list
> > infrastructure needs to change. Folks will appreciate the search function
> > and git clone for a local instance.
>
> Where will that git archive actually be created/maintained? As this will
> be a
> Git repo, looks like getting it timestamped could be as simple as
> installing
> OpenTimestamps appropriately on whatever server is actually maintaining it.
>
> Equally, it'd be good to have the archive PGP signed.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2193 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-20 0:22 99% ` Rusty Russell
@ 2019-03-20 3:33 99% ` Rusty Russell
2019-03-20 7:38 99% ` ZmnSCPxj
0 siblings, 1 reply; 123+ results
From: Rusty Russell @ 2019-03-20 3:33 UTC (permalink / raw)
To: Anthony Towns, bitcoin-dev; +Cc: lightning-dev
Sorry AJ, my prior email was not constructive :(
I consider the "my software reused my keys" the most reasonable attack
scenario, though still small compared to other lightning attack surfaces.
But I understand the general wariness of third-parties reusing
SIGHASH_NOINPUT signatures.
Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
scenario (as well as the second), I'd be content with that proposal.
Future segwit versions may choose to relax it.[1]
Cheers,
Rusty.
[1] Must be consensus, not standardness; my prev suggestion was bogus.
Rusty Russell <rusty@rustcorp•com.au> writes:
> Anthony Towns <aj@erisian•com.au> writes:
>> If you publish to the blockchain:
> ...
>> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
>> is chosen by the participants, the above is still a possible scenario
>> in eltoo, though, and it means there's some risk for someone accepting
>> bitcoins that result from a non-cooperative close of an eltoo channel.
>
> AJ, this was a meandering random walk which shed very little light.
>
> I don't find the differentiation between malicious and non-malicious
> double-spends convincing. Even if you trust A, you already have to
> worry about person-who-sent-the-coins-to-A. This expands that set to be
> "miner who mined coins sent-to-A", but it's very hard to see what
> difference that makes to how you'd handle coins from A.
>
>> Beyond that, I think NOINPUT has two fundamental ways to cause problems
>> for the people doing NOINPUT sigs:
>>
>> 1) your signature gets applied to a unexpectedly different
>> script, perhaps making it look like you've being dealing
>> with some blacklisted entity. OP_MASK and similar solves
>> this.
>
> ... followed by two paragraphs describing how it's not a "fundamental
> way to cause problems" that you (or I) can see.
>
>> For the second case, that seems a little more concerning. The nightmare
>> scenario is maybe something like:
>>
>> * naive users do silly things with NOINPUT signatures, and end up
>> losing funds due to replays like the above
>
> As we've never seen with SIGHASH_NONE?
>
>> * initial source of funds was some major exchange, who decide it's
>> cheaper to refund the lost funds than deal with the customer complaints
>>
>> * the lost funds end up costing enough that major exchanges just outright
>> ban sending funds to any address capable of NOINPUT, which also bans
>> all taproot/schnorr addresses
>
> I don't find this remotely credible.
>
>> FWIW, I don't have a strong opinion here yet, but:
>>
>> - I'm still inclined to err on the side of putting more safety
>> measures in for NOINPUT, rather than fewer
>
> In theory, sure. But not feel-good and complex "safety measures" which
> don't actually help in practical failure scenarios.
>
>> - the "must have a sig that commits to the input tx" seems like it
>> should be pretty safe, not too expensive, and keeps taproot's privacy
>> benefits in the cases where you end up needing to use NOINPUT
>
> If this is considered necessary, can it be a standardness rule rather
> than consensus?
>
> Thanks,
> Rusty.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-13 1:41 99% [bitcoin-dev] More thoughts on NOINPUT safety Anthony Towns
2019-03-13 6:41 99% ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
@ 2019-03-20 0:22 99% ` Rusty Russell
2019-03-20 3:33 99% ` Rusty Russell
1 sibling, 1 reply; 123+ results
From: Rusty Russell @ 2019-03-20 0:22 UTC (permalink / raw)
To: Anthony Towns, bitcoin-dev; +Cc: lightning-dev
Anthony Towns <aj@erisian•com.au> writes:
> If you publish to the blockchain:
...
> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> is chosen by the participants, the above is still a possible scenario
> in eltoo, though, and it means there's some risk for someone accepting
> bitcoins that result from a non-cooperative close of an eltoo channel.
AJ, this was a meandering random walk which shed very little light.
I don't find the differentiation between malicious and non-malicious
double-spends convincing. Even if you trust A, you already have to
worry about person-who-sent-the-coins-to-A. This expands that set to be
"miner who mined coins sent-to-A", but it's very hard to see what
difference that makes to how you'd handle coins from A.
> Beyond that, I think NOINPUT has two fundamental ways to cause problems
> for the people doing NOINPUT sigs:
>
> 1) your signature gets applied to a unexpectedly different
> script, perhaps making it look like you've being dealing
> with some blacklisted entity. OP_MASK and similar solves
> this.
... followed by two paragraphs describing how it's not a "fundamental
way to cause problems" that you (or I) can see.
> For the second case, that seems a little more concerning. The nightmare
> scenario is maybe something like:
>
> * naive users do silly things with NOINPUT signatures, and end up
> losing funds due to replays like the above
As we've never seen with SIGHASH_NONE?
> * initial source of funds was some major exchange, who decide it's
> cheaper to refund the lost funds than deal with the customer complaints
>
> * the lost funds end up costing enough that major exchanges just outright
> ban sending funds to any address capable of NOINPUT, which also bans
> all taproot/schnorr addresses
I don't find this remotely credible.
> FWIW, I don't have a strong opinion here yet, but:
>
> - I'm still inclined to err on the side of putting more safety
> measures in for NOINPUT, rather than fewer
In theory, sure. But not feel-good and complex "safety measures" which
don't actually help in practical failure scenarios.
> - the "must have a sig that commits to the input tx" seems like it
> should be pretty safe, not too expensive, and keeps taproot's privacy
> benefits in the cases where you end up needing to use NOINPUT
If this is considered necessary, can it be a standardness rule rather
than consensus?
Thanks,
Rusty.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Notice: List Infrastructure Migration
2019-03-18 22:35 99% [bitcoin-dev] Notice: List Infrastructure Migration Warren Togami Jr.
@ 2019-03-19 18:01 99% ` Peter Todd
2019-03-20 6:03 99% ` Omar Shibli
0 siblings, 1 reply; 123+ results
From: Peter Todd @ 2019-03-19 18:01 UTC (permalink / raw)
To: Warren Togami Jr., Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Mon, Mar 18, 2019 at 06:35:47PM -0400, Warren Togami Jr. via bitcoin-dev wrote:
> The new archive will be operated independently outside from the Linux
> Foundation as generated by this open source tool. This hopefully will allow
> all future archives to never move again even if the underlying list
> infrastructure needs to change. Folks will appreciate the search function
> and git clone for a local instance.
Where will that git archive actually be created/maintained? As this will be a
Git repo, looks like getting it timestamped could be as simple as installing
OpenTimestamps appropriately on whatever server is actually maintaining it.
Equally, it'd be good to have the archive PGP signed.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
2019-03-17 20:27 99% ` Alistair Mann
@ 2019-03-19 0:22 99% ` ZmnSCPxj
0 siblings, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-03-19 0:22 UTC (permalink / raw)
To: Alistair Mann, Bitcoin Protocol Discussion
Good morning Alistair,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 4:27 AM, Alistair Mann via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> This update collects community feedback on my HTLB Pre-BIP
>
> As reminder, I'm suggesting a BIP for a hitherto poorly supported class of
> transactions: "Good Behaviour Bonds".
>
> 1. On this mailing list:
> ZmnSCPxj notes HTLB over HTLC can improve privacy by obscuring whether a
> transaction is, in fact, an HTLB or an HTLC. This requires that the
> 'redundant' <digest> and [HASHOP] be not standardised. I intend to follow that
>
>
> advice.
>
> 2. On Reddit at http://tinyurl.com/yxdketdo:
> /u/almkglor nudges me to consider if Bob could immediately fail the HTLB to
> Alice's benefit. I believe he could with something like this script:
> OP_IF
> OP_DUP OP_HASH160 <seller pubkey hash>
> OP_ELSE
> OP_IF
> [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <buyer pubkey hash>
>
> OP_ELSE
> <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
>
> OP_ENDIF
>
>
> OP_ENDIF
> OP_EQUALVERIFY
> OP_CHECKSIG
> The second OP_IF is new and would mean Bob can give Alice a [HASHOP] and
> <digest> that allows her to immediately redeem the funds. I will be modifying
>
> the proof-of-concept code to investigate and prove this change.
The above is at odds with my suggestion to transport HTLBs over HTLCs.
BIP-199 already exists and defines a standard template for HTLC contracts.
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
To use the above contract as HTLB:
1. Alice is the "buyer".
2. Bob is the "seller".
3. The preimage of `<digest>` is generated by Alice and given by Alice to Bob.
I observe that an "early return to Alice" can be implemented by Bob, by taking the first branch, but sending the money back to an address Alice controls.
Since Bob is the one who will decide whether to take the money (i.e. Alice is wasting Bob precious time and resource) or return to Alice (i.e. Alice sent the message in good faith), this decision can be made by Bob entirely without any input from Alice.
So the overall flow of the messages would be:
1. Alice sends preimage of `<digest>`, `[HASHOP]`, `<num>` and a new address that Alice controls (for purpose of "early return").
2. Alice makes transaction to the above HTLC pattern.
3. Bob has until `<num> [HASHOP]` to decide:
3.1. To claim the money for itself by taking the first branch and sending to a new address that Bob controls.
3.2. To return the money to Alice by taking the first branch and sending to the address Alice gave.
4. If Bob has not decided at the timeout, Alice can get her money back by taking the second branch.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Notice: List Infrastructure Migration
@ 2019-03-18 22:35 99% Warren Togami Jr.
2019-03-19 18:01 99% ` Peter Todd
0 siblings, 1 reply; 123+ results
From: Warren Togami Jr. @ 2019-03-18 22:35 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]
Be advised that starting this week bitcoin-dev, lightning-dev and other
Bitcoin-oriented lists currently still active at
https://lists.linuxfoundation.org/mailman/listinfo will begin migration to
the Linux Foundation's new list infrastructure operated by groups.io. You
may continue to use these lists as-is until each list is notified that
migration is complete. It is unclear when the switch-over happens because
we need imports to complete without error and some testing to pass.
IMPORTANT: If you do not wish to be auto-subscribed to the new list
management system then please unsubscribe prior to the migration.
ARCHIVES: The archives are of utmost importance for prior art and historic
value. We are working on a plan with the Linux Foundation sysadmins to
ensure the current archive permalinks will remain as-is static or to
redirect to the correct post that lives at a new archive.
https://lwn.net/Articles/748184/
The new archive will be operated independently outside from the Linux
Foundation as generated by this open source tool. This hopefully will allow
all future archives to never move again even if the underlying list
infrastructure needs to change. Folks will appreciate the search function
and git clone for a local instance.
More details to be posted here soon.
Warren Togami
[-- Attachment #2: Type: text/html, Size: 1609 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Payjoin privacy with the receiver of the transaction
@ 2019-03-18 10:55 99% Kenshiro []
2019-03-21 16:52 99% ` rhavar
0 siblings, 1 reply; 123+ results
From: Kenshiro [] @ 2019-03-18 10:55 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Hi,
I think Payjoin can be a very good privacy solution for Bitcoin, but I have a question about it:
- If a user has 1 BTC in a single address and make a payjoin payment to other person of 0.1 BTC using that address as input, the other person can see in a blockchain explorer the change address with an amount of 0.9 BTC. That's a serious privacy leak. I would like to know what will be the standard solution to this issue. An easy fix could be that the user wallet check if any address contains a BTC amount higher than a "safe" amount like 0.01 BTC or less. If some address exceed that amount the wallet could automatically make 1 payment to itself to split the amount in several addresses. In this way nobody receiving a payment from a user will ever know that he has a bitcoin balance higher than the "safe" amount.
What do you think?
Regards,
[-- Attachment #2: Type: text/html, Size: 1371 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
2019-03-17 16:11 99% ` Alistair Mann
@ 2019-03-18 4:22 99% ` ZmnSCPxj
0 siblings, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-03-18 4:22 UTC (permalink / raw)
To: Alistair Mann; +Cc: Bitcoin Protocol Discussion
Funding Transaction Pattern is how I name it; I am unaware if this pattern has been named before.
I know gmax created Taproot precisely as an optimization of this pattern, so I presume he is aware of it, and might know a proper name for such.
It is massively ambiguous to call it "gmax technique" as that name could apply to many, many techniques.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 12:11 AM, Alistair Mann <al@pectw•net> wrote:
> Many thanks for your thoughts, ZmnSCPxj.
>
> > I believe there is indeed an important usecase for HTLB over HTLC, which is
> > to improve the anonymity set. An HTLB over HTLC would be indistinguishable
> > onchain from other uses of HTLC; assuming that HTLCs have other uses, this
> > is a (small?) plus to privacy.
> > Note that the redundant <digest> would have to be given by Alice to Bob,
> > since using a standardized one will also reveal use of HTLB over HTLC
> > instead of hiding it among other HTLC UTXOs.
>
> Both these are good observations and I'll act on them.
>
> > Another thing to improve privacy would be to apply the Funding Transaction
> > pattern: https://zmnscpxj.github.io/offchain/generalized.html
>
> <snip>
>
> I've not read of the FTP before; I welcome it, and take on board that it
> improves privacy by keeping a script offline. My first thought is that doesn't
> affect the suggested BIP, so my next update here won't include it. I recognise
> it would improve mainnet use of scripts though, so do expect to return to it.
>
> Cheers,
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Alistair Mann
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
2019-03-11 16:01 99% [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB Alistair Mann
2019-03-12 4:14 99% ` ZmnSCPxj
@ 2019-03-17 20:27 99% ` Alistair Mann
2019-03-19 0:22 99% ` ZmnSCPxj
1 sibling, 1 reply; 123+ results
From: Alistair Mann @ 2019-03-17 20:27 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
This update collects community feedback on my HTLB Pre-BIP
As reminder, I'm suggesting a BIP for a hitherto poorly supported class of
transactions: "Good Behaviour Bonds".
1. On this mailing list:
ZmnSCPxj notes HTLB over HTLC can improve privacy by obscuring whether a
transaction is, in fact, an HTLB or an HTLC. This requires that the
'redundant' <digest> and [HASHOP] be not standardised. I intend to follow that
advice.
2. On Reddit at http://tinyurl.com/yxdketdo:
/u/almkglor nudges me to consider if Bob could immediately fail the HTLB to
Alice's benefit. I believe he could with something like this script:
OP_IF
OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
OP_IF
[HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
The second OP_IF is new and would mean Bob can give Alice a [HASHOP] and
<digest> that allows her to immediately redeem the funds. I will be modifying
the proof-of-concept code to investigate and prove this change.
At https://twitter.com/ChristopherA/status/1105153022206722048
3. @mappum observes the HTLB idea is "like proof-of-stake". Such a succint
comparison of HTLB with existing work is useful to me even though HTLB has
nothing to do with mining and PoS consensus. I'll be investigating if the PoS
penalty system has more that can inform this BIP.
I'm grateful to the above for their contributions, and also to the circa 60+
non-bot visitors to the berewic.com site: quiet interest is positive.
Assuming no other major changes my next update will be a formal write-up for
the BIP.
Cheers,
--
Alistair Mann
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
2019-03-12 4:14 99% ` ZmnSCPxj
@ 2019-03-17 16:11 99% ` Alistair Mann
2019-03-18 4:22 99% ` ZmnSCPxj
0 siblings, 1 reply; 123+ results
From: Alistair Mann @ 2019-03-17 16:11 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Many thanks for your thoughts, ZmnSCPxj.
> I believe there is indeed an important usecase for HTLB over HTLC, which is
> to improve the anonymity set. An HTLB over HTLC would be indistinguishable
> onchain from other uses of HTLC; assuming that HTLCs have other uses, this
> is a (small?) plus to privacy.
>
> Note that the redundant <digest> would have to be given by Alice to Bob,
> since using a standardized one will also reveal use of HTLB over HTLC
> instead of hiding it among other HTLC UTXOs.
Both these are good observations and I'll act on them.
> Another thing to improve privacy would be to apply the Funding Transaction
> pattern: https://zmnscpxj.github.io/offchain/generalized.html
<snip>
I've not read of the FTP before; I welcome it, and take on board that it
improves privacy by keeping a script offline. My first thought is that doesn't
affect the suggested BIP, so my next update here won't include it. I recognise
it would improve mainnet use of scripts though, so do expect to return to it.
Cheers,
--
Alistair Mann
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-14 7:24 99% ` Anthony Towns
2019-03-14 7:55 99% ` ZmnSCPxj
@ 2019-03-14 12:00 99% ` Christian Decker
1 sibling, 0 replies; 123+ results
From: Christian Decker @ 2019-03-14 12:00 UTC (permalink / raw)
To: Anthony Towns, ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
Anthony Towns <aj@erisian•com.au> writes:
> I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
> so if you used a tagged output, you could do everything normal taproot
> address could, but also do noinput sigs for them.
>
> So you might have:
>
> funding tx -> cooperative claim
>
> funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
>
> funding tx -> update 3 [TAGGED] ->
> update 4 [TAGGED,NOINPUT] ->
> settlement 4 [TAGGED,NOINPUT] ->
> claim [NOINPUT]
>
> In the cooperative case, no output tagging needed.
I might be missing something here, but how do you bind update 3 to the
funding tx output, when that output is not tagged? Do we keep each
update in multiple separate states, one bound to the funding tx output
and another signed with noinput? If that's the case we just doubled our
storage and communication requirements for very little gain. An
alternative is to add a trigger transaction that needs to be published
in a unilateral case, but that'd increase our on-chain footprint.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-13 22:30 99% ` Dustin Dettmer
@ 2019-03-14 9:46 99% ` Aymeric Vitte
0 siblings, 0 replies; 123+ results
From: Aymeric Vitte @ 2019-03-14 9:46 UTC (permalink / raw)
To: Dustin Dettmer, Bitcoin Protocol Discussion, Oscar Guindzberg
Cc: Andreas Schildbach
[-- Attachment #1: Type: text/plain, Size: 4114 bytes --]
Apparently I don't have the same experience than others here, what I
encountered is no reject message received for wrong txs, but from what I
understand here it's not unusual to receive reject message for valid
txs, then I don't see how it can be really helpful/relied, given also
that the reject messages are unclear and even can be misleading
As it was written already I found it useful only for debugging purposes,
at least it can give some kind of ideas about what happened,
bitcoin-transactions is implementing the bitcoin protocol but does not
act as a node and does not pretend to fake a node behavior waiting for
example to get the tx back, is the method of sending a getdata for a
given tx to see if it was accepted by a node wrong ? It can't guarantee
100% that it was successful and will propagate but I see that you are
doing completely different things
Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit :
> I’ve solved the same problem in a different way.
>
> 1) Submit a transaction
> 2) Collect all reject messages (that have matching txid in the reject
> data)
> 3) Wait 16 seconds after first error message received (chosen
> semirandomly from trial and error) before processing errors
> 4) Wait for our txid to be submitted back to us through the mempool,
> if we get it notify success and delete all pending error events
> 5) Signal failure with the given reject code if present (after the 16
> seconds have elapsed)
> 6) If no error or success after 20 seconds, signal timeout failure
>
> This works fairly well in testing. Newer transaction types seem to
> generate reject codes 100% of the time (from at least one node when
> sending to 4 nodes) so this culling / time delay approach is
> essentially required.
>
> On a related note: One issue is that RBF attempts with too small a fee
> and accidental double spends (with enough fee for 1 tx but not a RBF)
> both generate the same reject code: not enough fee.
>
> A new reject code for RBF based too small of fee would definitely make
> for a better user experience as I’ve seen this exact problem create
> confusion for users.
>
> Removing reject codes would make for a much worse user experience.
> “Your tx failed and we have no idea why” would be the only message and
> it would require waiting for a full timeout.
>
> On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> <mailto: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
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
[-- Attachment #2: Type: text/html, Size: 7434 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-14 7:24 99% ` Anthony Towns
@ 2019-03-14 7:55 99% ` ZmnSCPxj
2019-03-14 12:00 99% ` Christian Decker
1 sibling, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-03-14 7:55 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev, lightning-dev
Good morning aj,
>
> Trying to maximise privacy there has the disadvantage that you have to
> do a new signature for every in-flight HTLC every time you update the
> state, which could be a lot of signatures for very active channels.
If I remember accurately this is already true for current Poon-Dryja channels in BOLT 1.0, so at least it is not a degradation of performance.
It does make this modified form of Decker-Russell-Osuntokun much less attractive for use with DLC as the Fulgurite effort would like, but the Fulgurite effort already mitigates this by splitting a channel into two sub-channels (one for high-activity LN payments, one for rare-activity DLC bets) anyway.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-14 5:22 99% ` ZmnSCPxj
@ 2019-03-14 7:24 99% ` Anthony Towns
2019-03-14 7:55 99% ` ZmnSCPxj
2019-03-14 12:00 99% ` Christian Decker
0 siblings, 2 replies; 123+ results
From: Anthony Towns @ 2019-03-14 7:24 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
On Thu, Mar 14, 2019 at 05:22:59AM +0000, ZmnSCPxj via Lightning-dev wrote:
> When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case.
I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
so if you used a tagged output, you could do everything normal taproot
address could, but also do noinput sigs for them.
So you might have:
funding tx -> cooperative claim
funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
funding tx -> update 3 [TAGGED] ->
update 4 [TAGGED,NOINPUT] ->
settlement 4 [TAGGED,NOINPUT] ->
claim [NOINPUT]
In the cooperative case, no output tagging needed.
For the unilateral case, you need to tag all the update tx's, because
they *could* be spend by a later update with a NOINPUT sig, and if
that actually happens, then the settlement tx also needs to use a
NOINPUT sig, and if you're using scriptless scripts to resolve HTLCs,
claiming/refunding the HTLCs needs a partially-pre-signed tx which also
needs to be a NOINPUT sig, meaning the settlement tx also needs to be
tagged in that case.
You'd only need the script path for the last case where there actually
are multiple updates, but because you have to have a tagged output in the
second case anyway, maybe you've already lost privacy and always using
NOINPUT and the script path for update and settlement tx's would be fine.
> However, it is probably more likely that I simply misunderstood what you said, so if you can definitively say that it would be possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot then I am fine.
Yeah, that's my thinking.
> Minor pointless reactions:
> > 5. if you're using scriptless scripts to do HTLCs, you'll need to
> > allow for NOINPUT sigs when claiming funds as well (and update
> > the partial signatures for the non-NOINPUT cases if you want to
> > maximise privacy), which is a bit fiddly
> If I remember accurately, we do not allow bilateral/cooperative close when HTLC is in-flight.
> However, I notice that later you point out that a non-cheating unilateral close does not need NOINPUT, so I suppose. the above thought applies to that case.
Yeah, exactly.
Trying to maximise privacy there has the disadvantage that you have to
do a new signature for every in-flight HTLC every time you update the
state, which could be a lot of signatures for very active channels.
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-13 11:10 99% ` Anthony Towns
@ 2019-03-14 5:22 99% ` ZmnSCPxj
2019-03-14 7:24 99% ` Anthony Towns
0 siblings, 1 reply; 123+ results
From: ZmnSCPxj @ 2019-03-14 5:22 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev, lightning-dev
Good morning aj,
When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case.
However, it is probably more likely that I simply misunderstood what you said, so if you can definitively say that it would be possible to hide the clause "or a NOINPUT sig from A with a non-NOINPUT sig from B" behind a Taproot then I am fine.
Minor pointless reactions:
> 5. if you're using scriptless scripts to do HTLCs, you'll need to
> allow for NOINPUT sigs when claiming funds as well (and update
> the partial signatures for the non-NOINPUT cases if you want to
> maximise privacy), which is a bit fiddly
If I remember accurately, we do not allow bilateral/cooperative close when HTLC is in-flight.
However, I notice that later you point out that a non-cheating unilateral close does not need NOINPUT, so I suppose. the above thought applies to that case.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
[not found] <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
@ 2019-03-14 1:17 99% ` Karl-Johan Alm
0 siblings, 0 replies; 123+ results
From: Karl-Johan Alm @ 2019-03-14 1:17 UTC (permalink / raw)
To: Varunram Ganesh; +Cc: Bitcoin Protocol Discussion
Hi Varunram,
On Wed, Mar 13, 2019 at 3:41 PM Varunram Ganesh
<varunramganesh@gmail•com> wrote:
>
> I like your idea of a signet as it would greatly help test reorgs and stuff without having to experiment with regtest. But I'm a bit concerned about running a common signet (Signet1) controlled by a trusted entity. I guess if someone wants to test signet on a global scale, they could spin up a couple nodes in a couple places (and since it is anyway trusted, they can choose to run it on centralised services like AWS). Another concern is that the maintainer might have unscheduled work, emergencies, etc and that could affect how people test stuff on. This would also mean that we need people to run signet1 nodes in parallel with current testnet nodes (one could argue that Signet is trusted anyway and this doesn't matter, still)
>
> I'm sure you would have considered these while designing, so would be great to hear your thoughts.
For starters, I assume that the signer would run an automated script
that generated blocks on regular intervals without requiring manual
interaction. So even if the signer went on a vacation, the network
would keep on ticking. I also assume the signer would be running a
faucet service so users could get coins as needed. Ultimately though,
if a signer ended up vanishing or being unreliable, people would just
set up a new signet with a different signer and use that instead, so
ultimately it's not a big deal.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-13 3:23 99% ` Anthony Towns
@ 2019-03-14 1:07 99% ` Karl-Johan Alm
0 siblings, 0 replies; 123+ results
From: Karl-Johan Alm @ 2019-03-14 1:07 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
Hi Anthony,
On Wed, Mar 13, 2019 at 12:23 PM Anthony Towns <aj@erisian•com.au> wrote:
>
> Maybe make the signature be an optional addition to the header, so
> that you can have a "light node" that doesn't download/verify sigs
> and a full node that does? (So signatures just sign the traditional
> 80-byte header, and aren't included in the block's tx merkle root, and
> the prevHash reflects the hash of the previous block's 80-byte header,
> without the signature)
This seems to be what everyone around me thinks is the best approach.
I.e. signet is a "p2p level agreement" that an additional signature is
required for a block to be considered fully valid.
It has the added complexity that a signature-aware signet node talking
to a non-signature-aware signet node should reject/discard headers
sent from the peer, or you will run into situations where a node
doesn't know if the headers are valid or not and has to hold onto them
indefinitely, which is a situation that currently does not occur in
"regular" nets.
If you detach the signature from the header, you also end up with
cases where a malicious user could send garbage data as the signature
for a valid header, forcing peers to mark that header as invalid, even
though it isn't. That is regardless of whether a fix is in place for
the above, too.
> If you did this, it might be a good idea to enforce including the previous
> block's header signature in the current block's coinbase.
Yeah that is one of the ideas we had early on, and I think it's a good
one to do. It doesn't mean someone cannot spam a bunch of invalid
headers at block height current_tip+1, but at least you can get all
but the latest signature now. So as long as you are able to fetch the
latest signature, you should theoretically be able to verify the
entire chain just from the blocks + that one sig.
-Kalle.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-13 14:41 99% ` Oscar Guindzberg
@ 2019-03-13 22:30 99% ` Dustin Dettmer
2019-03-14 9:46 99% ` Aymeric Vitte
0 siblings, 1 reply; 123+ results
From: Dustin Dettmer @ 2019-03-13 22:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Oscar Guindzberg; +Cc: Andreas Schildbach
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]
I’ve solved the same problem in a different way.
1) Submit a transaction
2) Collect all reject messages (that have matching txid in the reject data)
3) Wait 16 seconds after first error message received (chosen semirandomly
from trial and error) before processing errors
4) Wait for our txid to be submitted back to us through the mempool, if we
get it notify success and delete all pending error events
5) Signal failure with the given reject code if present (after the 16
seconds have elapsed)
6) If no error or success after 20 seconds, signal timeout failure
This works fairly well in testing. Newer transaction types seem to generate
reject codes 100% of the time (from at least one node when sending to 4
nodes) so this culling / time delay approach is essentially required.
On a related note: One issue is that RBF attempts with too small a fee and
accidental double spends (with enough fee for 1 tx but not a RBF) both
generate the same reject code: not enough fee.
A new reject code for RBF based too small of fee would definitely make for
a better user experience as I’ve seen this exact problem create confusion
for users.
Removing reject codes would make for a much worse user experience. “Your tx
failed and we have no idea why” would be the only message and it would
require waiting for a full timeout.
On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3184 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-12 22:14 99% ` Gregory Maxwell
2019-03-13 14:29 99% ` Andreas Schildbach
@ 2019-03-13 14:41 99% ` Oscar Guindzberg
2019-03-13 22:30 99% ` Dustin Dettmer
1 sibling, 1 reply; 123+ results
From: Oscar Guindzberg @ 2019-03-13 14:41 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion; +Cc: Andreas Schildbach
> I'd like to better understand this, but it would be easier to just
> read the code than ask a bunch of questions. I tried looking for the
> handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> and didn't really find and handling other than logging exceptions.
> Would you mind giving me a couple pointers to where in the code
> they're handled?
https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-12 22:14 99% ` Gregory Maxwell
@ 2019-03-13 14:29 99% ` Andreas Schildbach
2019-03-13 14:41 99% ` Oscar Guindzberg
1 sibling, 0 replies; 123+ results
From: Andreas Schildbach @ 2019-03-13 14:29 UTC (permalink / raw)
To: bitcoin-dev
On 12/03/2019 23.14, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> These two cases are understood and handled by current code. Generally
>> the idea is take reject messages serious, but don't overrate the lack
>> of. Luckily, network confirmations fill the gap. (Yes, a timeout is
>
> I'd like to better understand this, but it would be easier to just
> read the code than ask a bunch of questions. I tried looking for the
> handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> and didn't really find and handling other than logging exceptions.
> Would you mind giving me a couple pointers to where in the code
> they're handled?
It's implemented in bitcoinj's TransactionBroadcast class. Received
reject messages are collected and -- if a certain consensus (currently:
half of connected peers) is reached -- a RejectedTransactionException is
raised.
The handling of that exception in Bitcoin Wallet is extremely
rudimentary. I think it still only shows the exception message. But
certainly I was hoping to improve on this soon.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-13 6:41 99% ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
@ 2019-03-13 11:10 99% ` Anthony Towns
2019-03-14 5:22 99% ` ZmnSCPxj
0 siblings, 1 reply; 123+ results
From: Anthony Towns @ 2019-03-13 11:10 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev, lightning-dev
On Wed, Mar 13, 2019 at 06:41:47AM +0000, ZmnSCPxj via Lightning-dev wrote:
> > - alternatively, we could require every script to have a valid signature
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > <A> CHECKSIGVERIFY <B> CHECKSIG
> > or <P> CHECKSIGVERIFY <Q> CHECKSIG
> > where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> > a key they both know the private key for. In the first case, Alice
> > would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> > Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> > Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> > finish that when they wanted to publish.
> At my point of view, if a NONINPUT sig is restricted and cannot be
> used to spend an "ordinary" 2-of-2, this is output tagging regardless
> of exact mechanism.
With taproot, you could always do the 2-of-2 spend without revealing a
script at all, let alone that it was meant to be NOINPUT capable. The
setup I'm thinking of in this scenario is something like:
0) my key is A, your key is B, we want to setup an eltoo channel
1) post a funding tx to the blockchain, spending money to an address
P = muSig(A,B)
2) we cycle through a bunch of states from 0..N, with "0" being the
refund state we establish before publishing the funding tx to
the blockchain. each state essentially has two corresponding tx's,
and update tx and a settlement tx.
3) the update tx for state k spends to an output Qk which is a
taproot address Qk = P + H(P,Sk)*G where Sk is the eltoo ratchet
condition:
Sk = (5e8+k+1) CLTV A CHECKDLS_NOINPUT B CHECKDLS_NOINPUT_VERIFY
we establish two partial signatures for update state k, one which
is a partial signature spending the funding tx with key P and
SIGHASH_ALL, the other is a NOINPUT signature via A (for you) and
via B (for me) with locktime set to (k+5e8), so that we can spend
any earlier state's update tx's, but not itself or any later
state's update tx's.
4) for each state we have also have a settlement transaction,
Sk, which spends update tx k, to outputs corresponding to the state
of the channel, after a relative timelock delay.
we have two partial signatures for this transaction too, one with
SIGHASH_ALL assuming that we directly spent the funding tx with
update state k (so the input txid is known), via the key path with
key Qk; the other SIGHASH_NOINPUT via the Sk path. both partially
signed tx's have nSequence set to the required relative timelock
delay.
5) if you're using scriptless scripts to do HTLCs, you'll need to
allow for NOINPUT sigs when claiming funds as well (and update
the partial signatures for the non-NOINPUT cases if you want to
maximise privacy), which is a bit fiddly
6) when closing the channel the process is then:
- if you're in contact with the other party, negotiate a new
key path spend of the funding tx, publish it, and you're done.
- otherwise, if the funding tx hasn't been spent, post the latest
update tx you know about, using the "spend the funding tx via
key path" partial signature
- otherwise, trace the children of the funding tx, so you can see
the most recent published state:
- if that's newer than the latest state you know about, your
info is out of date (restored from an old backup?), and you
have to wait for your counterparty to post the settlement tx
- if it's equal to the latest state you know about, wait
- if it's older than the latest state, post the latest update
tx (via the NOINPUT script path sig), and wait
- once the CSV delay for the latest update tx has expired, post
the corresponding settlement tx (key path if the update tx
spent the funding tx, NOINPUT if the update tx spent an earlier
update tx)
- once the settlement tx is posted, claim your funds
So the cases look like:
mutual close:
funding tx -> claimed funds
-- only see one key via muSig, single signature, SIGHASH_ALL
-- if there are active HTLCs when closing the channel, and they
timeout, then the claiming tx will likely be one-in, one-out,
SIGHASH_ALL, with a locktime, which may be unusual enough to
indicate a lightning channel.
unilateral close, no cheating:
funding tx -> update N -> settlement N -> claimed funds
-- update N is probably SINGLE|ANYONECANPAY, so chain analysis
of accompanying inputs might reveal who closed the channel
-- settlement N has relative timelock
-- claimed funds may have timelocks if they claim active HTLCs via
the refund path
-- no NOINPUT signatures needed, and all signatures use the key path
so don't reveal any scripts
unilateral close, attempted cheating:
funding tx -> update K -> update N -> settlement N -> claimed funds
-- update K, update N are probably SINGLE|ANYONECANPAY, so chain
analysis might reveal the identity of both sides of the channel
-- update N and settlement N both use NOINPUT signatures and
reveal CLTV script that looks like eltoo
-- update N has timelock set
-- settlement N has a relative timelock
-- claimed funds may have timelocks if they claim active HTLCs via
the refund path
Notes:
* cheating isn't 100% accurate: could be due to someone having to
restore from an old backup
* you could end up with:
funding tx -> update K -> update W -> update N
-> settlement N -> claimed funds
if someone restored from an old backup and posted K, a watchtower
had a newer but not current state W, and finally you posted
state N directly. with multiple watchtowers you might have more
intermediate states' update tx's posted. afaics it has similar
privacy results to the 2-update-tx case.
> So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is still output tagging, as a cooperative close would still reveal that the output is not a 2-of-2.
With the above setup, you don't discover that NOINPUT was possible unless it
is actually needed because someone cheated.
As long as you're using muSig key path spending for a cooperative close,
you're not even revealing the output is 2-of-2, let alone a weird
2-of-2 variant.
> Ideally, historical data of whether onchain coin was used in Lightning or not should be revealed as little as possible.
> So in a cooperative close (which we hope, to be a common case), ideally the spend should look no different from an ordinary 2-of-2 spend.
With taproot, the goal is it shouldn't look different from an ordinary
"pay to public key" spend, and I think that's pretty achievable.
> Of course if the channel is published on Lightning, those who participated in Lightning at the time will learn of it, but at least the effort to remember this information is on those who want to remember this fact.
Well, presumaby lightning will continue to support private channels that
don't get published, and the concern's definitely valid for them!
> Now, this can be worked around by adding a "kickoff" transaction that spends the eltoo setup transaction.
> The eltoo setup transaction outputs to an ordinary 2-of-2.
> The kickoff outputs to an output that allows NOINPUT.
> Then the rest of the protocol anchors on top of the kickoff.
> [...]
I think this is possible too, but I think the scheme I describe above
is superior: iit means calculating a few more signatures each update,
but keeps more information off chain, which is better for privacy, and
probably cheaper (unless you have very high-frequency channel updates?).
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
@ 2019-03-13 9:15 99% Varunram Ganesh
0 siblings, 0 replies; 123+ results
From: Varunram Ganesh @ 2019-03-13 9:15 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 867 bytes --]
Hello Kalle,
I like your idea of a signet as it would greatly help test reorgs and stuff
without having to experiment with regtest. But I'm a bit concerned about
running a common signet (Signet1) controlled by a trusted entity. I guess
if someone wants to test signet on a global scale, they could spin up a
couple nodes in a couple places (and since it is anyway trusted, they can
choose to run it on centralised services like AWS). Another concern is that
the maintainer might have unscheduled work, emergencies, etc and that could
affect how people test stuff on. This would also mean that we need people
to run signet1 nodes in parallel with current testnet nodes (one could
argue that Signet is trusted anyway and this doesn't matter, still)
I'm sure you would have considered these while designing, so would be great
to hear your thoughts.
Regards,
Varunram
[-- Attachment #2: Type: text/html, Size: 1004 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
2019-03-13 1:41 99% [bitcoin-dev] More thoughts on NOINPUT safety Anthony Towns
@ 2019-03-13 6:41 99% ` ZmnSCPxj
2019-03-13 11:10 99% ` Anthony Towns
2019-03-20 0:22 99% ` Rusty Russell
1 sibling, 1 reply; 123+ results
From: ZmnSCPxj @ 2019-03-13 6:41 UTC (permalink / raw)
To: Anthony Towns; +Cc: bitcoin-dev, lightning-dev
Good morning aj,
First off, I have little to no idea of the issues at the lower-level Bitcoin.
In any case ---
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.
>
> This is a bit more costly than a key path spend: you have to reveal
> the taproot point to do a script (+33B) and you have two signatures
> instead of one (+65B) and you have to reveal two keys as well
> (+66B), plus some script overhead. If we did the <P,Q> variant,
> we could provide a "PUSH_TAPROOT_KEY" opcode that would just push
> the taproot key to stack, saving 33B from pushing P as a literal,
> but you can't do much better than that. All in all, it'd be about 25%
> overhead in order to prevent cheating. [0]
>
> I think that output tagging doesn't provide a workable defense against the
> third party malleability via a deeper-than-the-CSV-delay reorg mentioned
> earlier; but requiring a non-NOINPUT sig does: you'd have to replace
> the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,
> and only the holders of the appropriate private key can do that.
At my point of view, if a NONINPUT sig is restricted and cannot be used to spend an "ordinary" 2-of-2, this is output tagging regardless of exact mechanism.
So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is still output tagging, as a cooperative close would still reveal that the output is not a 2-of-2.
Ideally, historical data of whether onchain coin was used in Lightning or not should be revealed as little as possible.
So in a cooperative close (which we hope, to be a common case), ideally the spend should look no different from an ordinary 2-of-2 spend.
Of course if the channel is published on Lightning, those who participated in Lightning at the time will learn of it, but at least the effort to remember this information is on those who want to remember this fact.
Now, this can be worked around by adding a "kickoff" transaction that spends the eltoo setup transaction.
The eltoo setup transaction outputs to an ordinary 2-of-2.
The kickoff outputs to an output that allows NOINPUT.
Then the rest of the protocol anchors on top of the kickoff.
The kickoff is kept offchain, until a non-cooperative close is needed.
Of course, as it is not a NOINPUT itself, it must need onchain fees attached to it.
This of course complicates fees, as we know.
Alternately maybe the kickoff can be signed with `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` so that it is possible to add a fee-paying UTXO to it.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-08 20:20 99% ` Matt Corallo
2019-03-10 0:43 99% ` Karl-Johan Alm
@ 2019-03-13 3:23 99% ` Anthony Towns
2019-03-14 1:07 99% ` Karl-Johan Alm
1 sibling, 1 reply; 123+ results
From: Anthony Towns @ 2019-03-13 3:23 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On Fri, Mar 08, 2019 at 03:20:49PM -0500, Matt Corallo via bitcoin-dev wrote:
> To make testing easier, it may make sense to keep the existing block header
> format (and PoW) and instead apply the signature rules to some field in the
> coinbase transaction.
Maybe make the signature be an optional addition to the header, so
that you can have a "light node" that doesn't download/verify sigs
and a full node that does? (So signatures just sign the traditional
80-byte header, and aren't included in the block's tx merkle root, and
the prevHash reflects the hash of the previous block's 80-byte header,
without the signature)
I think you could do that by adding a p2p service bit to say "send me
signatures if you have them / I can send you signatures", which changes
the p2p encoding of the header from (ver, prev, mrkl, time, bits, nonce)
to (ver, prev, mrkl, time, 0, nonce, bits, sig), and change header
processing to ignore headers from nodes that don't have the service
bit set?
If you did this, it might be a good idea to enforce including the previous
block's header signature in the current block's coinbase.
Cheers,
aj
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] More thoughts on NOINPUT safety
@ 2019-03-13 1:41 99% Anthony Towns
2019-03-13 6:41 99% ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-03-20 0:22 99% ` Rusty Russell
0 siblings, 2 replies; 123+ results
From: Anthony Towns @ 2019-03-13 1:41 UTC (permalink / raw)
To: bitcoin-dev; +Cc: lightning-dev
Hi all,
The following has some more thoughts on trying to make a NOINPUT
implementation as safe as possible for the Bitcoin ecosystem.
One interesting property of NOINPUT usage like in eltoo is that it
actually reintroduces the possibility of third-party malleability to
transactions -- ie, you publish transactions to the blockchain (tx A,
which is spent by tx B, which is spent by tx C), and someone can come
along and change A or B so that C is no longer valid). The way this works
is due to eltoo's use of NOINPUT to "skip intermediate states". If you
publish to the blockchain:
funding tx -> state 3 -> state 4[NOINPUT] -> state 5[NOINPUT] -> finish
then in the event of a reorg, state 4 could be dropped, state 5's
inputs adjusted to refer to state 3 instead (the sig remains valid
due to NOINPUT, so this can be done by anyone not just holders of some
private key), and finish would no longer be a valid tx (because the new
"state 5" tx has different inputs so a different txid, and finish uses
SIGHASH_ALL for the signature so committed to state 5's original txid).
There is a safety measure here though: if the "finish" transaction is
itself a NOINPUT tx, and has a a CSV delay (this is the case in eltoo;
the CSV delay is there to give time for a hypothetical state 6 to be
published), then the only way to have a problem is for some SIGHASH_ALL tx
that spends finish, and a reorg deeper than the CSV delay (so that state
4 can be dropped, state 5 and finish can be altered). Since the CSV delay
is chosen by the participants, the above is still a possible scenario
in eltoo, though, and it means there's some risk for someone accepting
bitcoins that result from a non-cooperative close of an eltoo channel.
Beyond that, I think NOINPUT has two fundamental ways to cause problems
for the people doing NOINPUT sigs:
1) your signature gets applied to a unexpectedly different
script, perhaps making it look like you've being dealing
with some blacklisted entity. OP_MASK and similar solves
this.
2) your signature is applied to some transaction and works
perfectly; but then someone else sends money to the same address
and reuses your prior signature to forward it on to the same
destination, without your consent
I still like OP_MASK as a solution to (1), but I can't convince myself that
the problem it solves is particularly realistic; it doesn't apply to
address blacklists, because for OP_MASK to make the signature invalid
the address has to be different, and you could just short circuit the
whole thing by sending money from a blacklisted address to the target's
personal address directly. Further, if the sig's been seen on chain
before, that's probably good evidence that someone's messing with you;
and if it hasn't been seen on chain before, how is anyone going to tell
it's your sig to blame you for it?
I still wonder if there isn't a real problem hiding somewhere here,
but if so, I'm not seeing it.
For the second case, that seems a little more concerning. The nightmare
scenario is maybe something like:
* naive users do silly things with NOINPUT signatures, and end up
losing funds due to replays like the above
* initial source of funds was some major exchange, who decide it's
cheaper to refund the lost funds than deal with the customer complaints
* the lost funds end up costing enough that major exchanges just outright
ban sending funds to any address capable of NOINPUT, which also bans
all taproot/schnorr addresses
That's not super likely to happen by chance: NOINPUT sigs will commit
to the value being spent, so to lose money, you (Alice) have to have
done a NOINPUT sig spending a coin sent to your address X, to someone
(Bob) and then have to have a coin with the exact same value sent from
someone else again (Carol) to your address X (or if you did a script
path NOINPUT spend, to some related address Y with a script that uses the same
key). But because it involves losing money to others, bad actors might
trick people into having it happen more often than chance (or well
written software) would normally allow.
That "nightmare" could be stopped at either the first step or the
last step:
* if we "tag" addresses that can be spent via NOINPUT then having an
exchange ban those addresses doesn't also impact regular
taproot/schnorr addresses, though it does mean you can tell when
someone is using a protocol like eltoo that might need to make use
of NOINPUT signatures. This way exchanges and wallets could simply
not provide NOINPUT capable addresses in the first place normally,
and issue very large warnings when asked to send money to one. That's
not a problem for eltoo, because all the NOINPUT-capable address eltoo
needs are internal parts of the protocol, and are spent automatically.
* or we could make it so NOINPUT signatures aren't replayable on
different transactions, at least by third parties. one way of doing
this might be to require NOINPUT signatures always be accompanied by a
non-NOINPUT signature (presumably for a different public key, or there
would be no point). This would prevent NOINPUT key-path spends, you'd
always have to use the taproot script-path for a NOINPUT signature so
that you could specify both public keys, and would also increase the
witness size due to needing two signatures and specifying an additional
public key -- this would increase the cost in fees by about 25% compared
to a plain key-path spend.
Conversely, this "nightmare" scenario *can't* be stopped if we allow
key-path spending of (untagged) taproot addresses with NOINPUT signatures:
exchanges could not distinguish such addresses from regular addresses, and
the only way to prevent the signature from applying to two tx's with the
same value and address would be for the sig to commit to info from the tx.
It seems like there's one big choice then:
- just ignore this concern
- drop NOINPUT from normal taproot key path spending
If we drop NOINPUT from taproot key path spending, then we can do NOINPUT
as a logically separate upgrade to taproot, rather than it needing to
be done at the same time. There's two ways we could do proceed:
- introduce a new NOINPUT-capable scriptPubKey format (ie, "tag"
NOINPUT spendable addresses); either a different length segwit v1
output, or a different segwit version entirely. Using version "16" in
this scenario might be appealing: we could reserve all v16 addresses
for "not intended to be used by humans directly" and update BIP 173
to say these aren't even something you should use bech32 to represent.
- alternatively, we could require every script to have a valid signature
that commits to the input. In that case, you could do eltoo with a
script like either:
<A> CHECKSIGVERIFY <B> CHECKSIG
or <P> CHECKSIGVERIFY <Q> CHECKSIG
where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
a key they both know the private key for. In the first case, Alice
would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
Bob would just do a SIGHASH_ALL sig with his own key. In the second,
Alice and Bob would share partial NOINPUT sigs of the tx with P, and
finish that when they wanted to publish.
This is a bit more costly than a key path spend: you have to reveal
the taproot point to do a script (+33B) and you have two signatures
instead of one (+65B) and you have to reveal two keys as well
(+66B), plus some script overhead. If we did the <P,Q> variant,
we could provide a "PUSH_TAPROOT_KEY" opcode that would just push
the taproot key to stack, saving 33B from pushing P as a literal,
but you can't do much better than that. All in all, it'd be about 25%
overhead in order to prevent cheating. [0]
I think that output tagging doesn't provide a workable defense against the
third party malleability via a deeper-than-the-CSV-delay reorg mentioned
earlier; but requiring a non-NOINPUT sig does: you'd have to replace
the non-NOINPUT sig to make state 5 spend state 3 instead of state 4,
and only the holders of the appropriate private key can do that.
In any event, if we get some experience with NOINPUT in practice, we can
reconsider whether NOINPUT key path spends are a good idea when we do
the next segwit version -- both cross-input signature aggregation and
graftroot will need an upgrade anyway.
(Also, note that, at least for eltoo, all of the above only applies to
non-cooperative closes: the funding tx's txid is known from the start,
so you can always arrange to spend it via SIGHASH_ALL, so it doesn't
need to be tagged, and a cooperative/mutual close of the channel will
still just be a simple key path spend)
Anyway, presented for your consideration.
FWIW, I don't have a strong opinion here yet, but:
- I'm still inclined to err on the side of putting more safety
measures in for NOINPUT, rather than fewer
- the "must have a sig that commits to the input tx" seems like it
should be pretty safe, not too expensive, and keeps taproot's privacy
benefits in the cases where you end up needing to use NOINPUT
Cheers,
aj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 2:23 99% ` Matt Corallo
@ 2019-03-13 1:38 99% ` Russell O'Connor
0 siblings, 0 replies; 123+ results
From: Russell O'Connor @ 2019-03-13 1:38 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]
Hi Matt,
On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> I think you may have misunderstood part of the motivation. Yes, part of
> the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly
> simplifying the theoretical operation of checksig operations (thus somewhat
> simplifying the implementation but also simplifying analysis of future
> changes, such as sighash-caching code).
>
I see. I was under the mistaken impression the concerns about of
OP_CODESEPARATOR was simply due to the vulnerability it induces.
I'll say it now then: Simplifying the theoretical operation of Bitcoin is
not a sufficient reason to make changes to the consensus rules, and it is
most certainly not a sufficient reason to remove usable op codes.
Had I understood that this was your motivation I would have presented my
opinion earlier. I understand that the OP_CODESEPARATOR vulnerability is
quite serious and making it non-standard while we address the problem is a
good idea (hence the reason why I never objected before now).
What I don't understand is why you feel that avoiding flushing the sigcache
is so critical that you are willing to go through a risky consensus change
just to achieve it? The sigcache is effectively flushed for each input of
a transaction anyways, so what's the big deal about flushing it during
Script execution as well?
> I think a key part of the analysis here is that no one I've spoken to (and
> we've been discussing removing it for *years*, including many attempts at
> coming up with reasons to keep it) is aware of any real proposals to use
> OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in
> invalid pubic keys is a long-discussed-and-implemented idea (despite it's
> discouragement, not to mention it appears on the chain in many places).
>
Well you've spoken to me now, and I believe I have given you good reasons
to keep it. We all used to think that OP_CODESEPARATOR was a useless
operation that no one in their right mind would ever use, but it turns out
that we were wrong. Lesson learned. We should be more humble about
considering these sorts of changes in the future because it seems we might
not understand Bitcoin as well as we think we do. At the very least I was
caught by surprise by the utility of OP_CODESEPARATOR.
You misunderstand my point regarding invalid public keys. My point is that
if no one has spoken up about the invalid public key issue on this mailing
list, something that we know really does affects people, why do you expect
that people would have spoken up about OP_CODESEPARATATOR affecting them?
> It would end up being a huge shame to have all the OP_CORESEPARATOR mess
> left around after all the effort that has gone into removing it for the
> past few years, especially given the stark difference in visibility of a
> fork when compared to a standardness change.
>
> As for your specific proposal of increasing the weight of anything that
> has an OP_CODESEPARATOR in it by the cost of an additional (simple) input,
> this doesn't really solve the issue. After all, if we're assuming some user
> exists who has been using sending money, unspent, to scripts with
> OP_CODESEPARATOR to force signatures to commit to whether some other
> signature was present and who won't see a (invariably media-covered)
> pending soft-fork in time to claim their funds, we should also assume such
> a user has pre-signed transactions which are time-locked and claim a number
> of inputs and have several paths in the script which contain
> OP_CODESEPARATOR, rendering their transcription invalid.
>
Agreed, that's why we will want to not simply count the OP_CODESEPARATORS,
but rather count the maximum number of OP_CODESEPARATORS that can be
executed through the any of the various possible OP_IF branches. Adding
this sort of control-flow analysis is a pretty simple. It just requires a
small stack of pairs of numbers and linear traversal through the Script.
This sort of OP_IF control flow analysis ought to have been done for
counting CHECKSIG operations, but unfortunately it is too late for that
now. I could prototype the sort of analysis I have in mind if you think
that would be helpful.
In fact, it is really alternating uses of OP_CODESEPARATOR and CheckSig
operations that is problematic, so it is probably worth attempting to count
these pairs rather than just OP_CODESEPARATORS.
[-- Attachment #2: Type: text/html, Size: 5502 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 22:39 99% ` Jacob Eliosoff
2019-03-13 0:54 99% ` Gregory Maxwell
@ 2019-03-13 1:34 99% ` Russell O'Connor
1 sibling, 0 replies; 123+ results
From: Russell O'Connor @ 2019-03-13 1:34 UTC (permalink / raw)
To: Jacob Eliosoff; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
On Tue, Mar 12, 2019 at 6:39 PM Jacob Eliosoff <jacob.eliosoff@gmail•com>
wrote:
> Also, if future disabling isn't the point of making a tx type like
> OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
> support of these oddball features, what do we gain by making them hard to
> use/mine?
>
The purpose of making OP_CODESEPARATOR non-standard was to partly mitigate
the risk of the vulnerability that OP_CODESEPARATOR induces while we
consider how to patch it.
>
[-- Attachment #2: Type: text/html, Size: 1008 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 15:57 99% ` Russell O'Connor
@ 2019-03-13 1:34 99% ` Russell O'Connor
0 siblings, 0 replies; 123+ results
From: Russell O'Connor @ 2019-03-13 1:34 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4666 bytes --]
Hi Matt,
(I moved your comment to this thread, where I think it is more relevant).
This is a fair point. I concede that as far as Sighash Type Byte is
concerned, the type of change is fairly similar to BIP 68 (though I don't
think the argument applies to OP_CODESEPARATOR).
I might rephrase what you say as "invalidating otherwise-unusable bits of
the protocol". I don't quite know the right phrasing that captures both
the insecure and redundant aspects of the protocol. I'm willing to accept
that nSequence numbers (as they originally were), NOP1-NOP10 and these
extra sighash types can all be classified as redundant aspects of the
Bitcoin protocol.
I still think the alternative proposal of caching the sha256 midstate is
the better choice. We should strive to avoid changing the consensus rules
when we have reasonable alternatives to achieve our goals. However, I now
see that this proposal isn't entirely unprecedented.
On Tue, Mar 12, 2019 at 5:08 PM Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream•io>
> wrote:
> > Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
On Fri, Mar 8, 2019 at 10:57 AM Russell O'Connor <roconnor@blockstream•io>
wrote:
> On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo•com>
> wrote:
>
>> I can't say I'm particularly married to this idea (hence the alternate
>> proposal in the original email), but at the same time the lack of
>> existing transactions using these bits (and the redundancy thereof -
>> they don't *do* anything special) seems to be pretty strong indication
>> that they are not in use. One could argue a similarity between these
>> bits and OP_NOPs - no one is going to create transactions that require
>> OP_NOP execution to be valid as they are precisely the kind of thing
>> that may get soft-forked to have a new meaning. While the sighash bits
>> are somewhat less candidates for soft-forking,
>
>
> I don't think "somewhat less candidates for soft-forking" is a fair
> description. These bits essentially unsuitable for soft-forking within
> legacy Script.
>
> I don't think "someone
>> may have shoved random bits into parts of their
>> locked-for-more-than-a-year transactions" is sufficient reason to not
>> soft-fork something out.
>
>
> I disagree. It is sufficient.
>
> When was the last time Bitcoin soft-forked out working transactions that
> sent funds from securely held UTXOs to securely held UTXOs (aside from
> those secured by Scripts using the reserved OP_NOP1-OP_NOP10)? AFAIK it
> has never occurred since the time of Satoshi, even for the most
> hypothetical of transactions. It is my understanding is that Bitcoin Core
> would never do such a thing unless the security of Bitcoin protocol itself
> was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
> Core would only soft-fork out the minimal amount necessary to safely
> diffuse such a threat.
>
> Since the above soft-fork isn't addressing addressing any such threat
> (that I'm aware of), and could hypothetically destroy other people money,
> it crosses a line I thought we were never supposed to cross.
>
>>
>> Obviously, actually *seeing* it used in
>> practice or trying to fork them out in a fast manner would be
>> unacceptable, but neither is being proposed here.
>>
>
> Perhaps you don't see them in used in the blockchain because the users
> trying to use them are caught up by the fact they they are not being
> relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
> difficulty redeeming them.
> You cannot first make transactions non-standard and then use the fact that
> you don't see them being used to justify a soft-fork.
>
> I know of users who have their funds tied up due to other changes in
> Bitcoin Core's default relay policy. I believe they waiting for their
> funds to become valuable enough to go through the trouble of having them
> directly mined. Shall we now permanently destroy their funds too, before
> they have a chance to get their transactions mined?
>
>
[-- Attachment #2: Type: text/html, Size: 6314 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 22:39 99% ` Jacob Eliosoff
@ 2019-03-13 0:54 99% ` Gregory Maxwell
2019-03-13 1:34 99% ` Russell O'Connor
1 sibling, 0 replies; 123+ results
From: Gregory Maxwell @ 2019-03-13 0:54 UTC (permalink / raw)
To: Jacob Eliosoff, Bitcoin Protocol Discussion
On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Also, if future disabling isn't the point of making a tx type like OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite support of these oddball features, what do we gain by making them hard to use/mine?
It makes them infeasible to abuse without miner assistance... which
doesn't fix them, but in practice greatly reduces the risk they create
and allows efforts improving the system to be allocated to other more
pressing issues.
> I see questions like "Is it possible someone's existing tx relies on this?" as overly black-and-white. We all agree it's possible: the question is how likely, vs the harms of continued support - including not just security risks but friction on other useful changes, safety/correctness analyses, etc.
Don't underestimate the value of taking a principled position that
*strongly* avoids confiscating user funds. Among many other benefits
being cautious about this avoids creating a situation where people are
demanding human intervention to restore improperly lost funds and the
associated loss of effort that would come from the effort wasted
debating that.
It's true that most other cryptocurrencies proceed without any such
caution or care-- e.g. bcash recently confiscating all funds
accidentally sent to segwit using Bitcoin addresses because of their
reckless address aliasing as a result of promoting the standardness
rule that made those txn non-standard before segwit without
considering the implications--, but they're not the standard we should
hold Bitcoin to...
> Again, the point being not to throw caution to the wind, but that a case like this where extensive research unearthed zero users, is taking caution too far.
All things in balance: Codeseperator and its related costs are not an
especially severe problem. The arguments on both side of this point
have enough merit to be worth discussing, at least.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-12 21:08 99% ` Matt Corallo
@ 2019-03-12 22:39 99% ` Jacob Eliosoff
2019-03-13 0:54 99% ` Gregory Maxwell
2019-03-13 1:34 99% ` Russell O'Connor
0 siblings, 2 replies; 123+ results
From: Jacob Eliosoff @ 2019-03-12 22:39 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
Also, if future disabling isn't the point of making a tx type like
OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
support of these oddball features, what do we gain by making them hard to
use/mine?
I see questions like "Is it possible someone's existing tx relies on this?"
as overly black-and-white. We all agree it's possible: the question is how
likely, vs the harms of continued support - including not just security
risks but friction on other useful changes, safety/correctness analyses,
etc.
It is so easy to say stuff like this when one's own money isn't what is at
risk.
Stepping back for a second here: I dispute this framing. My money *is* at
risk, because the value of my bitcoins depends on adoption and feature
growth. And I've long viewed an absolutist, actual-known-user-indifferent
approach to backwards compatibility as the #1 impediment to Bitcoin's
adoption and growth.
Again, the point being not to throw caution to the wind, but that a case
like this where extensive research unearthed zero users, is taking caution
too far.
On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream•io>
> wrote:
> > Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3321 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-12 17:08 99% ` Andreas Schildbach
@ 2019-03-12 22:14 99% ` Gregory Maxwell
2019-03-13 14:29 99% ` Andreas Schildbach
2019-03-13 14:41 99% ` Oscar Guindzberg
0 siblings, 2 replies; 123+ results
From: Gregory Maxwell @ 2019-03-12 22:14 UTC (permalink / raw)
To: Andreas Schildbach, Bitcoin Protocol Discussion
On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> These two cases are understood and handled by current code. Generally
> the idea is take reject messages serious, but don't overrate the lack
> of. Luckily, network confirmations fill the gap. (Yes, a timeout is
I'd like to better understand this, but it would be easier to just
read the code than ask a bunch of questions. I tried looking for the
handling of reject messages in Android Bitcoin Wallet and BitcoinJ
and didn't really find and handling other than logging exceptions.
Would you mind giving me a couple pointers to where in the code
they're handled?
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-09 18:29 99% ` Russell O'Connor
2019-03-10 3:25 99% ` Jacob Eliosoff
@ 2019-03-12 21:08 99% ` Matt Corallo
2019-03-12 22:39 99% ` Jacob Eliosoff
1 sibling, 1 reply; 123+ results
From: Matt Corallo @ 2019-03-12 21:08 UTC (permalink / raw)
To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion
Note that even your carve-outs for OP_NOP is not sufficient here - if you were using nSequence to tag different pre-signed transactions into categories (roughly as you suggest people may want to do with extra sighash bits) then their transactions could very easily have become un-realistically-spendable. The whole point of soft forks is that we invalidate otherwise-unused bits of the protocol. This does not seem inconsistent with the proposal here.
> On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream•io> wrote:
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that invalidated transactions that send secured inputs to secured outputs (excluding uses of OP_NOP1-OP_NOP10).
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-08 0:52 99% ` Gregory Maxwell
@ 2019-03-12 17:08 99% ` Andreas Schildbach
2019-03-12 22:14 99% ` Gregory Maxwell
0 siblings, 1 reply; 123+ results
From: Andreas Schildbach @ 2019-03-12 17:08 UTC (permalink / raw)
To: bitcoin-dev
(Posting again, since my previous reply didn't appear)
On 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:
> That is already required because even in the presence of perfectly
> honest and cooperative hosts reject messages at most can only tell you
> about first-hop behaviour. It won't even tell you if the transaction
> was ever even attempted to be sent to a next hop. So alternative
> handling must be provided and must be reliable for the software to
> work at all regardless of reject messages.
>
> Rejection causes were also not stable or reliable because the validity
> criteria cannot generally be tested independently. For example, if a
> transaction is queued due to missing a parent it isn't rejected
> because missing the parent is often a temporary issue, but its feerate
> cannot be measured without the parent. Later, when the parent is
> obtained, the transaction can then be rejected due to feerate-- but no
> reject is sent then.
These two cases are understood and handled by current code. Generally
the idea is take reject messages serious, but don't overrate the lack
of. Luckily, network confirmations fill the gap. (Yes, a timeout is
still useful. But at least it almost never happens.)
> Similarly, the error state detected for things like invalid signatures
> are often not very useful. The software knows that script execution
> returned false, but in the general case _why_ it returned false is not
> clear, and a straightforward high performance validation
> implementation doesn't necessarily yield a good way of figuring out
> and propagating up that information. (I think invalid signatures end
> up returning a stack-nonempty state from validation currently, as an
> example of that).
Nevertheless, it has been proven as useful in debugging (just recently
when I implemented the witness signature hash in bitcoinj). I think
Wilmer Paulino summed up this point quite nicely in his reply to this
thread.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 18:24 99% ` Moral Agent
@ 2019-03-12 7:34 99% ` LORD HIS EXCELLENCY JAMES HRMH
0 siblings, 0 replies; 123+ results
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-03-12 7:34 UTC (permalink / raw)
To: Moral Agent, Bitcoin Protocol Discussion, Moral Agent
[-- Attachment #1: Type: text/plain, Size: 6062 bytes --]
I have not seen all of the emails in reply come through on the mailing list, I am sure it is always that way. There are a couple to reply to, replies indented>:
On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
What about putting it in a deprecated state for some time. Adjust the transaction weight so using the op code is more expensive (10x, 20x?) and get the word out that it will be removed in the future.
You could even have nodes send a reject code with the message “OP_CODESEPARATOR is depcrecated.”
>Yes, that sort of thing, widely publicised. Positive publicity is a good thing.
From: Moral Agent via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>>
Sent: Monday, 11 March 2019 5:24 AM
To: LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to the soft fork activation standard, with weight penalties as appropriate, so there would be no difficulty spending them before the cutoff?
>Yes, precisely that sort of thing so that there is no difficulty spending the UTXOs before the cutoff, preferably we would never prevent spending existing valid transactions in the blockchain, also not only to morally discourage the creation of new transactions with OP_CODESEAPRATOR but to physically prevent them if possible. At the minimum, 10 years of depreciated notifications should be enough for anyone but pre-signed lock-timed transactions may be a different matter. Do we currently allow them to be mined and the UTXO's not valid to be spent until n height/time? We should.
On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
Opinion: Lock in a blockheight to get rid of it 10 years in the future. Use it as press that Bitcoin is going to lose $1,000,000 if some mystery person does not put their transaction through by then, try for global presses. Use the opportunity to get rid of it while you are able. Once gazetted anything is public knowledge.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-bounces@lists•linuxfoundation.org> <bitcoin-dev-bounces@lists.linuxfoundation.org<mailto:bitcoin-dev-bounces@lists•linuxfoundation.org>> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>>
Sent: Saturday, 9 March 2019 7:14 AM
To: Sjors Provoost
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
Aside from the complexity issues here, note that for a user to be adversely affect, they probably have to have pre-signed lock-timed transactions. Otherwise, in the crazy case that such a user exists, they should have no problem claiming the funds before activation of a soft-fork (and just switching to the swgwit equivalent, or some other equivalent scheme). Thus, adding additional restrictions like tx size limits will equally break txn.
> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost.nl<mailto:sjors@sprovoost•nl>> wrote:
>
>
>> (1) It has been well documented again and again that there is desire to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in non-segwit scripts represents a rather significant vulnerability in Bitcoin today, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR's specific construction, with no successes as of yet. I strongly, strongly disagree that the highly-unlikely remote possibility that someone created something before which could be rendered unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
>>
>>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases the transactions weight suitably as to temper the vulnerability caused by it. Alternatively there could be some sort of limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be executed per script, but that would require an argument as to why exceeding that limit isn't reasonable.
>>
>> You could equally argue, however, that any such limit could render some moderately-large transaction unspendable, so I'm somewhat skeptical of this argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined is rather difficult in any case.
>
> Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
>
> Sjors
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 10602 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application
2019-03-12 5:53 99% ` Omar Shibli
@ 2019-03-12 7:05 99% ` ZmnSCPxj
0 siblings, 0 replies; 123+ results
From: ZmnSCPxj @ 2019-03-12 7:05 UTC (permalink / raw)
To: Omar Shibli, Bitcoin Protocol Discussion
Good morning Omar,
BIP32 includes this text:
> In case parse_256(I_L) >= n or K_i is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.
This seems to suggest that it is possible for an attacker with sufficient compute power to find two contracts whose derivations alias each other if we "proceed with the next value for i".
More generally, have you considered the possibility of multiple separate contracting systems?
It may be possible to have a particular sequence of bytes that has a valid interpretation under one contracting system, that also has a valid interpretation under another contracting system.
I bring this up here: https://github.com/rgb-org/spec/issues/61
and: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016354.html
It would then be possible to fool some victim into thinking it has committed to some innocuous contract in one contracting system, only to reveal later that the same sequence of bytes encoding that innocuous contract also corresponds to a more vicious contract in another contracting system.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, March 12, 2019 1:53 PM, Omar Shibli via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Dear Gregory,
>
> First of all, I would like to express my deep appreciation to your entire craft in the FOSS ecosystem, specially in Bitcoin, even more In Blockstream.
> I think you are a brilliant engineer and very principled leader. your efforts are an inspiration for many, a truly enduring forever mark in history of FOSS.
>
> I've submitted fixes to your concerns here:
> https://github.com/bitcoin/bips/commit/b63ed0e17e872b7e7b8634591b0ddfa3dedfdc73#diff-deacf3a22d788a10ce12e4d92ee814ff
>
> Would appreciate your review.
>
> On other note, I still think that this security fix is redundant, I believe CKD function (BIP32) does encapsulate sufficient amount of entropy, but due to lack of formal knowledge and assistance, I've not managed to get formal proof, so I fallback'ed to add this patch for security reasons.
>
> Best regards,
> Omar
>
> On Fri, Sep 1, 2017 at 10:16 AM Omar Shibli <omarshib@gmail•com> wrote:
>
> > Hello Gregory,
> >
> > Thanks for you feedback.
> >
> > The BIP has been updated to explicitly specify the multiparty key derivation scheme which hopefully addresses your concerns.
> >
> > Please have a look at the updated draft of the BIP at the link below:
> >
> > https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
> >
> > Any feedback is highly appreciated.
> >
> > Regards,
> > Omar
> >
> > On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <omarshib@gmail•com> wrote:
> >
> > > Thank you for your time Gregory, I really appreciate that.
> > >
> > > What we are describing here is a method to embed cryptographic signatures into a public key based on HD Wallets - BIP32.
> > > In a practical application, we should have two cryptographic signatures from both sides, I don't think in that case your scenario would be an issue.
> > >
> > > More specifically in our application, we do the following construction:
> > >
> > > contract base: m/200'/0'/<contract_number>'
> > > payment base (merchant commitment): contract_base/<merchant_contract_signature>
> > > payment address (customer commitment): contract_base/<merchant_contract_signature>/<customer_contract_signature>
> > >
> > > payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer.
> > >
> > > In terms of durability, our app is pretty simple at this point, we don't store anything, we let customer download and manage the files.
> > >
> > > I will update the BIP to address your concerns.
> > >
> > > On Tue, Aug 15, 2017 at 8:12 AM, Gregory Maxwell <greg@xiph•org> wrote:
> > >
> > > > This construction appears to me to be completely insecure.
> > > >
> > > > Say my pubkey (the result of the derivation path) is P.
> > > >
> > > > We agree to contract C1. A payment is made to P + G*H(C1).
> > > >
> > > > But in secret, I constructed contract C2 and pubkey Q and set P = Q + G*H(C2).
> > > >
> > > > Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert
> > > > it was in act a payment to P' + G*H(C2). (P' is simply Q + G*H(C1))
> > > >
> > > > I don't see anything in the proposal that addresses this. Am I missing it?
> > > >
> > > > The applications are also not clear to me, and it doesn't appear to
> > > > address durability issues (how do you avoid losing your funds if you
> > > > lose the exact contract?).
> > > >
> > > > On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev
> > > > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > > > Hey all,
> > > > >
> > > > > A lot of us familiar with the pay to contract protocol, and how it uses
> > > > > cleverly the homomorphic property of elliptic curve encryption system to
> > > > > achieve it.
> > > > > Unfortunately, there is no standard specification on how to conduct such
> > > > > transactions in the cyberspace.
> > > > >
> > > > > We have developed a basic trade finance application that relies on the
> > > > > original idea described in the Homomorphic Payment Addresses and the
> > > > > Pay-to-Contract Protocol paper, yet we have generalized it and made it BIP43
> > > > > complaint.
> > > > >
> > > > > We would like to share our method, and get your feedback about it, hopefully
> > > > > this effort will result into a standard for the benefit of the community.
> > > > >
> > > > > Abstract idea:
> > > > >
> > > > > We define the following levels in BIP32 path.
> > > > > m / purpose' / coin_type' / contract_id' / *
> > > > >
> > > > > contract_id is is an arbitrary number within the valid range of indices.
> > > > >
> > > > > Then we define, contract base as following prefix:
> > > > > m / purpose' / coin_type' / contract_id'
> > > > >
> > > > > contract commitment address is computed as follows:
> > > > > hash document using cryptographic hash function of your choice (e.g. blake2)
> > > > > map hash to partial derivation path
> > > > > Convert hash to binary array.
> > > > > Partition the array into parts, each part length should be 16.
> > > > > Convert each part to integer in decimal format.
> > > > > Convert each integer to string.
> > > > > Join all strings with slash `/`.
> > > > > compute child public key by chaining the derivation path from step 2 with
> > > > > contract base:
> > > > > m/<contract_base>/<hash_derivation_path>
> > > > > compute address
> > > > > Example:
> > > > >
> > > > > master private extended key:
> > > > > xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
> > > > > coin type: 0
> > > > > contract id: 7777777
> > > > >
> > > > > contract base computation :
> > > > >
> > > > > derivation path:
> > > > > m/999'/0'/7777777'
> > > > > contract base public extended key:
> > > > > xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
> > > > >
> > > > > Contract content:
> > > > > foo
> > > > >
> > > > > Contract sha256 signature:
> > > > > 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
> > > > >
> > > > > Contract partial derivation path:
> > > > > 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
> > > > >
> > > > > Contract commitment pub key path:
> > > > > m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
> > > > > or
> > > > > <contract_base_extended_pub_key>/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
> > > > >
> > > > > Contract commitment pub key:
> > > > > xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
> > > > >
> > > > > Contract commitment address:
> > > > > 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
> > > > >
> > > > >
> > > > > You can find the full BIP draft in the following link:
> > > > > https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
> > > > >
> > > > >
> > > > > Regards,
> > > > > Omar
> > > > >
> > > > > _______________________________________________
> > > > > bitcoin-dev mailing list
> > > > > bitcoin-dev@lists•linuxfoundation.org
> > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > >
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application
@ 2019-03-12 5:53 99% ` Omar Shibli
2019-03-12 7:05 99% ` ZmnSCPxj
0 siblings, 1 reply; 123+ results
From: Omar Shibli @ 2019-03-12 5:53 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6814 bytes --]
Dear Gregory,
First of all, I would like to express my deep appreciation to your entire
craft in the FOSS ecosystem, specially in Bitcoin, even more In Blockstream.
I think you are a brilliant engineer and very principled leader. your
efforts are an inspiration for many, a truly enduring forever mark in
history of FOSS.
I've submitted fixes to your concerns here:
https://github.com/bitcoin/bips/commit/b63ed0e17e872b7e7b8634591b0ddfa3dedfdc73#diff-deacf3a22d788a10ce12e4d92ee814ff
Would appreciate your review.
On other note, I still think that this security fix is redundant, I believe
CKD function (BIP32) does encapsulate sufficient amount of entropy, but due
to lack of formal knowledge and assistance, I've not managed to get formal
proof, so I fallback'ed to add this patch for security reasons.
Best regards,
Omar
On Fri, Sep 1, 2017 at 10:16 AM Omar Shibli <omarshib@gmail•com> wrote:
> Hello Gregory,
>
> Thanks for you feedback.
>
> The BIP has been updated to explicitly specify the multiparty key
> derivation scheme which hopefully addresses your concerns.
>
> Please have a look at the updated draft of the BIP at the link below:
>
>
> https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
>
> Any feedback is highly appreciated.
>
> Regards,
> Omar
>
> On Tue, Aug 15, 2017 at 7:40 PM, omar shibli <omarshib@gmail•com> wrote:
>
>> Thank you for your time Gregory, I really appreciate that.
>>
>> What we are describing here is a method to embed cryptographic signatures
>> into a public key based on HD Wallets - BIP32.
>> In a practical application, we should have two cryptographic signatures
>> from both sides, I don't think in that case your scenario would be an issue.
>>
>> More specifically in our application, we do the following construction:
>>
>> contract base: m/200'/0'/<contract_number>'
>> payment base (merchant commitment):
>> contract_base/<merchant_contract_signature>
>> payment address (customer commitment):
>> contract_base/<merchant_contract_signature>/<customer_contract_signature>
>>
>> payment address funds could be reclaimed only if the
>> customer_contract_signature is provided by the customer.
>>
>> In terms of durability, our app is pretty simple at this point, we don't
>> store anything, we let customer download and manage the files.
>>
>> I will update the BIP to address your concerns.
>>
>> On Tue, Aug 15, 2017 at 8:12 AM, Gregory Maxwell <greg@xiph•org> wrote:
>>
>>> This construction appears to me to be completely insecure.
>>>
>>>
>>> Say my pubkey (the result of the derivation path) is P.
>>>
>>> We agree to contract C1. A payment is made to P + G*H(C1).
>>>
>>> But in secret, I constructed contract C2 and pubkey Q and set P = Q +
>>> G*H(C2).
>>>
>>> Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert
>>> it was in act a payment to P' + G*H(C2). (P' is simply Q + G*H(C1))
>>>
>>> I don't see anything in the proposal that addresses this. Am I missing
>>> it?
>>>
>>> The applications are also not clear to me, and it doesn't appear to
>>> address durability issues (how do you avoid losing your funds if you
>>> lose the exact contract?).
>>>
>>>
>>>
>>>
>>> On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> > Hey all,
>>> >
>>> > A lot of us familiar with the pay to contract protocol, and how it uses
>>> > cleverly the homomorphic property of elliptic curve encryption system
>>> to
>>> > achieve it.
>>> > Unfortunately, there is no standard specification on how to conduct
>>> such
>>> > transactions in the cyberspace.
>>> >
>>> > We have developed a basic trade finance application that relies on the
>>> > original idea described in the Homomorphic Payment Addresses and the
>>> > Pay-to-Contract Protocol paper, yet we have generalized it and made it
>>> BIP43
>>> > complaint.
>>> >
>>> > We would like to share our method, and get your feedback about it,
>>> hopefully
>>> > this effort will result into a standard for the benefit of the
>>> community.
>>> >
>>> > Abstract idea:
>>> >
>>> > We define the following levels in BIP32 path.
>>> > m / purpose' / coin_type' / contract_id' / *
>>> >
>>> > contract_id is is an arbitrary number within the valid range of
>>> indices.
>>> >
>>> > Then we define, contract base as following prefix:
>>> > m / purpose' / coin_type' / contract_id'
>>> >
>>> > contract commitment address is computed as follows:
>>> > hash document using cryptographic hash function of your choice (e.g.
>>> blake2)
>>> > map hash to partial derivation path
>>> > Convert hash to binary array.
>>> > Partition the array into parts, each part length should be 16.
>>> > Convert each part to integer in decimal format.
>>> > Convert each integer to string.
>>> > Join all strings with slash `/`.
>>> > compute child public key by chaining the derivation path from step 2
>>> with
>>> > contract base:
>>> > m/<contract_base>/<hash_derivation_path>
>>> > compute address
>>> > Example:
>>> >
>>> > master private extended key:
>>> >
>>> xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
>>> > coin type: 0
>>> > contract id: 7777777
>>> >
>>> > contract base computation :
>>> >
>>> > derivation path:
>>> > m/999'/0'/7777777'
>>> > contract base public extended key:
>>> >
>>> xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>>> >
>>> > Contract content:
>>> > foo
>>> >
>>> > Contract sha256 signature:
>>> > 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
>>> >
>>> > Contract partial derivation path:
>>> >
>>> 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>>> >
>>> > Contract commitment pub key path:
>>> >
>>> m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>>> > or
>>> >
>>> <contract_base_extended_pub_key>/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>>> >
>>> > Contract commitment pub key:
>>> >
>>> xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>>> >
>>> > Contract commitment address:
>>> > 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
>>> >
>>> >
>>> > You can find the full BIP draft in the following link:
>>> >
>>> https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
>>> >
>>> >
>>> > Regards,
>>> > Omar
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists•linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>>
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 9643 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-10 17:01 99% ` David A. Harding
@ 2019-03-12 5:44 99% ` Karl-Johan Alm
0 siblings, 0 replies; 123+ results
From: Karl-Johan Alm @ 2019-03-12 5:44 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
Hello all,
I started writing code that puts the signature in the coinbase
transaction similar to the witness commitment, and encountered a
potential issue. See inline comments below.
On Mon, Mar 11, 2019 at 2:02 AM David A. Harding <dave@dtrt•org> wrote:
>
> On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> > Keeping the PoW rule and moving the signature would mean DoS attacks
> > would be trivial as anyone could mine blocks without a signature in
> > them
>
> Sure, but anyone could also just connect their lite client to a trusted
> node (or nodes) on signet. The nodes would protect the clients from
> missing/invalid-signature DoS and the clients wouldn't have to implement
> any more network-level changes than they need to now for testnet.
>
> For people who don't want to run their own trusted signet nodes, there
> could be a list of signet nodes run by well-known Bitcoiners (and this
> could even be made available via a simple static dns seeder lite clients
> could use).
This sounds sensible. One issue here is that the "proper" signer will
be orders of magnitude slower than the fake miner when constructing
blocks. Because the signature is now stuffed into the coinbase
transaction, it becomes a part of the block merkle root, so the true
miner now has to (1) create a block, (2) sign it, (3) check if hash <
target, (4) nudge nonce if not, and then repeat from step (2) until it
finds a valid block. I.e. it has to sign the entire thing for every
nonce.
> This post from Maxwell could be the idea Corallo is describing:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html
That's pretty cool. The plan I had was to set up some simple interface
where anyone could "order" reorgs whenever they wanted to. It would
reorg/double spend people on request (e.g. "send 1 signetcoin to
signet1qfoobar and then double spend it in a reorg 3 blocks deep") and
so on.
With that kind of tool, I don't know if you need the alternate signing
approach you described, but I could be mistaken.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
2019-03-11 16:01 99% [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB Alistair Mann
@ 2019-03-12 4:14 99% ` ZmnSCPxj
2019-03-17 16:11 99% ` Alistair Mann
2019-03-17 20:27 99% ` Alistair Mann
1 sibling, 1 reply; 123+ results
From: ZmnSCPxj @ 2019-03-12 4:14 UTC (permalink / raw)
To: Alistair Mann, Bitcoin Protocol Discussion
Good morning Alistair,
> It won't have escaped notice that the HTLB script can be wholly written in an
> HTLC script: 'HTLB over HTLC', however there are additional reasons to
> consider HTLB for a separate BIP:
I believe there is indeed an important usecase for HTLB over HTLC, which is to improve the anonymity set.
An HTLB over HTLC would be indistinguishable onchain from other uses of HTLC; assuming that HTLCs have other uses, this is a (small?) plus to privacy.
Note that the redundant <digest> would have to be given by Alice to Bob, since using a standardized one will also reveal use of HTLB over HTLC instead of hiding it among other HTLC UTXOs.
Another thing to improve privacy would be to apply the Funding Transaction pattern: https://zmnscpxj.github.io/offchain/generalized.html
In such a case, Alice would prepare two transactions, one which pays to a 2-of-2, and another which spends that 2-of-2 and pays to an HTLB (over HTLC).
Alice would provide the second transaction to Bob, who must return a valid signature for that transaction, then place the first transaction onchain.
Then the protocol resumes as normal.
If Alice and Bob both agree that the bond can be returned to Alice, then they recreate the second transaction as a normal spend from 2-of-2 to a flat P2PKH of Alice (or whatever address Alice desires), obscuring that HTLB was used at all.
The Funding Transaction Pattern is applicable to all constructions that have a fixed participant set, and is effectively gotten "for free" with Taproot (the requirement is the "Taproot assumption"), but is available now even without Taproot.
Regards,
ZmnSCPxj
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-11 19:15 99% ` Russell O'Connor
@ 2019-03-12 2:23 99% ` Matt Corallo
2019-03-13 1:38 99% ` Russell O'Connor
0 siblings, 1 reply; 123+ results
From: Matt Corallo @ 2019-03-12 2:23 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]
I think you may have misunderstood part of the motivation. Yes, part of the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the theoretical operation of checksig operations (thus somewhat simplifying the implementation but also simplifying analysis of future changes, such as sighash-caching code).
I think a key part of the analysis here is that no one I've spoken to (and we've been discussing removing it for *years*, including many attempts at coming up with reasons to keep it) is aware of any real proposals to use OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pubic keys is a long-discussed-and-implemented idea (despite it's discouragement, not to mention it appears on the chain in many places).
It would end up being a huge shame to have all the OP_CORESEPARATOR mess left around after all the effort that has gone into removing it for the past few years, especially given the stark difference in visibility of a fork when compared to a standardness change.
As for your specific proposal of increasing the weight of anything that has an OP_CODESEPARATOR in it by the cost of an additional (simple) input, this doesn't really solve the issue. After all, if we're assuming some user exists who has been using sending money, unspent, to scripts with OP_CODESEPARATOR to force signatures to commit to whether some other signature was present and who won't see a (invariably media-covered) pending soft-fork in time to claim their funds, we should also assume such a user has pre-signed transactions which are time-locked and claim a number of inputs and have several paths in the script which contain OP_CODESEPARATOR, rendering their transcription invalid.
Matt
> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (overhead for varints) = 572ish bytes should be enough to completely eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transactions without the need to remove it ever. I think it is worth attempting to be a bit more clever than such a blunt rule, but it would be much better than eliminating OP_CODESEPARATOR within P2SH entirely.
>
> Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulnerability associated with it.
>
>> On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> What about putting it in a deprecated state for some time. Adjust the transaction weight so using the op code is more expensive (10x, 20x?) and get the word out that it will be removed in the future.
>>
>> You could even have nodes send a reject code with the message “OP_CODESEPARATOR is depcrecated.”
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 4246 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 18:28 99% ` Dustin Dettmer
@ 2019-03-11 19:15 99% ` Russell O'Connor
2019-03-12 2:23 99% ` Matt Corallo
0 siblings, 1 reply; 123+ results
From: Russell O'Connor @ 2019-03-11 19:15 UTC (permalink / raw)
To: Dustin Dettmer, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size
limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few
more (overhead for varints) = 572ish bytes should be enough to completely
eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH
transactions without the need to remove it ever. I think it is worth
attempting to be a bit more clever than such a blunt rule, but it would be
much better than eliminating OP_CODESEPARATOR within P2SH entirely.
Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal
is to eliminate the vulnerability associated with it.
On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> What about putting it in a deprecated state for some time. Adjust the
> transaction weight so using the op code is more expensive (10x, 20x?) and
> get the word out that it will be removed in the future.
>
> You could even have nodes send a reject code with the message
> “OP_CODESEPARATOR is depcrecated.”
>
[-- Attachment #2: Type: text/html, Size: 1485 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 3:25 99% ` Jacob Eliosoff
@ 2019-03-11 17:49 99% ` Russell O'Connor
0 siblings, 0 replies; 123+ results
From: Russell O'Connor @ 2019-03-11 17:49 UTC (permalink / raw)
To: Jacob Eliosoff; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3050 bytes --]
Hi Jacob,
> Huh?! The whole point of non-standardness in this context is to (a) make
>>> soft-forking something out safer by derisking miners not upgrading right
>>> away and (b) signal something that may be a candidate for soft-forking
>>> out so that we get feedback. Who is getting things disabled who isn't
>>> bothering to *tell* people that their use-case is being hurt?!
>>>
>>
>> People have told me that they are hurt by some other non-standardness
>> changes and I understand that they have been sitting on those funds for
>> years. Maybe they don't realize their is some place to complain or maybe
>> they think there must be a good reason why they are not allowed to do what
>> they were previously allowed to do. Perhaps others don't want to risk
>> blowing their pseudonymity. Perhaps they think that attempting to undo
>> some of these non-standardness changes is futile. I can bring up the
>> specific cases I've encountered in a new thread if you think it is
>> worthwhile.
>>
>
> Like Matt, I understand non-standardness to be specifically for making a
> transaction type more difficult to set the stage for a future disabling.
>
> If anyone is actually harmed by this change, let them at least speak up
> pseudonymously as others have before. Backwards compatibility shouldn't
> mean letting imaginary implausible cases veto net-beneficial changes.
>
It is so easy to say stuff like this when one's own money isn't what is at
risk.
While I encourage users who would be harmed to chime in if they can,
unfortunately, I think it is mostly wishful thinking on our part that they
necessarily would. In fact, there is evidence that in practice people
don't.
To illustrate this, consider the example of the people affected by PR #5247
<https://github.com/bitcoin/bitcoin/pull/5247>, which makes unparsable
public keys non-standard. As far as I am aware none have commented on this
mailing list about it yet even though I happen to know such people do exist
because I've talked with them on Slack. I believe the person I spoke with
to took over a year (and probably more than two years) to even notice that
the transactions they want to redeem with are no longer standard. To be
fair, their money that is stuck due to PR #5247 isn't lost yet, but I'm
skeptical they would think or know to speak up here even if their money was
on the chopping block. The fact that they haven't been able to move their
money in the last *4 years* doesn't mean they wouldn't like it back one day.
While non-standardness is a helpful in dissuading users from committing new
funds to OP_CODESEPARATOR scripts, it doesn't do anything to help users
that may have been caught unaware by the non-standardness change.
Furthermore, because these transactions are non-standard, anyone caught off
guard by the change is going to have a very hard time redeeming their
funds, as we have already seen with PR #5247, a non-standardness change
that is far older than the OP_CODESERPATOR change in PR #11423
<https://github.com/bitcoin/bitcoin/pull/11423>.
[-- Attachment #2: Type: text/html, Size: 4171 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
@ 2019-03-11 16:01 99% Alistair Mann
2019-03-12 4:14 99% ` ZmnSCPxj
2019-03-17 20:27 99% ` Alistair Mann
0 siblings, 2 replies; 123+ results
From: Alistair Mann @ 2019-03-11 16:01 UTC (permalink / raw)
To: bitcoin-dev
Greetings all,
I'm looking for thoughts on the BIPability of a relatively minor change, with
an outsize benefit, with the provisional name 'Hashed Time-Locked Bond', HTLB
for short.
The minor change is to implement HTLC without its digest element. The outsize
benefit is to incentivise against spam and other abuse. In this post I'll
introduce the script, motivation, a working proof-of-concept site, and then
round out addressing the desirability of a BIP.
Implementation of HTLB:
The script takes the form:
OP_IF
OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
<num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
Notice that this is the script of BIP-0199 with '[HASHOP] <digest>
OP_EQUALVERIFY' removed.
A worked example. Alice is the buyer and Bob the seller. Alice knows that Bob
is her father and that he doesn't know her new email address. She commits
50,000 satoshis to the above script with a 24 hour timeout, then sends proof
of that transaction along with an email reintroducing herself. Bob's MUA
recognises that the bond is good and alerts him to the email from a strange
sender: he knows that if he disagrees with the implicit assertion that he will
want that email, he has 24 hours to redeem those funds at the sender's
expense. He reads the email. Bob is incentivised not to redeem against his
daughter though, and lets the timeout expire: Alice reclaims her funds. Carol
did not bond at all, so her email was refused at the server. Dave's bond of
100 satoshis was too small to pass Bob's minimum, so his email too was refused
at the server. Erin guaranteed 50,000 satoshis each to reach Bob and ten
thousand others with an email offering triple-glazed windows: she's now well
on the way to losing them all.
Motivation:
There is a transaction class we can identify as 'Good Behaviour Bonds'
currently poorly served in Bitcoin*. Bail bonds and bar tabs are real world
exemplars. Conceptually, Alice guarantees Bob she will do or be something for
a fixed period: if she complies Bob refrains from redeeming her guarantee; if
she does not comply Bob redeems some or all of it. It's inherent to the class
that Alice is incentivised within the transaction to good behaviour outside
it. Conversely, Bob is incentivised outside the transaction to good behaviour
within it.
In essence, Alice commits funds to a penalty in advance of a connection to
Bob. Alice is incentivised by getting her funds back, Bob is incentivised by
her - and others - continued patronage.
This transaction class can protect any addressable resource. Alice can
therefore guarantee Bob that:
1. Her email to him is not spam
2. Her telephone call to him is not a robocall
3. Her posts to his website are not flamebait.
In each case this is handled by extending the protocol concerned to detect for
and change behaviour depending on Alice's proof of bond.
That Alice can guarantee her behaviour to addressable resources means she can
also guarantee her behaviour to non-addressable resources. She could
guarantee:
1. a group chat that she won't upload NSFW content
2. an IRC channel that she won't flood
3. a streamed multiplayer game that she won't swear over teamspeak.
This is accomplished by use of an addressable resource and an enforcement
mechanism such as IRC's devoice command.
Alice can also guarantee her behaviour offline in much the same way. She can
guarantee to:
1. a magistrate that she'll appear for trial by a given date (Bail bond/
Surety)
2. a houseowner that she'll cover costs incurred from cleaning up after her
(Rental/Security deposit)
3. an innkeeper that she can pay for the drinks she's ordering (Bar tab)
That a transaction has been entered into online can be proved offline, so
these can be accomplished by means of an online, addressable resource and an
offline plaintext token.
Live site:
I have put up a live proof-of-concept at http://berewic.com. This protects a
specific URL accessed through HTTP (the "demo page") whereby visitors who have
posted bond on testnet3 get different content than those who have not posted
bond, or whose bond has expired. This is accomplished through an experimental
protocol where an agent with a hot wallet speaks for a credentialed user in a
similar way to how SMTP speaks for an email's original sender. That protocol
would seem to be outside the scope of the proposed BIP but I'm happy to
elaborate if required.
A short video demonstrating live use of the HTLB is also posted there.
BIP:
Name: "Hashed Time-Locked Bond" seems a reasonable name - the script is still
hashed even if the digest is gone, and HTLB nicely scans like HTLC - 1.
It won't have escaped notice that the HTLB script can be wholly written in an
HTLC script: 'HTLB over HTLC', however there are additional reasons to
consider HTLB for a separate BIP:
1. Alternative implementations using HTLB over HTLC would need to standardise
on what the redundant [HASHOP] and <digest> should be
2. Using HTLB over HTLC is inefficient as it compels unused storage and
unnecessary processing
3. Amending or superceding BIP-0199 to recognise the digest element as
optional creates backward compatibility issues
4. Recognising the motivation onchain would help inform second-layer solutions
where HTLB would be even more useful (eg, I believe that HTLCs and HTLBs do
not have analogues in the Lightning Network)
5. Wallet support. A limiting factor for the live site above has been the lack
of wallet HTLC support to the point that the demo does not implement CHECKSIG.
HTLC & HTLB signing would ideally take place in the wallet that must be
present, and so a BIP would help bolster the case for, and inform anyone
revisiting, PR7601.
Thoughts?
* The HTLB lives in the space somewhere near
https://en.bitcoin.it/wiki/Fidelity_bonds and
https://en.bitcoin.it/wiki/Contract#Example_1:_Providing_a_deposit. The former
requires an unnecessary sacrifice, the latter does not allow for penalisation.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 14:25 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 99% ` Moral Agent
@ 2019-03-10 18:28 99% ` Dustin Dettmer
2019-03-11 19:15 99% ` Russell O'Connor
1 sibling, 1 reply; 123+ results
From: Dustin Dettmer @ 2019-03-10 18:28 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4373 bytes --]
What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.
You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”
On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces@lists•linuxfoundation.org <
> bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost•nl> wrote:
> >
> >
> >> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >>
> >>> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the vulnerability
> caused by it. Alternatively there could be some sort of limit (maybe 1) on
> the maximum number of OP_CODESEPARATORs allowed to be executed per script,
> but that would require an argument as to why exceeding that limit isn't
> reasonable.
> >>
> >> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of this
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined
> is rather difficult in any case.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> 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
>
[-- Attachment #2: Type: text/html, Size: 6789 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-10 14:25 99% ` LORD HIS EXCELLENCY JAMES HRMH
@ 2019-03-10 18:24 99% ` Moral Agent
2019-03-12 7:34 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:28 99% ` Dustin Dettmer
1 sibling, 1 reply; 123+ results
From: Moral Agent @ 2019-03-10 18:24 UTC (permalink / raw)
To: LORD HIS EXCELLENCY JAMES HRMH, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4253 bytes --]
>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to
the soft fork activation standard, with weight penalties as appropriate, so
there would be no difficulty spending them before the cutoff?
On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
> ------------------------------
> *From:* bitcoin-dev-bounces@lists•linuxfoundation.org <
> bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Matt Corallo
> via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost•nl> wrote:
> >
> >
> >> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >>
> >>> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the vulnerability
> caused by it. Alternatively there could be some sort of limit (maybe 1) on
> the maximum number of OP_CODESEPARATORs allowed to be executed per script,
> but that would require an argument as to why exceeding that limit isn't
> reasonable.
> >>
> >> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of this
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined
> is rather difficult in any case.
> >
> > Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
> >
> > What if such a transaction:
> >
> > 1. must have one input; and
> > 2. must be smaller than 400 vbytes; and
> > 3. must spend from a UTXO older than fork activation
> >
> > Adding such a contextual check seems rather painful, perhaps comparable
> to nLockTime. Anything more specific than the above, e.g. counting the
> number of OP_CODESEPARATOR calls, seems like guess work.
> >
> > Transaction weight currently doesn't consider OP codes, it only
> considers if bytes are part of the witness. Changing that to something more
> akin to Ethereums gas pricing sounds too complicated to even consider.
> >
> >
> > I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
> >
> > Sjors
> >
>
> _______________________________________________
> 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
>
[-- Attachment #2: Type: text/html, Size: 6865 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-10 0:43 99% ` Karl-Johan Alm
@ 2019-03-10 17:01 99% ` David A. Harding
2019-03-12 5:44 99% ` Karl-Johan Alm
0 siblings, 1 reply; 123+ results
From: David A. Harding @ 2019-03-10 17:01 UTC (permalink / raw)
To: Karl-Johan Alm, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3020 bytes --]
On Sun, Mar 10, 2019 at 09:43:43AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
> Keeping the PoW rule and moving the signature would mean DoS attacks
> would be trivial as anyone could mine blocks without a signature in
> them
Sure, but anyone could also just connect their lite client to a trusted
node (or nodes) on signet. The nodes would protect the clients from
missing/invalid-signature DoS and the clients wouldn't have to implement
any more network-level changes than they need to now for testnet.
For people who don't want to run their own trusted signet nodes, there
could be a list of signet nodes run by well-known Bitcoiners (and this
could even be made available via a simple static dns seeder lite clients
could use).
> On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo <lf-lists@mattcorallo•com>
> wrote:
> > A previous idea regarding reorgs (that I believe Greg came up with)
> > is to allow multiple keys to sign blocks, with one signing no reorgs
> > and one signing a reorg every few blocks, allowing users to choose
> > the behavior they want.
>
> Not sure how this would work in practice.
This post from Maxwell could be the idea Corallo is describing:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html
I read it as:
- Trusted signer Alice only signs extensions of her previous blocks
- Trusted signer Bob periodically extends one of Alice's blocks
(either the tip or an earlier block) with a chain that grows faster
than Alice's chain, becoming the most-PoW chain. At some point he
stops and Alice's chain overtakes Bob's fork as the most-PoW chain
- User0 who wants to ignore reorg problems starts his node with
-signet -signers="alice", causing his node to only accept blocks
from Alice.
- User1 who wants to consider reorg problems starts his node with
-signet -signers="alice,bob", causing his node to accept blocks from
both Alice and Bob, thus experiencing periodic reorgs.
- There can also be other signing keys for any sort of attack
that can be practically executed, allowing clients to test their
response to the attack when they want to but also ignore any
disruption it would otherwise cause the rest of the time.
- As an alternative to particular signing keys, there could just be
flags put in the header versionbits, header nonce, or generation
transaction indicating how the block should be classified (e.g.
no_reorg, reorg_max6, reorg_max144, merkle_vulnerability, special0,
special1, etc...)
(If something like this is implemented, I propose reserving one of the
signing keys/classification flags for use by any of Bitcoin's more
devious devs in unannounced attacks. Having to occasionally dig
through weird log messages and odd blocks with other Bitcoin dorks on
IRC in order to figure out why things went horribly sideways in our
signet clients sounds to me like an enjoyable experience. :-)
-Dave
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
@ 2019-03-10 15:22 99% ` Russell O'Connor
0 siblings, 0 replies; 123+ results
From: Russell O'Connor @ 2019-03-10 15:22 UTC (permalink / raw)
To: LORD HIS EXCELLENCY JAMES HRMH; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]
I fear that we cannot simply wait 10 years to address the vulnerability
that OP_CODESEPARATOR has in its current form.
On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <
willtech@live•com.au> wrote:
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
> ------------------------------
> *From:* bitcoin-dev-bounces@lists•linuxfoundation.org <
> bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 6:12 AM
> *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
>
> > (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >
> >> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the vulnerability
> caused by it. Alternatively there could be some sort of limit (maybe 1) on
> the maximum number of OP_CODESEPARATORs allowed to be executed per script,
> but that would require an argument as to why exceeding that limit isn't
> reasonable.
> >
> > You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of this
> argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined
> is rather difficult in any case.
>
> Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to
> nLockTime. Anything more specific than the above, e.g. counting the number
> of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers
> if bytes are part of the witness. Changing that to something more akin to
> Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
>
> Sjors
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4964 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 20:14 99% ` Matt Corallo
@ 2019-03-10 14:25 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 99% ` Moral Agent
2019-03-10 18:28 99% ` Dustin Dettmer
0 siblings, 2 replies; 123+ results
From: LORD HIS EXCELLENCY JAMES HRMH @ 2019-03-10 14:25 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]
Opinion: Lock in a blockheight to get rid of it 10 years in the future. Use it as press that Bitcoin is going to lose $1,000,000 if some mystery person does not put their transaction through by then, try for global presses. Use the opportunity to get rid of it while you are able. Once gazetted anything is public knowledge.
Regards,
LORD HIS EXCELLENCY JAMES HRMH
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Saturday, 9 March 2019 7:14 AM
To: Sjors Provoost
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
Aside from the complexity issues here, note that for a user to be adversely affect, they probably have to have pre-signed lock-timed transactions. Otherwise, in the crazy case that such a user exists, they should have no problem claiming the funds before activation of a soft-fork (and just switching to the swgwit equivalent, or some other equivalent scheme). Thus, adding additional restrictions like tx size limits will equally break txn.
> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost•nl> wrote:
>
>
>> (1) It has been well documented again and again that there is desire to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in non-segwit scripts represents a rather significant vulnerability in Bitcoin today, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR's specific construction, with no successes as of yet. I strongly, strongly disagree that the highly-unlikely remote possibility that someone created something before which could be rendered unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
>>
>>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases the transactions weight suitably as to temper the vulnerability caused by it. Alternatively there could be some sort of limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be executed per script, but that would require an argument as to why exceeding that limit isn't reasonable.
>>
>> You could equally argue, however, that any such limit could render some moderately-large transaction unspendable, so I'm somewhat skeptical of this argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined is rather difficult in any case.
>
> Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
>
> Sjors
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 5318 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-09 18:29 99% ` Russell O'Connor
@ 2019-03-10 3:25 99% ` Jacob Eliosoff
2019-03-11 17:49 99% ` Russell O'Connor
2019-03-12 21:08 99% ` Matt Corallo
1 sibling, 1 reply; 123+ results
From: Jacob Eliosoff @ 2019-03-10 3:25 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 11828 bytes --]
>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
This principle was only ever a rule of thumb to protect users, not a
commandment from God. It shouldn't be violated lightly, but that's why
Matt did the legwork to show that the tradeoffs around OP_CODESEPARATOR
justify removing it.
Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years. Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do. Perhaps others don't want to risk
> blowing their pseudonymity. Perhaps they think that attempting to undo
> some of these non-standardness changes is futile. I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
Like Matt, I understand non-standardness to be specifically for making a
transaction type more difficult to set the stage for a future disabling.
If anyone is actually harmed by this change, let them at least speak up
pseudonymously as others have before. Backwards compatibility shouldn't
mean letting imaginary implausible cases veto net-beneficial changes.
On Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi Matt,
>
> On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists@mattcorallo•com>
> wrote:
>
>> Replies inline.
>>
>> On 3/8/19 3:57 PM, Russell O'Connor wrote:
>> > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo•com
>> > <mailto:lf-lists@mattcorallo•com>> wrote:
>> > It's very easy to construct a practical script using OP_CODESEPARATOR.
>> >
>> > IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
>> > CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
>> >
>> > Now when someone hands Alice, the CFO of XYZ corp., some transaction,
>> > she has the option of either signing it unilaterally herself, or
>> > creating a partial signature such that the transaction additionally
>> > needs Bob, the CEOs signature as well, and Alice's choice is committed
>> > to the blockchain for auditing purposes later.
>> >
>> > Now, there are many things you might object about this scheme, but my
>> > point is that (A) regardless of what you think about this scheme, it,
>> or
>> > similar schemes, may have been devised by users, and (B) users may have
>> > already committed funds to such schemes, and due to P2SH you cannot
>> know
>> > that this is not the case.
>>
>> The common way to set that up is to have a separate key, but, ok, fair
>> enough. That said, the argument that "it may be hidden by P2SH!" isn't
>> sufficient here. It has to *both* be hidden by P2SH and have never been
>> spent from (either on mainnet or testnet) or be lock-timed a year in the
>> future. I'm seriously skeptical that someone is using a highly esoteric
>> scheme and has just been pouring money into it without ever having
>> tested it or having withdrawn any money from it whatsoever. This is just
>> a weird argument.
>>
>
> No one is required to test their Scripts on a public testnet; they can use
> regtest. Because these transactions are non-standard on mainnet, it could
> take years to arrange for these funds to be recovered by having their
> transactions mined directly, or take years to become valuable enough to be
> worth bothering having them directly mined. As I have noted elsewhere, you
> cannot first make transactions non-standard and then use the fact that you
> don't see them being used on mainnet to justify a soft-fork.
>
> My argument isn't weird; it is principled. You are skeptical that any
> uses of OP_CODESEPARATOR have P2SH commitments. I am also skeptical, and
> so is everyone reading this mailing list. But none of us know this with
> certainty, and it is /wrong/ for any of us to gamble with other people's
> money that our assumptions are true.
>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
> The fact that Bitcoin has stuck to this principle gives me and everyone
> else confidence in the protocol; that anyone can secure their funds by
> whatever scheme they dream up, and deploy it without needing permission or
> anyone else to vet their Scripts. So long as they are not impairing the
> Bitcoin protocol itself, the most that Bitcoin Core will do is stop
> relaying their transactions by default.
>
> Undermining this principle means undermining what provides Bitcoin's value
> in the first place.
>
> The problem in this particular case is that there exist valid secure
> transactions that make use OP_CODESEPARATOR such that these transactions
> themselves impair the Bitcoin protocol (through excessive validation costs)
> in a way that, AFAIU, is fundamental to the nature of such transactions (in
> particular, it isn't just due to an implementation detail of Bitcoin
> Core). Thus to fix this vulnerability we must necessarily violate the
> principle of not invalidating, secure transactions. However, this fact
> isn't license to freely invalidate any transactions we want. We ought to
> strive to minimize the scope of violation of this principle. Alice and Bob
> from XYZ. corp should be able to keep their benign transaction illustrated
> above, and we only eliminate those transactions that actually impair the
> Bitcoin protocol.
>
> This is the perfect opportunity to show the world that Bitcoin Core simply
> doesn't take chances when it comes to other people money.
>
> > Please don't strawman my position. I am not suggesting we don't fix a
>> > vulnerability in Bitcoin. I am suggesting we find another way. One
>> > that limits the of risk destroying other people's money.
>> >
>> > Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR
>> > is, it cannot be worse than instead including another input that spends
>> > another identically sized UTXO. So how about we soft-fork in a rule
>> > that says that an input's weight is increased by an amount equal to the
>> > number of OP_CODESEPARATORs executed times the sum of weight of the
>> UTXO
>> > being spent and 40 bytes, the weight of a stripped input. The risk of
>> > destroying other people's money is limited and AFAIU it would
>> completely
>> > address the vulnerabilities caused by OP_CODESEPARATOR.
>>
>> You're already arguing that someone has such an esoteric use of script,
>> suggesting they aren't *also* creating pre-signed, long-locktimed
>> transactions with many inputs isn't much of a further stretch
>> (especially since this may result in the fee being non-standardly low if
>> you artificially increase its weight).
>>
>
> There is no consensus rule about minimum fees, and CPFP could add the more
> fees. But yes, I am saying that Alice and Bob could be building on their
> transaction illustrated above, but not creating a many input tx that
> wouldn't fit into a block with my proposed added weight, because if their
> transaction won't fit into a block with the added weight then it was a
> malicious transaction to begin with.
>
> Do you not recognize the material difference between a soft-fork that
> doubles the cost of a transaction like Alice and Bob's versus making their
> transaction entirely illegal?
>
>
>> Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
>> of complexity and reduces the simple analysis that fees (almost) have
>> today vs just removing it allows us to also remove a ton of code.
>
>
> Further note that if you don't remove it getting the efficiency wins
>> right is even harder because instead of being able to cache sighashes
>> you now have to (at a minimum) wipe the cache between each
>> OP_CODESEPARATOR call, which results in a ton of additional
>> implementation complexity.
>>
>
> How can this be "additional" complexity when this is how the protocol
> works today? All you have to do is not change the semantics of
> OP_CODESEPARATOR. It is literally no work.
> Regarding the efficiency wins, let me repeat myself: The performance costs
> of wiping the cached sighashs is not worse than what the performance costs
> would be if the transaction had an additional input spending an equally
> sized UTXO.
>
>
>> > > I suggest an alternative whereby the execution of
>> OP_CODESEPARATOR
>> > > increases the transactions weight suitably as to temper the
>> > > vulnerability caused by it. Alternatively there could be some
>> > sort of
>> > > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
>> > allowed to be
>> > > executed per script, but that would require an argument as to why
>> > > exceeding that limit isn't reasonable.
>> >
>> > You could equally argue, however, that any such limit could render
>> some
>> > moderately-large transaction unspendable, so I'm somewhat skeptical
>> of
>> > this argument. Note that OP_CODESEPARATOR is non-standard, so
>> getting
>> > them mined is rather difficult in any case.
>> >
>> >
>> > I already know of people who's funds are tied up due to in other
>> changes
>> > to Bitcoin Core's default relay policy. Non-standardness is not an
>> > excuse to take other people's tied up funds and destroy them
>> permanently.
>>
>> Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years. Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do. Perhaps others don't want to risk
> blowing their pseudonymity. Perhaps they think that attempting to undo
> some of these non-standardness changes is futile. I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
> Regarding OP_CODESEAPRATOR specifically, disabling the rely of such
> transactions partially mitigates the vulnerability. Once the vulnerability
> is properly patched, for example by suitably increasing the weight of the
> operation or opcode, we could drop the prohibition on relaying such
> transactions. Non-standardness is not necessarily a path to a new
> consensus rule. We have several non-standardness rules in place that are
> never intended to become new consensus rules. Sometimes non-standardness
> is a temporary mitigation.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 15211 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-09 19:52 99% ` Lautaro Dragan
@ 2019-03-10 1:02 99% ` Karl-Johan Alm
0 siblings, 0 replies; 123+ results
From: Karl-Johan Alm @ 2019-03-10 1:02 UTC (permalink / raw)
To: lautaro.dragan; +Cc: Bitcoin Protocol Discussion
Hi Lautaro,
Using regtest is not ideal for public networks, as anyone anywhere can
just rewrite the blockchain at their whim by mining a ton of blocks.
On Sun, Mar 10, 2019 at 4:52 AM Lautaro Dragan <lautarodragan@gmail•com> wrote:
>
> Hi Karl-Johan, my two cents:
>
> At Po.et we use regtest to simulate reorgs in integration tests in Travis / CircleCI. It has proved quite useful.
>
> In general regtest for automated testing has given us all we needed so far, but I admit we have a rather simple use of Bitcoin right now (colored coins).
>
> For local development, we sometimes use a script that "mines" blocks in regtest periodically. It was my goal to also use this method in QA, although we wound up using testnet and didn't encounter any problems so far.
>
> Out of curiosity: what limitations did you find in using, for example, a private network of bitcoin core nodes running regtest? (this gives you the same power as centralization without any changes or extra functionality required)
>
> El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> escribió:
>>
>> Hello,
>>
>> As some of you already know, I've been working on a network called "signet", which is bascially a complement to the already existing testnet, except it is completely centralized, and blocks are signed by a specific key rather than using proof of work.
>>
>> Benefits of this:
>>
>> 1. It is more predictable than testnet. Miners appear and disappear regularly, causing irregular block generation.
>>
>> 2. Since it is centrally controlled, it is easy to perform global testing, such as reorgs (e.g. the network performs a 4 block reorg by request, or as scheduled).
>>
>> 3. It is more stable than testnet, which occasionally sees several thousand block reorgs.
>>
>> 4. It is trivial to spin up (and shut down) new signets to make public tests where anyone can participate.
>>
>> Anyone can create a signet at any time, simply by creating a key pair and creating a challenge (scriptPubKey). The network can then be used globally by anyone, assuming the creator sends some coins to the other participants.
>>
>> Having a persistent signet would be beneficial in particular to services which need a stable place to test features over an extended period of time. My own company implements protocols on top of Bitcoin with sidechains. We need multi-node test frameworks to behave in a predictable manner (unlike testnet) and with the same standardness relay policy as mainnet.
>>
>> Signets consist of 2 parameters: the challenge script (scriptPubKey) and the solution length. (The latter is needed to retain fixed length block headers, despite having an additional payload.)
>>
>> I propose that a default persistent "signet1" is created, which can be replaced in future versions e.g. if the coins are unwisely used as real money, similarly to what happened to previous testnets. This signet is picked by default if a user includes -signet without providing any of the parameters mentioned above. The key holder would be someone sufficiently trusted in the community, who would be willing to run the system (block generation code, faucet, etc). It could be made a little more sturdy by using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers disappear. If people oppose this, it can be skipped, but will mean people can't just jump onto signet without first tracking down parameters from somewhere.
>>
>> Implementation-wise, the code adds an std::map with block hash to block signature. This is serialized/deserialized as appropriate (Segwit witness style), which means block headers in p2p messages are (80 + solution_length) bytes. Block header non-contextual check goes from checking if block header hash < target to checking if the payload is a valid signature for the block header hash instead.
>>
>> Single commit with code (will split into commits and make PR later, but just to give an idea what it looks like): https://github.com/kallewoof/bitcoin/pull/4
>>
>> I don't think this PR is overly intrusive, and I'm hoping to be able to get signet code into Bitcoin Core eventually, and am equally hopeful that devs of other (wallet etc) implementations will consider supporting it.
>>
>> Feedback requested on this.
>>
>> Attribution: parts of the signet code (in particular signblock and getnewblockhex) were adapted from the ElementsProject/elements repository. When PR is split into atomic commits, I will put appropriate attribution there.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-08 20:20 99% ` Matt Corallo
@ 2019-03-10 0:43 99% ` Karl-Johan Alm
2019-03-10 17:01 99% ` David A. Harding
2019-03-13 3:23 99% ` Anthony Towns
1 sibling, 1 reply; 123+ results
From: Karl-Johan Alm @ 2019-03-10 0:43 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
Hi Matt,
On Sat, Mar 9, 2019 at 5:20 AM Matt Corallo <lf-lists@mattcorallo•com> wrote:
>
> To make testing easier, it may make sense to keep the existing block header format (and PoW) and instead apply the signature rules to some field in the coinbase transaction. This means SPV clients (assuming they only connect to honest/trusted nodes) work as-is.
Keeping the PoW rule and moving the signature would mean DoS attacks
would be trivial as anyone could mine blocks without a signature in
them, unless you ramped up the difficulty, which would mean it's just
another testnet. It's a test network, admittedly, but I think it would
kind of defeat the purpose.
> A previous idea regarding reorgs (that I believe Greg came up with) is to allow multiple keys to sign blocks, with one signing no reorgs and one signing a reorg every few blocks, allowing users to choose the behavior they want.
Not sure how this would work in practice. The idea with signet is to
have an actual network that is occasionally reorged, i.e. it's a
global network (for those participating) that everyone agrees on. Not
sure how you would have choices there.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-08 5:54 99% [bitcoin-dev] Signet Karl-Johan Alm
2019-03-08 20:20 99% ` Matt Corallo
@ 2019-03-09 19:52 99% ` Lautaro Dragan
2019-03-10 1:02 99% ` Karl-Johan Alm
1 sibling, 1 reply; 123+ results
From: Lautaro Dragan @ 2019-03-09 19:52 UTC (permalink / raw)
To: Karl-Johan Alm, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]
Hi Karl-Johan, my two cents:
At Po.et we use regtest to simulate reorgs in integration tests in Travis /
CircleCI. It has proved quite useful.
In general regtest for automated testing has given us all we needed so far,
but I admit we have a rather simple use of Bitcoin right now (colored
coins).
For local development, we sometimes use a script that "mines" blocks in
regtest periodically. It was my goal to also use this method in QA,
although we wound up using testnet and didn't encounter any problems so far.
Out of curiosity: what limitations did you find in using, for example, a
private network of bitcoin core nodes running regtest? (this gives you the
same power as centralization without any changes or extra functionality
required)
El vie., 8 de mar. de 2019 a la(s) 16:02, Karl-Johan Alm via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> escribió:
> Hello,
>
> As some of you already know, I've been working on a network called
> "signet", which is bascially a complement to the already existing testnet,
> except it is completely centralized, and blocks are signed by a specific
> key rather than using proof of work.
>
> Benefits of this:
>
> 1. It is more predictable than testnet. Miners appear and disappear
> regularly, causing irregular block generation.
>
> 2. Since it is centrally controlled, it is easy to perform global testing,
> such as reorgs (e.g. the network performs a 4 block reorg by request, or as
> scheduled).
>
> 3. It is more stable than testnet, which occasionally sees several
> thousand block reorgs.
>
> 4. It is trivial to spin up (and shut down) new signets to make public
> tests where anyone can participate.
>
> Anyone can create a signet at any time, simply by creating a key pair and
> creating a challenge (scriptPubKey). The network can then be used globally
> by anyone, assuming the creator sends some coins to the other participants.
>
> Having a persistent signet would be beneficial in particular to services
> which need a stable place to test features over an extended period of time.
> My own company implements protocols on top of Bitcoin with sidechains. We
> need multi-node test frameworks to behave in a predictable manner (unlike
> testnet) and with the same standardness relay policy as mainnet.
>
> Signets consist of 2 parameters: the challenge script (scriptPubKey) and
> the solution length. (The latter is needed to retain fixed length block
> headers, despite having an additional payload.)
>
> I propose that a default persistent "signet1" is created, which can be
> replaced in future versions e.g. if the coins are unwisely used as real
> money, similarly to what happened to previous testnets. This signet is
> picked by default if a user includes -signet without providing any of the
> parameters mentioned above. The key holder would be someone sufficiently
> trusted in the community, who would be willing to run the system (block
> generation code, faucet, etc). It could be made a little more sturdy by
> using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers
> disappear. If people oppose this, it can be skipped, but will mean people
> can't just jump onto signet without first tracking down parameters from
> somewhere.
>
> Implementation-wise, the code adds an std::map with block hash to block
> signature. This is serialized/deserialized as appropriate (Segwit witness
> style), which means block headers in p2p messages are (80 +
> solution_length) bytes. Block header non-contextual check goes from
> checking if block header hash < target to checking if the payload is a
> valid signature for the block header hash instead.
>
> Single commit with code (will split into commits and make PR later, but
> just to give an idea what it looks like):
> https://github.com/kallewoof/bitcoin/pull/4
>
> I don't think this PR is overly intrusive, and I'm hoping to be able to
> get signet code into Bitcoin Core eventually, and am equally hopeful that
> devs of other (wallet etc) implementations will consider supporting it.
>
> Feedback requested on this.
>
> Attribution: parts of the signet code (in particular signblock and
> getnewblockhex) were adapted from the ElementsProject/elements repository.
> When PR is split into atomic commits, I will put appropriate attribution
> there.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5513 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 18:35 99% ` Matt Corallo
@ 2019-03-09 18:29 99% ` Russell O'Connor
2019-03-10 3:25 99% ` Jacob Eliosoff
2019-03-12 21:08 99% ` Matt Corallo
0 siblings, 2 replies; 123+ results
From: Russell O'Connor @ 2019-03-09 18:29 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9368 bytes --]
Hi Matt,
On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> Replies inline.
>
> On 3/8/19 3:57 PM, Russell O'Connor wrote:
> > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo•com
> > <mailto:lf-lists@mattcorallo•com>> wrote:
> > It's very easy to construct a practical script using OP_CODESEPARATOR.
> >
> > IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
> > CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
> >
> > Now when someone hands Alice, the CFO of XYZ corp., some transaction,
> > she has the option of either signing it unilaterally herself, or
> > creating a partial signature such that the transaction additionally
> > needs Bob, the CEOs signature as well, and Alice's choice is committed
> > to the blockchain for auditing purposes later.
> >
> > Now, there are many things you might object about this scheme, but my
> > point is that (A) regardless of what you think about this scheme, it, or
> > similar schemes, may have been devised by users, and (B) users may have
> > already committed funds to such schemes, and due to P2SH you cannot know
> > that this is not the case.
>
> The common way to set that up is to have a separate key, but, ok, fair
> enough. That said, the argument that "it may be hidden by P2SH!" isn't
> sufficient here. It has to *both* be hidden by P2SH and have never been
> spent from (either on mainnet or testnet) or be lock-timed a year in the
> future. I'm seriously skeptical that someone is using a highly esoteric
> scheme and has just been pouring money into it without ever having
> tested it or having withdrawn any money from it whatsoever. This is just
> a weird argument.
>
No one is required to test their Scripts on a public testnet; they can use
regtest. Because these transactions are non-standard on mainnet, it could
take years to arrange for these funds to be recovered by having their
transactions mined directly, or take years to become valuable enough to be
worth bothering having them directly mined. As I have noted elsewhere, you
cannot first make transactions non-standard and then use the fact that you
don't see them being used on mainnet to justify a soft-fork.
My argument isn't weird; it is principled. You are skeptical that any uses
of OP_CODESEPARATOR have P2SH commitments. I am also skeptical, and so is
everyone reading this mailing list. But none of us know this with
certainty, and it is /wrong/ for any of us to gamble with other people's
money that our assumptions are true.
Instead, it is this soft-fork proposal that is unprecedented. Let me
reiterate what I posted in another thread:
Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
invalidated transactions that send secured inputs to secured outputs
(excluding uses of OP_NOP1-OP_NOP10).
The fact that Bitcoin has stuck to this principle gives me and everyone
else confidence in the protocol; that anyone can secure their funds by
whatever scheme they dream up, and deploy it without needing permission or
anyone else to vet their Scripts. So long as they are not impairing the
Bitcoin protocol itself, the most that Bitcoin Core will do is stop
relaying their transactions by default.
Undermining this principle means undermining what provides Bitcoin's value
in the first place.
The problem in this particular case is that there exist valid secure
transactions that make use OP_CODESEPARATOR such that these transactions
themselves impair the Bitcoin protocol (through excessive validation costs)
in a way that, AFAIU, is fundamental to the nature of such transactions (in
particular, it isn't just due to an implementation detail of Bitcoin
Core). Thus to fix this vulnerability we must necessarily violate the
principle of not invalidating, secure transactions. However, this fact
isn't license to freely invalidate any transactions we want. We ought to
strive to minimize the scope of violation of this principle. Alice and Bob
from XYZ. corp should be able to keep their benign transaction illustrated
above, and we only eliminate those transactions that actually impair the
Bitcoin protocol.
This is the perfect opportunity to show the world that Bitcoin Core simply
doesn't take chances when it comes to other people money.
> Please don't strawman my position. I am not suggesting we don't fix a
> > vulnerability in Bitcoin. I am suggesting we find another way. One
> > that limits the of risk destroying other people's money.
> >
> > Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR
> > is, it cannot be worse than instead including another input that spends
> > another identically sized UTXO. So how about we soft-fork in a rule
> > that says that an input's weight is increased by an amount equal to the
> > number of OP_CODESEPARATORs executed times the sum of weight of the UTXO
> > being spent and 40 bytes, the weight of a stripped input. The risk of
> > destroying other people's money is limited and AFAIU it would completely
> > address the vulnerabilities caused by OP_CODESEPARATOR.
>
> You're already arguing that someone has such an esoteric use of script,
> suggesting they aren't *also* creating pre-signed, long-locktimed
> transactions with many inputs isn't much of a further stretch
> (especially since this may result in the fee being non-standardly low if
> you artificially increase its weight).
>
There is no consensus rule about minimum fees, and CPFP could add the more
fees. But yes, I am saying that Alice and Bob could be building on their
transaction illustrated above, but not creating a many input tx that
wouldn't fit into a block with my proposed added weight, because if their
transaction won't fit into a block with the added weight then it was a
malicious transaction to begin with.
Do you not recognize the material difference between a soft-fork that
doubles the cost of a transaction like Alice and Bob's versus making their
transaction entirely illegal?
> Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
> of complexity and reduces the simple analysis that fees (almost) have
> today vs just removing it allows us to also remove a ton of code.
Further note that if you don't remove it getting the efficiency wins
> right is even harder because instead of being able to cache sighashes
> you now have to (at a minimum) wipe the cache between each
> OP_CODESEPARATOR call, which results in a ton of additional
> implementation complexity.
>
How can this be "additional" complexity when this is how the protocol works
today? All you have to do is not change the semantics of
OP_CODESEPARATOR. It is literally no work.
Regarding the efficiency wins, let me repeat myself: The performance costs
of wiping the cached sighashs is not worse than what the performance costs
would be if the transaction had an additional input spending an equally
sized UTXO.
> > > I suggest an alternative whereby the execution of OP_CODESEPARATOR
> > > increases the transactions weight suitably as to temper the
> > > vulnerability caused by it. Alternatively there could be some
> > sort of
> > > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
> > allowed to be
> > > executed per script, but that would require an argument as to why
> > > exceeding that limit isn't reasonable.
> >
> > You could equally argue, however, that any such limit could render
> some
> > moderately-large transaction unspendable, so I'm somewhat skeptical
> of
> > this argument. Note that OP_CODESEPARATOR is non-standard, so getting
> > them mined is rather difficult in any case.
> >
> >
> > I already know of people who's funds are tied up due to in other changes
> > to Bitcoin Core's default relay policy. Non-standardness is not an
> > excuse to take other people's tied up funds and destroy them permanently.
>
> Huh?! The whole point of non-standardness in this context is to (a) make
> soft-forking something out safer by derisking miners not upgrading right
> away and (b) signal something that may be a candidate for soft-forking
> out so that we get feedback. Who is getting things disabled who isn't
> bothering to *tell* people that their use-case is being hurt?!
>
People have told me that they are hurt by some other non-standardness
changes and I understand that they have been sitting on those funds for
years. Maybe they don't realize their is some place to complain or maybe
they think there must be a good reason why they are not allowed to do what
they were previously allowed to do. Perhaps others don't want to risk
blowing their pseudonymity. Perhaps they think that attempting to undo
some of these non-standardness changes is futile. I can bring up the
specific cases I've encountered in a new thread if you think it is
worthwhile.
Regarding OP_CODESEAPRATOR specifically, disabling the rely of such
transactions partially mitigates the vulnerability. Once the vulnerability
is properly patched, for example by suitably increasing the weight of the
operation or opcode, we could drop the prohibition on relaying such
transactions. Non-standardness is not necessarily a path to a new
consensus rule. We have several non-standardness rules in place that are
never intended to become new consensus rules. Sometimes non-standardness
is a temporary mitigation.
[-- Attachment #2: Type: text/html, Size: 11659 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 19:12 99% ` Sjors Provoost
2019-03-08 20:14 99% ` Matt Corallo
@ 2019-03-09 18:29 99% ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2 siblings, 0 replies; 123+ results
From: Russell O'Connor @ 2019-03-09 18:29 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
Hi Sjors,
On Fri, Mar 8, 2019 at 2:12 PM Sjors Provoost <sjors@sprovoost•nl> wrote:
> Transaction weight currently doesn't consider OP codes, it only considers
> if bytes are part of the witness. Changing that to something more akin to
> Ethereums gas pricing sounds too complicated to even consider.
>
I did say per executed OP_CODESEPARATOR, but upon reflection, I agree that
we'd like to know the weight without execution. I think counting the
number of occurrences of OP_CODESEPARATOR (perhaps at the same time we
count OP_CHECKSIG operations?) is a reasonable compromise, and increasing
the weight according to my proposed formula based on that count (ideally
we'd take OP_IF branches into account).
> I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
>
I wish this were the case too, but I don't think it is reasonable to assume
that (even maaku isn't subscribed
<https://github.com/bitcoin/bitcoin/pull/15482#issuecomment-469836918>),
and I don't even think it is fair to assume such a someone necessarily even
speaks English.
[-- Attachment #2: Type: text/html, Size: 1666 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Signet
2019-03-08 5:54 99% [bitcoin-dev] Signet Karl-Johan Alm
@ 2019-03-08 20:20 99% ` Matt Corallo
2019-03-10 0:43 99% ` Karl-Johan Alm
2019-03-13 3:23 99% ` Anthony Towns
2019-03-09 19:52 99% ` Lautaro Dragan
1 sibling, 2 replies; 123+ results
From: Matt Corallo @ 2019-03-08 20:20 UTC (permalink / raw)
To: Karl-Johan Alm, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4197 bytes --]
To make testing easier, it may make sense to keep the existing block header format (and PoW) and instead apply the signature rules to some field in the coinbase transaction. This means SPV clients (assuming they only connect to honest/trusted nodes) work as-is.
A previous idea regarding reorgs (that I believe Greg came up with) is to allow multiple keys to sign blocks, with one signing no reorgs and one signing a reorg every few blocks, allowing users to choose the behavior they want.
> On Mar 8, 2019, at 00:54, Karl-Johan Alm via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hello,
>
> As some of you already know, I've been working on a network called "signet", which is bascially a complement to the already existing testnet, except it is completely centralized, and blocks are signed by a specific key rather than using proof of work.
>
> Benefits of this:
>
> 1. It is more predictable than testnet. Miners appear and disappear regularly, causing irregular block generation.
>
> 2. Since it is centrally controlled, it is easy to perform global testing, such as reorgs (e.g. the network performs a 4 block reorg by request, or as scheduled).
>
> 3. It is more stable than testnet, which occasionally sees several thousand block reorgs.
>
> 4. It is trivial to spin up (and shut down) new signets to make public tests where anyone can participate.
>
> Anyone can create a signet at any time, simply by creating a key pair and creating a challenge (scriptPubKey). The network can then be used globally by anyone, assuming the creator sends some coins to the other participants.
>
> Having a persistent signet would be beneficial in particular to services which need a stable place to test features over an extended period of time. My own company implements protocols on top of Bitcoin with sidechains. We need multi-node test frameworks to behave in a predictable manner (unlike testnet) and with the same standardness relay policy as mainnet.
>
> Signets consist of 2 parameters: the challenge script (scriptPubKey) and the solution length. (The latter is needed to retain fixed length block headers, despite having an additional payload.)
>
> I propose that a default persistent "signet1" is created, which can be replaced in future versions e.g. if the coins are unwisely used as real money, similarly to what happened to previous testnets. This signet is picked by default if a user includes -signet without providing any of the parameters mentioned above. The key holder would be someone sufficiently trusted in the community, who would be willing to run the system (block generation code, faucet, etc). It could be made a little more sturdy by using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers disappear. If people oppose this, it can be skipped, but will mean people can't just jump onto signet without first tracking down parameters from somewhere.
>
> Implementation-wise, the code adds an std::map with block hash to block signature. This is serialized/deserialized as appropriate (Segwit witness style), which means block headers in p2p messages are (80 + solution_length) bytes. Block header non-contextual check goes from checking if block header hash < target to checking if the payload is a valid signature for the block header hash instead.
>
> Single commit with code (will split into commits and make PR later, but just to give an idea what it looks like): https://github.com/kallewoof/bitcoin/pull/4
>
> I don't think this PR is overly intrusive, and I'm hoping to be able to get signet code into Bitcoin Core eventually, and am equally hopeful that devs of other (wallet etc) implementations will consider supporting it.
>
> Feedback requested on this.
>
> Attribution: parts of the signet code (in particular signblock and getnewblockhex) were adapted from the ElementsProject/elements repository. When PR is split into atomic commits, I will put appropriate attribution there.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 5276 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 19:12 99% ` Sjors Provoost
@ 2019-03-08 20:14 99% ` Matt Corallo
2019-03-10 14:25 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-09 18:29 99% ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2 siblings, 1 reply; 123+ results
From: Matt Corallo @ 2019-03-08 20:14 UTC (permalink / raw)
To: Sjors Provoost; +Cc: Bitcoin Protocol Discussion
Aside from the complexity issues here, note that for a user to be adversely affect, they probably have to have pre-signed lock-timed transactions. Otherwise, in the crazy case that such a user exists, they should have no problem claiming the funds before activation of a soft-fork (and just switching to the swgwit equivalent, or some other equivalent scheme). Thus, adding additional restrictions like tx size limits will equally break txn.
> On Mar 8, 2019, at 14:12, Sjors Provoost <sjors@sprovoost•nl> wrote:
>
>
>> (1) It has been well documented again and again that there is desire to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in non-segwit scripts represents a rather significant vulnerability in Bitcoin today, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR's specific construction, with no successes as of yet. I strongly, strongly disagree that the highly-unlikely remote possibility that someone created something before which could be rendered unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
>>
>>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases the transactions weight suitably as to temper the vulnerability caused by it. Alternatively there could be some sort of limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be executed per script, but that would require an argument as to why exceeding that limit isn't reasonable.
>>
>> You could equally argue, however, that any such limit could render some moderately-large transaction unspendable, so I'm somewhat skeptical of this argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined is rather difficult in any case.
>
> Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
>
> Sjors
>
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 19:50 99% ` Matt Corallo
2019-03-08 15:57 99% ` Russell O'Connor
@ 2019-03-08 19:12 99% ` Sjors Provoost
2019-03-08 20:14 99% ` Matt Corallo
` (2 more replies)
1 sibling, 3 replies; 123+ results
From: Sjors Provoost @ 2019-03-08 19:12 UTC (permalink / raw)
To: Matt Corallo, Russell O'Connor, Bitcoin Protocol Discussion
> (1) It has been well documented again and again that there is desire to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in non-segwit scripts represents a rather significant vulnerability in Bitcoin today, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR's specific construction, with no successes as of yet. I strongly, strongly disagree that the highly-unlikely remote possibility that someone created something before which could be rendered unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
>
>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases the transactions weight suitably as to temper the vulnerability caused by it. Alternatively there could be some sort of limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be executed per script, but that would require an argument as to why exceeding that limit isn't reasonable.
>
> You could equally argue, however, that any such limit could render some moderately-large transaction unspendable, so I'm somewhat skeptical of this argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined is rather difficult in any case.
Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
What if such a transaction:
1. must have one input; and
2. must be smaller than 400 vbytes; and
3. must spend from a UTXO older than fork activation
Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
Sjors
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-08 15:57 99% ` Russell O'Connor
@ 2019-03-08 18:35 99% ` Matt Corallo
2019-03-09 18:29 99% ` Russell O'Connor
0 siblings, 1 reply; 123+ results
From: Matt Corallo @ 2019-03-08 18:35 UTC (permalink / raw)
To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion
Replies inline.
On 3/8/19 3:57 PM, Russell O'Connor wrote:
> On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo•com
> <mailto:lf-lists@mattcorallo•com>> wrote:
> It's very easy to construct a practical script using OP_CODESEPARATOR.
>
> IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
> CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
>
> Now when someone hands Alice, the CFO of XYZ corp., some transaction,
> she has the option of either signing it unilaterally herself, or
> creating a partial signature such that the transaction additionally
> needs Bob, the CEOs signature as well, and Alice's choice is committed
> to the blockchain for auditing purposes later.
>
> Now, there are many things you might object about this scheme, but my
> point is that (A) regardless of what you think about this scheme, it, or
> similar schemes, may have been devised by users, and (B) users may have
> already committed funds to such schemes, and due to P2SH you cannot know
> that this is not the case.
The common way to set that up is to have a separate key, but, ok, fair
enough. That said, the argument that "it may be hidden by P2SH!" isn't
sufficient here. It has to *both* be hidden by P2SH and have never been
spent from (either on mainnet or testnet) or be lock-timed a year in the
future. I'm seriously skeptical that someone is using a highly esoteric
scheme and has just been pouring money into it without ever having
tested it or having withdrawn any money from it whatsoever. This is just
a weird argument.
> Please don't strawman my position. I am not suggesting we don't fix a
> vulnerability in Bitcoin. I am suggesting we find another way. One
> that limits the of risk destroying other people's money.
>
> Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR
> is, it cannot be worse than instead including another input that spends
> another identically sized UTXO. So how about we soft-fork in a rule
> that says that an input's weight is increased by an amount equal to the
> number of OP_CODESEPARATORs executed times the sum of weight of the UTXO
> being spent and 40 bytes, the weight of a stripped input. The risk of
> destroying other people's money is limited and AFAIU it would completely
> address the vulnerabilities caused by OP_CODESEPARATOR.
You're already arguing that someone has such an esoteric use of script,
suggesting they aren't *also* creating pre-signed, long-locktimed
transactions with many inputs isn't much of a further stretch
(especially since this may result in the fee being non-standardly low if
you artificially increase its weight).
Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
of complexity and reduces the simple analysis that fees (almost) have
today vs just removing it allows us to also remove a ton of code.
Further note that if you don't remove it getting the efficiency wins
right is even harder because instead of being able to cache sighashes
you now have to (at a minimum) wipe the cache between each
OP_CODESEPARATOR call, which results in a ton of additional
implementation complexity.
>
> > I suggest an alternative whereby the execution of OP_CODESEPARATOR
> > increases the transactions weight suitably as to temper the
> > vulnerability caused by it. Alternatively there could be some
> sort of
> > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
> allowed to be
> > executed per script, but that would require an argument as to why
> > exceeding that limit isn't reasonable.
>
> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of
> this argument. Note that OP_CODESEPARATOR is non-standard, so getting
> them mined is rather difficult in any case.
>
>
> I already know of people who's funds are tied up due to in other changes
> to Bitcoin Core's default relay policy. Non-standardness is not an
> excuse to take other people's tied up funds and destroy them permanently.
Huh?! The whole point of non-standardness in this context is to (a) make
soft-forking something out safer by derisking miners not upgrading right
away and (b) signal something that may be a candidate for soft-forking
out so that we get feedback. Who is getting things disabled who isn't
bothering to *tell* people that their use-case is being hurt?!
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 19:50 99% ` Matt Corallo
@ 2019-03-08 15:57 99% ` Russell O'Connor
2019-03-08 18:35 99% ` Matt Corallo
2019-03-08 19:12 99% ` Sjors Provoost
1 sibling, 1 reply; 123+ results
From: Russell O'Connor @ 2019-03-08 15:57 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5399 bytes --]
On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> Replies inline.
>
> Matt
>
> On 3/7/19 3:03 PM, Russell O'Connor wrote:
> >
> > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script
> validation.
> > This includes OP_CODESEPARATORs in unexecuted branches of if
> > statements,
> > similar to other disabled opcodes, but unlike OP_RETURN.
> >
> >
> > OP_CODESEPARATOR is the only mechanism available that allows users to
> > sign which particular branch they are authorizing for within scripts
> > that have multiple possible conditions that reuse the same public key.
>
> This is true, and yet it does not appear to actually be practically
> usable. Thus far, despite a ton of effort, I have not yet seen a
> practical use-case for OP_CODESEPARATOR (except for one example of it
> being used to make SegWit scripts ever-so-slightly more effecient in
> TumbleBit, hence why this BIP does not propose disabling it for SegWit).
>
It's very easy to construct a practical script using OP_CODESEPARATOR.
IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR
<ALICEPUBKEY> CHECKSIGVERFY ENDIF
Now when someone hands Alice, the CFO of XYZ corp., some transaction, she
has the option of either signing it unilaterally herself, or creating a
partial signature such that the transaction additionally needs Bob, the
CEOs signature as well, and Alice's choice is committed to the blockchain
for auditing purposes later.
Now, there are many things you might object about this scheme, but my point
is that (A) regardless of what you think about this scheme, it, or similar
schemes, may have been devised by users, and (B) users may have already
committed funds to such schemes, and due to P2SH you cannot know that this
is not the case.
> > Because of P2SH you cannot know that no one is currently using this
> > feature. Activating a soft-fork as describe above means these sorts of
> > funds would be permanently lost. It is not acceptable to risk people's
> > money like this.
>
> (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in
> Bitcoin today, and (3) lots of effort has gone into attempting to find
> practical use-cases for OP_CODESEPARATOR's specific construction, with
> no successes as of yet. I strongly, strongly disagree that the
> highly-unlikely remote possibility that someone created something before
> which could be rendered unspendable is sufficient reason to not fix a
> vulnerability in Bitcoin today.
>
Please don't strawman my position. I am not suggesting we don't fix a
vulnerability in Bitcoin. I am suggesting we find another way. One that
limits the of risk destroying other people's money.
Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR is,
it cannot be worse than instead including another input that spends another
identically sized UTXO. So how about we soft-fork in a rule that says that
an input's weight is increased by an amount equal to the number of
OP_CODESEPARATORs executed times the sum of weight of the UTXO being spent
and 40 bytes, the weight of a stripped input. The risk of destroying other
people's money is limited and AFAIU it would completely address the
vulnerabilities caused by OP_CODESEPARATOR.
Even soft forking a rule like, "it is illegal to execute an
OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation", would be
vastly better than the current proposal, even though I would still object
to it.
> > I suggest an alternative whereby the execution of OP_CODESEPARATOR
> > increases the transactions weight suitably as to temper the
> > vulnerability caused by it. Alternatively there could be some sort of
> > limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be
> > executed per script, but that would require an argument as to why
> > exceeding that limit isn't reasonable.
>
> You could equally argue, however, that any such limit could render some
> moderately-large transaction unspendable, so I'm somewhat skeptical of
> this argument. Note that OP_CODESEPARATOR is non-standard, so getting
> them mined is rather difficult in any case.
>
I already know of people who's funds are tied up due to in other changes to
Bitcoin Core's default relay policy. Non-standardness is not an excuse to
take other people's tied up funds and destroy them permanently.
There is some sort of crisis in the Bitcoin protocol stemming from the
possible excessive usage of OP_CODESEPARTOR otherwise we wouldn't even be
considering this soft fork. Fine. But presumably it is impossible for a
transaction to both be produced in good faith for legitimate use and at the
same time are expensive enough to be used as an attack vector, and
hopefully there is a wide gap between these two cases. So let's draw a
line between the two cases to rule out attacks while allowing legitimate
uses by simply suitably pricing the OP_CODESEPARATOR opcode by weight. At
worst case this moderately-large transaction is very expensive, reflecting
its true cost, or is was so expensive that it couldn't possibly have been
legitimate to begin with since the resources to validate it exceed the
amount that are reasonable to validate an entire block of regular
transactions.
[-- Attachment #2: Type: text/html, Size: 6567 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 19:57 99% ` Matt Corallo
@ 2019-03-08 15:57 99% ` Russell O'Connor
2019-03-13 1:34 99% ` Russell O'Connor
0 siblings, 1 reply; 123+ results
From: Russell O'Connor @ 2019-03-08 15:57 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> I can't say I'm particularly married to this idea (hence the alternate
> proposal in the original email), but at the same time the lack of
> existing transactions using these bits (and the redundancy thereof -
> they don't *do* anything special) seems to be pretty strong indication
> that they are not in use. One could argue a similarity between these
> bits and OP_NOPs - no one is going to create transactions that require
> OP_NOP execution to be valid as they are precisely the kind of thing
> that may get soft-forked to have a new meaning. While the sighash bits
> are somewhat less candidates for soft-forking,
I don't think "somewhat less candidates for soft-forking" is a fair
description. These bits essentially unsuitable for soft-forking within
legacy Script.
I don't think "someone
> may have shoved random bits into parts of their
> locked-for-more-than-a-year transactions" is sufficient reason to not
> soft-fork something out.
I disagree. It is sufficient.
When was the last time Bitcoin soft-forked out working transactions that
sent funds from securely held UTXOs to securely held UTXOs (aside from
those secured by Scripts using the reserved OP_NOP1-OP_NOP10)? AFAIK it
has never occurred since the time of Satoshi, even for the most
hypothetical of transactions. It is my understanding is that Bitcoin Core
would never do such a thing unless the security of Bitcoin protocol itself
was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin
Core would only soft-fork out the minimal amount necessary to safely
diffuse such a threat.
Since the above soft-fork isn't addressing addressing any such threat (that
I'm aware of), and could hypothetically destroy other people money, it
crosses a line I thought we were never supposed to cross.
>
> Obviously, actually *seeing* it used in
> practice or trying to fork them out in a fast manner would be
> unacceptable, but neither is being proposed here.
>
Perhaps you don't see them in used in the blockchain because the users
trying to use them are caught up by the fact they they are not being
relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having
difficulty redeeming them.
You cannot first make transactions non-standard and then use the fact that
you don't see them being used to justify a soft-fork.
I know of users who have their funds tied up due to other changes in
Bitcoin Core's default relay policy. I believe they waiting for their
funds to become valuable enough to go through the trouble of having them
directly mined. Shall we now permanently destroy their funds too, before
they have a chance to get their transactions mined?
[-- Attachment #2: Type: text/html, Size: 3656 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Signet
@ 2019-03-08 5:54 99% Karl-Johan Alm
2019-03-08 20:20 99% ` Matt Corallo
2019-03-09 19:52 99% ` Lautaro Dragan
0 siblings, 2 replies; 123+ results
From: Karl-Johan Alm @ 2019-03-08 5:54 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]
Hello,
As some of you already know, I've been working on a network called
"signet", which is bascially a complement to the already existing testnet,
except it is completely centralized, and blocks are signed by a specific
key rather than using proof of work.
Benefits of this:
1. It is more predictable than testnet. Miners appear and disappear
regularly, causing irregular block generation.
2. Since it is centrally controlled, it is easy to perform global testing,
such as reorgs (e.g. the network performs a 4 block reorg by request, or as
scheduled).
3. It is more stable than testnet, which occasionally sees several thousand
block reorgs.
4. It is trivial to spin up (and shut down) new signets to make public
tests where anyone can participate.
Anyone can create a signet at any time, simply by creating a key pair and
creating a challenge (scriptPubKey). The network can then be used globally
by anyone, assuming the creator sends some coins to the other participants.
Having a persistent signet would be beneficial in particular to services
which need a stable place to test features over an extended period of time.
My own company implements protocols on top of Bitcoin with sidechains. We
need multi-node test frameworks to behave in a predictable manner (unlike
testnet) and with the same standardness relay policy as mainnet.
Signets consist of 2 parameters: the challenge script (scriptPubKey) and
the solution length. (The latter is needed to retain fixed length block
headers, despite having an additional payload.)
I propose that a default persistent "signet1" is created, which can be
replaced in future versions e.g. if the coins are unwisely used as real
money, similarly to what happened to previous testnets. This signet is
picked by default if a user includes -signet without providing any of the
parameters mentioned above. The key holder would be someone sufficiently
trusted in the community, who would be willing to run the system (block
generation code, faucet, etc). It could be made a little more sturdy by
using 1-of-N multisig as the challenge, in case 1 <= x < N of the signers
disappear. If people oppose this, it can be skipped, but will mean people
can't just jump onto signet without first tracking down parameters from
somewhere.
Implementation-wise, the code adds an std::map with block hash to block
signature. This is serialized/deserialized as appropriate (Segwit witness
style), which means block headers in p2p messages are (80 +
solution_length) bytes. Block header non-contextual check goes from
checking if block header hash < target to checking if the payload is a
valid signature for the block header hash instead.
Single commit with code (will split into commits and make PR later, but
just to give an idea what it looks like):
https://github.com/kallewoof/bitcoin/pull/4
I don't think this PR is overly intrusive, and I'm hoping to be able to get
signet code into Bitcoin Core eventually, and am equally hopeful that devs
of other (wallet etc) implementations will consider supporting it.
Feedback requested on this.
Attribution: parts of the signet code (in particular signblock and
getnewblockhex) were adapted from the ElementsProject/elements repository.
When PR is split into atomic commits, I will put appropriate attribution
there.
[-- Attachment #2: Type: text/html, Size: 3870 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-07 17:58 99% ` Andreas Schildbach
@ 2019-03-08 0:52 99% ` Gregory Maxwell
2019-03-12 17:08 99% ` Andreas Schildbach
0 siblings, 1 reply; 123+ results
From: Gregory Maxwell @ 2019-03-08 0:52 UTC (permalink / raw)
To: Andreas Schildbach, Bitcoin Protocol Discussion
On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> First and foremost, reject messages are an indication that the
> transaction isn't going to confirm. Without these messages, we'd need to
> revert to pre-BIP61 behaviour of using a timeout for reception of
> network confirmations.
That is already required because even in the presence of perfectly
honest and cooperative hosts reject messages at most can only tell you
about first-hop behaviour. It won't even tell you if the transaction
was ever even attempted to be sent to a next hop. So alternative
handling must be provided and must be reliable for the software to
work at all regardless of reject messages.
> - Not enough fee
Rejection on low fee (over the static minimum feerate) only happens at
the point where the nodes mempool is full, which is already at a point
where you might be waiting weeks for confirmation.
Rejection causes were also not stable or reliable because the validity
criteria cannot generally be tested independently. For example, if a
transaction is queued due to missing a parent it isn't rejected
because missing the parent is often a temporary issue, but its feerate
cannot be measured without the parent. Later, when the parent is
obtained, the transaction can then be rejected due to feerate-- but no
reject is sent then.
Output already spend is often completely indistinguishable from a
missing parent and can't get rejects generated for it generally.
Similarly, the error state detected for things like invalid signatures
are often not very useful. The software knows that script execution
returned false, but in the general case _why_ it returned false is not
clear, and a straightforward high performance validation
implementation doesn't necessarily yield a good way of figuring out
and propagating up that information. (I think invalid signatures end
up returning a stack-nonempty state from validation currently, as an
example of that).
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP174 / PSBT extensions
2019-03-07 15:34 99% ` Andrew Chow
@ 2019-03-08 0:40 99% ` Gregory Maxwell
0 siblings, 0 replies; 123+ results
From: Gregory Maxwell @ 2019-03-08 0:40 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
On Thu, Mar 7, 2019 at 11:49 PM Andrew Chow via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I feel like this breaks the central idea of PSBT that a PSBT contains everything you need to construct a transaction.
> This would rely on parties in the transaction having state and remembering things which I don't think is something
> that we can assume.
I think it's perfectly fine for someone to have a propritary extension
to PSBT that isn't going to work right unless used only between their
own stuff or need a translator to talk to ordinary PSBT stuff.
For that purpose, having some kind of versioning field that you can
use to indicate what weird PSBT dialect you're speaking might be
helpful, if only to allow for more reasonable error messages.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-08 0:09 99% ` Wilmer Paulino
@ 2019-03-08 0:30 99% ` Eric Voskuil
0 siblings, 0 replies; 123+ results
From: Eric Voskuil @ 2019-03-08 0:30 UTC (permalink / raw)
To: Wilmer Paulino, Bitcoin Protocol Discussion
>> On Mar 7, 2019, at 19:09, Wilmer Paulino via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> ...
>> Nodes on the network can not generally be trusted to send valid ("reject") messages, so this should only ever be used when connected to a trusted node.
>
> Nodes in the network generally rely on the assumption that they are connected to at least one honest peer, so we can actually converge on the set of honest peers and ban/disconnect any who send an invalid reject message for a valid transaction.
This implies the reject message is valid only when it is expected (i.e. the sender is knowingly sending invalid transactions), which is presumably useful only in a local development environment.
e
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-06 0:53 99% [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke
` (2 preceding siblings ...)
2019-03-07 20:52 99% ` Aymeric Vitte
@ 2019-03-08 0:09 99% ` Wilmer Paulino
2019-03-08 0:30 99% ` Eric Voskuil
3 siblings, 1 reply; 123+ results
From: Wilmer Paulino @ 2019-03-08 0:09 UTC (permalink / raw)
To: Marco Falke, Bitcoin Protocol Discussion
Hi Marco,
> At this time, I am not aware of any software that requires this feature, and I
> would like to remove if from Bitcoin Core to make the codebase slimmer, easier
> to understand and maintain.
Neutrino[1], a light client implementation that uses BIPs 157 and 158,
currently relies on receiving reject messages from its peers when broadcasting
a transaction to the network. I've personally gone through the relevant parts
of the Bitcoin Core codebase involving reject messages and respectfully
disagree that removing it would help much in terms of comprehension and
maintainability. IMO, the benefits outweigh this small cost.
> Nodes on the network can not generally be trusted to send valid ("reject")
> messages, so this should only ever be used when connected to a trusted node.
Nodes in the network generally rely on the assumption that they are connected
to at least one honest peer, so we can actually converge on the set of honest
peers and ban/disconnect any who send an invalid reject message for a valid
transaction.
> Let us know if your application relies on this feature and you can not use any
> of the recommended alternatives:
Unfortunately, none of the recommended alternatives work for our use case. The
main thing we want to identify when broadcasting a transaction is whether is
it invalid or not. As long as it is valid, reject messages aren't required as
the light client can just rebroadcast the transaction upon every new block to
ensure it is eventually included in the chain. It can then stop rebroadcasting
it once it detects it has confirmed on-chain through its filters. However, if
it is invalid, some of the validity checks required cannot be performed by
light clients as they do not have a mempool and/or UTXO set.
Reject messages also useful when developing new light clients, as we can get
some feedback from the network on why a transaction was rejected, which helps
identify potential bugs in their transaction crafting logic. I understand that
this can be done by setting up test nodes with the flag enabled, but this
justifies that the feature should at least exist and not be completely
removed.
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
These RPCs are not helpful for light clients. Even for full nodes, in the case
of `testmempoolaccept`, mempool conditions can quickly change and cause a
transaction to be rejected after the fact. One alternative would be for a
third-party to set up an endpoint where users can submit their transactions
to, but now you're placing your trust solely on them, rather than the network,
which doesn't seem like a reasonable or comparable compromise.
With that said, I believe the feature should remain enabled by default in
order to aid the light clients of the network. If we disable them by default,
no one will bother to enable them manually, and light clients won't be able to
realize they are broadcasting invalid transactions.
[1] https://github.com/lightninglabs/neutrino
- Wilmer
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-06 0:53 99% [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke
2019-03-06 4:00 99% ` Dustin Dettmer
2019-03-06 16:49 99% ` Andreas Schildbach
@ 2019-03-07 20:52 99% ` Aymeric Vitte
2019-03-08 0:09 99% ` Wilmer Paulino
3 siblings, 0 replies; 123+ results
From: Aymeric Vitte @ 2019-03-07 20:52 UTC (permalink / raw)
To: Marco Falke, Bitcoin Protocol Discussion
Bitcoin-transactions did use this "feature", but does not rely on it any
longer since I observed some strange behavior sometimes (no reject
message for bad tx, with suprnova for example as far as I remember),
then it doublechecks using getdata to see if the tx is in mempool
Indeed you can't trust what a node tells you with or without reject
(idem for getdata but more difficult to fake and better than nothing)
Then I don't see any problem to remove it, taking into account also that
the error message is too vague to be really helpful
https://github.com/bitcoin/bitcoin/issues/11891
Le 06/03/2019 à 01:53, Marco Falke via bitcoin-dev a écrit :
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected to a
> trusted node. At this time, I am not aware of any software that requires this
> feature, and I would like to remove if from Bitcoin Core to make the codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network protocol
> should be done by inspecting the log messages that are produced by a recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee estimation
> to determine transaction fees and set replace-by-fee if desired. Thus, they
> could wait until the transaction has confirmed (taking into account the fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 15:16 99% ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
@ 2019-03-07 19:57 99% ` Matt Corallo
2019-03-08 15:57 99% ` Russell O'Connor
0 siblings, 1 reply; 123+ results
From: Matt Corallo @ 2019-03-07 19:57 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
I can't say I'm particularly married to this idea (hence the alternate
proposal in the original email), but at the same time the lack of
existing transactions using these bits (and the redundancy thereof -
they don't *do* anything special) seems to be pretty strong indication
that they are not in use. One could argue a similarity between these
bits and OP_NOPs - no one is going to create transactions that require
OP_NOP execution to be valid as they are precisely the kind of thing
that may get soft-forked to have a new meaning. While the sighash bits
are somewhat less candidates for soft-forking, I don't think "someone
may have shoved random bits into parts of their
locked-for-more-than-a-year transactions" is sufficient reason to not
soft-fork something out. Obviously, actually *seeing* it used in
practice or trying to fork them out in a fast manner would be
unacceptable, but neither is being proposed here.
Matt
On 3/7/19 3:16 PM, Russell O'Connor wrote:
>
> * If the sighash type byte (ie last byte in a signature being evaluated
> during the execution of OP_CHECKSIG[VERIFY] or
> OP_CHECKMULTISIG[VERIFY])
> is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
> execution fails. This does not apply to 0-length signature stack
> elements.
>
>
> The sighash type byte is a "great" place to store a few bits of
> ancillary data when making signatures. Okay it isn't great, but it is
> good enough that some misguided users may have been using it and have
> unbroadcast transactions in cold storage (think sweeps) for UTXOs whose
> private keys may have been lost. I don't think that one's hunch that
> there isn't much risk in disabling these sighashes is good enough to put
> people funds at risk, especially given the alternative proposal of
> caching the just-before-the-last-byte sighash midstate that is available.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-07 15:03 99% ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
@ 2019-03-07 19:50 99% ` Matt Corallo
2019-03-08 15:57 99% ` Russell O'Connor
2019-03-08 19:12 99% ` Sjors Provoost
0 siblings, 2 replies; 123+ results
From: Matt Corallo @ 2019-03-07 19:50 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
Replies inline.
Matt
On 3/7/19 3:03 PM, Russell O'Connor wrote:
>
> * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
> This includes OP_CODESEPARATORs in unexecuted branches of if
> statements,
> similar to other disabled opcodes, but unlike OP_RETURN.
>
>
> OP_CODESEPARATOR is the only mechanism available that allows users to
> sign which particular branch they are authorizing for within scripts
> that have multiple possible conditions that reuse the same public key.
This is true, and yet it does not appear to actually be practically
usable. Thus far, despite a ton of effort, I have not yet seen a
practical use-case for OP_CODESEPARATOR (except for one example of it
being used to make SegWit scripts ever-so-slightly more effecient in
TumbleBit, hence why this BIP does not propose disabling it for SegWit).
> Because of P2SH you cannot know that no one is currently using this
> feature. Activating a soft-fork as describe above means these sorts of
> funds would be permanently lost. It is not acceptable to risk people's
> money like this.
(1) It has been well documented again and again that there is desire to
remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
non-segwit scripts represents a rather significant vulnerability in
Bitcoin today, and (3) lots of effort has gone into attempting to find
practical use-cases for OP_CODESEPARATOR's specific construction, with
no successes as of yet. I strongly, strongly disagree that the
highly-unlikely remote possibility that someone created something before
which could be rendered unspendable is sufficient reason to not fix a
vulnerability in Bitcoin today.
> I suggest an alternative whereby the execution of OP_CODESEPARATOR
> increases the transactions weight suitably as to temper the
> vulnerability caused by it. Alternatively there could be some sort of
> limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be
> executed per script, but that would require an argument as to why
> exceeding that limit isn't reasonable.
You could equally argue, however, that any such limit could render some
moderately-large transaction unspendable, so I'm somewhat skeptical of
this argument. Note that OP_CODESEPARATOR is non-standard, so getting
them mined is rather difficult in any case.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
2019-03-07 10:44 99% ` Luke Dashjr
@ 2019-03-07 19:44 99% ` Matt Corallo
0 siblings, 0 replies; 123+ results
From: Matt Corallo @ 2019-03-07 19:44 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion
Replies inline.
On 3/7/19 10:44 AM, Luke Dashjr wrote:
> On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
>> I'd like to ask the BIP editor to assign a BIP number.
>
> Needs a Backward Compatibility section, and should have a bips repo PR opened
> after discussion on the ML.
Oops, I guess most of the "Discussion" section can just be moved into a
"Backwards Compatibility" section. Will do before PR'ing.
>> * The 4th change (making non-standard signature hash types invalid)
>> may be worth discussing. In order to limit the number of potential
>> signature hashes which could be used per-input (allowing us to cache
>> them to avoid re-calculation), we can disable non-standard sighash
>> types. Alternatively, however, most of the same effect could be achieved
>> by caching the just-before-the-last-byte sighash midstate and hashing
>> only the last byte when a checking signatures. Still, them having been
>> non-standard for many years makes me doubt there is much risk involved
>> in disabling them, and I don't see much potential use-case for keeping
>> them around so I'd like to just remove them.
>
> I don't understand what is being removed here.
This refers to the following spec change:
If the sighash type byte (ie last byte in a signature being evaluated
during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY])
is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
execution fails. This does not apply to 0-length signature stack elements.
>> As for why the timewarp vulnerability should (IMO rather obviously) be
>> fixed, it seems rather clear that the only potential use for exploiting
>> it would be either to inflate the currency supply maliciously by miners
>> or to fork in what amounts to extension blocks. As for why extension
>> blocks are almost certainly not the right approach to such changes, its
>> likely worth reading this old post:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
>> .html
>
> While I agree that extension blocks are typically a bad choice, I'm not sure
> the argument really applies to forward blocks. (That being said, I find
> forward blocks overcomplicated and probably not a reason to avoid this.)
I agree they are somewhat separate ideas, but the arguments in that
thread apply equally to timewarp-based inter-block-time reductions. If
you want to discuss it further, I'd suggest a new thread.
>> * Transactions smaller than 65 bytes when serialized without witness
>> data are invalid.
>
> Rationale should include the reason(s) why the size doesn't count the witness
> here.
Will add.
>> ** Note that miners today only enforce increasing timestamps against the
>> median-timestamp-of-last-11-blocks, so miners who do not upgrade may
>> mine a block which violates this rule at the beginning of a difficulty
>> window if the last block in a difficulty window has a timestamp in the
>> future. Thus, it is strongly recommended that SPV clients enforce the
>> new nTime rules to avoid following any potential forks which occur.
>
> This should probably be moved outside Discussion. (Perhaps to the missing
> Backward Compatibility section?)
>
>> * There are several early-stage proposals which may affect the execution
>> of scripts, including proposals such as Schnorr signatures, Taproot,
>> Graftroot, and MAST. These proposals are not expected to have any
>> interaction with the changes in this BIP, as they are likely to only
>> apply to SegWit scripts, which are not covered by any of the new rules
>> except for the sighash type byte rule. Thus, the sighash type byte rule
>> defined above only applies to *current* signature-checking opcodes, as
>> any new signature-checking is likely to be implemented via the
>> introduction of new opcodes.
>
> It's not clear that new opcodes will necessarily always be used. Probably
> would be good to clarify the "non-Segwit or witness v0 only" rule in the
> Specification section.
Note that you inherently have to use a new opcode for such things - the
non-standard type bytes *are* defined and define a sighash/signature,
they can't be simply redefined to a new sighash/signature type in a soft
fork.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP - Symbol for satoshi
2019-03-06 23:35 99% ` Gregory Maxwell
2019-03-06 23:59 99% ` Amine Chakak
2019-03-07 10:57 99% ` Tamas Blummer
@ 2019-03-07 18:10 99% ` Federico Tenga
2 siblings, 0 replies; 123+ results
From: Federico Tenga @ 2019-03-07 18:10 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion; +Cc: Amine Chakak
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
On Thu, 7 Mar 2019 at 11:13, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> If Satoshi wanted the currency units named after him, he would simply
> have done it. I think this behaviour seems creepy and is harmful to
> Bitcoin.
>
I don't believe the will of Satoshi is particularly relevant on this
matter. Having a term everybody can converge on to express small amounts is
very important to improve the user experience, and satoshis seem to have
more chances to achieve this than scientific notations.
My main concern with satoshis as a unit is that it may sound weird/funny to
native Japanese speakers. It could probably be useful to have the opinion
of some of them on this topic.
Regarding the BIP to formalise the symbol for satoshi, I think that maybe
is better to wait for something to emerge with more widespread usage (e.g.
already used by some wallets or service providers). The linked proposal
does not seem to have sufficient support to be proposed as a standard.
[-- Attachment #2: Type: text/html, Size: 1425 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-07 13:59 99% ` Sjors Provoost
@ 2019-03-07 17:58 99% ` Andreas Schildbach
2019-03-08 0:52 99% ` Gregory Maxwell
0 siblings, 1 reply; 123+ results
From: Andreas Schildbach @ 2019-03-07 17:58 UTC (permalink / raw)
To: bitcoin-dev
Yes, I'm talking about P2P connections.
First and foremost, reject messages are an indication that the
transaction isn't going to confirm. Without these messages, we'd need to
revert to pre-BIP61 behaviour of using a timeout for reception of
network confirmations.
Regarding the content, these cases are useful to distinguish:
- Not enough fee
- UTXO already spent
- Tx validity/standardness (e.g. invalid signature)
While the last one in theority wouldn't be necessary if you produced
your software bug-free to begin with, this just isn't how software
development works. Developers need any indication they can get.
The first two happen even in the ideal case. Fees are impossible to
predict, and unintentional double spends happen because users clone
their wallet state.
On 07/03/2019 14.59, Sjors Provoost via bitcoin-dev wrote:
> Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network?
>
> What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)?
>
> Sjors
>
>> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> het volgende geschreven:
>>
>> Reject messages cannot be replaced for debugging user problems. At least
>> unless you plan to make RPC or bitcoind logfiles available via the P2P
>> protocol (both probably not a good idea).
>>
>> The typical case is, I get mailed a wallet logfile with reject messages
>> and that's all I have. I cannot access the bitcoind logfile(s) of the
>> node(s) that generated the reject message in the first place. Nor can I
>> access their RPC interface.
>>
>> I strongly suggest re-enabling reject messages by default before 0.18.
>>
>>
>> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
>>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>>> "version" messages from a network peer when the message could not be accepted.
>>>
>>> This feature is toggled by the `-enablebip61` command line option and has been
>>> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
>>> time of writing). Nodes on the network can not generally be trusted to send
>>> valid ("reject") messages, so this should only ever be used when connected to a
>>> trusted node. At this time, I am not aware of any software that requires this
>>> feature, and I would like to remove if from Bitcoin Core to make the codebase
>>> slimmer, easier to understand and maintain. Let us know if your application
>>> relies on this feature and you can not use any of the recommended alternatives:
>>>
>>> * Testing or debugging of implementations of the Bitcoin P2P network protocol
>>> should be done by inspecting the log messages that are produced by a recent
>>> version of Bitcoin Core. Bitcoin Core logs debug messages
>>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>>> (`-debuglogfile=<debug.log>`).
>>>
>>> * Testing the validity of a block can be achieved by specific RPCs:
>>> - `submitblock`
>>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>>> potentially invalid POW
>>>
>>> * Testing the validity of a transaction can be achieved by specific RPCs:
>>> - `sendrawtransaction`
>>> - `testmempoolaccept`
>>>
>>> * Wallets should not use the absence of "reject" messages to indicate a
>>> transaction has propagated the network, nor should wallets use "reject"
>>> messages to set transaction fees. Wallets should rather use fee estimation
>>> to determine transaction fees and set replace-by-fee if desired. Thus, they
>>> could wait until the transaction has confirmed (taking into account the fee
>>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>>> transaction announcement by other network peers to check for propagation.
>>>
>>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
>>> valid concerns about its removal.
>>>
>>> Marco
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP174 / PSBT extensions
2019-03-06 18:08 99% [bitcoin-dev] BIP174 / PSBT extensions Andrew Poelstra
@ 2019-03-07 15:34 99% ` Andrew Chow
2019-03-08 0:40 99% ` Gregory Maxwell
0 siblings, 1 reply; 123+ results
From: Andrew Chow @ 2019-03-07 15:34 UTC (permalink / raw)
To: Andrew Poelstra, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]
Hi Andrew,
I think having some of these extensions would be great.
On 3/6/19 1:08 PM, Andrew Poelstra via bitcoin-dev wrote:
> 1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contains
> just a txid of the unsigned transaction, for bandwidth savings in case
> signers have already seen the tx or can construct it themselves.
>
> This field would be fixed 32 bytes.
>
> (This would actually be a breaking change since the current PSBT rules require
> PSBT_GLOBAL_UNSIGNED_TX to always be present. Maybe this is a no-go for that
> reason alone.)
I feel like this breaks the central idea of PSBT that a PSBT contains everything you need to construct a transaction.
This would rely on parties in the transaction having state and remembering things which I don't think is something
that we can assume.
> 2. Add a version field to the global table.
For what purpose?
The rest of the proposed extensions I think are fine.
Regards,
Andrew Chow
> 3. Add fields to the per-input tables for
> (a) confirmed depth of the referenced txout; this is useful for finalizers
> trying to create optimized witnesses, for e.g. cases when CSV timeouts
> expire and some signatures become unnecessary.
>
> This field must be a varint.
>
> (b) a map from SHA2 hashes to their 32-byte preimages; this field must be
> fixed 32 bytes. This, plus the CSV thing, would allow writing finalizers
> that work with all of Miniscript [2].
>
> (c) a map from public keys to 32-byte "tweaks" that are used in the pay-to-contract
> construction. Selfishly I'd like this to be a variable-length bytestring
> with the semantics that (a) the first 33 bytes represent an untweaked
> pubkey; (b) the HMAC-SHA256 of the whole thing, when multiplied by G and
> added to the untweaked pubkey, result in the target key. This matches the
> algorithm in [3] which is deployed in Blockstream's Liquid, but I'd be
> happy with a more efficient scheme which e.g. used SHA256 rather than
> HMAC-SHA256.
>
> (d) maps from public keys to partial nonce commitments, partial nonces, and
> partial signatures, for MuSig [4] support.
>
> (e) a map from signatures (or signature nonces?) to sign-to-contract tweaks.
> Same semantics as (c) above.
>
> The last two suggestions are probably premature and need further development
> and standardization of the related protocols. But I'm throwing them in to see
> if other people have strong feelings about this.
>
> 4. Add fields to the per-output tables for pay-to-contract, like in (c) above.
>
> 5. Add a field (or rather, family of fields) to every table which is "proprietary
> use" and guaranteed not to be defined by any future PSBT extension. Specifically
> every field with key-type 0xFF could be considered "proprietary".
>
> 5a. The special field in the global table whose key is only 0xFF should be a
> "proprietary version field" with unspecified semantics but an understanding
> that specific users might stick a GUID or something in there as a way to
> recognize their own PSBTs.
>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Encoding
> [2]
> http://bitcoin.sipa.be/miniscript/miniscript.html
> [3]
> https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/validation.cpp
> [4]
> https://eprint.iacr.org/2018/068
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web:
> https://www.wpsoftware.net/andrew
> "There are some mornings when the sky looks like a road
> There are some dragons who were built to have and hold
> And some machines are dropped from great heights lovingly
> And some great bellies ache with many bumblebees
> And they sting so terribly"
> --Joanna Newsom
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5772 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup
2019-03-06 21:39 99% [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 99% ` Luke Dashjr
2019-03-07 15:03 99% ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
@ 2019-03-07 15:16 99% ` Russell O'Connor
2019-03-07 19:57 99% ` Matt Corallo
2 siblings, 1 reply; 123+ results
From: Russell O'Connor @ 2019-03-07 15:16 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
> * If the sighash type byte (ie last byte in a signature being evaluated
> during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY])
> is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
> execution fails. This does not apply to 0-length signature stack elements.
>
The sighash type byte is a "great" place to store a few bits of ancillary
data when making signatures. Okay it isn't great, but it is good enough
that some misguided users may have been using it and have unbroadcast
transactions in cold storage (think sweeps) for UTXOs whose private keys
may have been lost. I don't think that one's hunch that there isn't much
risk in disabling these sighashes is good enough to put people funds at
risk, especially given the alternative proposal of caching the
just-before-the-last-byte sighash midstate that is available.
--
Russell O'Connor
[-- Attachment #2: Type: text/html, Size: 1181 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
2019-03-06 21:39 99% [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 99% ` Luke Dashjr
@ 2019-03-07 15:03 99% ` Russell O'Connor
2019-03-07 19:50 99% ` Matt Corallo
2019-03-07 15:16 99% ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2 siblings, 1 reply; 123+ results
From: Russell O'Connor @ 2019-03-07 15:03 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
> * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
> This includes OP_CODESEPARATORs in unexecuted branches of if statements,
> similar to other disabled opcodes, but unlike OP_RETURN.
>
OP_CODESEPARATOR is the only mechanism available that allows users to sign
which particular branch they are authorizing for within scripts that have
multiple possible conditions that reuse the same public key. Because of
P2SH you cannot know that no one is currently using this feature.
Activating a soft-fork as describe above means these sorts of funds would
be permanently lost. It is not acceptable to risk people's money like this.
I suggest an alternative whereby the execution of OP_CODESEPARATOR
increases the transactions weight suitably as to temper the vulnerability
caused by it. Alternatively there could be some sort of limit (maybe 1) on
the maximum number of OP_CODESEPARATORs allowed to be executed per script,
but that would require an argument as to why exceeding that limit isn't
reasonable.
--
Russell O'Connor
[-- Attachment #2: Type: text/html, Size: 1356 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-06 16:49 99% ` Andreas Schildbach
@ 2019-03-07 13:59 99% ` Sjors Provoost
2019-03-07 17:58 99% ` Andreas Schildbach
0 siblings, 1 reply; 123+ results
From: Sjors Provoost @ 2019-03-07 13:59 UTC (permalink / raw)
To: Andreas Schildbach, Bitcoin Protocol Discussion
Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network?
What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)?
Sjors
> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> het volgende geschreven:
>
> Reject messages cannot be replaced for debugging user problems. At least
> unless you plan to make RPC or bitcoind logfiles available via the P2P
> protocol (both probably not a good idea).
>
> The typical case is, I get mailed a wallet logfile with reject messages
> and that's all I have. I cannot access the bitcoind logfile(s) of the
> node(s) that generated the reject message in the first place. Nor can I
> access their RPC interface.
>
> I strongly suggest re-enabling reject messages by default before 0.18.
>
>
> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>> "version" messages from a network peer when the message could not be accepted.
>>
>> This feature is toggled by the `-enablebip61` command line option and has been
>> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
>> time of writing). Nodes on the network can not generally be trusted to send
>> valid ("reject") messages, so this should only ever be used when connected to a
>> trusted node. At this time, I am not aware of any software that requires this
>> feature, and I would like to remove if from Bitcoin Core to make the codebase
>> slimmer, easier to understand and maintain. Let us know if your application
>> relies on this feature and you can not use any of the recommended alternatives:
>>
>> * Testing or debugging of implementations of the Bitcoin P2P network protocol
>> should be done by inspecting the log messages that are produced by a recent
>> version of Bitcoin Core. Bitcoin Core logs debug messages
>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>> (`-debuglogfile=<debug.log>`).
>>
>> * Testing the validity of a block can be achieved by specific RPCs:
>> - `submitblock`
>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>> potentially invalid POW
>>
>> * Testing the validity of a transaction can be achieved by specific RPCs:
>> - `sendrawtransaction`
>> - `testmempoolaccept`
>>
>> * Wallets should not use the absence of "reject" messages to indicate a
>> transaction has propagated the network, nor should wallets use "reject"
>> messages to set transaction fees. Wallets should rather use fee estimation
>> to determine transaction fees and set replace-by-fee if desired. Thus, they
>> could wait until the transaction has confirmed (taking into account the fee
>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>> transaction announcement by other network peers to check for propagation.
>>
>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
>> valid concerns about its removal.
>>
>> Marco
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP - Symbol for satoshi
2019-03-06 23:35 99% ` Gregory Maxwell
2019-03-06 23:59 99% ` Amine Chakak
@ 2019-03-07 10:57 99% ` Tamas Blummer
2019-03-07 18:10 99% ` Federico Tenga
2 siblings, 0 replies; 123+ results
From: Tamas Blummer @ 2019-03-07 10:57 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion; +Cc: Amine Chakak
It is highly unikely that non-engineers will adopt scientific notation or mili/nano/pico prefixes for money.
All common currencies either have no change or one that is 1/100 of the base unit.
This is the convention that practically all existing finance software and non-Bitcoin related UI that deals with money assumes.
Ignoring evident cultural preference and all pre-existenting finance related software is blatant Bitcoin engineering blindness.
We already had a BIP for bits, which I support for above reasons. https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki
Tamas Blummer
> On Mar 7, 2019, at 00:35, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> The idea has been floated around to switch to satoshi as a base unit.
>
> If Satoshi wanted the currency units named after him, he would simply
> have done it. I think this behaviour seems creepy and is harmful to
> Bitcoin.
>
>> The lightning network uses satoshis as a base unit.
>
> It absolutely does not. Lightning uses units of 10 picobitcoin (1e-11
> btc), which is significantly smaller.
>
>> Pleas let me know if it would be appropriate to write a BIP for it.
>
> Please don't.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
2019-03-06 21:39 99% [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
@ 2019-03-07 10:44 99% ` Luke Dashjr
2019-03-07 19:44 99% ` Matt Corallo
2019-03-07 15:03 99% ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
2019-03-07 15:16 99% ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2 siblings, 1 reply; 123+ results
From: Luke Dashjr @ 2019-03-07 10:44 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
> I'd like to ask the BIP editor to assign a BIP number.
Needs a Backward Compatibility section, and should have a bips repo PR opened
after discussion on the ML.
> * The 4th change (making non-standard signature hash types invalid)
> may be worth discussing. In order to limit the number of potential
> signature hashes which could be used per-input (allowing us to cache
> them to avoid re-calculation), we can disable non-standard sighash
> types. Alternatively, however, most of the same effect could be achieved
> by caching the just-before-the-last-byte sighash midstate and hashing
> only the last byte when a checking signatures. Still, them having been
> non-standard for many years makes me doubt there is much risk involved
> in disabling them, and I don't see much potential use-case for keeping
> them around so I'd like to just remove them.
I don't understand what is being removed here.
> As for why the timewarp vulnerability should (IMO rather obviously) be
> fixed, it seems rather clear that the only potential use for exploiting
> it would be either to inflate the currency supply maliciously by miners
> or to fork in what amounts to extension blocks. As for why extension
> blocks are almost certainly not the right approach to such changes, its
> likely worth reading this old post:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
>.html
While I agree that extension blocks are typically a bad choice, I'm not sure
the argument really applies to forward blocks. (That being said, I find
forward blocks overcomplicated and probably not a reason to avoid this.)
> * Transactions smaller than 65 bytes when serialized without witness
> data are invalid.
Rationale should include the reason(s) why the size doesn't count the witness
here.
> ** Note that miners today only enforce increasing timestamps against the
> median-timestamp-of-last-11-blocks, so miners who do not upgrade may
> mine a block which violates this rule at the beginning of a difficulty
> window if the last block in a difficulty window has a timestamp in the
> future. Thus, it is strongly recommended that SPV clients enforce the
> new nTime rules to avoid following any potential forks which occur.
This should probably be moved outside Discussion. (Perhaps to the missing
Backward Compatibility section?)
> * There are several early-stage proposals which may affect the execution
> of scripts, including proposals such as Schnorr signatures, Taproot,
> Graftroot, and MAST. These proposals are not expected to have any
> interaction with the changes in this BIP, as they are likely to only
> apply to SegWit scripts, which are not covered by any of the new rules
> except for the sighash type byte rule. Thus, the sighash type byte rule
> defined above only applies to *current* signature-checking opcodes, as
> any new signature-checking is likely to be implemented via the
> introduction of new opcodes.
It's not clear that new opcodes will necessarily always be used. Probably
would be good to clarify the "non-Segwit or witness v0 only" rule in the
Specification section.
Luke
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP - Symbol for satoshi
2019-03-06 23:35 99% ` Gregory Maxwell
@ 2019-03-06 23:59 99% ` Amine Chakak
2019-03-07 10:57 99% ` Tamas Blummer
2019-03-07 18:10 99% ` Federico Tenga
2 siblings, 0 replies; 123+ results
From: Amine Chakak @ 2019-03-06 23:59 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
Thank you for the answer.
On Wed, 6 Mar 2019 at 18:36, Gregory Maxwell <greg@xiph•org> wrote:
> On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > The idea has been floated around to switch to satoshi as a base unit.
>
> If Satoshi wanted the currency units named after him, he would simply
> have done it. I think this behaviour seems creepy and is harmful to
> Bitcoin.
>
> > The lightning network uses satoshis as a base unit.
>
> It absolutely does not. Lightning uses units of 10 picobitcoin (1e-11
> btc), which is significantly smaller.
>
> > Pleas let me know if it would be appropriate to write a BIP for it.
>
> Please don't.
>
[-- Attachment #2: Type: text/html, Size: 1127 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP - Symbol for satoshi
@ 2019-03-06 23:35 99% ` Gregory Maxwell
2019-03-06 23:59 99% ` Amine Chakak
` (2 more replies)
0 siblings, 3 replies; 123+ results
From: Gregory Maxwell @ 2019-03-06 23:35 UTC (permalink / raw)
To: Amine Chakak, Bitcoin Protocol Discussion
On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> The idea has been floated around to switch to satoshi as a base unit.
If Satoshi wanted the currency units named after him, he would simply
have done it. I think this behaviour seems creepy and is harmful to
Bitcoin.
> The lightning network uses satoshis as a base unit.
It absolutely does not. Lightning uses units of 10 picobitcoin (1e-11
btc), which is significantly smaller.
> Pleas let me know if it would be appropriate to write a BIP for it.
Please don't.
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup
@ 2019-03-06 21:39 99% Matt Corallo
2019-03-07 10:44 99% ` Luke Dashjr
` (2 more replies)
0 siblings, 3 replies; 123+ results
From: Matt Corallo @ 2019-03-06 21:39 UTC (permalink / raw)
To: Bitcoin Protocol Discussion; +Cc: Luke Dashjr
The following is a proposed BIP to soft-fork out some oddities in the
current Bitcoin consensus rules, resolving several vulnerabilities, in
addition to fixing the timewarp vulnerability. I'd like to ask the BIP
editor to assign a BIP number.
The latest version of the BIP can be found at
https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki
(a text copy is included below).
Some things that may be worth discussing:
* Note that the activation times in this BIP may result in the
activation of the new soft-fork rules on the same block as the scheduled
block-subsidy halving. Sadly, avoiding this either requires a
significantly compressed BIP activation time (which may result in the
rules not activating for benign reasons) or beginning the activation
process significantly into the future.
* The BIP proposes allowing timestamps on the difficulty-adjustment
block to go backwards by 600 seconds which has the nice property of
making the difficulty-adjustment algorithm target almost exactly one
block per 600 seconds in the worst-case (where miners are attempting to
exploit the timewarp attack), while avoiding any potential hardware
bricking (assuming upgrades on the part of mining pools). Alternatively,
some have proposed allowing the time to go backwards 7200 seconds, which
introduces some small level of inflation in the case of a miner attack
(though much less than we've had historically simply due to the rapidly
growing hashrate) but avoids any requirements for upgrades as the
existing 7200-second-in-the-future check implies miners will only ever
build on blocks for which they can set the next timestamp to their
current time.
* The 4th change (making non-standard signature hash types invalid)
may be worth discussing. In order to limit the number of potential
signature hashes which could be used per-input (allowing us to cache
them to avoid re-calculation), we can disable non-standard sighash
types. Alternatively, however, most of the same effect could be achieved
by caching the just-before-the-last-byte sighash midstate and hashing
only the last byte when a checking signatures. Still, them having been
non-standard for many years makes me doubt there is much risk involved
in disabling them, and I don't see much potential use-case for keeping
them around so I'd like to just remove them.
As for why the timewarp vulnerability should (IMO rather obviously) be
fixed, it seems rather clear that the only potential use for exploiting
it would be either to inflate the currency supply maliciously by miners
or to fork in what amounts to extension blocks. As for why extension
blocks are almost certainly not the right approach to such changes, its
likely worth reading this old post:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510.html
<pre>
BIP: XXXX
Layer: Consensus (soft fork)
Title: The Great Consensus Cleanup
Author: Matt Corallo
Status: Draft
Type: Standards Track
Created: 2019-01-28
License: PD
</pre>
==Abstract==
This BIP defines a set of consensus changes which reduce the complexity
of Bitcoin implementations and improve worst-case validation times,
fixing a number of long-standing vulnerabilities.
==Motivation==
BIP 143 significantly improved certain aspects of Bitcoin's consensus
rules, key to this being changes to the format of the data which is
hashed and signed in CHECKSIG operations during script execution.
However, several improvements were left for later forks to avoid
bloating the original activation with unrelated changes. This BIP seeks
to make some of these changes as well as a few other simplifications.
Specifically, this BIP proposes the following changes:
* Worst-case validation time for non-BIP 143 transactions has long been
considered a significant vulnerability. To address this, both
OP_CODESEPARATOR in non-BIP 143 scripts and FindAndDelete fail script
validation, among other cleanups. This drastically reduces worst-case
validation time for non-BIP 143 transactions by enabling Signature Hash
caching on a per-input basis. While validation time of large, simple
non-BIP 143 transactions can still be excessively high on their own,
removing these multipliers goes a long way towards resolving the issue.
* By further restricting nTime fields on difficulty adjustment blocks,
we propose fixing the long-standing "timewarp" inflation vulnerability
in Bitcoin's difficulty adjustment without risking existing mining
hardware becoming unusable. This limits the worst-case difficulty
adjustment target in case of attack from the current exponential growth,
to once every roughly 600 seconds. Note that no change in default
behavior is proposed, keeping the existing target of one block every
~600.6 seconds[1] in the common case (ie we limit the attack scenario to
about a 0.1% inflation rate, much smaller than the historical inflation
rate due to rapid hashrate growth).
* Several vulnerabilities where Bitcoin clients needed to check for
specific cases of malleation in the merkle tree construction are
resolved by making certain transaction sizes invalid.
==Specification==
Upon activation, the following rules will be enforced on all new blocks:
* scriptSigs which contain non-push opcodes fail the script validation.
Push opcodes are OP_0 - OP_1NEGATE and OP_1 - OP_16. Note that this
implies any opcodes in scriptSigs greater than 0x60 will fail script
validation, in addition to OP_RESERVED (0x50, which already fails script
execution in executed branches, though all branches are now guaranteed
to execute).
* OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
This includes OP_CODESEPARATORs in unexecuted branches of if statements,
similar to other disabled opcodes, but unlike OP_RETURN.
* When validating signatures in non-BIP 143 scripts, if the scriptPubKey
being executed contains, pushed as a single element using minimal
PUSHDATA, a signature stack element being validated, the script fails
validation. For the avoidance of doubt, any FindAndDelete matches result
in script execution failure.
* If the sighash type byte (ie last byte in a signature being evaluated
during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY])
is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
execution fails. This does not apply to 0-length signature stack elements.
* Transactions smaller than 65 bytes when serialized without witness
data are invalid.
* The nTime field of each block whose height, mod 2016, is 0 must be
greater than or equal to the nTime field of the immediately prior block
minus 600. For the avoidance of doubt, such blocks must still comply
with existing Median-Time-Past nTime restrictions.
==Deployment==
This BIP will be deployed by "version bits" BIP9 with the name
"cleanups" and using bit (0-indexed) 3.
For Bitcoin mainnet, the BIP9 starttime will be midnight August 1st,
2019 UTC (Epoch timestamp 1564617600) and BIP9 timeout will be midnight
August 1st, 2020 UTC (Epoch timestamp 1596240000).
For Bitcoin testnet, the BIP9 starttime will be midnight June 1st, 2019
UTC (Epoch timestamp 1559347200) and BIP9 timeout will be midnight June
1st, 2020 UTC (Epoch timestamp 1590969600).
==Discussion==
* There are very few known uses for OP_CODESEPARATOR and none for
FindAndDelete. None of these uses enable new functionality, and any
efficiency gains are better made by switching to BIP 141. Further, there
is no known use of either on the chain today, and both have been
non-standard in Bitcoin Core since version 0.16.1, making them much more
difficult to have mined. Both changes, together, allow for signature
hash caching within each input script in a non-BIP 143 transaction
today. Note that due to their non-standardness, miners using Bitcoin
Core version 0.16.1 or later will not mine blocks which violate these
rules today.
* Reducing valid scriptSigs to the minimal set of operations which can
generate any stack state removes the requirement that scriptCodes need
to be generated for scriptSig execution, reducing the possible set of
scriptCodes which must be cached per input by 2x. Because any stack
state can be created using only push opcodes, this does not reduce
spendability except for pessimal scriptPubKeys which require a
significant number of identical stack elements (ie created using
OP_DUP). Note that such transactions have been non-standard in Bitcoin
Core since before git history (SVN 197) and thus miners running Bitcoin
Core will not mine such transactions today.
* Further, disabling non-canonical sighash types allows caching of the
sighash themselves instead of midstates (as the sighash type byte is
included in the sighash itself). Avoiding applying this rule to 0-length
signatures avoids breaking deliberate OP_CHECKSIG failures while still
avoiding having to ever calculate such sighashes. Such sighashes have
been non-standard and thus miners using Bitcoin Core version 0.8 or
higher will not mine blocks containing such transactions today.
<br/>
* While there are no known attempts to exploit the "timewarp"
vulnerability on Bitcoin's mainnet today, and the authors do not believe
it is likely to occur in the immediate future, removing the possibility
has long been on various wishlists and greatly simplifies potential
attack analysis.
** Sadly, some deployed mining hardware relies on the ability to roll
nTime forward by up to 600 seconds[3]. Thus, only requiring that the
nTime field move forward during difficulty adjustment would allow a
malicious miner to prevent some competitors from mining the next block
by setting their timestamp to two hours in the future. Thus, we allow
nTime to go backwards by 600 seconds, ensuring that even a block with a
timestamp two hours in the future allows for 600 seconds of nTime
rolling on the next block.
** Note that miners today only enforce increasing timestamps against the
median-timestamp-of-last-11-blocks, so miners who do not upgrade may
mine a block which violates this rule at the beginning of a difficulty
window if the last block in a difficulty window has a timestamp in the
future. Thus, it is strongly recommended that SPV clients enforce the
new nTime rules to avoid following any potential forks which occur.
<br/>
* The issues involved in having leaf nodes in the transaction merkle
tree which can be confused for inner nodes are well documented.
[4][5][6] While there are workarounds for the pitfalls, there are many
SPV-proof-validators which do not implement them. Further, the limited
use-cases for very small transactions does not suffice as reason to
force the added complexity onto clients. Note that any transactions
smaller than 83 bytes have been considered non-standard since Bitcoin
Core version 0.17.0, so miners will not mine blocks which validate this
rule by default.
<br/>
* There are several early-stage proposals which may affect the execution
of scripts, including proposals such as Schnorr signatures, Taproot,
Graftroot, and MAST. These proposals are not expected to have any
interaction with the changes in this BIP, as they are likely to only
apply to SegWit scripts, which are not covered by any of the new rules
except for the sighash type byte rule. Thus, the sighash type byte rule
defined above only applies to *current* signature-checking opcodes, as
any new signature-checking is likely to be implemented via the
introduction of new opcodes.
<br/>
* In spite of some suggestion that other activation methods be used, BIP
9 is proposed as ensuring miners have upgraded to enforce new rules is
an important part of minimizing disruption. While previous BIP 9
soft-forks have resulted in political contention, this
comparatively-unimportant soft-fork provides a good opportunity to
attempt to return to utilizing BIP 9 to ensure miner upgrade prior to
activation, which the authors believe is a critical goal. However, if
there is broad agreement to activate these rules when the BIP 9 expiry
time is reached, and miners have not yet signaled sufficient level of
readiness, a later flag-day activation may be merited. For this reason,
implementations may wish to provide a compatibility option which allows
flag-day enforcement of these rules without an update.
==Reference Implementation==
[https://github.com/bitcoin/bitcoin/pull/15482 Bitcoin Core Pull #15482]
==References==
[1] The difficulty adjustment algorithm in Bitcoin multiplies the
previous difficulty by (2016 / time taken to mine the last 2015 blocks).
Intuitively[2], this implies the actual Inter-Block-Time (IBT) target is
2016/2015*600, or about 600.3 seconds. However, the expected value of
the inverse of an Erlang distribution (which the above is effectively
sampling from) is actually 1/(N-1), not 1/N. Thus, the above expression
actually targets an IBT of 2016/2014*600, or about 600.6 seconds, ie
E(2016*600/X) = 1 where X~ErlangDistribution(k=2015, λ=1/IBT) when IBT
is 2016/2014*600. This is equivalent to 600*E(2016*600/X) where
X~ErlangDistribution(k=2015, λ=1/600). In the case of a miner
deliberately reducing timestamps by 600 seconds on the
difficulty-retargeting block, we are effectively changing the difficulty
multiplier to (2016 / (time taken to mine the last 2016 blocks + 600)),
or 600*E(2016*600/(X + 600)) where X~Erlang Distribution(k=2016,
λ=1/600), which is effectively targeting an inter-block time of
~599.9999 seconds.
[2] See [https://twitter.com/pwuille/status/1098288749098795008] for
most peoples' intuition. For more info see Pieter's writeup at
[https://gist.github.com/sipa/1a70884abe6d0a7cddc340c99f741a41]
[3] While no official stratum specification exists, the btc.com pool
server (one of the most popular pool servers today) rejects shares with
timestamps more than 600 seconds in the future at
[https://github.com/btccom/btcpool/blob/e7c536834fd6785af7d7d68ff29111ed81209cdf/src/bitcoin/StratumServerBitcoin.cc#L384].
While there are few resources describing hardware operation today,
timestamp rolling can be observed on the chain (in some rare cases) as
block timestamps go backwards when a miner rolled one block nTime
forward and the next does not, but only incredibly rarely more than 600
seconds.
[4]
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html]
[5]
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.pdf]
[6]
[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016697.html]
==Acknowledgments==
Thanks (in alphabetical order) to Suhas Daftuar, James Hilliard, Johnson
Lau, Steve Lee, Greg Maxwell, John Newberry, and Pieter Wuille for their
helpful feedback at various stages as well as the entire Bitcoin
Protocol Development Community.
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] BIP174 / PSBT extensions
@ 2019-03-06 18:08 99% Andrew Poelstra
2019-03-07 15:34 99% ` Andrew Chow
0 siblings, 1 reply; 123+ results
From: Andrew Poelstra @ 2019-03-06 18:08 UTC (permalink / raw)
To: bitcoin-dev
Hi all,
I'd like to start initial discussion about an extension to BIP174 [1] to add
some fields that I've found myself wanting when using PSBT in practice. For
now I'll just list the things that I'd like to see, and if we can come up
with a stable list then I'll try to write up a more formal draft.
Basically I'd just like to add some more fixed data fields.
1. Add an field to PSBT_GLOBAL_UNSIGNED_TX to the global table which contains
just a txid of the unsigned transaction, for bandwidth savings in case
signers have already seen the tx or can construct it themselves.
This field would be fixed 32 bytes.
(This would actually be a breaking change since the current PSBT rules require
PSBT_GLOBAL_UNSIGNED_TX to always be present. Maybe this is a no-go for that
reason alone.)
2. Add a version field to the global table.
3. Add fields to the per-input tables for
(a) confirmed depth of the referenced txout; this is useful for finalizers
trying to create optimized witnesses, for e.g. cases when CSV timeouts
expire and some signatures become unnecessary.
This field must be a varint.
(b) a map from SHA2 hashes to their 32-byte preimages; this field must be
fixed 32 bytes. This, plus the CSV thing, would allow writing finalizers
that work with all of Miniscript [2].
(c) a map from public keys to 32-byte "tweaks" that are used in the pay-to-contract
construction. Selfishly I'd like this to be a variable-length bytestring
with the semantics that (a) the first 33 bytes represent an untweaked
pubkey; (b) the HMAC-SHA256 of the whole thing, when multiplied by G and
added to the untweaked pubkey, result in the target key. This matches the
algorithm in [3] which is deployed in Blockstream's Liquid, but I'd be
happy with a more efficient scheme which e.g. used SHA256 rather than
HMAC-SHA256.
(d) maps from public keys to partial nonce commitments, partial nonces, and
partial signatures, for MuSig [4] support.
(e) a map from signatures (or signature nonces?) to sign-to-contract tweaks.
Same semantics as (c) above.
The last two suggestions are probably premature and need further development
and standardization of the related protocols. But I'm throwing them in to see
if other people have strong feelings about this.
4. Add fields to the per-output tables for pay-to-contract, like in (c) above.
5. Add a field (or rather, family of fields) to every table which is "proprietary
use" and guaranteed not to be defined by any future PSBT extension. Specifically
every field with key-type 0xFF could be considered "proprietary".
5a. The special field in the global table whose key is only 0xFF should be a
"proprietary version field" with unspecified semantics but an understanding
that specific users might stick a GUID or something in there as a way to
recognize their own PSBTs.
[1] https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#Encoding
[2] http://bitcoin.sipa.be/miniscript/miniscript.html
[3] https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/validation.cpp
[4] https://eprint.iacr.org/2018/068
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
"There are some mornings when the sky looks like a road
There are some dragons who were built to have and hold
And some machines are dropped from great heights lovingly
And some great bellies ache with many bumblebees
And they sting so terribly"
--Joanna Newsom
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] bitcoinj 0.15 (segwit)
@ 2019-03-06 17:14 99% Andreas Schildbach
0 siblings, 0 replies; 123+ results
From: Andreas Schildbach @ 2019-03-06 17:14 UTC (permalink / raw)
To: bitcoin-dev
In case anyone missed the announcement: bitcoinj 0.15, with support for
native segregated witness, has recently been released.
https://groups.google.com/d/msg/bitcoinj-announce/X6Zv1NSFxOk/KJACzHZMAQAJ
For operability testing, I just released new versions 7.0 of Bitcoin
Wallet. For now, they still create a keychain of legacy addresses but
they can send to native segwit addresses via Bech32.
Testnet:
https://play.google.com/store/apps/details?id=de.schildbach.wallet_test
Mainnet:
https://play.google.com/store/apps/details?id=de.schildbach.wallet
(At the time of this writing, you need to opt into beta in order to
receive 7.x: https://play.google.com/apps/testing/de.schildbach.wallet)
Receiving to native segwit addresses and spending from them will follow
in the coming days and weeks.
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-06 0:53 99% [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke
2019-03-06 4:00 99% ` Dustin Dettmer
@ 2019-03-06 16:49 99% ` Andreas Schildbach
2019-03-07 13:59 99% ` Sjors Provoost
2019-03-07 20:52 99% ` Aymeric Vitte
2019-03-08 0:09 99% ` Wilmer Paulino
3 siblings, 1 reply; 123+ results
From: Andreas Schildbach @ 2019-03-06 16:49 UTC (permalink / raw)
To: bitcoin-dev
Reject messages cannot be replaced for debugging user problems. At least
unless you plan to make RPC or bitcoind logfiles available via the P2P
protocol (both probably not a good idea).
The typical case is, I get mailed a wallet logfile with reject messages
and that's all I have. I cannot access the bitcoind logfile(s) of the
node(s) that generated the reject message in the first place. Nor can I
access their RPC interface.
I strongly suggest re-enabling reject messages by default before 0.18.
On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected to a
> trusted node. At this time, I am not aware of any software that requires this
> feature, and I would like to remove if from Bitcoin Core to make the codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network protocol
> should be done by inspecting the log messages that are produced by a recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee estimation
> to determine transaction fees and set replace-by-fee if desired. Thus, they
> could wait until the transaction has confirmed (taking into account the fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
> valid concerns about its removal.
>
> Marco
>
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Privacy literature review
@ 2019-03-06 14:28 99% ` Adam Ficsor
0 siblings, 0 replies; 123+ results
From: Adam Ficsor @ 2019-03-06 14:28 UTC (permalink / raw)
To: Chris Belcher, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
I would like to grab the opportunity to point out that I am doing the same,
but in the form of presentations. I started with a two part presentation,
but I decided to make it into a 6 part presentation series in the future.
Part 1: Concentrating on network level privacy -
https://vimeo.com/album/5765075/video/316635787
Part 2: Concentrating on blockchain level privacy -
https://www.youtube.com/watch?v=AmFC9dhtemo&t=358m0s
I think this work is very important and nothing comparable has been done
before, so thank you for taking the time for this Belcher!
On Wed, Mar 6, 2019 at 1:38 AM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hello list,
>
> For the last few weeks I've been working on a literature review for
> bitcoin privacy:
>
> https://en.bitcoin.it/wiki/Privacy
>
> It aims to cover about all privacy issues in bitcoin, including
> Lightning network, and has a bunch of examples to help demonstrate how
> the concepts work in practice.
>
> There is also a new wiki category with smaller related articles:
>
> https://en.bitcoin.it/wiki/Category:Privacy
>
> Regards
> CB
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Best,
Ádám
[-- Attachment #2: Type: text/html, Size: 2490 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Fwd: BIP proposal - Signatures of Messages using Bitcoin Private Keys
@ 2019-03-06 10:37 99% ` Aymeric Vitte
0 siblings, 0 replies; 123+ results
From: Aymeric Vitte @ 2019-03-06 10:37 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6940 bytes --]
Re-sending to the list since it never made it
BIP or not, at least this process desserves to be documented precisely
-------- Message transféré --------
Sujet : Re: [bitcoin-dev] BIP proposal - Signatures of Messages using
Bitcoin Private Keys
Date : Mon, 18 Feb 2019 16:29:34 -0800
De : Christopher Gilliard <christopher.gilliard@gmail•com>
Pour : Aymeric Vitte <vitteaymeric@gmail•com>
Copie à : Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this,
but if there is a header field currently in use, it seemed reasonable to
me to use it specify which type of key is being used. If the header
includes whether the key is compressed or not compressed it seems
logical to include all data about what type of key it is and not just
this one type of information. That's why I thought the solution made
sense and I wrote it up.
On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte <vitteaymeric@gmail•com
<mailto:vitteaymeric@gmail•com>> wrote:
Ah, OK, that's of course a good thing to document this undocumented
(and strange) stuff, as a matter of fact I implemented it after
reading your post (because this was on my todo list since some time)
and got annoyed quickly, mainly by what is doing
formatMessageForSigning (which is quite trivial when you know it but
would be good to document precisely)
So, yes, it's a good idea to write this, regarding the header I
still don't see the use, testing the different possibilities is not
a big deal, why the signature format is not the same as transactions
one is mysterious too
Le 19/02/2019 à 00:24, Christopher Gilliard a écrit :
> The proposal includes actual code that does verification, but I
> didn't include code for signing. I thought it could be inferred,
> but I could at least include a description of how to sign. I am
> not sure exactly what part you are referring to by "keys speech",
> but the signatures are done by ECDSA keys so it's hard to not
> include anything about keys even though that's not the main topic.
> The "Background on ECDSA keys" section was mainly meant to give
> background about what kind of keys Bitcoin uses, for people who
> already know that they can easily skip this section so I would
> probably think it's best just to leave in. Maybe it should be at
> the end as an addendum though. Yes, I did not invent any of this,
> I'm just documenting what people actually seem to do because I had
> to verify signatures as part of a project I'm working on. I would
> have liked to have had this document when I started the project so
> I thought it might be useful to others since as far as I can tell
> this was not specified anywhere. The reason for including this
> data in the header is the same that compressed/uncompressed is
> included in the header so that you know which type of key the
> signature is from and you don't have to try all options to see if
> any matches. This is why Trezor did that way and why I documented
> it. I'm sure there are other ways to do this, but since this is
> out there in the field being used and is a reasonable solution, I
> thought I'd write it up.
>
> On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte
> <vitteaymeric@gmail•com <mailto:vitteaymeric@gmail•com>> wrote:
>
> Then, since you wrote this proposal, maybe you should add the
> very precise description of the signing/verification process
> since it is documented nowhere
>
> I don't get the use of the speech regarding keys while it
> should focus on signatures which are summarized in a vague
> sentence inspired by your ref [2] with a not very logical link
> to the next paragraph stating that r,s should be 32B and the
> whole thing 65B with a header of 1B, you did not invent it,
> that's probably the rule, not sure where it is specified again
> and for what purpose, the header seems completely of no use
> especially when you extend to segwit/bech32 since you just
> have to check that related compressed key matches
>
> Le 17/02/2019 à 15:14, Christopher Gilliard via bitcoin-dev a
> écrit :
>> I have written up a proposed BIP. It has to do with Signature
>> formats when using Bitcoin Private keys. It is
>> here: https://github.com/cgilliard/BIP/blob/master/README.md
>>
>> This BIP was written up as suggested in this github
>> issue: https://github.com/bitcoin/bitcoin/issues/10542
>>
>> Note that the proposal is inline with the implementation that
>> Trezor implemented in the above issue.
>>
>> Any feedback would be appreciated. Please let me know what
>> the steps are with regards to getting a BIP number assigned
>> or any other process steps required.
>>
>> Regards,
>> Chris
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
[-- Attachment #2: Type: text/html, Size: 15519 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal - addrv2 message
2019-03-06 3:02 99% ` Gregory Maxwell
@ 2019-03-06 9:05 99% ` Sjors Provoost
1 sibling, 0 replies; 123+ results
From: Sjors Provoost @ 2019-03-06 9:05 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Wladimir J. van der Laan
Concept ACK.
> ==Considerations==
>
> (to be discussed)
>
> * ''Client MAY store and gossip address formats that they do not know about'': does it ever make sense to gossip addresses outside a certain overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for networks that have no exit nodes as there is no overlap with the globally routed internet at all.
What exactly do you mean by "do not know about"? It could mean:
1. A new Network ID was recently introduced which an older node doesn't about.
In that case the node won't even know the address length, so it can't parse the entry.
In fact it can't parse the entire address message if a single address has an unknown format. Maybe require a single address type per ADDR2 message?
2. The Network ID doesn't match the network the node received this message on
The node should probably be agnostic about where it received this information from.
3. The node currently doesn't support a Network ID
But what does that mean? No connection? An explicitly disabled setting? A missing dependency? The operating system doesn't support it?
I think "MAY" is the correct choice for storing for (2).
For (3) I think it makes sense for nodes to store information even if they're disconnected, but not if they have a setting disabled or no driver. Though that implementation detail doesn't seem relevant to the standard.
I don't think it's a good idea to gossip information you can't at least in theory verify, but we already do that with Tor V2. It's useful to gossip information about other networks to help e.g. IPv4 nodes bootstrap Tor connections. On the other hand, that could also help an attacker link them. We could recommend that with addrv2 the node should make sure gossip messages were received on the correct interface, but that may not be practical.
> * Lower precision of <code>time</code> field? seconds precision seems overkill, and can even be harmful, there have been attacks that exploited high precision timestamps for mapping the current network topology.
>
> ** (gmaxwell) If you care about space time field could be reduced to 16 bits easily. Turn it into a "time ago seen" quantized to 1 hour precision. (IIRC we quantize times to 2hrs regardless).
That seems like a good idea.
> * (gmaxwell) Optional (per-service) data could be useful for various things:
> [...]
> ** If we want optional flags. I guess the best thing would just be a byte to include the count of them, then a byte "type" for each one where the type also encodes if the payload is 0/8/16/32 bits. (using the two MSB of the type to encode the length). And then bound the count of them so that the total is still reasonably sized.
Adding more information seems useful, though also creates more topology mapping opportunities.
- Sjors
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
2019-03-06 0:53 99% [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke
@ 2019-03-06 4:00 99% ` Dustin Dettmer
2019-03-06 16:49 99% ` Andreas Schildbach
` (2 subsequent siblings)
3 siblings, 0 replies; 123+ results
From: Dustin Dettmer @ 2019-03-06 4:00 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Marco Falke
[-- Attachment #1: Type: text/plain, Size: 3327 bytes --]
The reject message is helpful for figuring out why a tx was rejected.
It’s not useful for determining success, yes. Particularly when doing
segwit / newer types of tx’s as there’s always one or more pesky nodes who
still don’t support it and send a reject message for perfectly good tx’s.
But after a delay where you haven’t seen your tx propagated on the network,
it’s useful to know *why* it failed.
What would be nice is actually expanding this error message. Currently with
RBF tx’s “fee too small” is sent for both original transactions as well as
replacement transactions. So a bug accidentally sending spent txos
(currently in mempool) says “fee too small” instead of something more
appropriate like “fee too small to supersede existing unconfirmed
transaction.”
On Tue, Mar 5, 2019 at 7:26 PM Marco Falke via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be
> accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has
> been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as
> of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected
> to a
> trusted node. At this time, I am not aware of any software that requires
> this
> feature, and I would like to remove if from Bitcoin Core to make the
> codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network
> protocol
> should be done by inspecting the log messages that are produced by a
> recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee
> estimation
> to determine transaction fees and set replace-by-fee if desired. Thus,
> they
> could wait until the transaction has confirmed (taking into account the
> fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
> there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4106 bytes --]
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] BIP proposal - addrv2 message
@ 2019-03-06 3:02 99% ` Gregory Maxwell
2019-03-06 9:05 99% ` Sjors Provoost
1 sibling, 0 replies; 123+ results
From: Gregory Maxwell @ 2019-03-06 3:02 UTC (permalink / raw)
To: Wladimir J. van der Laan, Bitcoin Protocol Discussion
On Wed, Mar 6, 2019 at 12:22 AM Wladimir J. van der Laan via
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject
> longer addresses.
Is 32 bytes long enough for I2P? It seems like there are two formats,
is there a reason we might want to use the longer one?
https://geti2p.net/en/docs/naming
Probably the spec should define the limit per address type (e.g.
sending a 32 byte IPv4 makes no sense). And either a maximum for ANY
type (so that 1000*largest size is reasonable), or a maximum size for
the message (e.g. regardless of the included size, an add message
should never be over, say 100k).
> * ''Client MAY store and gossip address formats that they do not know about'': does it ever make sense to gossip addresses outside a certain overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for networks that have no exit nodes as there is no overlap with the globally routed internet at all.
I think clients should be discouraged from gossiping stuff they cannot
test but not forbidden from doing so. Separately, they should be
strongly discouraged from gossiping types they don't understand at
all. We don't really want to see people doing file xfer over invalid
addr types. :)
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Fortune Cookies to Bitcoin Seed
2019-03-06 1:05 99% ` James MacWhyte
@ 2019-03-06 1:37 99% ` Trey Del Bonis
0 siblings, 0 replies; 123+ results
From: Trey Del Bonis @ 2019-03-06 1:37 UTC (permalink / raw)
To: James MacWhyte; +Cc: Bitcoin Protocol Discussion
>Mid-level hardware can check 50k addresses per second, which means it would only take around 2 hours to check all possibilities.
Yes that's a problem that I'm now realizing exists. Whoops! Changing
the parameters to a 25-of-50 setup gets us ~129 bits in that case,
which is better but still somewhat crappy as 25 is a lot of words to
remember. You'd be *far* better off just memorizing a BIP-39
seedphrase. Maybe it would make sense to include in the hash some
extra secret phrase as extra entropy? Probably not worth it.
>Maybe they only print 35 different combinations and assume people don't eat Chinese food enough to notice?
Upon some later research I found that this is actually the case from
certain vendors, which is unfortunate.
>I'm not sure why you would want to go this route :)
Because it was a fun idea I had while eating Chinese take-out the other day. :)
On Tue, Mar 5, 2019 at 8:06 PM James MacWhyte <macwhyte@gmail•com> wrote:
>
> On Tue, Mar 5, 2019 at 4:39 PM Trey Del Bonis via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Keeping 20 around is a little excessive but it gives 390700800 possible wallets. So security can be trivially parameterized based on how secure you want your wallet to be if someone finds your stash.
>
>
> Mid-level hardware can check 50k addresses per second, which means it would only take around 2 hours to check all possibilities. So please don't think this presents any kind of challenge to someone who finds your 20 pieces of paper and assumes you would only keep them if they are hiding your wallet ;)
>
> Entropy-wise, simply using a strong RNG would provide a better result than relying on the printing company. Maybe they only print 35 different combinations and assume people don't eat Chinese food enough to notice?
>
> If it's poor entropy and doesn't really provide any protection against being brute forced if found, I'm not sure why you would want to go this route :)
>
> James
^ permalink raw reply [relevance 99%]
* Re: [bitcoin-dev] Fortune Cookies to Bitcoin Seed
@ 2019-03-06 1:05 99% ` James MacWhyte
2019-03-06 1:37 99% ` Trey Del Bonis
0 siblings, 1 reply; 123+ results
From: James MacWhyte @ 2019-03-06 1:05 UTC (permalink / raw)
To: Trey Del Bonis, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
On Tue, Mar 5, 2019 at 4:39 PM Trey Del Bonis via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Keeping 20 around is a little excessive but it gives 390700800 possible
> wallets. So security can be trivially parameterized based on how secure you
> want your wallet to be if someone finds your stash.
>
Mid-level hardware can check 50k addresses per second, which means it would
only take around 2 hours to check all possibilities. So please don't think
this presents any kind of challenge to someone who finds your 20 pieces of
paper and assumes you would only keep them if they are hiding your wallet ;)
Entropy-wise, simply using a strong RNG would provide a better result than
relying on the printing company. Maybe they only print 35 different
combinations and assume people don't eat Chinese food enough to notice?
If it's poor entropy and doesn't really provide any protection against
being brute forced if found, I'm not sure why you would want to go
this route :)
James
[-- Attachment #2: Type: text/html, Size: 1483 bytes --]
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
@ 2019-03-06 0:53 99% Marco Falke
2019-03-06 4:00 99% ` Dustin Dettmer
` (3 more replies)
0 siblings, 4 replies; 123+ results
From: Marco Falke @ 2019-03-06 0:53 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Bitcoin Core may send "reject" messages as response to "tx", "block" or
"version" messages from a network peer when the message could not be accepted.
This feature is toggled by the `-enablebip61` command line option and has been
disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
time of writing). Nodes on the network can not generally be trusted to send
valid ("reject") messages, so this should only ever be used when connected to a
trusted node. At this time, I am not aware of any software that requires this
feature, and I would like to remove if from Bitcoin Core to make the codebase
slimmer, easier to understand and maintain. Let us know if your application
relies on this feature and you can not use any of the recommended alternatives:
* Testing or debugging of implementations of the Bitcoin P2P network protocol
should be done by inspecting the log messages that are produced by a recent
version of Bitcoin Core. Bitcoin Core logs debug messages
(`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
(`-debuglogfile=<debug.log>`).
* Testing the validity of a block can be achieved by specific RPCs:
- `submitblock`
- `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
potentially invalid POW
* Testing the validity of a transaction can be achieved by specific RPCs:
- `sendrawtransaction`
- `testmempoolaccept`
* Wallets should not use the absence of "reject" messages to indicate a
transaction has propagated the network, nor should wallets use "reject"
messages to set transaction fees. Wallets should rather use fee estimation
to determine transaction fees and set replace-by-fee if desired. Thus, they
could wait until the transaction has confirmed (taking into account the fee
target they set (compare the RPC `estimatesmartfee`)) or listen for the
transaction announcement by other network peers to check for propagation.
I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
valid concerns about its removal.
Marco
^ permalink raw reply [relevance 99%]
* [bitcoin-dev] Mailing list downtime, archive, and its future
@ 2019-03-06 0:34 99% Bryan Bishop
0 siblings, 0 replies; 123+ results
From: Bryan Bishop @ 2019-03-06 0:34 UTC (permalink / raw)
To: Bitcoin Dev, Bryan Bishop
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Hi all,
Just fyi, but this bitcoin-dev mailing list has been down for a few weeks.
It's currently hosted by Linux Foundation, and they are slowly deprecating
their support for email. We will have to find an alternative service
provider for the mailing list moving forward. I have received a variety of
recommendations for how to move forward.
My one reservation in this process is that I am concerned about the
subscriber list and I am not sure how we want to treat this. I view this as
a possible privacy issue. For example, if we were to migrate to a new
mailing list, it's important that list subscribers are not disclosed. At
the same time, some people rely on this mailing list for important
announcements maybe even security announcements in some situations. I'd
appreciate feedback on what people think about this particular issue. Since
the mailing list is not reliable anymore, please remember to cc the
feedback to me directly.
In the mean time, here is an archive of the mailing list content including
some old timestamps in the opentimestamps format for some of the older
content:
http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/bitcoin-dev-mailing-list-archive-2019-03-05.zip
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 1578 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-123 of 123 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2017-08-14 6:05 [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application omar shibli
2017-08-15 5:12 ` Gregory Maxwell
2017-08-15 16:40 ` omar shibli
2017-09-01 7:16 ` Omar Shibli
2019-03-12 5:53 99% ` Omar Shibli
2019-03-12 7:05 99% ` ZmnSCPxj
2019-02-18 7:56 [bitcoin-dev] BIP proposal - addrv2 message Wladimir J. van der Laan
2019-03-06 3:02 99% ` Gregory Maxwell
2019-03-06 9:05 99% ` Sjors Provoost
2019-02-19 0:29 [bitcoin-dev] BIP proposal - Signatures of Messages using Bitcoin Private Keys Christopher Gilliard
2019-03-06 10:37 99% ` [bitcoin-dev] Fwd: " Aymeric Vitte
2019-02-23 20:17 [bitcoin-dev] Privacy literature review Chris Belcher
2019-03-06 14:28 99% ` Adam Ficsor
2019-02-23 22:10 [bitcoin-dev] BIP - Symbol for satoshi Amine Chakak
2019-03-06 23:35 99% ` Gregory Maxwell
2019-03-06 23:59 99% ` Amine Chakak
2019-03-07 10:57 99% ` Tamas Blummer
2019-03-07 18:10 99% ` Federico Tenga
2019-02-28 3:48 [bitcoin-dev] Fortune Cookies to Bitcoin Seed Trey Del Bonis
2019-03-06 1:05 99% ` James MacWhyte
2019-03-06 1:37 99% ` Trey Del Bonis
2019-03-06 0:34 99% [bitcoin-dev] Mailing list downtime, archive, and its future Bryan Bishop
2019-03-06 0:53 99% [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke
2019-03-06 4:00 99% ` Dustin Dettmer
2019-03-06 16:49 99% ` Andreas Schildbach
2019-03-07 13:59 99% ` Sjors Provoost
2019-03-07 17:58 99% ` Andreas Schildbach
2019-03-08 0:52 99% ` Gregory Maxwell
2019-03-12 17:08 99% ` Andreas Schildbach
2019-03-12 22:14 99% ` Gregory Maxwell
2019-03-13 14:29 99% ` Andreas Schildbach
2019-03-13 14:41 99% ` Oscar Guindzberg
2019-03-13 22:30 99% ` Dustin Dettmer
2019-03-14 9:46 99% ` Aymeric Vitte
2019-03-07 20:52 99% ` Aymeric Vitte
2019-03-08 0:09 99% ` Wilmer Paulino
2019-03-08 0:30 99% ` Eric Voskuil
2019-03-06 17:14 99% [bitcoin-dev] bitcoinj 0.15 (segwit) Andreas Schildbach
2019-03-06 18:08 99% [bitcoin-dev] BIP174 / PSBT extensions Andrew Poelstra
2019-03-07 15:34 99% ` Andrew Chow
2019-03-08 0:40 99% ` Gregory Maxwell
2019-03-06 21:39 99% [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup Matt Corallo
2019-03-07 10:44 99% ` Luke Dashjr
2019-03-07 19:44 99% ` Matt Corallo
2019-03-07 15:03 99% ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
2019-03-07 19:50 99% ` Matt Corallo
2019-03-08 15:57 99% ` Russell O'Connor
2019-03-08 18:35 99% ` Matt Corallo
2019-03-09 18:29 99% ` Russell O'Connor
2019-03-10 3:25 99% ` Jacob Eliosoff
2019-03-11 17:49 99% ` Russell O'Connor
2019-03-12 21:08 99% ` Matt Corallo
2019-03-12 22:39 99% ` Jacob Eliosoff
2019-03-13 0:54 99% ` Gregory Maxwell
2019-03-13 1:34 99% ` Russell O'Connor
2019-03-08 19:12 99% ` Sjors Provoost
2019-03-08 20:14 99% ` Matt Corallo
2019-03-10 14:25 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 99% ` Moral Agent
2019-03-12 7:34 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:28 99% ` Dustin Dettmer
2019-03-11 19:15 99% ` Russell O'Connor
2019-03-12 2:23 99% ` Matt Corallo
2019-03-13 1:38 99% ` Russell O'Connor
2019-03-09 18:29 99% ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2019-03-10 15:22 99% ` Russell O'Connor
2019-03-07 15:16 99% ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2019-03-07 19:57 99% ` Matt Corallo
2019-03-08 15:57 99% ` Russell O'Connor
2019-03-13 1:34 99% ` Russell O'Connor
2019-03-08 5:54 99% [bitcoin-dev] Signet Karl-Johan Alm
2019-03-08 20:20 99% ` Matt Corallo
2019-03-10 0:43 99% ` Karl-Johan Alm
2019-03-10 17:01 99% ` David A. Harding
2019-03-12 5:44 99% ` Karl-Johan Alm
2019-03-13 3:23 99% ` Anthony Towns
2019-03-14 1:07 99% ` Karl-Johan Alm
2019-03-09 19:52 99% ` Lautaro Dragan
2019-03-10 1:02 99% ` Karl-Johan Alm
2019-03-11 16:01 99% [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB Alistair Mann
2019-03-12 4:14 99% ` ZmnSCPxj
2019-03-17 16:11 99% ` Alistair Mann
2019-03-18 4:22 99% ` ZmnSCPxj
2019-03-17 20:27 99% ` Alistair Mann
2019-03-19 0:22 99% ` ZmnSCPxj
2019-03-13 1:41 99% [bitcoin-dev] More thoughts on NOINPUT safety Anthony Towns
2019-03-13 6:41 99% ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2019-03-13 11:10 99% ` Anthony Towns
2019-03-14 5:22 99% ` ZmnSCPxj
2019-03-14 7:24 99% ` Anthony Towns
2019-03-14 7:55 99% ` ZmnSCPxj
2019-03-14 12:00 99% ` Christian Decker
2019-03-20 0:22 99% ` Rusty Russell
2019-03-20 3:33 99% ` Rusty Russell
2019-03-20 7:38 99% ` ZmnSCPxj
2019-03-20 8:07 99% ` ZmnSCPxj
2019-03-21 8:37 99% ` Johnson Lau
2019-03-21 9:06 99% ` Anthony Towns
2019-03-21 10:05 99% ` ZmnSCPxj
2019-03-21 11:55 99% ` Anthony Towns
2019-03-22 1:59 99% ` ZmnSCPxj
2019-03-22 2:58 99% ` Anthony Towns
2019-03-22 7:46 99% ` ZmnSCPxj
2019-03-22 4:23 99% ` Johnson Lau
2019-03-13 9:15 99% [bitcoin-dev] Signet Varunram Ganesh
[not found] <CACJ+Xm+-+C43ev_Sk8T-wdm=1nsmHHR_wB4rk+wu9CJvMHS5jw@mail.gmail.com>
2019-03-14 1:17 99% ` Karl-Johan Alm
2019-03-18 10:55 99% [bitcoin-dev] Payjoin privacy with the receiver of the transaction Kenshiro []
2019-03-21 16:52 99% ` rhavar
2019-03-22 10:23 99% ` Kenshiro []
2019-03-22 11:15 99% ` Kenshiro []
2019-03-22 16:05 99% ` ZmnSCPxj
2019-03-18 22:35 99% [bitcoin-dev] Notice: List Infrastructure Migration Warren Togami Jr.
2019-03-19 18:01 99% ` Peter Todd
2019-03-20 6:03 99% ` Omar Shibli
2019-03-22 17:29 99% [bitcoin-dev] BIP proposal - Hashed Time-Locked Collateral Contract transactions Matthew Black
2019-03-22 21:04 99% [bitcoin-dev] New BIP - v2 peer-to-peer message transport protocol (former BIP151) Jonas Schnelli
2019-03-24 13:29 99% ` David A. Harding
2019-03-24 15:38 99% ` David A. Harding
2019-03-24 19:35 99% ` Jonas Schnelli
2019-03-25 6:32 99% ` Eric Voskuil
2019-04-01 0:30 99% [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC Luke Dashjr
2019-04-01 1:04 99% ` Ricardo Filipe
2019-04-01 2:57 99% ` Thomas France
2019-04-01 3:04 99% ` Dave Scotese
2019-04-01 1:11 99% ` Peter Todd
2019-04-01 2:55 99% ` Omar Shibli
2019-04-01 3:02 99% ` ZmnSCPxj
2019-04-01 3:07 99% ` Satoshin
2019-04-01 8:55 99% ` LORD HIS EXCELLENCY JAMES HRMH
2019-04-01 2:54 99% ` Omar Shibli
2019-04-01 11:22 99% ` Melvin Carvalho
2019-04-01 11:50 99% ` Dana L. Coe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox