Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Gregory Maxwell via bitcoin-dev]

On Fri, Dec 22, 2017 at 12:30 AM, Mark Friedenbach via bitcoin-dev
 wrote:
> Every transaction is replace-by-fee capable already. Opt-in replace by fee
> as specified in BIP 125 is a fiction that held sway only while the income
> from fees or fee replacement was so much smaller than subsidy.

The distinction is does a next fee replacement hit the next block 99%
of the time or does it do so with 10% probability each successive
block that the original remains unconfirmed; eventually converging to
the same 99% but only after a non-trivial additional delay.  As a
result it's still useful to flip it on.

I believe electrum has been defaulting to opt-in without any big problems.

There was discussion in the bitcoin core weekly irc meeting today
about defaulting it on.  Some expressed the view that perhaps it
should be left off by default for the RPC because some industrial
users but I'm of the view that those users are both most likely to
want it on and also the most able to see it in the release notes and
change their settings.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Mark Friedenbach via bitcoin-dev]

Every transaction is replace-by-fee capable already. Opt-in replace by fee as 
specified in BIP 125 is a fiction that held sway only while the income from 
fees or fee replacement was so much smaller than subsidy.

> On Dec 21, 2017, at 3:35 PM, Paul Iverson via bitcoin-dev 
>  wrote:
> 
> I agree with Greg.  What is happening is a cause for celebration: it is the 
> manifestation of our long-desired fee market in action.  That people are 
> willing to pay upwards of $100 per transaction shows the huge demand to 
> transact on the world's most secure ledger. This is what success looks like, 
> folks!
> 
> Now that BTC is being phased out as a means of payment nearly everywhere 
> (e.g., Steam dropping BTC as a payment option) (to be replaced with the 
> more-suitable LN when ready), I'd propose that we address the stuck 
> transaction issue by making replace-by-fee (RBF) ubiquitous.  Why not make 
> every transaction RBF by default, and then encourage via outreach and 
> education other wallet developers to do the same?  
> 
> The frustration with BTC today is less so the high-fees (people realize 
> on-chain transactions in a secure decentralized ledger are necessarily 
> costly) but by the feeling of helplessness when their transaction is stuck.  
> Being able to easily bump a transaction's fee for users who are in a hurry 
> would go a long way to improving the user experience.  
> 
> Paul.
> 
> 
> On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev 
>  > wrote:
> Personally, I'm pulling out the champaign that market behaviour is
> indeed producing activity levels that can pay for security without
> inflation, and also producing fee paying backlogs needed to stabilize
> consensus progress as the subsidy declines.
> 
> I'd also personally prefer to pay lower fees-- current levels even
> challenge my old comparison with wire transfer costs-- but we should
> look most strongly at difficult to forge market signals rather than
> just claims-- segwit usage gives us a pretty good indicator since most
> users would get a 50-70% fee reduction without even considering the
> second order effects from increased capacity.
> 
> As Jameson Lopp notes, more can be done for education though-- perhaps
> that market signal isn't efficient yet. But we should get it there.
> 
> But even independently of segwit we can also look at other inefficient
> transaction styles: uncompressed keys, unconfirmed chaining instead of
> send many batching, fee overpayment, etc... and the message there is
> similar.
> 
> I've also seen some evidence that a portion of the current high rate
> congestion is contrived traffic. To the extent that it's true there
> also should be some relief there soon as the funding for that runs
> out, in addition to expected traffic patterns, difficulty changes,
> etc.
> 
> 
> On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev
>  > wrote:
> > I asked adam back at hcpp how the block chain would be secured in the long
> > term, once the reward goes away.  The base idea has always been that fees
> > would replace the block reward.
> >
> > At that time fees were approximately 10% of the block reward, but have now
> > reached 45%, with 50% potentially being crossed soon
> >
> > https://fork.lol/reward/feepct 
> >
> > While this bodes well for the long term security of the coin, I think there
> > is some legitimate concern that the fee per tx is prohibitive for some use
> > cases, at this point in the adoption curve.
> >
> > Observations of segwit adoption show around 10% at this point
> >
> > http://segwit.party/charts/ 
> >
> > Watching the mempool shows that the congestion is at a peak, though it's
> > quite possible this will come down over the long weekend.  I wonder if this
> > is of concern to some.
> >
> > https://dedi.jochen-hoenicke.de/queue/more/#24h 
> > 
> >
> > I thought these data points may be of interest and are mainly FYI.  Though
> > if further discussion is deemed appropriate, it would be interesting to hear
> > thoughts.
> >
> > ___
> > 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 
> 
> 
> 

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Paul Iverson via bitcoin-dev]

I agree with Greg.  What is happening is a cause for celebration: it is the
manifestation of our long-desired fee market in action.  That people are
willing to pay upwards of $100 per transaction shows the huge demand to
transact on the world's most secure ledger. This is what success looks
like, folks!

Now that BTC is being phased out as a means of payment nearly everywhere
(e.g., Steam dropping BTC as a payment option) (to be replaced with the
more-suitable LN when ready), I'd propose that we address the stuck
transaction issue by making replace-by-fee (RBF) ubiquitous.  Why not make
every transaction RBF by default, and then encourage via outreach and
education other wallet developers to do the same?

The frustration with BTC today is less so the high-fees (people realize
on-chain transactions in a secure decentralized ledger are necessarily
costly) but by the feeling of helplessness when their transaction is
stuck.  Being able to easily bump a transaction's fee for users who are in
a hurry would go a long way to improving the user experience.

Paul.


On Thu, Dec 21, 2017 at 2:44 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Personally, I'm pulling out the champaign that market behaviour is
> indeed producing activity levels that can pay for security without
> inflation, and also producing fee paying backlogs needed to stabilize
> consensus progress as the subsidy declines.
>
> I'd also personally prefer to pay lower fees-- current levels even
> challenge my old comparison with wire transfer costs-- but we should
> look most strongly at difficult to forge market signals rather than
> just claims-- segwit usage gives us a pretty good indicator since most
> users would get a 50-70% fee reduction without even considering the
> second order effects from increased capacity.
>
> As Jameson Lopp notes, more can be done for education though-- perhaps
> that market signal isn't efficient yet. But we should get it there.
>
> But even independently of segwit we can also look at other inefficient
> transaction styles: uncompressed keys, unconfirmed chaining instead of
> send many batching, fee overpayment, etc... and the message there is
> similar.
>
> I've also seen some evidence that a portion of the current high rate
> congestion is contrived traffic. To the extent that it's true there
> also should be some relief there soon as the funding for that runs
> out, in addition to expected traffic patterns, difficulty changes,
> etc.
>
>
> On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev
>  wrote:
> > I asked adam back at hcpp how the block chain would be secured in the
> long
> > term, once the reward goes away.  The base idea has always been that fees
> > would replace the block reward.
> >
> > At that time fees were approximately 10% of the block reward, but have
> now
> > reached 45%, with 50% potentially being crossed soon
> >
> > https://fork.lol/reward/feepct
> >
> > While this bodes well for the long term security of the coin, I think
> there
> > is some legitimate concern that the fee per tx is prohibitive for some
> use
> > cases, at this point in the adoption curve.
> >
> > Observations of segwit adoption show around 10% at this point
> >
> > http://segwit.party/charts/
> >
> > Watching the mempool shows that the congestion is at a peak, though it's
> > quite possible this will come down over the long weekend.  I wonder if
> this
> > is of concern to some.
> >
> > https://dedi.jochen-hoenicke.de/queue/more/#24h
> >
> > I thought these data points may be of interest and are mainly FYI.
> Though
> > if further discussion is deemed appropriate, it would be interesting to
> hear
> > thoughts.
> >
> > ___
> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Michel 'ic' Luczak via bitcoin-dev]

Hi,

This is the first time I post on this list.

First of all, Thank you Jameson for the interview you gave yesterday, it’s been 
a model of calm and self-control for all of us.

I deeply believe the high average fees we experience right now are mostly due 
to the miscalculations of most of the hardware (ledger & trezor) wallets (and 
probably software too) on the market.

I personally made transactions at the worst period for the Blockchain with less 
than 40 sat/WU of fees and got confirmed in less than a day.

I think there’s a lot of work to do in used education to make them understand 
that for a low amount of fees they can still get a transaction confirmed and 
that’s the POS’ work to make sure the transaction is legit.

Regards, Michel.

> On 21 Dec 2017, at 23:02, Jameson Lopp via bitcoin-dev 
>  wrote:
> 
> I'd hope that the incentives are in place to encourage high volume senders to 
> be more efficient in their use of block space by batching transactions and 
> implementing SegWit, though this may not be the case for providers that pass 
> transaction fees along to their users.
> 
> We've been trying to be more proactive about outreach regarding efficient use 
> of block space to our own customers at BitGo - when we break down the cost 
> savings of implementing a new technique, it generally helps to hasten their 
> adoption. I suspect that in many cases this is an issue of education - we 
> should be more proactive in calling out inefficient uses of block space.
> 
> Good resources to bookmark and share:
> 
> https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb
>  
> 
> 
> https://blog.zebpay.com/how-zebpay-reduced-bitcoin-transaction-fees-a9e24c788598
>  
> 
> 
> - Jameson
> 
> On Thu, Dec 21, 2017 at 4:30 PM, Melvin Carvalho via bitcoin-dev 
>  > wrote:
> I asked adam back at hcpp how the block chain would be secured in the long 
> term, once the reward goes away.  The base idea has always been that fees 
> would replace the block reward.
> 
> At that time fees were approximately 10% of the block reward, but have now 
> reached 45%, with 50% potentially being crossed soon
> 
> https://fork.lol/reward/feepct 
> 
> While this bodes well for the long term security of the coin, I think there 
> is some legitimate concern that the fee per tx is prohibitive for some use 
> cases, at this point in the adoption curve.
> 
> Observations of segwit adoption show around 10% at this point
> 
> http://segwit.party/charts/ 
> 
> Watching the mempool shows that the congestion is at a peak, though it's 
> quite possible this will come down over the long weekend.  I wonder if this 
> is of concern to some.
> 
> https://dedi.jochen-hoenicke.de/queue/more/#24h 
> 
> 
> I thought these data points may be of interest and are mainly FYI.  Though if 
> further discussion is deemed appropriate, it would be interesting to hear 
> thoughts.
> 
> ___
> 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

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

Re: [bitcoin-dev] BIP for Legacy Sign Verify functions

[Dan Bryant via bitcoin-dev]

Thank you... I've updated.

> New schemes should probably NOT be based on the current one.

Fair enough... I still think there are those who would still like an
existing sign/verify BIP to reference.

On Thu, Dec 21, 2017 at 5:09 PM, Luke Dashjr  wrote:

> On Thursday 21 December 2017 10:26:25 PM Dan Bryant via bitcoin-dev wrote:
> > https://github.com/brianddk/bips/blob/legacysignverify/
> bip-0xyz.mediawiki
>
> It's not even correct... Your first "verify message" step is not possible;
> you
> can't get a public key from an address.
>
> What is actually done, is using the signature + message to perform key
> recovery, to extract the public key of the signer, and then hashing that
> and
> comparing it to the address provided.
>
> > Although this is a well established functionality, it has never been
> > published in a BIP.  My proposal is simply to provide a reference point
> for
> > future expansion of these capabilities into new address schemes.
>
> New schemes should probably NOT be based on the current one.
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP for Legacy Sign Verify functions

[Luke Dashjr via bitcoin-dev]

On Thursday 21 December 2017 10:26:25 PM Dan Bryant via bitcoin-dev wrote:
> https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki

It's not even correct... Your first "verify message" step is not possible; you 
can't get a public key from an address.

What is actually done, is using the signature + message to perform key 
recovery, to extract the public key of the signer, and then hashing that and 
comparing it to the address provided.

> Although this is a well established functionality, it has never been
> published in a BIP.  My proposal is simply to provide a reference point for
> future expansion of these capabilities into new address schemes.

New schemes should probably NOT be based on the current one.

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

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Jim Rogers via bitcoin-dev]

It seems that the exchanges are doing everything that they can to slow things. 
Not only have the major exchanges not implemented segwit yet, but a bigger, 
less addressed issue is that they have start applying transfer limits on crypto 
as well as cash. They do not respond for months to requests to upgrade limits, 
and this results in many transactions instead of one to transfer crypto to cold 
storage devices. 

 

These issues may self-resolve over time, since I think they are all impacted by 
KYC and the explosive growth. 

 

 

From: bitcoin-dev-boun...@lists.linuxfoundation.org 
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Jameson 
Lopp via bitcoin-dev
Sent: Thursday, December 21, 2017 1:03 PM
To: Melvin Carvalho ; Bitcoin Protocol Discussion 

Subject: Re: [bitcoin-dev] Total fees have almost crossed the block reward

 

I'd hope that the incentives are in place to encourage high volume senders to 
be more efficient in their use of block space by batching transactions and 
implementing SegWit, though this may not be the case for providers that pass 
transaction fees along to their users.

 

We've been trying to be more proactive about outreach regarding efficient use 
of block space to our own customers at BitGo - when we break down the cost 
savings of implementing a new technique, it generally helps to hasten their 
adoption. I suspect that in many cases this is an issue of education - we 
should be more proactive in calling out inefficient uses of block space.

 

Good resources to bookmark and share:

 

https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb

 

https://blog.zebpay.com/how-zebpay-reduced-bitcoin-transaction-fees-a9e24c788598

 

- Jameson

 

On Thu, Dec 21, 2017 at 4:30 PM, Melvin Carvalho via bitcoin-dev 
 > wrote:

I asked adam back at hcpp how the block chain would be secured in the long 
term, once the reward goes away.  The base idea has always been that fees would 
replace the block reward.

At that time fees were approximately 10% of the block reward, but have now 
reached 45%, with 50% potentially being crossed soon

https://fork.lol/reward/feepct

While this bodes well for the long term security of the coin, I think there is 
some legitimate concern that the fee per tx is prohibitive for some use cases, 
at this point in the adoption curve.

Observations of segwit adoption show around 10% at this point

http://segwit.party/charts/

Watching the mempool shows that the congestion is at a peak, though it's quite 
possible this will come down over the long weekend.  I wonder if this is of 
concern to some.

https://dedi.jochen-hoenicke.de/queue/more/#24h

I thought these data points may be of interest and are mainly FYI.  Though if 
further discussion is deemed appropriate, it would be interesting to hear 
thoughts.


___
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

[bitcoin-dev] BIP for Legacy Sign Verify functions

[Dan Bryant via bitcoin-dev]

https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki

Although this is a well established functionality, it has never been
published in a BIP.  My proposal is simply to provide a reference point for
future expansion of these capabilities into new address schemes.

Original reference thread [Sign / Verify message against SegWit P2SH
addresses]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sign / Verify message against SegWit P2SH addresses.

[Dan Bryant via bitcoin-dev]

legacy message sign verify BIP to get the ball rolling.

early draft:
https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki

On Tue, Dec 19, 2017 at 3:36 PM, Pavol Rusnak  wrote:

> On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> > I know there are posts, and an issue opened against it, but is there
> > anyone writing a BIP for Sign / Verify message against a SegWit address?
>
> Dan, are you still planning to write this BIP?
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Jameson Lopp via bitcoin-dev]

I'd hope that the incentives are in place to encourage high volume senders
to be more efficient in their use of block space by batching transactions
and implementing SegWit, though this may not be the case for providers that
pass transaction fees along to their users.

We've been trying to be more proactive about outreach regarding efficient
use of block space to our own customers at BitGo - when we break down the
cost savings of implementing a new technique, it generally helps to hasten
their adoption. I suspect that in many cases this is an issue of education
- we should be more proactive in calling out inefficient uses of block
space.

Good resources to bookmark and share:

https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb

https://blog.zebpay.com/how-zebpay-reduced-bitcoin-transaction-fees-a9e24c788598

- Jameson

On Thu, Dec 21, 2017 at 4:30 PM, Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I asked adam back at hcpp how the block chain would be secured in the long
> term, once the reward goes away.  The base idea has always been that fees
> would replace the block reward.
>
> At that time fees were approximately 10% of the block reward, but have now
> reached 45%, with 50% potentially being crossed soon
>
> https://fork.lol/reward/feepct
>
> While this bodes well for the long term security of the coin, I think
> there is some legitimate concern that the fee per tx is prohibitive for
> some use cases, at this point in the adoption curve.
>
> Observations of segwit adoption show around 10% at this point
>
> http://segwit.party/charts/
>
> Watching the mempool shows that the congestion is at a peak, though it's
> quite possible this will come down over the long weekend.  I wonder if this
> is of concern to some.
>
> https://dedi.jochen-hoenicke.de/queue/more/#24h
>
> I thought these data points may be of interest and are mainly FYI.  Though
> if further discussion is deemed appropriate, it would be interesting to
> hear thoughts.
>
> ___
> 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

[bitcoin-dev] Total fees have almost crossed the block reward

[Melvin Carvalho via bitcoin-dev]

I asked adam back at hcpp how the block chain would be secured in the long
term, once the reward goes away.  The base idea has always been that fees
would replace the block reward.

At that time fees were approximately 10% of the block reward, but have now
reached 45%, with 50% potentially being crossed soon

https://fork.lol/reward/feepct

While this bodes well for the long term security of the coin, I think there
is some legitimate concern that the fee per tx is prohibitive for some use
cases, at this point in the adoption curve.

Observations of segwit adoption show around 10% at this point

http://segwit.party/charts/

Watching the mempool shows that the congestion is at a peak, though it's
quite possible this will come down over the long weekend.  I wonder if this
is of concern to some.

https://dedi.jochen-hoenicke.de/queue/more/#24h

I thought these data points may be of interest and are mainly FYI.  Though
if further discussion is deemed appropriate, it would be interesting to
hear thoughts.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sign / Verify message against SegWit P2SH addresses.

[Jason Dreyzehner via bitcoin-dev]

You might be interested in this proposal, which is very similar. The repo
contains a very basic implementation in typescript:
https://github.com/bitauth/bitauth2017/blob/master/bips/0-bitauth.mediawiki

https://github.com/bitauth/bitauth2017/

On Tue, Dec 19, 2017 at 4:59 PM Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For what it’s worth, I think it would be quite easy to do better than the
> implied solution of rejiggering the message signing system to support
> non-P2PKH scripts. Instead, have the signature be an actual bitcoin
> transaction with inputs that have the script being signed. Use the salted
> hash of the message being signed as the FORKID as if this were a spin-off
> with replay protection. This accomplishes three things:
>
> (1) This enables signing by any infrastructure out there — including
> hardware wallets and 2FA signing services — that have enabled support for
> FORKID signing, which is a wide swath of the ecosystem because of Bitcoin
> Cash and Bitcoin Gold.
>
> (2) It generalizes the message signing to allow multi-party signing setups
> as complicated (via sighash, etc.) as those bitcoin transactions allow,
> using existing and future tools based on Partially Signed Bitcoin
> Transactions; and
>
> (3) It unifies a single approach for message signing, proof of reserve
> (where the inputs are actual UTXOs), and off-chain colored coins.
>
> There’s the issue of size efficiency, but for the single-party message
> signing application that can be handled by a BIP that specifies a template
> for constructing the pseudo-transaction and its inputs from a raw script.
>
> Mark
>
> > On Dec 19, 2017, at 1:36 PM, Pavol Rusnak via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> >> I know there are posts, and an issue opened against it, but is there
> >> anyone writing a BIP for Sign / Verify message against a SegWit address?
> >
> > Dan, are you still planning to write this BIP?
> >
> > --
> > Best Regards / S pozdravom,
> >
> > Pavol "stick" Rusnak
> > CTO, SatoshiLabs
> > ___
> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sign / Verify message against SegWit P2SH addresses.

[Mark Friedenbach via bitcoin-dev]

It doesn’t matter what it does under the hood. The api could be the same.

> On Dec 21, 2017, at 3:19 AM, Damian Williamson via bitcoin-dev 
>  wrote:
> 
> In all seriousness, being able to sign a message is an important feature 
> whether it is with Bitcoin Core or, with some other method. It is a good 
> feature and it would be worthwhile IMHO to update it for SegWit addresses. I 
> don't know about renewing it altogether, I like the current simplicity.
> 
> Regards,
> Damian Williamson
> 
> 
> Sometimes I like to sign a message just to verify that is what I have said.
> -
> Bitcoin: 1PMUf9aaQ41M4bgVbCAPVwAeuKvj8CwxJg
> 
> Signature:
> HwJPqyWF0CbdsR7x737HbNIDoRufsrMI5XYQsKZ+MrWCJ6K7imtLY00sTCmSMDigZxRuoxyYZyQUw/lL0m/MV9M=
> 
> (Of course, signed messages will verify better usually with plain text and 
> not HTML interpreted email - need a switch for outlook.com to send plaintext.)
> From: bitcoin-dev-boun...@lists.linuxfoundation.org 
>  on behalf of Mark Friedenbach 
> via bitcoin-dev 
> Sent: Wednesday, 20 December 2017 8:58 AM
> To: Pavol Rusnak; Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] Sign / Verify message against SegWit P2SH 
> addresses.
>  
> For what it’s worth, I think it would be quite easy to do better than the 
> implied solution of rejiggering the message signing system to support 
> non-P2PKH scripts. Instead, have the signature be an actual bitcoin 
> transaction with inputs that have the script being signed. Use the salted 
> hash of the message being signed as the FORKID as if this were a spin-off 
> with replay protection. This accomplishes three things:
> 
> (1) This enables signing by any infrastructure out there — including hardware 
> wallets and 2FA signing services — that have enabled support for FORKID 
> signing, which is a wide swath of the ecosystem because of Bitcoin Cash and 
> Bitcoin Gold.
> 
> (2) It generalizes the message signing to allow multi-party signing setups as 
> complicated (via sighash, etc.) as those bitcoin transactions allow, using 
> existing and future tools based on Partially Signed Bitcoin Transactions; and
> 
> (3) It unifies a single approach for message signing, proof of reserve (where 
> the inputs are actual UTXOs), and off-chain colored coins.
> 
> There’s the issue of size efficiency, but for the single-party message 
> signing application that can be handled by a BIP that specifies a template 
> for constructing the pseudo-transaction and its inputs from a raw script.
> 
> Mark
> 
> > On Dec 19, 2017, at 1:36 PM, Pavol Rusnak via bitcoin-dev 
> >  wrote:
> > 
> > On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> >> I know there are posts, and an issue opened against it, but is there
> >> anyone writing a BIP for Sign / Verify message against a SegWit address?
> > 
> > Dan, are you still planning to write this BIP?
> > 
> > -- 
> > Best Regards / S pozdravom,
> > 
> > Pavol "stick" Rusnak
> > CTO, SatoshiLabs
> > ___
> > 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
> ___
> 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

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Sjors Provoost via bitcoin-dev]

Just to clarify two points:

> The good part is that it does not have to be adopted by exchanges. If popular 
> exchanges do not adopt it, it is trivial to make an adapter service which 
> translate COX to whatever proprietary API of the exchange.

Be sure to elaborate on the difference in trust assumptions between a merchant 
running such an adapter on their own infrastructure vs. trusting a SAAS that 
sits in between the exchange and the merchants infrastructure.

In general adapters would create additional risks to think about, depending on 
how fine-tuned the API key permissions are. E.g. if API keys come with full 
permissions you don’t want to install an adaptor plugin if your shop is hosted 
on wordpress.com. PayPal and Stripe make sure their API keys can’t do too much 
damage in case the merchant shop hosting is compromised.

> > Can this be combined with an invoice mechanism similar to Lightning, e.g. 
> > where the exchange sends a pre-image to the users wallet (relayed via and 
> > retained by the web shop) upon receipt of the funds, which they can then 
> > present to the merchant in case something went wrong. Exchanges might be 
> > happy to support this protocol, but they don’t want the burden of dealing 
> > with user support requests, so having signed invoices could help with that.
> 
> This protocol can be expanded later for lightning trivially, where the call 
> to the address source uri also returns a lightning payment request. (BOLT11)

I didn’t mean adding Lightning support (though that would be cool), I mean 
adding an invoice system to your proposal that is similar to how Lightning 
invoices work. Right now if the customer pays and the merchant has a poorly 
functioning shopping cart system, which I’ve seen more often than not, the 
customer would have to email their transaction id to the merchant, who then 
needs to login to their exchange to check if that address indeed belongs to 
them. But a merchant shouldn’t give all their support staff such access, and 
support staff may not have the right training, or even permission, to assess 
whether a transaction is cleared (“computer says no").

So you’d want some sort of signed message as part of the protocol that says “if 
this transaction ID confirms, this order ID is paid for”.   Although this 
specific example wouldn’t play well with RBF. So maybe “if the confirmed 
balance of this address is >= X, this order ID is paid for”, but then the 
exchange can’t sweep it. So maybe instead you need a callback from the exchange 
to just tell you when it’s (expected to be) confirmed. BitPay offers merchants 
various risk settings for this, so that might be worth looking into.

Sjors


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX)

[Nicolas Dorier via bitcoin-dev]

Thanks a lot for the feedback

> I think this could be quite useful, although I don’t know if it will get
adopted.

The good part is that it does not have to be adopted by exchanges. If
popular exchanges do not adopt it, it is trivial to make an adapter service
which translate COX to whatever proprietary API of the exchange.

Collaboration with the exchange is only needed if the exchange wants to
provide a service for taking the risk of volatility.

> I have personally been integrating BitPay into a website for payments in
BTC and like what you are trying to do.  One of the biggest hurdle’s I see
for merchants to adopt BitCoin today is the transaction fee.

This BIP supports alternatives currencies.

>  Can you refer to the kind of best practices Stripe and PayPal recommend?
Should some additional shared-secret or cookie / macaroon based
authentication be added?

Yes, I must add guidelines (SSL and how to manage the addresses). I don't
think authentication is needed as the merchant is the only one having
access to the source URI. This can be considered as a shared secret.
Even if this secret leaks, no funds are in danger.

> Can you clarify if this integration can run in a browser, or due to
security / privacy constraints must be server-to-server?

Thanks, I need to clarify the scope. But indeed, this is not meant to be
used by a browser, as merchants will not host their payment processors on
their mobile or browser.

> Though it’s important to remain future-proof by being flexible, leaving
the above details to individual implementers is probably going to result in
bad things.

Thanks, I think you are right I should add more recommendations for
implementers.

> What are your thoughts on rate limiting vs. privacy? Should a payment
source never return the same address even if nothing is paid to it?
Otherwise someone could just crawl webshops to create an inventory of
payment addresses. A new address every page reload could be a DDOS vector.
It also wouldn't be compatible with BIP44 because of its gap limit,
although I don’t think that’s a huge problem for exchanges.

You are right, I must introduce a sort of "order id" so that one order map
to exactly one address response.
The DDOS vector will then be on the shoulder of the ecommerce website by
preventing users to create too much orders. (they certainly already do)

> Can this be combined with an invoice mechanism similar to Lightning, e.g.
where the exchange sends a pre-image to the users wallet (relayed via and
retained by the web shop) upon receipt of the funds, which they can then
present to the merchant in case something went wrong. Exchanges might be
happy to support this protocol, but they don’t want the burden of dealing
with user support requests, so having signed invoices could help with that.

This protocol can be expanded later for lightning trivially, where the call
to the address source uri also returns a lightning payment request. (BOLT11)

> Speaking of Bisq, it would be neat if merchants can rely on random peer
to peer counterparties to convert to fiat, so their customer information
and revenue figures aren’t in the hands of a single counter party.
Obviously that’s a can of worms today, but it would be nice if the protocol
was able to support that if one day someone figures out the fraud,
compliance and bookkeeping stuff.

Conversion to fiat always need trust, so we must rule out anonymous
parties. If you want to spread on several trusted party, this can be done
transparently at the payment processor level, and does not requires change
to the protocol.

> Finally, why only exchanges? It could make sense fo shopping cart
software to talk to a Bitcoin wallet that’s hosted somewhere else for
similar reasons. Right now the best these plugins can do is hold on to an
XPUB, and I’ve even seen solutions that just send the customers coins to
their own backend wallet and then forward it.

Because BIP70/XPUB already solves the problem. (Which I already use in
BTCPay)
BIP70 is a pain in the ass to implement and does not provide any benefits,
and it does not define a way for the exchange to communicate a rate
attached to the bitcoin address, nor define a way to communicate to the
payment processor the conditions under which they can bear volatility risk.

I will revisit the BIP based on your feedback.

Nicolas,

On Wed, Dec 20, 2017 at 5:49 PM, Sjors Provoost  wrote:

>
>
> I think this could be quite useful, although I don’t know if it will get
> adopted. If any such small local exchanges want to weigh in on this
> proposal, that would help. Same goes for shopping cart integrators, e.g.
> the folks writing WooCommerce and Shopify plugins.
>
> Consider adding some requirements around the use of SSL and certificate
> pinning. Can you refer to the kind of best practices Stripe and PayPal
> recommend? Should some additional shared-secret or cookie / macaroon based
> authentication be added?
>
> Can you clarify if this integration can