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

[Nicolas Dorier via bitcoin-dev]

Hi everyone,

As some of you know, I am working on a complete open source replacement of
Bitpay for allowing merchant to accept cryptocurrency payments while having
a way to sell automatically.

A crucial, missing part, is fiat conversion. And I figured out a simple
protocol that exchanges (or adapters) can implement to allow any merchant
to cash out BTC in fiat while giving them the freedom to choose their own
payment processor solution.

This also have positive impact on scalability: Before, a merchant would
receive the bitcoin from the customer then would send to the exchange,
resulting in two transactions.
With this specification, it would be one transaction.

Special thanks to anditto and kallewoof for reviewing. I am waiting for
your feedback:

Github link:
https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawiki


  BIP: XXX
  Layer: Applications
  Title: Crypto Open Exchange Protocol (COX)
  Author: Nicolas Dorier 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
  Status: Draft
  Type: Standards Track
  Created: 2017-12-20
  License: BSD-3-Clause
   CC0-1.0


==Abstract==

A simple protocol for decoupling payment processor solutions from exchanges.

==Motivation==

Cryptocurrency merchant adoption is mainly driven by availability, ease of
use and means of acceptance.
We call such solutions `Payment Processors`.

Until now, payment processing solutions fall into one of the two following
categories:

# Self-hosted with the customer paying in cryptocurrency and the merchant
receiving it directly.
# Centralized, coupled with an exchange feature, with the customer paying
in cryptocurrency to the merchant, and receiving fiat or cryptocurrency on
his exchange account.

The self-hosted solution has two issues:

# The merchant becomes vulnerable to the wild volatility of
cryptocurrencies.
# It is wasteful of blockchain space, if the merchant does not pay
suppliers in crypto, as they need a second transaction to change to his
exchange,

The centralized solution has two issues:

# It locks-in the merchant to a particular payment processor whose
intentions might not be aligned (e.g. Bitpay who tried to redefine Bitcoin
as being a different chain, without merchant approval)
# It has to deal with local regulations (e.g. Bitpay does not provide fiat
CAD to canadian merchants)

The goal of this BIP is to specify a simple protocol which makes possible
decoupling of payment processors from exchanges.

We believe this BIP will gather a lot of interest among local exchanges
which do not have the resources to develop their own payment solutions.

Their customers can decide which payment processor solution they prefer,
while the exchanges give them a way to protect against cryptocurrency
volatility.

==Summary==

The merchant log in to its exchange website, go into "Address sources"
section of it, an click on "Create a new address source".

The address source creation wizard asks him questions about what to do when
crypto currency is sent to this the address source. (Cryptocurrency, Market
sell order, limit order of past day average etc...)

The merchant receives an "address source URI" which they can input inside
the payment processor.

An exchange compatible with the Crypto Open Exchange Protocol would reply
to any HTTP POST request to this  "address source URI" returning the
following information (more details in the Specification part)

# A deposit address for accepting a payment
# The current rate
# Optional: If the exchange is willing to take the risk of rate
fluctuation, until when this rate is guaranteed and under which conditions.



===Interaction===

* Manny (the "merchant") wants to accept Bitcoin payments on his e-commerce
website.
* Manny chooses the payment processor "PROCCO" which has a powerful plugin
for his e-commerce website.
* Manny is based in Canada and already has an account on the exchange
"MYCOIN" which supports the Crypto Open Exchange Protocol.
* Manny connects to the exchange website, and creates a new address source.
* In the configuration screen of the address source, for each payment sent
to this address source, Manny decides to keep 30% in Bitcoin and place a
market sell order for the remaining 70% of the amount.
* "MYCOIN" creates the address source, and gives the "address source URI"
to the merchant. (e.g. https://example.com/addresssources/abd29ddn92)
* Manny copies the address source URI and goes inside "PROCCO" settings,
and configures his store to use this address source URI.

Now a customer, Carol, wants to order a brand new phone for 0.01 BTC on
Manny's store and decides to pay in Bitcoin.

* The E-Commerce website plugin requests the creation of an invoice from
PROCCO.
* PROCCO queries the "address source URI" and retrieves the rate, the
expiration of this rate and conditions.
* PROCCO can now show the Bitcoin Payment Checkout page.
* Carla pays.
* PROCCO marks the payment as 

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

[Mark Friedenbach via bitcoin-dev]

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

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

[Pavol Rusnak via bitcoin-dev]

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] Clarification about SegWit transaction size and bech32

[Alberto De Luigi via bitcoin-dev]

Thank you Gregory,
so SegWit P2PHK have strictly less weight than P2WPKH, 3 fewer bytes (-1%) no 
matter the n. of outputs.
Instead, Segwit P2WPKH/P2SH cost 11% more than P2PHK, while compared to P2SH, 
SegWit transaction P2WSH and P2WSH/P2SH cost respectively 6% and 19% more 
space. And it can be much more if outputs are, as you say, an absurd number, 
which is the case of tx made by an exchange.

I understand there is a rationale for the overhead size. It's transparent from 
here: https://bitcoincore.org/en/2016/01/26/segwit-benefits
I don't understand your two points, which are new to me, maybe I lack of some 
technical details?
1) outputs were previously undercosted
2) a great many TXOUTs are putting a serious long term cost on the network

But independently from that, my point is: does an exchange have economic 
incentives in adopting SegWit? I think the answer is no.
Does SegWit help making bitcoin more scalable? Not until Lightning Network, 
since transactions just take up more space. 

Instead, if bech32 really makes possible to save up to 22% of space (I still 
need confirmation), it would help a lot in scaling bitcoin. We just need to 
coordinate the network to bring it on most of the wallets. Since using bech32 
everybody will benefit and pay smaller fees there are economic incentives in 
implementing it. For this reason I think an agreement about a transition to 
bech32 as default address for every wallet is a highly realistic scenario, 
while widespread SegWit adoption without bech32 is not, in my opinion, because 
poor or negative economic incentives (including also the costs companies 
sustain for development).

I know an agreement is a political matter, should it be discussed elsewhere?
I think a network upgrade to bech32 addresses requires the same coordination of 
a hard fork, but.. just a hint: bech32 helps saving space, in the meanwhile we 
reach widespread segwit adoption. If transition is achieved, we would have 
blocks of 2mb fulfilled with transactions using bech32, which have a 20% 
discount. Compared to the current situation of 1.05mb average blocks and 400k 
tx daily, we could have about 2mb blocks and 960k tx daily...

Thank you,
Alberto De Luigi
(.com)



-Original Message-
From: Gregory Maxwell [mailto:gmaxw...@gmail.com]
Sent: martedì 19 dicembre 2017 09:06
To: m...@albertodeluigi.com; Bitcoin Protocol Discussion

Cc: Mark Friedenbach 
Subject: Re: [bitcoin-dev] Clarification about SegWit transaction size and
bech32

Alberto,

You are confused about the impact.  Ordinary P2WPKH have strictly less
weight no matter how many outputs you have.  P2WSH in very output heavy
transactions can be more, but this is inherent in the upgrade from
inadequate 80-bit security to 128-bit security, an intentional
change: because outputs were previously _radically_ undercosted in the
system and any party making a great many new TXOUTs are putting a serious
long term cost on the network,  and in any case it's except for transactions
that make an absurd number of P2WSH outputs at once the difference is pretty
small.

On Mon, Dec 18, 2017 at 10:19 PM, Alberto De Luigi via bitcoin-dev
 wrote:
> Mark,
> suppose I am an average user. Give me a bech32 address and ask me to
> send a few coins there. I am 100% sure you will never receive my
> coins. I will call you back saying: "Mark, sorry, I tried with three
> different wallets, but it seems what you gave me is not a bitcoin
> address!"
>
> My point is: we want SegWit is used and implemented more and more by
> the community. But if besides malleability fix, the main effect of sw
> adoption is this:
>
> 1) The blockahin is heavier (transactions require more space)
> 2) the fee is smaller only for some kind of tx
> 3) the transactions of the exchanges, which aggregate outputs, would
> be heavier and pay a higher fee using segwit!
>
> then how can we expect people, exchanges and services to adopt segwit?
>
> Thank you,
> Alberto De Luigi
>
>
>
>
> Il 2017-12-18 23:03 Mark Friedenbach ha scritto:
>>
>> Why would I send you coins to anything other than the address you
>> provided to me? If you send me a bech32 address I use the native
>> segwit scripts. If you send me an old address, I do what it specifies
>> instead. The recipient has control over what type of script the
>> payment is sent to, without any ambiguity.
>>
>>> On Dec 18, 2017, at 1:41 PM, m...@albertodeluigi.com wrote:
>>>
>>> Hi Mark,
>>> thank you. I understand your point, but despite what we define as a
>>> fork, when a software uses a particular address, it becomes part of
>>> the rules of that software. If another software doesn't recognize
>>> that address as a bitcoin address, then the rules it enforces aren't
>>> compatible with the behaviour of the first software. If you send me
>>> your bitcoins, I can't receive it, exactly like if it was in another
>>> chain. This happens 

Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?

[Hampus Sjöberg via bitcoin-dev]

Most solutions only work with a single Bitcoin address (terrible for
privacy, and also potentially a security risk) or xpubkey (also terrible
for privacy).

I think the best solution here is some kind of store-and-forward server,
where you trade a little bit of privacy (to the server, that is), but get
the convenience of using (for example) an email address as the account.
I like for example BIP75 for this, and I hope the community can work
towards a solution like this. This could potentially work good with LN as
well. https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki

Hampus

2017-12-19 10:05 GMT+01:00 Damian Williamson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> There is no reason it should not be easily possible to develop a Bitcoin
> wallet that has an integrated name to address mapping feature. It might be
> a good idea for a software product, it could even be based on Bitcoin Core.
> There is no specific reason that people wanting that sort of feature could
> not use it. In fact, you could map names, strings, email addresses, it
> could be very flexible.
>
>
> Relying on an additional service like DNS which is flexible enough to
> handle the job, does introduce an additional availability risk. There is no
> additional privacy risk provided each mapped name or address is only used
> once to send/receive one payment unless you directly use something
> personally identifiable like an email address which could be used to map
> bitcoin addresses to an individual. Personally, I am not concerned about
> privacy so much but can understand that some highly value their privacy.
>
>
> If you get it right it will be a service better than namecoin transacting
> in Bitcoin. If you think that is valuable, go for it.
>
>
> Regards,
>
> Damian Williamson
>
>
> --
> *From:* bitcoin-dev-boun...@lists.linuxfoundation.org <
> bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev 
> *Sent:* Monday, 18 December 2017 10:26 PM
> *To:* Douglas Roark; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet
> addresses?
>
> Have you thought about combining this with BIP-47? You could associate
> payment codes with email via DNS.
>
> It would be nice if there was a way to get rid of the announcement
> transaction in BIP-47 and establish a shared secret out of bound. That
> would simplify things, at the cost of an additional burden of storing more
> than an HD seed to recover a wallet that received funds this way.
>
> Perhaps the sender can email to the recipient the information they need to
> retrieve the funds. The (first) transaction could have a time locked refund
> in it, in case the payment code is stale.
>
> Sjors
>
> > Op 1 dec. 2017, om 04:08 heeft Douglas Roark via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
> >
> > On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
> >> I was wondering in terms of mass adoption, instead of long wallet
> >> addresses, maybe there should be a DNS-like decentralized mapping
> >> service to provide a user@crypto address?
> >
> > A few years ago, I was part of an effort with Armory and Verisign to
> > make something similar to what you're describing.
> > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
> > find the one and only official draft. I worked on a follow-up with some
> > changes and some nice appendices, explaining some nice tricks one could
> > use to make payment management flexible. For various reasons, it never
> > got published. I think it's an interesting draft that could be turned
> > into something useful. Among other things, it was able to leverage BIP32
> > and allow payment requests to be generated that automatically pointed
> > payees to the correct branch. DNSSEC may have some issues but, AFAIK,
> > it's as the easiest way to bootstrap identity to a common, reasonably
> > secure standard.
> >
> > --
> > ---
> > Douglas Roark
> > Cryptocurrency, network security, travel, and art.
> > https://onename.com/droark
> > joro...@vt.edu
> > PGP key ID: 26623924
> >
> > ___
> > 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] A DNS-like decentralized mapping for wallet addresses?

[Damian Williamson via bitcoin-dev]

There is no reason it should not be easily possible to develop a Bitcoin wallet 
that has an integrated name to address mapping feature. It might be a good idea 
for a software product, it could even be based on Bitcoin Core. There is no 
specific reason that people wanting that sort of feature could not use it. In 
fact, you could map names, strings, email addresses, it could be very flexible.


Relying on an additional service like DNS which is flexible enough to handle 
the job, does introduce an additional availability risk. There is no additional 
privacy risk provided each mapped name or address is only used once to 
send/receive one payment unless you directly use something personally 
identifiable like an email address which could be used to map bitcoin addresses 
to an individual. Personally, I am not concerned about privacy so much but can 
understand that some highly value their privacy.


If you get it right it will be a service better than namecoin transacting in 
Bitcoin. If you think that is valuable, go for it.


Regards,

Damian Williamson



From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Sjors Provoost via 
bitcoin-dev 
Sent: Monday, 18 December 2017 10:26 PM
To: Douglas Roark; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet 
addresses?

Have you thought about combining this with BIP-47? You could associate payment 
codes with email via DNS.

It would be nice if there was a way to get rid of the announcement transaction 
in BIP-47 and establish a shared secret out of bound. That would simplify 
things, at the cost of an additional burden of storing more than an HD seed to 
recover a wallet that received funds this way.

Perhaps the sender can email to the recipient the information they need to 
retrieve the funds. The (first) transaction could have a time locked refund in 
it, in case the payment code is stale.

Sjors

> Op 1 dec. 2017, om 04:08 heeft Douglas Roark via bitcoin-dev 
>  het volgende geschreven:
>
> On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
>> I was wondering in terms of mass adoption, instead of long wallet
>> addresses, maybe there should be a DNS-like decentralized mapping
>> service to provide a user@crypto address?
>
> A few years ago, I was part of an effort with Armory and Verisign to
> make something similar to what you're describing.
> https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
> find the one and only official draft. I worked on a follow-up with some
> changes and some nice appendices, explaining some nice tricks one could
> use to make payment management flexible. For various reasons, it never
> got published. I think it's an interesting draft that could be turned
> into something useful. Among other things, it was able to leverage BIP32
> and allow payment requests to be generated that automatically pointed
> payees to the correct branch. DNSSEC may have some issues but, AFAIK,
> it's as the easiest way to bootstrap identity to a common, reasonably
> secure standard.
>
> --
> ---
> Douglas Roark
> Cryptocurrency, network security, travel, and art.
> https://onename.com/droark
> joro...@vt.edu
> PGP key ID: 26623924
>
> ___
> 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 Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

[Damian Williamson via bitcoin-dev]

Thank you for your constructive feedback. I now see that the proposal 
introduces a potential issue.


>Finally in terms of the broad goal, having block size based on the number of 
>transactions is NOT something desirable in the first place, even if it did 
>work. That’s effectively the same as an infinite block size since anyone 
>anywhere can create transactions in the mempool at no cost.


Do you have any critical suggestion as to how transaction bandwidth limit could 
be addressed, it will eventually become an issue if nothing is changed 
regardless of how high fees go?


Regards,

Damian Williamson




From: Mark Friedenbach 
Sent: Tuesday, 19 December 2017 3:08 AM
To: Damian Williamson
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction 
Priority For Ordering Transactions In Blocks

Damian, you seem to be misunderstanding that either

(1) the strong form of your proposal requires validating the commitment to the 
mempool properties, in which case the mempool becomes consensus critical (an 
impossible requirement); or

(2) in the weak form where the current block is dependent on the commitment in 
the last block only it is becomes a miner-selected field they can freely 
parameterize with no repercussions for setting values totally independent of 
the actual mempool.

If you want to make the block size dependent on the properties of the mempool 
in a consensus critical way, flex cap achieves this. If you want to make the 
contents or properties of the mempool known to well-connected nodes, weak 
blocks achieves that. But you can’t stick the mempool in consensus because it 
fundamentally is not something the nodes have consensus over. That’s a 
chicken-and-the-egg assumption.

Finally in terms of the broad goal, having block size based on the number of 
transactions is NOT something desirable in the first place, even if it did 
work. That’s effectively the same as an infinite block size since anyone 
anywhere can create transactions in the mempool at no cost.

On Dec 16, 2017, at 8:14 PM, Damian Williamson via bitcoin-dev 
>
 wrote:

I do not know why people make the leap that the proposal requires a consensus 
on the transaction pool. It does not.

It may be helpful to have the discussion from the previous thread linked here.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015370.html

Where I speak of validating that a block conforms to the broadcast next block 
size, I do not propose validating the number broadcast for the next block size 
itself, only that the next generated block is that size.

Regards,
Damian Williamson



From: Damian Williamson >
Sent: Saturday, 16 December 2017 7:59 AM
To: Rhavar
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction 
Priority For Ordering Transactions In Blocks

There are really two separate problems to solve.


  1.  How does Bitcoin scale with fixed block size?
  2.  How do we ensure that all valid transactions are eventually included in 
the blockchain?

Those are the two issues that the proposal attempts to address. It makes sense 
to resolve these two problems together. Using the proposed system for variable 
block sizes would solve the first problem but there would still be a whole 
bunch of never confirming transactions. I am not sure how to reliably solve the 
second problem at scale without first solving the first.

>* Every node has a (potentially) different mempool, you can't use it to decide 
>consensus values like the max block size.

I do not suggest a consensus. Depending on which node solves a block the value 
for next block size will be different. The consensus would be that blocks will 
adhere to the next block size value transmitted with the current block. It is 
easy to verify that the consensus is being adhered to once in place.

>* Increasing the entropy in a block to make it more unpredictable doesn't 
>really make sense.

Not a necessary function, just an effect of using a probability-based 
distribution.

>* Bitcoin should be roughly incentive compatible. Your proposal explicits asks 
>miners to ignore their best interests, and confirm transactions by "priority". 
> What are you going to do if a "malicious" miner decides to go after their 
>profits and order by what makes them the most money. Add "ordered by priority" 
>as a consensus requirement? And even if you miners can still sort their 
>mempool by fee, and then order the top 1MB by priority.

I entirely agree with your sentiment that Bitcoin must be incentive compatible. 
It is necessary.

It is in only miners immediate interest to make the most profitable block from 
the available transaction pool. As with so many other things, it is necessary 
to partially 

[bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

[Damian Williamson via bitcoin-dev]

Thank you for your constructive feedback. I now see that the proposal 
introduces a potential issue.


It is difficult to define then, what is a valid transaction? Clearly, my 
definition was insufficient.


Regards,

Damian Williamson



From: Chris Riley 
Sent: Monday, 18 December 2017 11:09 PM
To: Damian Williamson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction 
Priority For Ordering Transactions In Blocks

Regarding "problem" #2 where you say "How do we ensure that all valid 
transactions are eventually included in the blockchain?":  I do not believe 
that all people would (a) agree this is a problem or (b) that we do want to 
*ENSURE* that *ALL* valid transactions are eventually included in the 
blockchain.  There are many *valid* transactions that oftentimes miners do not 
(and should not) wish to require be confirmed and included in the blockchain.  
Spam transactions for example can be valid, but used to attack bitcoin by using 
no or low fee.  Any valid transaction MAY be included by a miner, but requiring 
it in some fashion at this point would open the network to other attack 
vectors.  Perhaps you meant it a different way.


On Fri, Dec 15, 2017 at 3:59 PM, Damian Williamson via bitcoin-dev 
>
 wrote:
>
> There are really two separate problems to solve.
>
>
> How does Bitcoin scale with fixed block size?
> How do we ensure that all valid transactions are eventually included in the 
> blockchain?
>
>
> Those are the two issues that the proposal attempts to address. It makes 
> sense to resolve these two problems together. Using the proposed system for 
> variable block sizes would solve the first problem but there would still be a 
> whole bunch of never confirming transactions. I am not sure how to reliably 
> solve the second problem at scale without first solving the first.
>
>
> >* Every node has a (potentially) different mempool, you can't use it to 
> >decide consensus values like the max block size.
>
>
> I do not suggest a consensus. Depending on which node solves a block the 
> value for next block size will be different. The consensus would be that 
> blocks will adhere to the next block size value transmitted with the current 
> block. It is easy to verify that the consensus is being adhered to once in 
> place.
>
> >* Increasing the entropy in a block to make it more unpredictable doesn't 
> >really make sense.
>
> Not a necessary function, just an effect of using a probability-based 
> distribution.
>
> >* Bitcoin should be roughly incentive compatible. Your proposal explicits 
> >asks miners to ignore their best interests, and confirm transactions by 
> >"priority".  What are you going to do if a "malicious" miner decides to go 
> >after their profits and order by what makes them the most money. Add 
> >"ordered by priority" as a consensus requirement? And even if you miners can 
> >still sort their mempool by fee, and then order the top 1MB by priority.
>
> I entirely agree with your sentiment that Bitcoin must be incentive 
> compatible. It is necessary.
>
> It is in only miners immediate interest to make the most profitable block 
> from the available transaction pool. As with so many other things, it is 
> necessary to partially ignore short-term gain for long-term benefit. It is in 
> miners and everybody's long-term interest to have a reliable transaction 
> service. A busy transaction service that confirms lots of transactions per 
> hour will become more profitable as demand increases and more users are 
> prepared to pay for priority. As it is there is currently no way to fully 
> scale because of the transaction bandwidth limit and that is problematic. If 
> all valid transactions must eventually confirm then there must be a way to 
> resolve that problem.
>
> Bitcoin deliberately removes traditional scale by ensuring blocks take ten 
> minutes on average to solve, an ingenious idea and, incentive compatible but, 
> fixed block sizes leaves us with a problem to solve when we want to scale.
>
> >If you could find a good solution that would allow you to know if miners 
> >were following your rule or not (and thus ignore it if it doesn't) then you 
> >wouldn't even need bitcoin in the first place.
>
> I am confident that the math to verify blocks based on the proposal can be 
> developed (and I think it will not be too complex for a mathematician with 
> the relevant experience), however, I am nowhere near experienced enough with 
> probability and statistical analysis to do it. Yes, if Bitcoin doesn't then 
> it might make another great opportunity for an altcoin but I am not even 
> nearly interested in promoting any altcoins.
>
>
> If not the proposal that I have put forward, then, hopefully, someone can 
> come up with a better solution. The important thing is that the issues are